If your OpenSSO deployment architecture includes a reverse proxy server, you have the option of protecting the content servers by installing a policy agent on the proxy itself, or installing multiple policy agents on the content servers behind the reverse proxy server. The choice is dependent on the relative uniformity or variability of the hosted/protected content and the access-denied URLs.
NOTE: A reverse proxy server or a load balancer with a reverse proxy feature is usually installed between the outer firewall and the inner firewall - in the demilitarized zone (DMZ) between the internet and the secure intranet.
Using a Single Agent
When there is a uniformity in the configuration of the content servers in the back-end (including access denied URLs, application logout URLs, profile, session and response attributes, and the web container type), a single policy agent for the reverse proxy server would be the efficient way of protecting the content. The following diagram illustrates this.
Regardless of the number of content servers being fronted by the reverse proxy, only one agent is installed on the reverse proxy machine. The footprint of this configuration is less cost (fewer agents to maintain) and less memory (a single agent requires less memory to cache). With one agent no communication will occur between the content servers and the OpenSSO server. The policy agent will have back channel communications with the OpenSSO load balancer to update cache entries, perform session validation, and make policy requests but, since the agent is installed on the reverse proxy server and not on the content servers, only the reverse proxy server would communicate with the OpenSSO load balancer. This effectively reduces the number of communication channels which would result in fewer firewall rules, tighter control over server-to-server communications, and a higher level of security.
Using Multiple Agents
When a number of content servers use different types of web containers or each content server has different access denied URLs, agent profiles, session and response attributes, and application logout URLs, the only choice is to install multiple policy agents. Each agent will have its own customized agent profile.
Unlike in the case of the single reverse proxy server policy agent where the same session identifier is used to access many applications protected by the agent, multiple policy agents do not use the same session identifier (when the agents are configured in cookie hijacking prevention mode). With multiple agents, it is now easy to customize agent properties per content server; for example, customize profile attributes to be fetched, session attributes to be fetched, response attributes to be added to the header, URL of the access denied page, customized application error pages, and application logout URLs. (By customizing each application's logout URL, it is possible to perform cleanup tasks (destroying the user's session or resetting cookies) per application.
See the following links for more information.
Appropos to Dennis's announcement of the Entitlements Service source code being moved into the OpenSSO workspace, here's some information about the developing OpenSSO Entitlements Service.
The Entitlements Service is an authorization and policy component developed for inclusion in the soon-to-be-released OpenSSO Express 8. The user interface provides an easy-to-follow process to define rules for controlling access to applications and web resources. You can create fine-grained policies, and referrals (to assign policy creation based on an OpenSSO realm hierarchy), using these work flows.
The Entitlements Service is being developed in tandem with a new beta OpenSSO administration console. The OpenSSO Enterprise Policy Service, used for more coarse-grained policy implementation, is still available using the standard OpenSSO administration console. See The New OpenSSO Console Rip-Off.
From a high level a service used to create and manage access to web resources consists of the following:
A policy administration point (PAP) that comprises the interfaces used to create, read, update and delete the policies.
A policy evaluation engine or policy decision point (PDP) that, acting as a policy information point (PIP), is used to query permissions and privileges in order to obtain policy decisions. It gets identity attributes and applicable policies, evaluates the information, and returns the latter with a policy decision to be used for enforcement.
A policy enforcement point (PEP) is an agent, installed on the same machine as the resource, that protects it from unauthorized access.
A user data store for storing and obtaining identity data.
A policy data store for storing policies and the service's configuration attributes, and obtaining said data. (OpenSSO embeds OpenDS for its configuration data store. This configuration data store is used to store Entitlements Service data.)
Different types of resources can be protected by the Entitlements Service. By selecting a general application and adding a more specific resource with applicable subjects and conditions, a policy can be created to define authorization using the new beta console administration interface.
An application (term as used in the Entitlements Service) consolidates meta data for generic resource types that share a common set of actions. The format of a resource's definition, supported actions, conditions and subjects, decision combining algorithms (to resolve conflicting policy results) and other data can be defined as a schema for an application. Examples of applications in the Entitlements Service could be calendars, web resources, or user profiles. The following applications are added by default when deploying opensso.war.
Web Agent defines actions that can be used to create and manage policies that protect HTTP and HTTPS URLs through the use of a policy agent. This is the most common application use case with the following actions.
GET has these operations.
Allow: Enables access to the resource defined in the Rule.
Deny: Denies access to the resource defined in the Rule.
POST has these operations.
Allow: Enables access to the resource defined in the Rule.
Deny: Denies access to the resource defined in the Rule.
Liberty Personal Profile allows administrators to create and manage policies corresponding to actions that can be performed on identity attributes in a personal profile service defined by the Liberty Alliance Project specifications; for example, the OpenSSO implementation of the Liberty Personal Profile Service.
MODIFY has these operations.
Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource in order to modify it.
Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to modify a value on a resource.
Allow: Enables access to the resource defined in the Rule in order to modify an attribute value.
Deny: Denies access to the resource defined in the Rule therefore modification is disallowed.
QUERY has these operations.
Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource.
Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to query a resource.
Allow: Enables access to the resource defined in the Rule in order to query the resource.
Deny: Denies access to the resource defined in the Rule therefore the query is disallowed.
Discovery Service allows administrators to create and manage policies corresponding to actions that can dynamically determine a web services provider (WSP) registered for a particular principal.
LOOKUP: Allow or Deny access to search the discovery service.
UPDATE: Allow or Deny access to modify data in the discovery service.
A resource is an object on which you can perform an operation or an action. The policy is specifically configured to protect this object. A resource is a string; it could be a URL, a web service, a bank account, or graphical user interface controls (buttons, text fields and the like). Examples could be MyCalendar or other portal type services (located with URLs), a bank account, or a Submit button on a text form.
More information on the Entitlements Service will be forthcoming; these definitions should help you get started, in a small way, by following the inline help developed for the Entitlements Service GUI. But first - enjoy Tracey Ullman singing Breakaway into her hairbrush.
Here are some words on storing authentication information in an OpenSSO session and retrieving it. It assumes that the authentication module extends AMLoginModule and the information is to be shared with a post authentication plug-in.
If the size of the information is small, you can store it in the SSOToken. If the information is security sensitive and not to be readable by the Client SDK, you could encrypt it before setting it in the SSOToken. (Prefixing the property name with am.protected. defines it as NOT readable by the Client SDK.)
After you put the required information from the authentication module into the module principal class, implement the com.sun.identity.authentication.service.AuthenticationPrincipalDataRetriever interface. It has the following method to get the module principal from authSubject, retrieve the required data, and return that data as a Map (key/value pairs).
\* Returns the attribute map from the required Authentication module
\* Principal, to be set in the SSOToken.
\* @param authSubject Authenticated user Subject.
\* @return the Attribute Map.
Map getAttrMapForAuthenticationModule(Subject authSubject);
The Authentication Service will store this Map in the authenticated SSOToken. A post authentication plug-in can retrieve this data from the SSOToken later. You will need to set your implementation class as a value of the com.sun.identity.authentication.principalDataRetriever property in the OpenSSO configuration data store.
Now here is Zooey Deschanel and M. Ward, plugged in as She & Him. Why Do You Let Me Stay Here? is from their album, Volume 1. I love M (especially his album Transistor Radio), love Zooey (especially as an actress in the ScyFy take on Oz called Tin Man) and also Zooey's sis, Emily (especially as the femme lead on Bones). The video is quirky and endearing and bloody.
Policy agents deployed to web containers and web proxy servers protect content from unauthorized intrusions. Access to this content (services, for example) are controlled through policies configured with OpenSSO. Here is a description of the interactions that occur when a policy agent interacts with OpenSSO.
A policy agent intercepts the user's request and validates any authentication credentials contained within it. If the existing authentication level is insufficient, the OpenSSO Authentication Service will present a login page for an authentication upgrade. The login page prompts the user for the credentials appropriate to the configured module.
The Authentication Service verifies that the user credentials are valid. For example, the LDAP authentication module verifies that the user name and password are the same as those stored in the LDAP identity data store. If other authentication modules are passed to the user (such as RADIUS or Certificate), the credentials are verified with the appropriately configured identity data store.
Assuming the user's credentials are properly authenticated, the policy agent examines the policies assigned to the user.
Based on the aggregate of the user's configured policies, the individual is either allowed or denied access to the resource.
NOTE: In this scenario, if the user attempts access to a web resource without authentication credentials, the agent redirects the user to the login page of the default authentication module. (Even if the resource is protected by a different authentication module, the user must first authenticate using the default authentication module.)
Because some customers require a scenario in which the user authenticates against a particular module based on the resource being accessed, the Gateway servlet provides resource-based authentication; there is no need for the user to authenticate to the default authentication module to access the protected web resource. When using the Gateway servlet:
A web resource can not be defined in more than one policy. For example, if abc.html is defined in a policy definition as requiring LDAP authentication, abc.html can not be defined in a second policy definition as requiring Certificate authentication.
You can use the level and scheme conditions only when defining policies that the servlet will examine.
Additionally, the Gateway servlet does not work across internet domains. Use the following list to configure your deployment to use the Gateway Servlet.
Go to the installation directory for the agent protecting the resource on the web container host machine. For example, on Application Server, change to AppSvr-Directory/agents/j2ee_agents/appserver_v9_agent/Agent_001/config/.
Change the value for com.sun.am.policy.am.loginURL from http://machine-name.domain:port/opensso/UI/Login to http://machine-name.domain:port/opensso/gateway in OpenSSOAgentBootstrap.properties. It is the only change to the policy agent configuration.
Testing the Servlet
After these configurations, the test results are:
Access to resource A is permitted only after successful LDAP authentication.
Access to resource B is permitted only after successful Certificate-based authentication.
Access to resource C is permitted only after both successful LDAP and Certificate-based authentication.
Now that you've configured and tested resource-based authentication, the Shangri-Las are gonna give you a great big kiss with Give Him a Great Big Kiss. I was reminded of this song when it was used in a movie I saw this weekend called Stonewall, an account of the Stonewall riots of 1969. Worth checking out!
The current Access Manager 7.1 and the future Federated Access Manager (FAM) 8.0 (not OpenSSO as it does not bundle native platform binaries) can be configured to process authentication requests against Unix user IDs and passwords known to the Solaris or Linux system on which it is installed. The Unix Authentication module makes use of an authentication helper daemon, amunixd, which opens a socket to localhost:58946 in order to listen for Unix authentication requests. It is a separate process from the FAM process. At startup, this daemon listens on a port for configuration information.
Previously documented for Access Manager 7.1 incorrectly, this entry takes the information from the filed bug to rectify that faux-pas. The correct syntax for amunixd is:
amunixd -i #-of-addrs -a ipaddr-1 -a ipaddr-2 ... -a ipaddr-N
In an instance of Federated Access Manager deployed in a web container, amunixd can be found in any of the following directories:
And now that you see the correct usage, you can use amunixd or, if you'd like to, use something else - as Bill Withers so eloquently sings in the video below.
Here's a link to an excellent tutorial on getting started with OpenSSO and policy agents.
And now that you're finished, you just might want to loosen up so here is a clip of Pan's People, a group of females who would dance to a song on the BBC-TV music chart show Top of the Pops when the artist wasn't available to sing it live (or Memorex). (Think the Solid Gold dancers for those in the States.) This clip is the troupe dancing to Creedence Clearwater Revival's Green River.
And, of course, there's the even funnier take-off by French and Saunders' Pan's Indeedy People moving to Yellow River - with a long yellow cloth to boot.
Yellow River? Don't take me there.
Hot off the digital press - a new manual has been added to the Access Manager 7.1 set of documentation:
Sun Java System Access Manager Localization Guide
The Localization Guide (published as a Technical Note although the notes I usually read don't run to 26 paginas) describes the organization of localized Access Manager software resource files. It also explains how to add a new language to the list of supported languages and how to customize an existing language's resource files.
In other words, name that language!
Internationalization (numeronym: I18N) refers to the planning and implementation of a software framework for multiple language support. This framework can then be easily adapted for region-specific languages and cultures. You can refer to a product as being internationalized if it has been developed to meet most of the needs of an international community, but not yet customized (see localization) to a specific region. This might include:
Allowing space in user interfaces for translation
Developing with products that support international character sets
Creating graphics and images with text labels that can be translated inexpensively
Using written examples with global meaning
Ensuring data space so that messages can be translated from languages with single-byte character codes (such as English) into languages requiring multiple-byte character codes
Localization (numeronym: L10N) is the process of creating content (input and output data) for a region-specific culture and language.
Globalization (numeronym: G11N) refers to a program or application that is usable across multiple cultures and regions, irrespective of the language and regional differences. Sounds like I18N to me.
Glocalization (oh, brother) is a term that was invented to emphasize that the globalization of a product is more likely to succeed when the product or service is adapted specifically to each locality or culture in which it is marketed. The term combines the words globalization and localization.
For example, this German language video by super-singing sensation ABBA was internationalized when the original English lyrics were written simply for easy translation. It was localized when the lyrics were translated into German, Spanish, French, and Swedish. It was globalized when all versions were released worldwide, simultaneously, and it became a shining example of glocalization (oh, brother) when the song became a HUUGGGEEE hit.
(UPDATE: See Nico's comments for more precise (and certainly less facetious) information on the differences between the -izations.)