IdP initiated login with ThinkTecture IdentityServer v3

Question

Summary

In SAML there is a concept of IdP-inititated login, meaning that the Identifying Party (IdP) can send an unsolicited token to the Relying Party (RP / the consuming application) and the user can be logged in without ever calling out to the IdP. I have a scenario where I need to do that but I want ThinkTecture Identity Server v3 to be in the middle as I will be handling my normal auth (as in non-SAML everyday stuff) in there. I cannot do a call out to the SAML IdP for reasons beyond my control. What I would like to do is this:

I have spent a fair bit of time looking at this and I have also looked at the spec which does talk about initiating login from a third party, but if I understand it correctly, it still starts with the 3rd party directing the user to the RP, which then sends a login request to the IdP (which would be the ThinkTecture Identity Server), which is not really what I need.

In summary, I don't think OpenID Connect has an equivalent of SAML's IdP-initiated SSO. Is that correct or am I just unable to figure it out or is it that ThinkTecture IdentityServer doesn't support it?

More details

• I have successfully used KentorIT's AuthServices OWIN Middleware to implement IdP-initiated SAML SSO directly into a website, not using IdSrv at all.
• I have also integrated Kentor's OWIN Middleware with IdSrv so that my website redirects to IdSrv, which then redirects to the SAML Server where I log in, come back to IdSrv, which then translates the SAML token and sends an OpenID Identity Token back to my website.
• For fun, I have also used Kentor's library to just have an MVC controller which unpacks the SAML token, so if I wanted I could do some manual authentication with that.

It all works rather beautifully, big thanks to ThinkTecture and to KentorIT. Alas, it all still starts with my website and ends up with a redirect to the SAML server, which I can't do in my scenario for non-technical reasons.

Alternative solution

I can of course just dispense with IdSrv alltogether in this scenario but I have reasons for having IdSrv in the middle and having all my authentication go via that. So my thinking at the moment is to do this flow:

1. The SAML Server sends a SAML token to a specific URL on my website.
2. My website will re-post that token to the Identity Server as-is. The Identity Server has got the KentorIT OWIN middleware installed so this will simply log the user in to IdSrv, which means IdSrv sets an auth cookie.
3. IdSrv does a simple redirect back to another URL on my website and does not include any tokens. So far this has got nothing to do with IdSrv really.
4. My website now issues an authentication request to IdSrv
5. Because the user is already logged in to IdSrv, IdSrv will immediately respond and redirect the user back to my website with an Identity Token That is a lot of redirects but it should work.

Before I start implementing it, can anyone tell me if this is the right way to go about it or am I missing something really obvious?

EDIT 1

It looks like that idea won't work either. Essentially what I need to do is to use IdP initiated SAML SSO to authenticate to Identity Server, then redirect to the RP and get the RP to redirect to Identity Server with an authentication request. However, as far as I can tell, there is no way to get Identity Server to log in except as part of an RP request. In other words, even though my SAML middleware is happily accepting the unsolicited token, IdSrv ignores the SAML middlewares request to log it in (which I supposed is fair enough).

So, I think an alternative solution is to write a controller that can validate the SAML token and directly call IdSrv in code running on the same server and tell it to log the user in with a principal I manually construct.

The (new) question is, does Identity Server expose a mechanism for me to log a user in, in code, so Identity Server sets the appropriate cookies for the user?

Answer 1

The short answer is that this is not possible at the moment.
I have opened an issue with Identity Server and developed some proof-of-concept code for now.
This answer is just here as a placeholder for now - when a solution emerges I will update this answer with a sensible level of detail.