Sending Attributes with OAM and IdP

This article covers how OAM can be easily configured to send attributes with the SSO Assertion to the partner during the Federation SSO operation. Those attributes can be set to data retrieved from:

The LDAP user record (attributes, DN…)
The OAM user session (attributes, session count…)
The browser’s HTTP request (cookie, user-agent…)

Note that configuring how SAML NameID values are set is similar to how attributes are configured in OAM.

Attributes in SSO Response

During the Federation SSO operation, the IdP issues a token targeted for the SP which contains three kinds of data:

User information: Data about the user that also allows the SP to identify the user (userID, email address…)
Federation authentication information: How the user was authenticated, when was the user challenged, when does the user’s session expire…
Token related information used to validate the token’s issuance, to ensure that the IdP was the entity which created the token and the token has not yet expired…

The IdP server is able to send information as SAML / OpenID attributes to the SP/RP that can be based on:

Static string
User information:
- User ID
- Identity Store name
- User global unique identifier (guid)
- List of groups assigned to the user
- Value of an attribute stored in the LDAP user record
OAM user’s session:
- Session’s authentication level
- Name of the Authentication Scheme used to challenge the client
- Number of opened sessions for the client
- Date in XML format when the session was created
- Date in XML format when the session expires
- Value of an attribute stored in the OAM session. Note that this attribute might have been stored by another OAM component (for example OAM, OAM/SP…)
Browser’s HTTP request:
- Value of specific HTTP Header
- Value of specific cookie
- Client’s IP address
Combination of the above data as a single attribute: for example, the IdP could be configured to send the value of an attribute based on the UserID, Identity Store Name and the user’s session count.

The above applies for sending attributes in SAML Assertions and OpenID SSO Responses, but it is also valid for setting the SAML NameID value in a SAML Assertion.

Configuring IdP

There are several ways to configure IdP for SAML NameID and SAML/OpenID attributes:

Via the OAM Administration Console
The SAML NameID can be configured by
Indicating the LDAP user attribute to be used
Setting an expression based on LDAP user record, session data, http request data or static data
A SAML/OpenID attribute can be configured by indicating:
- The LDAP user attribute to be used
One of the following user data:
User ID
Identity Store name
User global unique identifier (guid)
List of groups assigned to the user
An OAM session attribute to be used
One of the following session data:
- Session’s authentication level
- Name of the Authentication Scheme used to challenge the client
- Number of opened sessions for the client
- Date in XML format when the session was created
- Date in XML format when the session expires
- An HTTP header to be used
- A cookie to be used
- The browser’s IP address
- A static string
- An expression based on LDAP user record, session data, http request data or static data
- Via a WLST command
- The SAML NameID can be configured by setting an expression based on LDAP user record, session data, http request data or static data
- A SAML/OpenID attribute can be configured by indicating an expression based on LDAP user record, session data, http request data or static data

Expressions

IdP is configured to send attributes/NameID via the use of an expression language similar to the one used in the OAM Authorization Policy Responses. Below is the list of possible elements that can be used to configure a NameID/Attribute.

Type	Data	Expression	Example
User	User ID	$user.userid	$user.userid
	Identity Store Name	$user.id_domain	$user.id_domain
	User GUID	$user.guid	$user.guid
	Comma separated list of groups which the user is member of	$user.groups	$user.groups
	LDAP User Attribute	$user.a?r.ATTR_NAME, with ATTR_NAME being the name of an LDAP User Attribute	$user.a?r.givenname
OAM user's session	Authentication Level	$session.authn_level	$session.authn_level
	Authentication Scheme	$session.authn_scheme	$session.authn_schem
	Session Count	$session.count	$session.count
	Session Creation Date	$session.creation	$session.creation
	Session Expiration Date	$session.expiration	$session.expiration
	Session Attribute	$session.a?r.ATTR_NAME, with ATTR_NAME being the name of an OAM Session Attribute	$session.a?r.fed.part (this session attribute set by OAM/SP when receiving an Assertio from a remote IdP an contains the IdP's partner name; we discuss more about those attributes in a future article)
Browser's HTTP request	HTTP Header value	$request.httpheader.HTTP_HEADER_NAME, with HTTP_HEADER_NAME being the name of an HTTP Header	$user.httpheader.user agent
	Cookie value	$request.cookie.COOKIE_NAME, with COOKIE_NAME being the name of a cookie	$user.cookie.JSESSION
	Client's IP Address	$request.client_ip	$request.client_ip

Note about Always Send

The SP Attribute Profile is used for various protocols, including:

SAML SSO, where the SP cannot request any attributes at runtime
SAML SOAP Attribute exchange, where the SP can request any attributes at runtime
OpenID 2.0, where the SP can request any attributes at runtime

The “Always Send” option seen in the SP Attribute Profile section allows an administrator to instruct IdP to always send the attribute in an Assertion even if it was not requested by the SP partner.

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

Title and Copyright Information

Sending Attributes with OAM and IdP

F61885-01

September 2022