Federation Guides › Partnership Federation Guide › Delegated Authentication

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:

• Local authentication

  CA SiteMinder® authenticates the user at the local site. You configure an authentication URL in the Administrative UI where the user is redirected to authentication and to establish a session.

• Delegated authentication

  CA SiteMinder® uses a third-party web access management (WAM) application that CA SiteMinder® does not protect. The third-party application authenticates any user who requests a protected federated resource then forwards the federated user identity to CA SiteMinder®. After CA SiteMinder® receives the user identity information, it locates the user in its own user directory and starts the federation process with the relying party.

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®:

• Using an open format cookie.

  You can encrypt the open format cookie to help ensure the security of the data.

• Using a query string that is appended to a redirect URL that sends the browser to CA SiteMinder®.

  The query string is sent in clear text.

  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.

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:
   • The WAM system uses the CA SiteMinder® Federation SDK to create an open-format cookie. The SDK creates the cookie and sends it back in a request to the WAM system.

     Note: To create an open-format cookie that is FIPS-encrypted, use a CA SiteMinder® Federation SDK.

     The third-party WAM application uses the same language as the SDK that it is using to create a cookie. If you are using the CA SiteMinder® Federation Java SDK, the third-party WAM application must be in Java. If you are using the .NET SDK, the third-party WAM application must support .NET.

   • The WAM system uses a manually created open-format cookie.

     You can create an open-format cookie without using a CA SiteMinder® Federation SDK. To create the cookie manually, use any programming language that supports UTF-8 encoding. You can use any of the following PBE encryption algorithms that CA SiteMinder® supports for password-based encryption:

     • PBE/SHA1/AES/CBC/PKCS12PBE-1000-128
     • PBE/SHA1/AES/CBC/PKCS12PBE-1000-192
     • PBE/SHA1/AES/CBC/PKCS12PBE-1000-256
     • PBE/SHA256/AES/CBC/PKCS12PBE-1000-128
     • PBE/SHA256/AES/CBC/PKCS12PBE-1000-192
     • PBE/SHA256/AES/CBC/PKCS12PBE-1000-256
     • PBE/SHA1/3DES_EDE/CBC/PKCS12PBE-1000-3
     • PBE/SHA256/3DES_EDE/CBC/PKCS12PBE-1000-3

     Verify that the open-format cookie gets set in the browser.

     To write a complete cookie, review the details about the contents of the open-format cookie.

   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.

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 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:

• To communicate the authenticated user login ID through a cookie, the third-party WAM system must generate a cookie.
  • For Java applications, the WAM can use a CA SiteMinder® Federation Java SDK to create a legacy cookie or an open-format cookie.
  • For .NET applications, the WAM can use a CA SiteMinder® Federation .NET SDK to create an open-format cookie.
  • For languages other than Java and .NET, the WAM can create an open-format cookie manually.

  For details on implementing the necessary class and methods, see the CA SiteMinder® Federation Java SDK Guide or the CA SiteMinder® Federation .NET SDK Guide. Each guide is installed with the SDK. If you create an open-format cookie manually, review the details about the required contents of the cookie.

• The third party must know the values of the following Administrative UI settings that are configured at the CA SiteMinder® asserting party:
  • Encryption Password
  • Open-format Cookie Name
  • Open-format Cookie Encryption Transformation

  CA SiteMinder® uses these values when creating the cookie. These settings are on the Single Sign-On (SAML 1.x) and SSO and SLO (SAML 2.0) steps of the partnership wizard.

• The third-party WAM system must create a redirect URL that sends the user back to CA SiteMinder®. This URL has to send the user back to the CA SiteMinder® single sign-on service. The CA SiteMinder® Administrator has to tell the third party about this URL in an out-of-band communication.

  Important! After the third-party WAM system receives an authentication request from CA SiteMinder®, it must capture and resend any existing query string. The incoming request can have CA SiteMinder® request information within the query string and the request must pass unchanged.

  Note: To pass the cookie, the third-party WAM system must be in the same cookie domain as CA SiteMinder® at the asserting party.

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