Cross-Context External Authn w/ IdP Initiated SSO

[Cantor, Scott]

On 7/24/14, 5:00 PM, "snekse" <snekse at gmail.com> wrote:

>I'm working on getting an IdP setup so I can provide authentication to a
>3rd party SP.  But here's my scenario:
>
>* User logs into www.example.com
>* User clicks on a link that should take them to
>www.external.com, logged in behind the scenes
>* My Shibboleth IdP sits at idp.example.com
>* Authentication on www.example.com varies by customer. Some are using
>LDAP, most use U/P.

I don't understand that, really, so I can't answer any questions about it.
In particular, what is the meaning of the second bullet? I don't know what
"logged in behind the scenes" means, but it doesn't sound like anything
SAML does.

Note that, despite nobody actually doing it, the best way to do the fourth
bullet is to hide all those methods behind one or more SAML IdPs and
abstract all the authentication methods into one facade. Combining all
that at the application is very challenging in most cases, and usually
requires a very well-defined session mechanism that is manageable from
code that's separate from the application.

> 1. Am I correct that this is best done as an IdP Initiated SSO request?

Very doubtful, that's almost never the right answer to anything except
being lazy about supporting SAML, or because of an unwillingness to handle
IdP discovery.

It's very common in enterprise scenarios to pretend users will start at
portals and click the links we want them to, but they don't do that. They
ignore portals and they bookmark applications. So "pushing" people into
apps never works terribly well, IMHO.

>2. Is the resource is the user is requesting
>/idp/profile/SAML2/Unsolicited/SSO? The UML diagrams that I've seen show
>in IdP-init that the user requests a resource from the IdP after login. I
>want to make sure I understand what I'm supposed to request on the IdP.
>It seems like I should call that URL with query params like providerId
>and shire

That's how you invoke it, yes. You shouldn't use it, and it's proprietary.
Generate a SAML request and do it properly. Or use a real SP
implementation that does it for you.

>3. How would you do this; am I going about this the wrong way? It seems
>like because my app is in the www context and my IdP is in a different
>context, it makes determining if they are already authenticated harder
>than it should be.

There is no general way to do that. That's how SSO is, because the whole
definition is that it's cross-domain. The feature in SAML that's designed
around probing for an existing session at an IdP is the IsPassive flag,
but that requires significant application involvement. You cannot
otherwise well if somebody is or isn't authenticated at an IdP from the
perspective an app, or more to the point if they will be prompted if you
send them to the IdP.

>I was planning on
> using ExternalAuthn for the LoginHandler, but now I'm starting to really
>question myself. Really just interested to hear the different ways this
>could be accomplished and what the pros/cons are to different methods.

The purpose of External is to handle mechanisms that aren't simple to
configure with JAAS or with the container/RemoteUser model, or to support
the latter with more advanced SAML options (like the IsPassive or
ForceAuthn options).

>4. Can I use www.example.com/login <http://www.example.com/login> to
>authenticate? All the example I've seen show a login page that is being
>served by the IdP directly.  If I'm using ExternalAuthn and I need to
>force a login, I'd like to use my existing login logic.

The UsernamePassword handler serves the login page directly. The
RemoteUser option delegates it to the container, so you can deploy an
existing container solution, a second SSO system, etc. External leaves it
to you write code to integrate with an arbitrary approach. Once you get
control in a servlet or JSP within the IdP's context, you have to deal
with getting an identity you can pass back using request attributes in the
manner defined.

None of that pertains to the SP, your application, or to how SSO is
initiated by the SP. That's all behind the scenes at the IdP.

-- Scott