Logout and User Expectations
Overview
When a user clicks a logout button or link in Aria, the user’s web application session and service provider session are ended, but the user is not logged out of the IdP. Therefore, if the user were to return to the Aria application, they would be automatically re-authenticated because their IdP session cookie is still valid.
Since an IdP does not know which service providers to which the user has sessions, it cannot inform those service providers to destroy the user’s sessions. This creates a false sense of security for users since it provides the impression that they are logged out of all SSO applications.
Logout Notifications
For SLO to be successful, users must be informed whether a logout was successful. The amount of information that Aria receives from an IdP is very limited; a URI that either indicates success or one that indicates some sort of failure.
In cases where SLO fails, Aria has little to no information to provide to the user regarding the cause of the failure. In turn, the user receives a very generic error message that notifies them of a failure, but because Aria does not know the cause, it is impossible to describe to the user how or why the failure occurred.
Single Logout Considerations
Single Logout (SLO) considerations are specific to each implementation of the functionality. Ideally, the process for single logout would be the reverse process of single sign-on, but this unfortunately is not the case. When an IdP server receives a request for SLO, the logout service removes the user’s session from the application server and it redirects the user’s browser to the logout service defined in the IdP configuration.
An SLO request contains:
- A NameID that indicates the user is logged out.
- Optionally, a session index that corresponds to the optional attribute within the initial authentication statement.
An SLO response contains a status message that indicates whether the logout operation was successful.