Identity Federation (when configured as an SP) supports the capability to request attributes from an IdP during the Federation process.
To configure for this, map the name of an attribute from the incoming Assertion to a local attribute that will be available in the Access Manager session ($session.attr.fed.attr.ATTR_NAME, for example). An IdP Attribute Mapping Profile contains these mappings.
Similarly, Identity Federation (when configured as an IdP) supports including attributes in an SSO Assertion or allowing SP partners to request that attributes be placed in the SSO Assertion. Configuring Identity Federation as an IdP involves setting up an SP Attribute Mapping profile that defines the name of the attribute in the SSO assertion, the expression to be used to populate the attribute value, and whether or not to always send the attribute in the SSO Assertion.
Note:
The protocol used by the provider must support the feature; for example, OpenID 2.0.
Each partner type (IdP or SP) references an Attribute Mapping Profile that defines the applicable mappings. It indicates how to map attributes for that partner to attributes defined in the Identity Federation server. If a partner does not have an Attribute Mapping Profile defined, the default Attribute Mapping Profile (based on the partner type) will be used. There is a default Attribute Mapping Profile for each provider type.
SP Attribute Mapping Profile: Each SP partner profile will reference an SP Attribute Mapping Profile. A default SP Attribute Mapping Profile will be used if none is configured.
IdP Attribute Mapping Profile: Each IdP partner profile will reference an IdP Attribute Mapping Profile. A default IdP Attribute Mapping Profile will be used if none is configured.
When the Identity Federation instance is configured as an IdP, the SP Attribute Mapping Profile allows the administrator to define which message attributes (included in an incoming or outgoing Identity Federation message) map to which Access Manager session attributes.
An expression is used to find the value for the Access Manager attribute when including it in an Assertion or outgoing message. Table 38-7 documents some sample SP attribute mappings.
Table 38-7 Sample SP Attribute Mappings
| Message Attribute | Access Manager Session Attribute | Always Send |
|---|---|---|
|
|
$user.attr.mail |
|
|
firstname |
$user.attr.givenname |
true |
|
lastname |
$user.attr.sn |
true |
|
authn-level |
$session.authn_level |
true |
Always Send indicates if the attribute should be sent even when it has not been specifically requested. If an attribute has to be included in an outgoing Assertion irrespective of whether it has been requested, Always Send should be set to true. If Always Send is false, this attribute will not be included in the Assertion unless requested. When an SP sends a request, message attributes are looked up and the mapping value for this message attribute is calculated by evaluating its expression.
Note:
The Value expression will use the OAM Policy Expression Language. More than one message attribute can have the same value expression.
When you create or modify an SP partner profile ), the available Attribute Mapping Profiles are displayed in a drop-down list. sp-attribute-profile is the default profile.
See Creating Remote Service Provider Partners.
Select the default or click the green plus sign to create a custom mapping profile. When creating a new Attribute Mapping for an SP partner, the expressions can be embedded in the value string of the attribute. These expressions are then replaced by their runtime values.
Table 38-8 lists the expressions for the attribute mapping values.
Table 38-8 Attribute Mapping Value Expressions
| Value Type | Accepted Values | Expression |
|---|---|---|
|
request |
httpheader.HTTP_HEADER_NAME |
HTTP_HEADER_NAME being the name of an HTTP Header stored as $request.httpheader.HTTP_HEADER_NAME |
|
request |
cookie.COOKIE_NAME |
COOKIE_NAME being the name of a cookie stored as $request.cookie.COOKIE_NAME |
|
request |
client_ip |
stored as $request.client_ip |
|
session |
authn_level |
stored as $session.authn_level |
|
session |
authn_scheme |
stored as $session.authn_scheme |
|
session |
count |
stored as $session.count |
|
session |
creation |
stored as $session.creation |
|
session |
expiration |
stored as $session.expiration |
|
session |
attr.ATTR_NAME |
ATTR_NAME being the name of an Access Manager Session Attribute stored as $session.attr.ATTR_NAME |
|
user |
userid |
stored as $user.userid |
|
user |
id_domain |
stored as $user.id_domain |
|
user |
guid |
stored as $user.guid |
|
user |
groups |
stored as $user.groups |
|
user |
attr.ATTR_NAME |
ATTR_NAME being the name of an LDAP User Attribute stored as $user.attr.ATTR_NAME |
|
expression (Based on the identifiers defined above and qualified with the type of data) |
- request:
|
-
|
|
expression (Based on the identifiers defined above and qualified with the type of data) |
- session:
|
-
|
|
expression (Based on the identifiers defined above and qualified with the type of data) |
- from user:
|
-
|
When the Identity Federation instance is configured as an SP, the IdP Attribute Mapping Profile allows the administrator to define which attributes (included in an incoming or outgoing Identity Federation message) map to which Access Manager session attributes.
The profile allows for the inclusion of the following data:
Message Attribute: the name of the attribute in the incoming/outgoing Federation messages.
Access Manager Session Attribute: the name by which the attribute is known to the local Access Manager server.
Request From Partner: Indicates if this attribute is sent in the Request made to the IdP (a value for this attribute is requested by the SP).
Table 38-9 provides sample IdP attribute mappings.
Table 38-9 Sample IdP Attribute Mappings
| Message Attribute | Access Manager Session Attribute | Request for Inclusion |
|---|---|---|
|
|
|
true |
|
givenname |
true |
|
|
sn |
surname |
|
|
uid |
uid |
In a protocol where a SP can specify which attributes are required in a response from the IdP, a Message Attribute name is sent in the request to the IdP. In cases when the SP receives an assertion or response from an IdP, the Attributes from the assertion are stored in the Access Manager session. If no Access Manager value is specified, the Message Attribute is stored.
When creating or modifying an IdP partner profile, the Attribute Mapping Profile is displayed with a drop-down list. The idp-attribute-profile is the default profile. Select the default or click the green plus sign to create a custom mapping profile.
See Creating Remote Identity Provider Partners.
The Ignore Umapped Attributes checkbox (in the configuration screen) indicates how to deal with Assertion Attributes not present (or that are present but have no value in the Access Manager Session Attribute column). If this checkbox is not checked, all Assertion Attributes that are not present in the table (or don't have a value mapped to Access Manager) will be stored in the Access Manager session with the same attribute name it had in the Assertion. If checked, any Assertion Attribute not present in the table (or with no value mapped to Access Manager) will be ignored and not added to the Access Manager session.
Note:
When the Identity Federation instance is configured as an SP it can request attributes only if the federation protocol used supports it. OpenID 2.0 supports this feature; SAML 2.0 and SAML 1.1 do not.