This post wraps our look at SAML v2.0 Use Cases. The first four use cases are described in “SAML v2.0 vs JWT: SAML2 Web Application SSO Use Cases” and “SAML v2.0 vs. JWT: SAML2 with SOAP Web Services and REST APIs”. The full list of SAML2 vs JWT-related blog posts can be found here.
Use Case #5: Single Logout
The SAML 2.0 specification provides for logging out of a web application (Service Provider) and the Identity Provider. This is done with the Single Logout Protocol. Basically, it allows a Principal to initiate a logout at the IdP or Service Provider(s). The Single Logout Protocol provides for logging out of sessions established with multiple Service Providers or a single Service Provider. What we have described as Service Providers in the other use cases are called Session Participants here. The Identity Provider is referred to as the Session Authority in this use case.
From the SAML 2.0 Profiles specification, we have this diagram:
This diagram doesn’t show the details of the user initiating the logout process at the Session Participant (Service Provider). The details of this are highly specific to the Service Provider (or Web Application); thus, the SAML 2.0 specification is vague about it. You can imagine a JEE Application Server such as WebSphere Application Server, which provides a proprietary logout Servlet endpoint that can be used to invalidate a user’s security session. The JEE Specification doesn’t define how this is supposed to be done; the specification doesn’t define how a JEE App Server implementer is supposed implement a security Sub-System. It implies the Java Authentication and Authorization Service. Thus, what is needed to destroy or invalidate a security session is not defined. Going back to our WAS example from a moment ago, the Logout Servlet invalidates the SecurityContext on the application server, but the session tracking cookie (LtpaToken2 cookie) remains after the session is invalidated — the cookie does not map to a valid SecurityContext. For JBoss, a security session is invalidated by invalidating the HTTP Session (since the JSESSIONID cookie is used to track the security session). These are some of differences just between two of the major JEE vendors. How security session sub-systems are implemented across other platforms can vary dramatically. So, if none of those details are standardized, the SAML 2.0 specification isn’t going to be able to go into much detail about how it integrates with various platforms beyond what request and response messages are supposed to look like and some general guidelines about how the system should behave.
The IdP Initiated Single Logout sequence is described in the following diagram.
The Service Provider Single Logout sequence is described in the following diagram.
A LogoutRequest message looks something like:
<samlp:LogoutRequest xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol” xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” ID=”902380923840239832098423498349848" Version=”2.0" IssueInstant=”2016–05–14T00:45:20Z” Destination=”http://idp.levvel.io/SAML2SLOService”> <saml:Issuer>http://app1.levvel.io/<saml:Issuer> <saml:NameID SPNameQualifier=”http://app1.levvel.io/" Format=”urn:oasis:names:tc:SAML:2.0:nameid-format:transient”>firstname.lastname@example.org</saml:NameID> </samlp:LogoutRequest>
The base64-encoded LogoutRequest message is passed in a SAMLRequest parameter if using the HTTP Redirect Binding — the HTTP Post Binding can also be used.
A LogoutResponse message looks something like:
<samlp:LogoutResponse xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol” xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” ID=”89034589348905340985340985039485430985" Version=”2.0" IssueInstant=”2016–05–14T00:45:23Z” Destination=”http://app1.levvel.io/login/acs” InResponseTo=”902380923840239832098423498349848"> <saml:Issuer>https://idp.levvel.io/sso/saml2/SAML2SLOService</saml:Issuer> <samlp:Status> <samlp:StatusCode Value=”urn:oasis:names:tc:SAML:2.0:status:Success”/> </samlp:Status> </samlp:LogoutResponse>
The base64-encoded LogoutResponse message is passed in a SAMLResponse parameter (again, assuming HTTP Redirect binding).
This all seems very interesting, but in practice has proven to be fragile. From my experience, especially in situations where the web application and its data is highly sensitive, there isn’t really a guarantee that all web applications (or even one for that matter is really going to have its session terminated). What is the problem? Well, you probably noticed the copious use of redirects in the last two diagrams. What happens if the user closes the browser window before all those redirects are finished? The authenticated session (security context) on the Identity Provider may not be terminated; the same could happen on the Service Provider. If either of these is the case and the user has another browser window open, then it is possible the user could be logged back into the application again by going to the launch page of the Service Provider. If the user thinks that they have been logged out,this could be an issue. If it is a shared computer, this will definitely be a problem. It is very important to understand functional requirements, security requirements, and how the user community will truly be using your application(s).
There are numerous other potential pitfalls with this type of logout. The users may not fully understand what clicking the logout button of a single application means, a single malfunctioning or misbehaving Service Provider could disrupt the logout process, native Service Provider session tracking may disrupt the process and other issues may result in the user not being globally logged out — ergo, it can be fragile.
We have finally reached the end of this series’ exploration of SAML use cases. SAML 2.0 is a versatile, but complex specification that can cover a wide variety of use cases. SAML2 can be used within an organization to scale security solutions to 100s or 1000s of Web Applications, SOAP Actors, and REST/API Actors; it can do the same for actors across organizations, lines of business, and public Internet. Once a Principal has authenticated against an IdP, the resulting SAML Assertion can be used to authenticate the Principal against any actor that trusts the IdP (and that the user actually has permission to access, of course). If system actors (SOAP and REST) are chained together (A calls B calls C, so on, so forth) and each uses a SAML Assertion to authenticate against the downstream (next) actor, taking each of these authentication steps together can be called Identity Propagation (or end-to-end identity propagation). Namely, the original Principal’s identity can be securely propagated from the first actor (the Principal) to the final actor in the chain. Moreover, this can be done in a standardized fashion using the SAML 2.0 specification. This is a powerful concept that we will be building upon later.
In the next part of this series, we will look at the JSON Web Token specification and its Use Cases.