0

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 application where the user triggered the logout sends a LogoutRequest [SAML-Core-2.0, line 2529] to the Location [SAML-Metadata-2.0, line 232] of the SingleLogoutService [SAML-Metadata-2.0, line 652] of IdP #1.
  • IdP #1 responds with an HTML page that causes the browser to send a LogoutRequest to the Location of the SingleLogoutService of IdP #2.
  • IdP #2 ends the user session and responds with an HTML page that causes the browser to send a LogoutResponse [SAML-Core-2.0, line 2569] to the ResponseLocation [SAML-Metadata-2.0, line 235] of the SingleLogoutService of IdP #1.
  • IdP #1 ends the user session and responds with an HTML page that causes the browser to send a LogoutResponse to the ResponseLocation of the SingleLogoutService of the application.

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?

Heiko Theißen
  • 12,807
  • 2
  • 7
  • 31
  • 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 it is addressed with, upon receiving the `LogoutRequest` the IDP marks the session as inactive in the registry and doesn't have to rely on cookies. – Wiktor Zychla Jul 07 '23 at 11:45
  • 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. Not sure if this comment suits you, let me know if I should make an answer out of it. – Wiktor Zychla Jul 07 '23 at 11:46

2 Answers2

1

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.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106
0

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.

Heiko Theißen
  • 12,807
  • 2
  • 7
  • 31