Single Sign-On Service › SSO Partnership Federation Guide › Single Sign-on Configuration › SAML 2.0 Entities Allowed to Initiate Single Sign-on

SAML 2.0 Entities Allowed to Initiate Single Sign-on

For SAML 2.0 partnerships, you can determine whether the IdP or the SP or both can initiate single sign-on. You can configure which transactions are allowed at each side of the partnership.

Consider how restricting the initiation of a transaction can impact other single sign-on features, such as exchanging user authentication context information.

Follow these steps:

1. Log in to the CSP console.
2. Select the SAML 2.0 partnership you want to edit.
3. Navigate to the SSO and SLO step of the partnership wizard.
4. In the Transactions Allowed field, select an option from the pull-down menu.
5. Skip to the Confirm step of the wizard and save your changes.

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).

Session Validity at a Service Provider

You can manage the duration of the authentication session at the Service Provider. The SessionNotOnOrAfter attribute is an optional attribute that the IdP can include in the <AuthnStatement> of an assertion. The configuration for session validity is done at the IdP.

Note: The SessionNotOnOrAfter parameter is different from the NotOnOrAfter parameter, which determines how long the assertion is valid.

A third-party SP can use the value of the SessionNotOnOrAfter to set its own timeout values, helping to ensure that sessions are not too short. If a user session becomes invalid, the user has to reauthenticate at the Identity Provider.

Important! If CA SiteMinder® is acting as an SP, it ignores the SessionNotOnOrAfter value. Instead, a CA SiteMinder® SP sets session timeouts from the realm timeout that corresponds to the SAML authentication scheme protecting the target resource.

Follow these steps:

1. Log in to the CSP console.
2. Select the IdP->SP partnership you want to modify.
3. Navigate to the SSO and SLO step.
4. In the SSO section, select the option for the SP Session Validity Duration. If you select the customize option, you can select several options.

   Click Help for the field descriptions.

5. Select the Confirm step after you complete your changes and click Finish.

Back Channel Authentication for Artifact SSO

Artifact single sign-on requires the relying party to send an artifact to the asserting party to retrieve the assertion. The asserting party uses the artifact to retrieve the correct assertion and returns the assertion to the relying party over a back channel.

You can require an entity to authenticate to access the back channel. The back channel can also be secured using SSL, though SSL is not required.

Securing the back channel using SSL involves:

1. Enabling SSL.

   SSL is not required for Basic authentication but you can use Basic over SSL. SSL is required for Client Cert authentication.

2. Configuring an incoming or outgoing back channel for the SAML 2.0 communication exchange. The direction you configure depends on the role of the local entity.

   Configuring separate channels is supported only for SAML 2.0. The back channel configuration for SAML 1.1 artifact single sign-on uses a single configuration for each partnership. CA SiteMinder® uses the correct direction automatically (incoming for a local producer and outgoing for a local consumer).

   Select which direction to configure for SAML 2.0 single sign-on based on the entity you are configuring.

   • The local asserting party uses the incoming channel.
   • The local relying party uses the outgoing channel.

   Note: You can configure an incoming and outgoing back channel; however, a channel can have only one configuration. If two services use the same channel, these two services use the same back channel configuration. For example, if the incoming channel for a local asserting party supports HTTP-Artifact SSO and SLO over SOAP, these two services must use the same back channel configuration.

3. Choosing the type of authentication for the relying party to gain access across the protected back channel. The authentication method applies per channel (incoming or outgoing).

   The options for back channel authentication are:

   • Basic
   • Client Cert
   • NoAuth

   The CSP console help describes these options in detail.

   Important! The authentication method for the incoming back channel must match the authentication method for the outgoing back channel on the other side of the partnership. Agreeing on the choice of authentication method is handled in an out of band communication.

Configure the HTTP-Artifact Back Channel

Protect the HTTP-artifact back channel across which the asserting party sends the assertion to the relying party.

Consider the following limitation:

You cannot use client certificate authentication with the following web servers running ServletExec:

• IIS web servers at a CA SiteMinder® producer/Identity Provider because of a limitation in IIS.
• SunOne/Sun Java Server web servers at a CA SiteMinder® producer/Identity Provider because of a documented limitation in ServletExec.

Follow these steps:

1. Begin at the Back Channel section in the Single Sign-on or the SSO and SLO step of the partnership wizard.
2. Select HTTP-Artifact in the SSO section.

   The Authentication Method field becomes active.

3. Select the type of authentication method for the incoming or outgoing back channel, or both.

   Click Help for the field descriptions.

   • If you select the client certificate authentication scheme, add a private key/certificate pair to the certificate data store. The private key/certificate pair is issued from a Certificate Authority.

     Important! The CN of the Subject in the certificate must be the same as the partnership name in the producer to consumer partnership that is configured at the producer.

     For instructions on adding a certificate, see the Policy Server Configuration Guide. Skip this step if the key/certificate pair is already in the data store.

   • If you select No Auth as the authentication method, no additional steps are required.
4. Depending on the authentication method you select, several additional fields are displayed for you to configure.

After entering values for all the necessary fields, the back channel configuration is complete. You can enable SSL on each side of the connection for added security.