Okta Kentor.AuthServices IdentityServer3 IDP-initiated SSO is triggering SP-initiated SSO - error or design?

Question

Using IdentityServer3, Kentor.AuthServices 0.19 (with OWIN middleware) and a standard MVC 4 WebApi 2 app, we have followed instructions at https://github.com/KentorIT/authservices/blob/master/doc/IdentityServer3Okta.md and it appeared that we achieved successful IDP-initiated login.

However, when we looked closely at this, and using KentorStubIdp (where we first noticed we were prompted to provide a SAML response), we found the following

1. IDP hits our endpoint, e.g. identityserver/okta/acs, status 303
2. Successful redirection to our redirection endpoint in our app, which is coded to return a redirection to the identityserver authorisation endpoint, thus var client = new AuthorizeRequest(new Uri(identityServerUrl + "connect/authorize")); var returnUrlForIdp = client.CreateAuthorizeUrl( "{client_identifier}", "id_token token", scopesForAuth, hostUrl, state, nonce, acrValues: string.Format("idp:{0}", idp), responseMode: "form_post" ); return Redirect(returnUrlForIdp);
3. This results in a 302 to identityserver/connect/authorise. It appears that this has all the login information it needs, and I would have expected a 200 straight into the app, but instead we get a 302 to identityserver/login?signin=xxx which gives a 401 which appears to trigger...
4. The subsequent call to the login endpoint gets a 303 redirection back to the IDP, which marks the start of an ultimately successful SP-initiated login. Meaning it comes back to identityserver/okta/acs, then the /callback endpoint, then /connect/authorise then the user is logged in.

I cannot find any meaningful difference between the first and second calls to /connect/authorise except

1. The successful attempt is preceeded by a call to identityserver/callback
2. Cookies for idsvr and idsvr.session appear not to be set on the first call but are in the second

Also, Kentor config settings seem to be in order - e.g. AllowUnsolicitedAuthnResponse = true and AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Passive although this last one didn't seem to have an effect either way

At this point I'm just trying to work out a) whether this is how it is supposed to work under the covers and b) if not, where should I focus my attention to diagnose the problem.

Is there a particular set of circustances that trigger authservices to initiate an SP-initiated SAML request if a, IDP-initiated one is lacking info?

Any advice much appreciated.

Answer 1

Using Idp-initiated sign on with SAML2 + OIDC is a bit tricky, as OIDC doesn't support it. Which means that IdSrv3 is not really built for that scenario either.

The outline of what you would need is:

1. Idp sends unsolicited response to IdSrv3/AuthServices.
2. AuthServices validates response
3. IdSrv3 establishes log in session on IdSrv3.
4. User is redirected to client application's login init url
5. Client app initiates a OIDC sig in towards IdSrv3.
6. IdSrv3 Single signs on with session established in 3.
7. User is redirect back to client app.

Looks like step 2 works, but step 3 is not properly done. Which means that in step 6 there is no session, so user is redirected all the way to the Idp to pick up existing session. This works, but is somewhat ugly. And if you later on want to do single sign out there is a session count mismatch which might cause issues.