Federation Guides › Partnership Federation Guide › Delegated Authentication

Delegated Authentication

Delegated Authentication Overview

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

SiteMinder offers two authentication choices:

• Local authentication

  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

  SiteMinder uses a third-party web access management (WAM) application that SiteMinder does not protect. The third-party application authenticates any user who requests a protected federated resource then forwards the federated user identity to SiteMinder. After 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 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 SiteMinder at the Asserting Party

SiteMinder can initiate an authentication request at an asserting party. If the request is made to SiteMinder, it is recognized as a delegated authentication request. 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 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 SiteMinder at the asserting party. 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 SiteMinder.

After the third-party WAM system receives the authentication request, it passes the user identity to 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 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 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 SiteMinder.

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

Cookie Method for Passing User Identity

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 SiteMinder. If authentication begins at 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 Federation Manager 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 Federation Manager 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 Federation Manager 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 Federation Manager 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 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 SiteMinder must be in the same cookie domain.

4. The WAM system redirects the browser to SiteMinder.
5. SiteMinder extracts the login ID from the cookie then locates the user in its user directory.
6. SiteMinder creates a 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. SiteMinder is not protecting the WAM application.

Important! To use an SDK-created open-format cookie, the third party must install a Federation Manager SDK. The SDK is a separately installed component from 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 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 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 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 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 SiteMinder.
5. 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. 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 Federation Manager 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 Federation Manager 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 Federation Manager 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 Federation Manager 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.

   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 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 Federation Manager Java SDK to create a legacy cookie or an open-format cookie.
  • For .NET applications, the WAM can use a Federation Manager .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 Federation Manager Java SDK Guide or the Federation Manager .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 SiteMinder asserting party:
  • Encryption Password
  • Open-format Cookie Name
  • Open-format Cookie Encryption Transformation

  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 SiteMinder. This URL has to send the user back to the SiteMinder single sign-on service. The 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 SiteMinder, it must capture and resend any existing query string. The incoming request can have 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 SiteMinder at the asserting party.

Third-party WAM Configuration for Query String Delegated Authentication

A third-party WAM system and 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.

Important! The LoginID parameter is case-sensitive.

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 SiteMinder configuration at the asserting party.

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

Important! The LoginIDHash parameter is case-sensitive.

The third-party WAM system must configure its federated application to construct a redirect URL that sends the user back to the SiteMinder Single Sign-on service. Therefore, the 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 SiteMinder, it captures and resends any existing query string. If the incoming request has 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