Previous Topic: Enable the Message Consumer Plug-in in the UINext Topic: URLs to Initiate Single Sign-on


Delegated Authentication

This section contains the following topics:

Delegated Authentication Overview

How the Third Party WAM Passes the User Identity

Delegated Authentication Configuration

Delegated Authentication Overview

One of the configuration decisions for single sign-on is determining how users are authenticated.

CA SiteMinder® offers two authentication choices:

A delegated authentication request takes place at the asserting party and it can be initiated at the third-party WAM system or at CA SiteMinder®. An authentication request can initiate at the relying party; however this scenario is not considered delegated authentication.

Authentication can be initiated as follows:

Authentication Initiated by CA SiteMinder® at the Asserting Party

CA SiteMinder® can initiate an authentication request at an asserting party. If the request is made to CA SiteMinder®, it is recognized as a delegated authentication request. CA SiteMinder® then redirects the user to the third-party WAM system.

Authentication Initiated by Direct Login to the WAM System at the Asserting Party

When a user logs in to a WAM system at the asserting party, an authentication request is initiated. After the WAM system successfully authenticates the user, the identity information is then forwarded to CA SiteMinder®.

Authentication Initiated at the Relying Party

The relying party can initiate an authentication request, but this scenario is not considered delegated authentication. Delegated authentication occurs only at the asserting party.

A request for a federated resource is made directly to the relying party, who then sends an AuthnRequest to CA SiteMinder® at the asserting party. CA SiteMinder® recognizes it as a delegated authentication request and redirects the user to the third-party WAM system at the asserting party. The user logs in to the WAM system, which initiates an authentication request. After the WAM system successfully authenticates the user, the identity information is then forwarded to CA SiteMinder®.

After the third-party WAM system receives the authentication request, it passes the user identity to CA SiteMinder®. The method the WAM system uses to pass the user identity depends on whether the delegated authentication method is cookie-based or a query string-based.

How the Third Party WAM Passes the User Identity

The third-party WAM system can use one of two methods to pass a federated user identity to CA SiteMinder®:

The method a third-party WAM system chooses depends on the configuration it wants to establish for passing a user identity to CA SiteMinder®.

The methods of passing the user identity are detailed in the following sections.

Cookie Method for Passing User Identity

CA SiteMinder® can use an open-format cookie to pass a user identity. The cookie contains a user login ID as one of its values.

Authentication can begin at the WAM system or at CA SiteMinder®. If authentication begins at CA SiteMinder®, it redirects the user to the WAM system. The authentication process is the same as if it began at the WAM system.

The delegated authentication process is as follows:

  1. An authentication request comes into to the third-party WAM system.
  2. The user is authenticated.
  3. The third-party WAM system obtains a cookie in one of two ways:

    Note: The WAM system and CA SiteMinder® must be in the same cookie domain.

  4. The WAM system redirects the browser to CA SiteMinder®.
  5. CA SiteMinder® extracts the login ID from the cookie then locates the user in its user directory.
  6. CA SiteMinder® creates a CA SiteMinder® session.
  7. After the session is created, federated communication with the relying party proceeds.

The following picture shows the cookie method when authentication is initiated at the third-party WAM. CA SiteMinder® is not protecting the WAM application.

Delegated authentication flow using an open format cookie

Important! To use an SDK-created open-format cookie, the third party must install a CA SiteMinder® Federation SDK. The SDK is a separately installed component from CA SiteMinder®. The installation kit contains the documentation that describes how to use the SDK for delegated authentication.

Query String Method for Passing User Identity

A third-party WAM system can pass a user identity to CA SiteMinder® by appending a query string on the redirect URL. For this method to work, the third-party WAM system has to configure a URL that redirects federated users to CA SiteMinder® after they are authenticated.

Important! Do not use the query string method in a production environment. The query string redirection method is only for a testing environment as a proof of concept.

If authentication is initiated at the WAM system, the process for delegated authentication using a query string is as follows:

Note: Authentication can also be initiated at CA SiteMinder® or at the relying party.

  1. The third-party WAM system receives an authentication request.
  2. The user is authenticated.
  3. The third-party WAM system constructs a redirect URL and adds the login ID and hashed login ID values to the query string in the format LoginID=LoginID&LoginIDHash=hashed_LoginID.

    Important! The LoginID and LoginIDHash parameters are case-sensitive. Be sure to include them in the redirect URL as shown in the example.

    The hashing mechanism allows CA SiteMinder® to verify that the user ID has been received unchanged.

    Example of a Redirect URL

    http://idp1.example.com:9090/affwebservices/public/saml2sso?SPID=FmSP&ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&LoginID=jdoe&LoginIDHash=454d3bd5cb839168eeffcf060ae0b9c28ed6eec0

  4. The WAM system redirects the browser to CA SiteMinder®.
  5. CA SiteMinder® extracts the login ID and hashed login ID from the URL, validates the identifier using the hashed value, and locates the user in its user directory.
  6. CA SiteMinder® creates a user session.
  7. After the session is created, federated communication with the relying party proceeds.

The following picture shows the query string method when authentication is initiated at the asserting party.

