Single logout (SLO) results in the simultaneous termination of all user sessions associated with the browser that initiated the logout. Closing all user sessions prevents unauthorized users from gaining access to resources at the SPs.
The single logout binding determines what is sent with a single logout message and how each received message is handled.
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 and the browser is involved in every request and response, as the redirections are always sent back to it. 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 as part of the URL. Also, HTTP-Redirect binding is an asynchronous process so timeouts are unlikely, but 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 so 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, which means that 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 lack of a browser; however, means that 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.
| Copyright © 2010 CA. All rights reserved. | Email CA about this topic |