CODEWITHSUNDEEP
samlsaml-2.0idpsingle-logout
DonLimpio
DonLimpio

Reputation: 1

Issue with SAML 2.0 single logout - How should IdP terminate SP sessions running in different user agents?

I'm having an issue with SAML 2.0 single logout.

I have a SAML 2.0 environment with an IdP (identity provider) and a web application acting as SP (service provider).

As user I start a web application session in an user agent (browser). The user is authenticated using the IdP.

In a different browser (running on the same client machine) I start another session as the same user in the same web application, i.e. in the same SP in terms of SAML.

Now I have two independent web application sessions where the same user is authenticated.

When I then perform a single logout initiated by the IdP in one of the browsers the IdP issues only one logout request which terminates the session that is running in that browser. The element of the logout request issued by the IdP equals the one that was sent by the IdP in the attribute SessionIndex of the AuthnStatement of the Assertion sent to the SP using that browser (user agent).

Wouldn't it actually be necessary for the IdP to send logout requests for all open sessions in order to achieve a true "single logout"?

Upvotes: 0

Views: 1765

Answers (1)

identigral
identigral

Reputation: 3949

Short answer: The SAML spec allows for Single Logout (SLO) to behave the way you want but a typical implementation isn't that sophisticated.

From SAML Profiles spec, section 4.4 (Single Logout Profile):

Once a principal has authenticated to an identity provider, the authenticating entity may establish a session with the principal (typically by means of a cookie, URL re-writing, or some other implementation-specific means). The identity provider may subsequently issue assertions to service providers or other relying parties, based on this authentication event; a relying party may use this to establish its own session with the principal. In such a situation, the identity provider can act as a session authority and the relying parties as session participants.

If the SLO sequence were to be initiated by one of the session participants, this whole discussion would be moot. The spec requires the session participant to identify the "shared" session being terminated via a unique ID (aka session index) that was originally sent to the session participant by the identity provider. As required by the spec, this ID will be different in your SP session #1 vs SP session #2.

...but when the SLO sequence is initiated by the IdP, your scenario is possible. Section 4.4.4.1 talks about the rules around issuing and processing <LogoutRequest>:

If the requester is a session participant, it MUST include at least one <SessionIndex> element in the request. [...] If the requester is a session authority (or acting on its behalf), then it MAY omit any such elements to indicate the termination of all of the principal's applicable sessions

Translation: if you could somehow tell the IdP to issue a <LogoutRequest> without a <SessionIndex> and your SP is sophisticated enough to correctly interpret such request and the SP can terminate all sessions for a particular user via its backend, then you've won.

In reality, the combination of conditions above is a very tall order. Out of the box, most IdPs will not issue a <LogoutRequest> without a <SessionIndex>. The very few SPs that even bother implementing SLO will not accept a request without a <SessionIndex>. In an extremely rare case where you'll be able to come up with a correct <LogoutRequest> and SP won't choke on it, you'll be very, very lucky if the SP correctly identifies all IdP-initiated sessions AND will be able to terminate them via the backend.

Upvotes: 0

Related Questions