IBM Tivoli Federated Identity Manager, Version 6.2.2

SAML 2.0 Attribute query

The SAML 2.0 attribute query feature extends the capability of the SAML 2.0 protocol. Traditional SAML 2.0 function requires that the identity provider sends all required user attributes to the federation partner. The attributes are included as part of the assertion generated during the single sign-on flow.

The SAML 2.0 attribute query feature eliminates this limitation. Administrators for identity providers can include in the single sign-on flow only the attributes that are used by most targeted applications. Applications can use a SAML 2.0 attribute query flow to obtain any attribute requirements or specialized values.

Support for attribute query provides a set of core attributes when the initial authentication context is established. You can query user information as needed during the application runtime operation. Different applications require different user information. For example, applications that require fine grained authorization require specific user entitlements to make the authorization decisions.

Attribute query supports the following modes:

Direct mode: The requesting application issues a direct call to the identity provider to obtain any required attributes.
On-behalf mode: The requesting application contacts the service provider, which proxies the attribute request to the identity provider.

Direct mode

In direct mode, the requesting application sends an AttributeQuery request to the SAML 2.0 federation SOAP endpoint on the identity provider. The SOAP delegate protocol finishes the necessary protocol actions and issues a SAML assertion. The SAML attribute query function uses the attribute query secure token service (STS) module to issue the assertion.

The direct mode requires the application (attribute requester) to be known to the identity provider. To make an application known at the identity provider, use the command-line interface command manageItfimPartner to import the requester metadata.

The single sign-on flow for direct mode is:

The user requires access to a resource or application and initiates a federated single sign-on flow.
The identity provider authenticates the user and issues a SAML assertion with a subset of attributes that most applications or resources require.
The application or resource determines if any additional attributes are required. If so, the application issues an AttributeQuery to the identity provider obtain them.
The identity provider returns a SAML assertion with the requested attributes.
The application or resource obtains the attributes returned by the identity provider in the attribute query SAML response message.

On-behalf mode

On-behalf mode requires that applications send query requests to the service provider, which then proxies them to the identity provider. The identity provider supplies the requested attributes. On-behalf mode supports two different types of requests:

SAML 2.0 <AttributeQuery> requests
The application must send AttributeQuery messages to the service provider SOAP endpoint. If an AttributeQuery request message is used, the service provider returns a SAML Response message with the corresponding assertion.
WS-Trust Request Security Token messages.
For this protocol, the application must send WS-Trust messages to the trust service endpoint. If the requesting application sends a WS-Trust message, the response message is a Universal User Token.

Note: If your application is a WS-Trust client, you can use this option instead of using the SAML protocol.

The on-behalf mode limits the amount of configuration required at the identity provider for many service provider applications to query user attributes. In this mode, the service provider is the only known entity at the identity provider.

The single sign-on flow for on-behalf mode is:

The user requires access to a resource or application on the service provider and initiates a federated single sign-on flow.
The identity provider authenticates the user and issues a SAML assertion with a subset of attributes that most applications or resources require.
The service provider selects which attributes to make available to the resource or application. The service provider then creates the authenticated session for the user.
The application or resource determines if any additional attributes are required. If so, the application issues an AttributeQuery or a WS-Trust RequestSecurityToken to obtain them. The application sends the request to the service provider. The service provider proxies the request to the identity provider.
The Identity Provider returns a SAML assertion with the requested attributes.
The application or resource obtains the attributes returned by the Identity Provider in the attribute query SAML response message. If a WS-Trust request is made, the attributes are returned to the client application using a Universal User Token. If the request is a SAML AttributeQuery request, the attributes are returned in a SAMLResponse generated by the Service Provider.

Attribute query request partner

The Attribute query feature defines a new type of role. Application partners to a SAML 2.0 federation can now act in an attribute query requester role. This role is different from the role of service provider partner or identity provider partner.

An attribute query requester is an entity that makes SOAP-based <AttributeQuery> request calls to obtain user attributes.

If you plan to configure an attribute query requester partner, you must generate a metadata file as specified by the SAML 2.0 specification. Tivoli® Federated Identity Manager uses this metadata file to create the attribute request partner. You must use the manageItfimPartner command to create the partner. This command uses a response file, which contains a parameter that specifies the location of the metadata file.

Developing an attribute query STS module

The attribute query function uses an STS token module called the attribute query module. You must configure the module for the STS trust chain for the SAML 2.0 federation.

Before you configure attribute query, you must:

Determine the attributes that your resource or application wants to request from the identity provider.
Develop a script or module that requests the attributes. This request can be made by an XSLT or JavaScript file, a Tivoli Directory Integrator assembly line, or a custom secure token service (STS) mapping module.

Limitation with migrating from previous release of Tivoli Federated Identity Manager

Tivoli Federated Identity Manager supports migration of SAML 2.0 federations from the previous release to the current release. The attribute query feature was not available in previous releases. Without the attribute query feature, attribute query is not automatically enabled in the new release when you migrate SAML 2.0 federations from the previous release.

To enable attribute query for the federation, take the following steps after you have migrated the federation:

Select the check box on the federation properties page to enable attribute query.
Use the graphical user interface on the federation properties page to configure an attribute query module.
Use the Add Partner wizard to add all partners that previously existed for the federation.

Feedback