Federation Guides › Partnership Federation Guide › Single Sign-on Configuration

Single Sign-on Configuration

This section contains the following topics:

Single Sign-on Configuration (Asserting Party)

Single Sign-on Configuration (Relying Party)

Status Redirects for HTTP Errors (SAML 2.0 IdP)

SAML 2.0 Entities Allowed to Initiate Single Sign-on

Assertion Validity for Single Sign-on

Session Validity at a Service Provider

Back Channel Authentication for Artifact SSO

How to Enable SAML 2.0 Attribute Query Support

Retrieve User Attribute Values from a Third-Party (SAML 2.0)

User Consent at a SAML 2.0 IdP

Enhanced Client or Proxy Profile Overview (SAML 2.0)

IDP Discovery Profile (SAML 2.0)

Single Sign-on Configuration (Asserting Party)

To specify how assertions are delivered to a relying party, configure single sign-on at the asserting party.

The procedure that follows offers the basic steps to enable single sign-on. Details about all the configurable features in the sign-on dialog are described in subsequent topics and in the Administrative UI help.

Follow these steps:

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

   SAML 1.1

   Single Sign-On

   SAML 2.0

   SSO and SLO

   WSFED

   Single Sign-on and Sign-Out

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

2. Complete the fields in the Authentication section, noting the following information:
   • If you select Local for the Authentication Mode field, enter a URL for the Authentication URL that points to the redirect.jsp file. For example:

     http://webserver1.example.com/affwebservices/redirectjsp/redirect.jsp

     In this example, webserver1 identifies the web server with the Web Agent Option Pack. The redirect.jsp file is included with the Web Agent Option Pack installed at the Identity Provider site.

     Important! Protect the Authentication URL with an access control policy. Configure the realm, rule, and policy. To add session information to the assertion, enable the Persist Authentication Session Variables check box.

   • If you select Delegated as the Authentication mode, configure the additional fields. Learn more about delegated authentication.
3. Complete the Authentication Class field (SAML 1.1 and 2.0 only). Supply a static URI for this field. Additionally, for SAML 2.0 only, the software can automatically detect an authentication class. The URI is placed in the AuthnContextClassRef element in the assertion to describe how a user is authenticated.
4. Complete the fields in the SSO section. 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. To understand how these settings work together, read the information about assertion validity.

   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

   Click Help for the field descriptions.

5. Specify the URL for the assertion consumer service or security token service. This remote relying party service consumes and processes assertions.

   Your partner must supply this URL to you.

6. If you selected HTTP-Artifact as the SAML binding, configure the back channel settings.
7. (Optional). For SAML 2.0, you can do the following tasks:
   • Enable IDP Discovery Profile.
   • Specify status redirect URLs for specific HTTP errors.

More information:

SAML 2.0 Entities Allowed to Initiate Single Sign-on

Status Redirects for HTTP Errors (SAML 2.0 IdP)

Legacy Artifact Protection Type for the HTTP-Artifact Back Channel

Authentication Mode for Partnership Federation

Partnership federation lets you define the authentication mode for federated single sign-on.

• Local authentication mode

  Local authentication primarily happens at the local federation system. For local authentication, you can select Basic or Forms as the authentication schemes. These options are the only two methods available locally.

  You can also select local for the authentication mode when an external third party authenticates a user. When the third party passes back the user information, the user information gets stored in the session store for later use in assertions.

• Delegated authentication mode

  Delegated authentication forwards the authentication task to a third-part web access management (WAM) system. The method by which the third party authenticates a user depends on the authentication schemes the third party supports. After the third-party WAM authenticates the user, it sends the federated user identity back to CA SiteMinder®.

Legacy Artifact Protection Type for the HTTP-Artifact Back Channel

For HTTP-Artifact single sign-on, you can select the legacy option for the Artifact Protection Type field. The legacy option indicates that you are using the legacy method of protecting the back channel to the artifact service at the asserting party.

