test

Sun OpenSSO Enterprise Policy Agent 3.0 User's Guide for Web Agents

Providing Personalization Capabilities

Web agents in Policy Agent 3.0 can personalize page content for users in three distinct ways as described in the following subsections:

Providing Personalization With Session Attributes

Web agents in Policy Agent 3.0 support a feature where a user's session attributes are fetched and set as headers or cookies.

Session attributes are especially effective for transferring information that is dynamic. However, the information transferred only lasts during the current session.

Unlike profile attributes, session attributes are not limited to LDAP attributes retrieved from the user data store. Since session attributes allow non-user profile attributes to be fetched, you can configure the deployment to fetch attributes such as SAML assertion.

The following are examples of session attributes: UserToken, UserId, Principal, AuthType, AuthLevel, sun.am.UniversalIdentifier, MyProperty

A good use case for fetching user session attributes presents itself when a post authentication plug-in is involved. A post authentication plug-in performs some tasks right after user authentication. You can configure a post authentication plug-in to fetch data from an external data repository and then set this data as session attributes for that user. These session attributes can be retrieved by the web container and made available to the application.

The web agent property labeled Session Attribute Fetch Mode (Tab: Application, Name: com.sun.identity.agents.config.session.attribute.fetch.mode) is responsible for fetching session attributes. This property can be configured using OpenSSO Enterprise Console and can be set to one of the following values:

When set to NONE, no session attributes are fetched and the property labeled Session Attribute Map (Tab: Application, Name: com.sun.identity.agents.config.session.attribute.mapping) is ignored.

With the Session Attribute Fetch Mode property set to either HTTP_HEADER or HTTP_COOKIE, the web agent fetches session attributes. Use the Session Attribute Map property to configure attributes that are to be forwarded as HTTP headers or cookies.

This section illustrates how the Session Attribute Fetch Mode property maps session attributes to headers or cookies.

Session attributes are added to an HTTP header following this format:


session_attribute_name|http_header_name[,...]

The value of the attribute being fetched in session is session_attribute_name. This value gets mapped to a header value as follows: http_header_name.

Note –

In most cases, in a destination application where http_header_name appears as a request header, it is prefixed with HTTP_ and the following type of conversion takes place:

Lower case letters

convert to upper case letters.

Hyphen “-”

converts to underscore “_”

"common-name”

as an example, converts to “HTTP_COMMON_NAME.”

Therefore, the Session Attribute Map property would have the following value:

successURL | success-url, contextId | context-id

The session attribute is forwarded as a header or a cookie as determined by the end-user applications on the web container that the web agent is protecting. These applications can be considered the consumers of the forwarded header values. The forwarded information is used for the customization and personalization of web pages. You can also write server side plug-ins to put any user session attribute and define the corresponding attribute name and mapping in the preceding property to retrieve the value.

Providing Personalization With Policy-Based Response Attributes

Header attributes can also be determined by OpenSSO Enterprise policy configurations. With policy-based response attributes you can define attribute-value pairs at each policy.

Policy-based response attributes can improve the deployment process, allow greater flexibility in terms of customization, and provide central and hierarchical control of attribute values.

Web agents set policy-based response attributes as headers or cookies based on configuration. All subjects that match this attribute set obtain this attribute. The web agent property labeled Response Attribute Fetch Mode (Tab: Application, Name: com.sun.identity.agents.config.response.attribute.fetch.mode) controls this functionality:

The default setting for this property is HTTP_HEADER. However, this property can be set to any of the following values:

Attribute mapping is available for response attributes. Therefore, the format of policy information can be mapped to the format of a header or a cookie. The property labeled Response Attribute Map (Tab: Application, Name: com.sun.identity.agents.config.response.attribute.mapping) is used for this type of mapping:

Unlike profile attributes and session attributes, where only the mapped attributes are displayed as headers or cookies, by default, response attributes are set by the agent as headers or cookies based on the setting of the Response Attribute Fetch Mode property.

If a response attribute map is specified, then the corresponding attribute mapped name is fetched from the map and its corresponding value is displayed as either a header or a cookie based on the setting of the above property.

Providing Personalization With User Profile Attributes Globally

Web agents in Policy Agent 3.0 have the ability to forward user profile attribute values via HTTP headers to end-web applications. The user profile attribute values come from the server side of OpenSSO Enterprise. The web agent behaves like a broker to obtain and relay user attribute values to the destination servlets, CGI scripts, or ASP pages. These applications can in turn use the attribute values to personalize page content.

This feature is configurable through two web agent properties. To turn this feature on and off, edit the property labeled Profile Attribute Fetch Mode (Tab: Application, Name: com.sun.identity.agents.config.profile.attribute.fetch.mode)

This property can be set to one of the following values:

When set to NONE, the web agent does not fetch LDAP attributes from the server and ignores the web agent property labeled Profile Attribute Map (Tab: Application, Name: com.sun.identity.agents.config.profile.attribute.mapping). In the other two cases, the web agent fetches the attribute.

To configure the attributes that are to be forwarded in the HTTP headers, use the Profile Attribute Map property.

By default, some LDAP user attribute names and HTTP header names are set to sample values.

To find the appropriate LDAP user attribute names, check the following XML file on the machine where OpenSSO Enterprise is installed: amUser.xml

Note –

The amUser.xml file is available from the directory within which the opensso.war file is deployed. This directory varies according to the web container. The following is an example of a possible location:

OpenSSO-Deploy-base/WEB-INF/classes/amUser.xml

The attributes in this file could be either OpenSSO Enterprise user attributes or OpenSSO Enterprise dynamic attributes. For an explanation of these two types of user attributes, see Sun OpenSSO Enterprise 8.0 Administration Guide

The attribute and HTTP header names that need to be forwarded must be determined by the end-user applications on the deployment container that the web agent is protecting. Basically, these applications are the consumers of the forwarded header values (the forwarded information is used for the customization and personalization of web pages).