Federation Security Services Guide › Configure SiteMinder as a SAML 1.x Consumer › Supply SAML Attributes as HTTP Headers

Supply SAML Attributes as HTTP Headers

An assertion response can include attributes in the assertion. These attributes can be supplied as HTTP header variables so a client application can use them for finer grained access control.

The benefits of including attributes in HTTP headers are as follows:

• HTTP headers are not persistent. They are present only within the request or response that contains them.
• HTTP headers, as supplied by the SiteMinder Web Agent, are not visible in the browser, which reduces security concerns.

Note: The HTTP headers have size restrictions that the attributes cannot exceed. SiteMinder can send an attribute in a header up to the web server size limit for a header. Only one assertion attribute per header is allowed. See the documentation for your web server to determine the header size limit.

Use Case for SAML Attributes As HTTP Headers

During authentication, a series of SAML attributes are extracted from an assertion and supplied as HTTP headers. During the authorization process, these headers are returned to the customer application.

The following flow diagram shows the sequence of events at runtime:

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. In the flow diagram, the Web Agent block would be the embedded Web Agent in the SPS federation gateway. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

To process the attributes as HTTP headers, the sequence of events is as follows:

1. After the assertion is generated at the asserting party, it sends the assertion to the appropriate consumer service at the relying party. The delivery mechanism (POST or Artifact or WS-Fed) is irrelevant.

   Note: The consumer service can be the SAML credential collector (SAML 1.x), the Assertion Consumer Service (SAML 2.0), or Security Token Consumer Service (WS-Federation).

2. The consumer service calls its local Policy Server to use the configured authentication scheme to authenticate the user with the assertion.
3. If the authentication scheme redirect mode parameter is set to PersistAttributes, the Policy Server caches the attributes in the session store as session variables.
4. The result of the authentication is returned to the consumer service.
5. The consumer service redirects the browser to the protected target resource.
6. The browser tries to access the target resource.
7. The Web Agent calls the Policy Server to validate the user session and to verify that the user is authorized to access the target resource.
8. The Policy Server retrieves the attributes by a configured response.
9. The Policy Server processes the responses and sends the attributes to the Web Agent.
10. The Web Agent sets the HTTP headers as necessary.

Configuration Overview to Supply Attributes as HTTP Headers

Several configuration steps are required to retrieve the SAML attributes cached in the session store and provide them as HTTP headers.

Follow these steps:

1. Select PersistAttributes as the redirect mode for the SAML authentication scheme, which enables the SAML Attributes to be returned as HTTP headers.
2. Configure an authorization rule for the realm that contains the target resource.
3. Set PersistentRealm in the realm protecting the target resource.
4. Configure a response that uses the active response type for each SAML attribute to be supplied as a header.
5. Create a policy that binds the authorization rule and active response to implement the user of attributes as HTTP headers.