To implement the legacy method of protection:

• Add the Web Agent that protects the FWS application to the Agent group FederationWebServicesAgentGroup.
  • For ServletExec, this Agent is on the web server where the Web Agent Option Pack is installed.
  • For an application server, such as WebLogic or JBOSS, this Web Agent is installed where the application server proxy is installed. The Web Agent Option Pack can be on a different system.
• Enforce the policy that protects the artifact service. To enforce the policy, you indicate which asserting party-to-relying party partnerships are permitted access to the artifact service.

Follow these steps: to add a web agent to an agent group

1. Log in to the Administrative UI.
2. Select Infrastructure, Agents, Create Agent.
3. Specify the name of the Web Agent in your deployment. Click Submit.
4. Select Infrastructure, Agent Groups.
5. Select the FederationWebServicesAgentGroup entry.

   The Agent Groups dialog opens.

6. Click Add/Remove and the Agent Group Members dialog opens.
7. Move the web agent from the Available Members list to the Selected Members list.
8. Click OK to return to the Agent Groups dialog.
9. Click Submit then click Close to return to the main page.

Follow these steps: to enforce the policy that protects the retrieval service

1. In the Administrative UI, configure the partnership using the legacy method for the artifact protection type.
2. Activate this partnership.
3. Select Policies, Domain, Domain Policies.

   A list of available domain policies displays.

4. Edit the appropriate artifact service policy by selecting the pencil icon.

   SAML 1.1

   FederationWSAssertionRetrievalServicePolicy

   SAML 2.0

   SAML2FWSArtifactResolutionServicePolicy

   Note: The supplied policies are default policies. You can use any policy that you created to protect the artifact service.

5. Go to the Users tab.

   The federation custom user stores display in the User Directories section.

6. Click Add Members for the user store you want to modify:

   SAML 1.1

   FederationWSCustomUserStore

   SAML 2.0

   SAML2FederationCustomUserStore

7. Select the partnerships for which you configured legacy artifact protection.

   Examples:

   • If the SAML 1.1 partnership is named Acme, select affiliate:affiliate:Acme
   • If the SAML 2.0 partnership is named Demo, select affiliate:samlsp:Demo
8. Click OK.

The partnership for HTTP-Artifact single sign-on now allows the access to the artifact service so the relying party can retrieve the assertion.

Single Sign-on Configuration (Relying Party)

To configure single sign-on at the relying party, specify the SAML binding and the other related SSO settings.

At the relying party, the system uses the skew time for the partnership to determine whether the assertion it receives is valid. To understand how the system uses the configured skew time, read more about assertion validity.

The procedure that follows offers the basic steps to enable single sign-on. Details about all the configurable features in the sign-on dialog are described in subsequent topics and in the Administrative UI help.

Follow these steps:

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

   SAML 1.1

   Single Sign-On

   SAML 2.0

   SSO and SLO

   WS-Federation

   Single Sign-On and Sign-Out

2. Configure the settings in the SSO section of the dialog. These settings let you control the single sign-on binding.

   Click Help for the field descriptions.

   For SAML, configure the HTTP-Artifact or the HTTP-POST profile. If the relying party initiates single sign-on, it includes a query parameter in the request. This query parameter indicates the SSO binding to use. If no binding is specified, the default is POST. If the asserting party initiates single sign-on, the asserting party indicates the binding in use for that particular transaction.

3. (Optional). For SAML 2.0, you can configure these settings:
   • Remote SSO Service URLs
   • Remote SOAP Artifact URLs
   • Initiation of single sign-on from which partner

     If a third-party IdP is authenticating a consumer user with no user record at the host, SSO is initiated at the SP.

   • User consent requirement
4. If you select the HTTP-Artifact profile, configure the authentication method for the back channel in the Back Channel section of the dialog.
5. For the remaining settings, accept the defaults.

The basic settings for single sign-on are complete. Other settings are available for SSO. Click Help for the field descriptions.