Single logout (SLO) results in the simultaneous termination of all user sessions for the browser that initiated the logout. Closing all user sessions prevents unauthorized users from gaining access to resources at the SPs.
Single logout 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 logout is terminated at all federated sites for that session. The session in the other browser is still active.
The single logout binding determines what is sent with a single logout message and how each received message is handled.
Important! To configure single logout, enable the session store using the Policy Server Management Console. For instructions about using the Management Console, see the Policy Server Administration Guide for instructions.
Two bindings are available for single logout operation:
HTTP-Redirect binding relies on a browser to conduct each logout transaction. The single logout message is always a GET request. The browser is involved in every request and response. The involvement of the browser means that HTTP-redirect binding provides browser session data, which the SOAP binding does not.
A disadvantage of HTTP-Redirect binding is that the data in the message is limited to what you can send on the query string. Also, HTTP-Redirect binding is an asynchronous process so timeouts are unlikely. However, if a redirect fails, that failure stops the entire single logout chain.
SOAP binding uses POST requests to conduct single logout transactions. POST requests let you send more data than the HTTP-Redirect binding. SOAP also enables you to do more in the way of encryption and other features.
SOAP is a synchronous process. The IdP has more control and can prevent a problem at a single SP from interfering with the whole process. SOAP communication takes place over a back channel. One logout failure does not have to stop the IdP from attempting to log out from the rest of the SPs.
SOAP relies on a back channel connection, so after the initial single logout call and response a browser is not involved. The SOAP binding does not clean up cookies at the remote entity as part of the logout process. Cookies are cleaned up only at the local entity. If deleting cookies is required, use HTTP-Redirect binding.
Your network can have some sites that support the HTTP-Redirect binding and others that support the SOAP binding. The IdP has to manage multiple bindings, but the SP sends or receives only one logout request.
The following sections provide configuration guidelines to handle a mixed-binding environment.
When CA SiteMinder® is at the IdP, configure the partnership to include an HTTP Redirect-based SLO Service URL and a SOAP-based SLO Service URL.
CA SiteMinder® at the IdP inspects the configuration for each SP in a session and handles all SOAP-enabled logouts first. HTTP-Redirect logouts for SPs that do not support SOAP follow.
If CA SiteMinder® is at the SP and the SP initiates single logout, we recommend the HTTP-Redirect binding to initiate the logout. Other SPs for the user session possibly do no support SOAP.
HTTP-Redirect relies on a browser session to handle all redirections. For this reason, it sends the necessary data that the IdP must have to logout SPs that only support HTTP-Redirect. If the SP starts the process with HTTP-Redirect, the IdP can use SOAP with all SPs that support it. Switch to HTTP-Redirect binding for the remaining SPs.
If you initiate single logout with the SOAP binding, the browser session data is not present.
To help ensure an SP-initiated logout uses HTTP-Redirect, embed an HTTP-Redirect link that points to the SP' local servlet in a page or application. For CA SiteMinder®, that link is:
http://sp_host:port/affwebservices/public/saml2slo
This embedded link causes CA SiteMinder® to generate a SAML <LogoutRequest> message that it sends to the SLO service at the IdP. When a user logs out, the logout at the SP is performed first and then the logout request is sent to the IdP. The IdP then completes the logout process with all the other SPs involved in the user session.
Two values are relevant when calculating how long the logout request is valid. These values are the IssueInstant value and the NotOnOrAfter value. In the SLO response, the single logout request is valid until the NotOnOrAfter value. When a single logout request is generated, CA SiteMinder® takes its system time. The resulting time becomes the IssueInstant set in the request message. To determine when the logout request expires, CA SiteMinder® takes its current system time and adds the Skew Time plus the SLO Validity Duration. The resulting time becomes the NotOnOrAfter value.
Note: Times are relative to GMT.
For example, a log out request is generated at the asserting party at 1:00 GMT. The Skew Time is 30 seconds and the SLO Validity Duration is 60 seconds. Therefore, the request is valid between 1:00 GMT and 1:01:30 GMT. The IssueInstant value is 1:00 GMT and the single logout request message is no longer valid 90 seconds afterward.
Configuring single logout requires that you enable the session store using the Policy Server Management Console. For instructions about using the Management Console, see the Policy Server Administration Guide for instructions. If the session store is not enabled, you cannot see the single logout settings in the Administrative UI.
When configuring single logout, note the following information:
Review guidelines for managing single logout in a mixed environment where SOAP and HTTP-Redirect are supported.
Follow these steps:
Note: The SLO configuration settings are the same at the IdP and SP.
The SLO binding enables single logout and indicates the binding in use at the local entity. The SLO binding also indicates which binding the local entity accepts when it receives a single logout request.
If you select SOAP, you can encrypt the Name ID in the SOAP message. Encryption options are set in the Signature and Encryption step of the partnership wizard.
If you select SOAP as the binding, the Incoming and Outgoing Configuration for the Back Channel becomes active. SLO requests and responses are sent across a back channel. Each local partner can secure the back channel by requiring the remote partner to authenticate.
More information can be found about the back channel settings for SLO.
Click Help for the field descriptions.
The SLO Service URL initiates single logout, which then triggers the Policy Server to generate a SAML <LogoutRequest> message. In addition, the SLO Service URL tells the Policy Server where to send the logout request message.
Specify a SLO service URL for each supported SLO binding, as follows:
Note: The Response Location URL field is optional.
Single logout configuration is complete.
Single logout using 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, and the Assertion Consumer Service.
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 only for testing purposes, not for production. The exception is when CA SiteMinder® sits behind a proxy server implementing SSL-enabled failover. If client certificate authentication is used to protect the back channel, the proxy server handles the authentication. All IdP->SP partnerships can use NoAuth as the authentication type.
Important! The authentication method for the incoming back channel must match 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.
To secure the back channel for single logout
If you select No Auth as the authentication method, no additional steps are required.
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://.
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 © 2014 CA.
All rights reserved.
|
|