Federation Guides › Partnership Federation Guide › Single Sign-on Configuration › Single Sign-on Configuration (Asserting Party)

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.

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

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/siteminderagent/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. For the policy, configure an authentication scheme, realm, and rule. To add session store attributes to the assertion, enable the Persist Authentication Session Variables check box, which is a setting in the authentication scheme.

   • 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

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

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:

Single Sign-on Initiation (SAML 2.0)

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.