Delegated authentication flow using a query string

Delegated Authentication Configuration

Delegated authentication is configured at the asserting party, where an assertion is generated based on an authenticated user identity.

To configure delegated authentication

  1. Determine which method (cookie or query string) the third-party WAM uses to pass the user identity.

    Note: The query string does not produce a FIPS-compliant partnership.

  2. Go to the appropriate step in the partnership wizard to set up delegated authentication.

Important! To use the SDK-created open-format cookie, the third party must install a CA SiteMinder® Federation SDK. The SDK is a separately installed component. The installation kit contains the documentation that describes how to use the SDK for delegated authentication.

Cookie Delegated Authentication Sample Setup

The following sample configuration is from the perspective of a SAML 2.0 IdP > SP partnership. The delegated authentication settings are on the SSO and SLO step of the partnership wizard.

This sample configuration reflects a SAML 2.0 configuration. The Identity Provider is http://idp1.xyz.com and the third-party WAM system is http://wamservice.xyz.com.

To configure cookie delegated authentication

  1. Create a partnership or edit an existing one.

    Note: To edit a partnership, deactivate it first.

  2. Navigate to the SSO and SLO step in the Partnership wizard.
  3. In the Authentication section, set the fields as follows:
    Authentication Mode

    Delegated

    Delegated Authentication Type

    Open format cookie

    For use with a web access management application. You can use a CA SiteMinder® Federation SDK to create a Java or .NET application. Alternatively, you can use an application written in another language, provided you build the open-format cookie manually.

    If you require FIPS 140-2 encryption, create the open-format cookie using the CA SiteMinder® Federation Java or .NET SDK.

    Delegated Authentication URL

    http://wamservice.xyz.com

    The URL of the third-party WAM system that authenticates users and uses a CA SiteMinder® Federation SDK to create the cookie.

    Authentication Class

    Enter the authentication method that is used at the third party. For example:

    urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

  4. Communicate all the open-format cookie settings to the third-party WAM system.

    CA SiteMinder® uses these values in the creation of the cookie.

  5. Continue with partnership configuration.
Query String Delegated Authentication Sample Setup

The following sample configuration is from the perspective of a SAML 2.0 IdP > SP partnership. The delegated authentication settings are on the SSO and SLO step of the partnership wizard.

Note: The query string method does not produce a FIPS-compliant partnership.

This sample configuration reflects a SAML 2.0 configuration. The Identity Provider is http://idp1.xyz.com and the third-party WAM system is http://wamservice.xyz.com.

Important! Do not use the query string method in a production environment. The query string redirection method is only for a testing environment as a proof of concept.

To configure query string delegated authentication

  1. Create a partnership or edit an existing one.

    Note: To edit a partnership, deactivate it first.

  2. Navigate to the appropriate step in the partnership wizard.
  3. In the Authentication section, set the fields as follows:
    Authentication Mode

    Delegated

    Delegated Authentication Type

    Query String

    Delegated Authentication URL

    http://wamservice.xyz.com

    The URL of the third-party WAM system that authenticates users and constructs the redirect URL back to CA SiteMinder® with the query parameters.

    Hash Secret

    FederatedAuth1

    The third-party WAM system uses this secret to hash the login ID.

    Confirm Hash Secret

    FederatedAuth1

    Authentication Class

    Enter the authentication method that is used at the third party. For example:

    urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

  4. Continue with partnership configuration.
Third-party WAM Configuration for Cookie Delegated Authentication

For delegated authentication to succeed, the third-party WAM must adjust its federated application, as follows:

Third-party WAM Configuration for Query String Delegated Authentication

A third-party WAM system and CA SiteMinder® at the asserting party communicate the login ID in a query string. The WAM system must add the following two attributes to the query string in the redirect URL:

LoginID

Specifies the value that identifies the user to the third-party WAM system.

LoginIDHash

A hash of the LoginID.

To generate the LoginIDHash value, the LoginID is prepended to a Hash Secret and the entire value is then run through a SHA-1 hashing algorithm. The Hash Secret is specified in the CA SiteMinder® configuration at the asserting party.

When CA SiteMinder® retrieves the credentials from the query string, it also combines these values and hashes them. If the hashes are equal, CA SiteMinder® considers the login ID to be valid and continues with the federation request.

Important! The LoginID and LoginIDHash parameters are case-sensitive.

The third-party WAM system must configure its federated application to construct a redirect URL that sends the user back to the CA SiteMinder® Single Sign-on service. Therefore, the CA SiteMinder® Administrator has to communicate the Single Sign-on service to the third party in an out-of-band communication.

Important! After the third-party WAM system receives an authentication request from CA SiteMinder®, it captures and resends any existing query string. If the incoming request has CA SiteMinder® request information within the query string, the WAM system must pass it along unchanged.

The syntax of the query string is as follows:

?existing_query_string&LoginID=LoginID&LoginIDHash=hashed_LoginID

Example

https://johndoe3227.b.com/affwebservices/public/saml2sso?SPID=sp1&
LoginID=user1&LoginIDHash=de164152ed6e8e9a7f760e47d135ecf0c98a
3e4e&ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact