Cross-Context External Authn w/ IdP Initiated SSO

[snekse]

Thanks Scott and Tom.

To be clear, for future readers of this thread, we _are_ the IdP and we are
using Shibboleth for that - we just are not using the IdP for the initial
login to our own site (we'll say for "legacy" reasons).  We're only using
our IdP when we need to generate a SAML response and our "authentication"
process is basically involves looking at a "SESSION_KEYS" table in the
database.  If the user has a record, we know they authenticated with our
www context and have not timed out or logged out, so the IdP considers them
"authenticated".  If they have no record, then the plan was to redirect
them to the www login screen, then once logged in, redirect back to the idp
context to re-check the auth. (Okay, that last part probably isn't totally
clear, but that part is still foggy to me)

Your concern about the user bookmarking the SP resource brings me great
concern that there's still something I don't get.  If I was using the
standard SSO protocol, wouldn't I still run into that issue?




On Fri, Jul 25, 2014 at 11:46 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 7/25/14, 12:09 PM, "snekse" <snekse at gmail.com> wrote:
> >
> >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.
>
> No, as Tom said, there is no standard way to do that. I defined a standard
> way to do that called Request Initiation, and Shibboleth supports it, but
> nothing else does. I recognized that there should be a way to tell an
> SP/app to initiate a SAML flow with a given IdP. Unfortunately nobody else
> cared.
>
> So assuming the SP isn't Shibboleth, no, there's no way to do that
> necessarily.
>
> As a workaround, you can use IdP-initiated SSO if you specifically rely on
> the IdP being Shibboleth, and you already figured out how. The problem is
> that that approach works only if the user is sitting in your portal and
> using the link. And as I said, that's a mistaken assumption. It looks
> great on paper and it gets projects done without regard for whether it
> actually works, but it's not reality.
>
> Once the user gets to the app, they'll bookmark it, and if there's no way
> for them to start at that end and still get signed in via their IdP,
> that's a usability problem.
>
> >Our SP, however, suggested we use the IdP initiated process.
>
> Sure. My response to that tends to involve insults and four letter words,
> but I'll spare you.
>
> >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.
>
> Yes, provided you know the IdP's proprietary method to kick that off, and
> provided the user never has to get into the SP via any other path. I
> believe that's false, as I said, but that's for you to assess.
>
> -- 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/cd3a87b8/attachment.html