Single Sign-On Service › SSO Getting Started Guide › SSO Using Advanced Authentication and Provisioning for a Sensitive Application › Configure an IdP to SP Partnership › Configure the Local IdP-to-Remote SP Partnership › Single Sign-on Configuration (Asserting Party)

Single Sign-on Configuration (Asserting Party)

Configure single sign-on at the asserting party to specify how the asserting party delivers an assertion to a relying party.

Follow these steps:

1. Begin at the appropriate step in the partnership wizard.

   SAML 1.1 and WS-FED

   Single Sign-On

   SAML 2.0

   SSO and SLO

   Any values that are defined during the creation or import of the remote relying party are filled in.

   Note: Click Help for a description of fields, controls, and their respective requirements.

2. In the Authentication section, configure the following fields so CA CloudMinder can act as the IdP

   Authentication Mode

   Delegated

   Delegated Authentication Type

   Cloud

   Delegated Authentication URL

   Enter the URL of the system authenticating the user requesting a resource. Use the following syntax for the delegated URL:

   http://cloud_system:port/chs/login/tenant_name/application_name

   The cloud_system is the system where the user console is installed.

   Example URL:

   http://cmserver.fowardinc.com:832/chs/login/tenant1/confidential_app

   Configure AuthnContext

   Use Predefined Authentication Class

   Authentication Class field

   Supply a static URI for SAML 1.1, SAML 2.0, and WS-FED.

   Additionally, for SAML 2.0 only, the system can automatically detect an authentication class. The URI is placed in the AuthnContextClassRef element in the assertion to describe how a user is authenticated.

3. Complete the fields in the SSO section to determine how single sign-on operates. These settings let you control the following features:
   • Single sign-on binding
   • Assertion validity

     The SSO Validity Duration and the Skew Time determine when the assertion is valid. Read the information about assertion validity to understand how these settings work together.

   For SAML 2.0, you can configure these features:

   • Initiation of single sign-on from which partner
   • SP session validity
   • SP session duration
   • User consent to share identity information with the SP

   Note: Click Help for a description of fields, controls, and their respective requirements.

4. Specify the URL for the Remote Assertion Consumer Service. This service is the service at the relying party that processes received assertions.

   Your partner needs to supply this URL to you.

5. If you selected HTTP-Artifact, configure the back channel settings.

Assertion Validity for Single Sign-on

For single sign-on, the values of the Skew Time and the SSO Validity Duration determine how long an assertion is valid. The Policy Server applies the skew time to the generation and consumption of assertions. In the assertion document, the NotBefore and NotOnOrAfter values represent the beginning and end of the validity interval.

At the asserting party, the Policy Server sets the assertion validity. The Policy Server determines the beginning of the validity interval by taking the system time when the assertion is generated. The software sets the IssueInstant value in the assertion from this time. The Policy Server then subtracts the skew time value from the IssueInstant value. The resulting time becomes the NotBefore value.

NotBefore=IssueInstant - Skew Time

To determine the end of the validity interval, the Policy Server adds the Validity Duration value and the skew time to the IssueInstant value. The resulting time becomes the NotOnOrAfter value.

NotOnOrAfter=Validity Duration + Skew Time + IssueInstant

Times are relative to GMT.

For example, an assertion is generated at the asserting party at 1:00 GMT. The skew time is 30 seconds and the validity duration is 60 seconds, making the assertion validity interval between 12:59:30 GMT and 1:01:30 GMT. This interval begins 30 seconds before the time the assertion was generated and ends 90 seconds afterward.

At the relying party, the Policy Server performs the same calculations as it does at the asserting party to determine if the assertion it receives is valid.

Calculating Assertion Validity when CA SiteMinder® is at Both Sides of the Partnership

The total time the assertion is valid is the sum of the SSO validity duration plus two times the skew time. The equation is:

Assertion Validity = 2x Skew Time (asserting party) + SSO Validity Duration + 2x Skew Time (relying party)

The initial part of the equation (2 x Skew Time + SSO Validity Duration) represents the validity window at the asserting party. The second part of the equation (2 x Skew Time) represents the skew time of the system clock at the relying party. You multiply by 2 because you are accounting for the NotBefore and the NotOnOrAfter ends of the validity window.

Note: For the Policy Server, the SSO Validity Duration is only set at the asserting party.

Example

Asserting Party

The values at the asserting party are as follows:

IssueInstant=5:00PM

SSO Validity Duration=60 seconds

Skew Time = 60 seconds

NotBefore = 4:59PM

NotOnOrAfter=5:02PM

Relying Party

The relying party takes the NotBefore and NotOnOrAfter values that is receives in the assertion then applies its skew time to calculate new values.

Skew Time = 180 seconds (3 minutes)

NotBefore = 4:56PM

NotOnOrAfter=5:05PM

Based on these values, the calculation for the total assertion validity window is:

120 seconds (2x60) + 60 seconds + 360 seconds (2x180) = 540 seconds (9 minutes).