Cross-Context External Authn w/ IdP Initiated SSO

[snekse]

Sorry about the lack of clarity.  The 2nd bullet just meant that the user
would not see another login form, but would be logged in via SSO.


"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."

The statement about being lazy about supporting SAML seems odd to me since
it's part of the SAML spec.  The site we have isn't a portal, but the user
can access additional information through one of our partner sites.  My
understanding is that if the user bookmarked the 3rd party site and their
auth expired, then the SP would present identity providers to the user and
our IdP just needs to be able to respond to standard browser SSO auth
requests. Is that way off?


"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."

I think this is the area where I'm most confused.  If the user in on my
website and I want to send them to another website (with them already
authenticated into that site), how would I generate a SAML request from the
browser?  When I first looked at this problem, I figured I'd use standard
browser SSO: Send them to the resource on the SP via a get request, put the
IdP entity ID in the URL as a param, have the SP start the authentication
process and go from there.

Our SP, however, suggested we use the IdP initiated process.  To me, it
looked like the same thing, just minus the inital trip to the SP.  Given
that, it also seemed like with an IdP initiated request, the whole process
would be kicked off by the user making a GET request to the IdP.  The GET
request would get handled in some way, then eventualy render an HTML screen
in the user's browser with an auto-submit HTML form that has the
SAMLResponse embedded which gets POSTed to the SP.

Am I reading this first paragraph wrong?
http://bit.ly/SAML_2_IdP_Initiated_POST_Binding (Section 5.1.4)

"In an IdP-initiated use case, the identity provider is configured with
specialized links that refer to the desired service providers. These links
actually refer to the local IdP's Single Sign-On Service and pass
parameters to the service identifying the remote SP. So instead of visiting
the SP directly, the user accesses the IdP site and clicks on one of the
links to gain access to the remote SP. This triggers the creation of a SAML
assertion that, in this example, will be transported to the service
provider using the HTTP POST binding."

If I'm reading this somewhat correctly, then my website should have a link
to my IdP with parameters to ID the SP resource (via RelayState?).  What I
don't know from the Shibboleth side is what URL (or form POST) do I use for
the link in step 3?

The Shibboleth docs seem to indicate that I should be using
'/idp/profile/SAML2/Unsolicited/SSO'
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO


On Thu, Jul 24, 2014 at 4:17 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140725/356a98cb/attachment.html