[FIXED] How to recognise formerly SP initiated authentication on subsequent IdP redirects to SP

Issue

When using SAML2 to perform a Service Provider (SP) initiated authentication, a secret ID is generated by the SP and the added to the the Authentication Request. The Identity Provider (IdP) responds to this AuthnRequest and echoes the secret ID of the SP ("in response to") to ensure coherence of the Authentication Request/Response. The authentication at the SP can then proceed (after verifying a whole lot of other things).

What happens when the current authentication session at the IdP is still valid and the "IdP Portal" is equipped with the ability to redirect to the SP by some sort of bookmark/link such as application icons in Office356. Is there any provisioning in the SAML2 standard to continue the formerly initiated session at the Service Provider (a IdP session id of some sort)? It would be odd if a re-authentication would be necessary in this case because the current session is still active (I wouldn't think this falls into the category of IdP initiated authentication). The IdP hits the ACS endpoint when this app icon is clicked, but I'm not sure where to look in the Authentication Response (according to SAML2 spec and more specifically in an Azure AD IdP response). Any help would be appreciated.

Solution

When "federating" identities, the session handling is entirely up to the individual systems. There is no real mechanism within the protocol to tie those separate sessions together. The Identity Provider (IdP) can inform the Service Provider (SP) of the length of time that the SP can consider the identity assertion "valid", but that's about it. Typically, if the identity being authenticated has a session at the IdP, then the IdP will just issue the assertion. When the user is redirected back to the SP, if they had a session there, then it's up to the SP if they allow that session to continue.

In order to tell the two types of assertion apart, the following guideline can be used.

• For IdP-initiated, the RelayState attribute will generally have a URL of where the User wishes to be sent at the SP, after the SP consumes and accepts the assertion from the IdP.
• For SP-initiated, when the SP starts the authentication process, it will insert an opaque ID in the RelayState attribute of the AuthnRequest. The IdP must use that same ID in the Assertion's RelayState field (and the same ID usually ends up in the InResponseTo field as well).

So, that's a whole lot of words to say "The handling at either end, IdP or SP, is determined solely by that end (though maybe there's some conversation about how the ends handle them)."

Answered By - Andrew K.

Answer Checked By - David Goodson (PHPFixing Volunteer)