CODEWITHSUNDEEP
saml-2.0single-logout
Heiko Theißen
Heiko Theißen

Reputation: 17487

Front-channel SLO mechanism for SAML 2.0 relying IdP on two different domains

Consider a relying SAML identity provider (IdP #1) that does not have its own user base but forwards logon and logoff requests to another SAML identity provider (IdP #2). Here, "forwarding" does not imply that one IdP makes a system-to-system request to the other, but that one IdP sends a response back to the browser that causes the browser to make the next request to the other IdP ("front-channel flow").

During a front-channel single logout flow, the following requests are made (among others):

The requests to IdP #1 made in the first and third bullet point are made to the same hostname, they use the same cookies and therefore happen in the same session that the browser has with IdP #1.

Now imagine that IdP #1 is reachable under different hostnames (for example because it wants to support different domains like idp.cloudservice.com and idp.customer.corp). The SAML Entity ID that IdP #1 uses in all SAML messages to identify itself is independent of the hostname. Therefore the SingleLogoutService of IdP #1 that is known to IdP #2 is also independent of the hostname. This means that the ResponseLocation to which IdP #2 causes the request in the third bullet point to go can either be on idp.cloudservice.com always or it can be on idp.customer.corp always. In half the cases, this will not be the hostname used in the first bullet point, therefore the IdP session cookie will be missed and the single logout flow will fail.

A similar problem with single sign-on is avoided, because the AuthnRequest can contain the AssertionConsumerServiceURL (which is analogous to the ResponseLocation of the SingleLogoutService) as an optional attribute [SAML-Core-2.0, line 2051]. The endpoint for the sign-on Response can therefore be request-specific.

But SAML-Core-2.0 does not allow an analogous optional attribute on the LogoutRequest and hence allows no request-specific ResponseLocation for SingleLogoutService. Is this an oversight?

Upvotes: 0

Views: 147

Answers (2)

Heiko Theißen
Heiko Theißen

Reputation: 17487

The problem can be avoided if IdP #1 uses different SAML Entity IDs depending on the hostname under which it is reached, for example:

GET https://idp.cloudservice.com/saml2/metadata

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
 entityID="idp.cloudservice.com" ...>
 ...
 <IDPSSODescriptor ...>
  <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Location="https://idp.cloudservice.com/saml2/idp/slo"/>
 </IDPSSODescriptor>
</EntityDescriptor>

and

GET https://idp.customer.corp/saml2/metadata

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
 entityID="idp.customer.corp" ...>
 ...
 <IDPSSODescriptor ...>
  <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Location="https://idp.customer.corp/saml2/idp/slo"/>
 </IDPSSODescriptor>
</EntityDescriptor>

IdP #1 must then be registered twice as a service provider on IdP #2, once under each SAML Entity ID, and with different ResponseLocations for the SingleLogoutService.

Upvotes: 0

Wiktor Zychla
Wiktor Zychla

Reputation: 48279

If your IDP sessions are cookie-based then yes, you have a problem.

This is why the LogoutRequest contains the required SessionIndex. Assuming the registry of active sessions is maintained at the IDP, it doesn't really matter what host name the IDP is addressed with: upon receiving the LogoutRequest, the IDP marks the session as inactive in its internal registry and doesn't have to rely on cookies at all.

In your relying scenario (fyi, an IDP that forwards requests to another IDP is usually called a relying IDP), this can be tricky as the relying IDP not only has to maintain a registry of its own sessions but also a mapping between its sessions and sessions at the other IDP the logon was forwarded to.

Upvotes: 1

Related Questions