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
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)
SAML 2.0 HTTP-POST Binding Configuration
Configure the SAML 2.0 Name ID Management Profile
Configure a SAML 2.0 Response for Authentication Failure
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:
Single Sign-On
SSO and SLO
Single Sign-on and Sign-Out
Any values that are defined during the creation or import of the remote relying party are filled in.
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.
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:
Click Help for the field descriptions.
Your partner must supply this URL to you.
Partnership federation lets you define the authentication mode for federated single sign-on.
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 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®.
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:
Follow these steps: to add a web agent to an agent group
The Agent Groups dialog opens.
Follow these steps: to enforce the policy that protects the retrieval service
A list of available domain policies displays.
FederationWSAssertionRetrievalServicePolicy
SAML2FWSArtifactResolutionServicePolicy
Note: The supplied policies are default policies. You can use any policy that you created to protect the artifact service.
The federation custom user stores display in the User Directories section.
FederationWSCustomUserStore
SAML2FederationCustomUserStore
Examples:
The partnership for HTTP-Artifact single sign-on now allows the access to the artifact service so the relying party can retrieve the assertion.
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:
Single Sign-On
SSO and SLO
Single Sign-On and Sign-Out
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.
If a third-party IdP is authenticating a consumer user with no user record at the host, SSO is initiated at the SP.
The basic settings for single sign-on are complete. Other settings are available for SSO. Click Help for the field descriptions.
Copyright © 2014 CA.
All rights reserved.
|
|