Single logout enabled with the SOAP binding sends logout requests and responses across 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:
SSL is not required for Basic authentication but you can use Basic over SSL. SSL is required for Client Cert authentication.
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.
The options for back channel authentication are:
Indicates that a Basic authentication scheme is protecting the back channel.
Note: If SSL is enabled for the back channel connection, Basic authentication can still be selected.
Indicates that SSL with an X.509 client certificate protects the asserting party back channel.
If you select Client Cert as the authentication method, all endpoint URLs have to use SSL communication. This means that the URLs must begin with https://. Endpoint URLs locate the various SAML services on a server, such as single sign-on, single logout, the Assertion Consumer Service, Artifact Resolution Service (SAML 2.0), and the Assertion Retrieval Service (SAML 1.x).
Indicates that the relying party is not required to supply credentials. The back channel is not secured. You can still enable SSL with this option. The back channel traffic is encrypted but no credentials are exchanged between parties.
Use the NoAuth option for testing purposes but not for production, unless CA SiteMinder® Federation Standalone is configured for SSL-enabled failover and sits behind a proxy server. In this case, if client certificate authentication is used to protect the back channel, the proxy server handles the authentication because it has the server certificate. In that case, all IdP->SP partnerships can use NoAuth as the authentication type.
Important! The authentication method chosen 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 out of band.
To secure the back channel for single logout
Note: Click Help for a description of fields, controls, and their respective requirements.
If you select No Auth as the authentication method, no additional steps are required.
Note: Click Help for a description of fields, controls, and their respective requirements.
After entering values for all the necessary fields, the back channel configuration is complete.
Sign-out is the simultaneous termination of all user sessions for the browser that initiated the sign-out. Closing all user sessions prevents unauthorized users from gaining access to resources at the Resource Partner.
Sign-out does not necessarily end all sessions for a user. For example, a user with two browsers open can have two independent sessions. Only the session for the browser that initiates the sign-out is terminated at all federated sites for that session. The session in the other browser is still active.
The Policy Server performs sign-out using a signoutconfirmurl.jsp. This page resides on the Identity Provider system. An Identity Provider partner initiates a sign-out request on behalf of a user. The JSP sends the sign-out request to each site where the user signed on during a given browser session. The user is then signed out.
A user can initiate a sign-out request only at an Identity Provider. The request is triggered by clicking a link that points to the appropriate servlet. The sign-out confirmation page must be an unprotected resource at the Identity Provider site.
Note: The Policy Server only supports the WS-Federation Passive Request profile for sign-out.
Requirements to configure sign-out:
For information about the session store, see the Policy Server Administration Guide.
For information about realms, see the Policy Server Configuration Guide.
Follow these steps:
The URLs must each have an entry that starts with https:// or http://.
Note: Click Help for a description of fields, controls, and their respective requirements.
Sign-out is configured.
CA SiteMinder® as an SP supports local logout for stand-alone applications. Local logout enables a user to be logged out at the local SP-side application. The session at the SP is removed, but no communication with the IdP or other SPs is involved. Sessions at the IdP and other SPs remain active.
If you include a logout link in an application at the SP, the SP sends a logout request to the local single logout service. The SP logs out the user upon receiving the request. The application at the SP is responsible for sending a confirmation message that the logout is successful.
CA SiteMinder® provides local logout using a query parameter named localLogout. To use this parameter, your application can have a page, such as the following example:
You have completed your registration with demoapp. To end your session securely, select LOGOUT.
The following sample string represents the link for the LOGOUT button:
<http://sp1server.demo.com:8080/affwebservices/public/saml2slo?LocalLogout=true
|
Copyright © 2013 CA.
All rights reserved.
|
|