Search code examples
samladfs

ADFS as a SAML Service Provider interacting with other Relying Parties

I have a web application that is capable of being a SAML 2.0 IdP as well as a SP, and have successfully implemented SSO between my platform and ADFS, but only when ADFS is the IdP.

This is my first foray into integrating with my platform, using ADFS as a SP and I'm having problems understanding the SSO flow.

In my situation, I have three players: WebApp (IdP), ADFS (SP), RelyingParty (S). The trusts are set up in ADFS, and the user experience is supposed to be a successful login to the RelyingParty having logged in to the WebApp

Setting up a new Claims Provider Trust in ADFS with my web app appear to work perfectly. I can go to my app's IdP-initiated URL which sends an unsolicited SAML message to ADFS's ACS URL. When I do this, I get redirected to /idpinitiatedsignon with the message "You are signed in" and a drop-down of the relying parties I've already set up.

If I click on the login button for the RP, ADFS generates a new AuthNRequest to my web app before eventually getting to the Relying Party.

So, seeing this behaviour, I have two questions:

  1. I would have thought that the initial sign in to ADFS via my IdP-initiated login would have got me though to my RP without the need for going back to the IdP for another sign-in. have I misunderstood, or have I just misconfigured ADFS?

  2. What mechanism is ADFS determining that my IdP is to be used? If I go to the ADFS /adfs/ls/idpinitiatedsignon.aspx page in a browser, I've not involved my IdP at all, and selecting my RP does use my IdP to authorize the user but I've no idea how this is determined since there's no link between the Trust Claims Provider and the Relying Party in ADFS configuration.

Solution

  • Completely forgot to return to post the solution to this. The reason I was seeing the behaviour I was is simple: ADFS (and AAD) enforces SP-initiated flow when it receives an unsolicited Assertion. Presumably the absence of a known ReplyTo attribute triggers this behaviour.

    I'm not certain if this is a behaviour that can be modified, but in any rate, it doesn't completely matter as long as your IdP supports SP-initiated flows.

    So, answering my own points:

    Q1 The flow goes:

    1. Service Provider generates an unsolicited SAML Response (with Assertions)
    2. IdP (ADFS or AAD in my case) detects an unsolicited Response and triggers an SP-initiated SSO flow (see Q2, below)
    3. SAML SP-initiated flow behaves as expected in IdP and the user is signed in.

    Q2 ADFS is using the Issuer to determine which RP to initiate the SSO flow with. As long as it matches one of the Relying Parties set up, then all is well.