Cross domain IdP trust

Cal Heldenbrand cal at fbsdata.com
Tue Nov 22 17:06:47 GMT 2011


I suppose that would solve the problem, if all SPs could authenticate at
any given source.  Then an unauthenticated request to a peer SP would flow
through the already authenticated IdP.  But the user would still have to
perform some selection process to choose the IdP.

In my case, I'd like the first hit to all subsequent SPs to authenticate
without any extra clicks or decisions involved.

Plus, as this peer (discovered) relationship grows it becomes a complex
selection process.  I'm thinking potentially this authentication method
could grow to hundreds of SP/IdP pairs.  In that case, a tiered IdP
paradigm would fit better.  One master authenticator to keep track of them
all, but each session could transparently propagate to all systems.

I'm sort of in the brainstorming phase now... but now that I think about
this more, I believe I might have just described OpenID.

Any thoughts on other protocols that accomplish this?

Thanks,

--Cal

On Tue, Nov 22, 2011 at 10:50 AM, Peter Schober
<peter.schober at univie.ac.at>wrote:

> * Cal Heldenbrand <cal at fbsdata.com> [2011-11-22 17:35]:
> > Each IdP has an entirely separate user/pass namespace.  And, I want each
> > IdP to "trust" each other, in the sense that any user logged in at any of
> > the IdPs will *transparently* have access to each SP without logging in
> > again.  No discovering IdP's or selecting where to log in, and only a
> > single authentication allows access to all domains.
>
> I probably don't understand the requirements but if all three SPs
> federate with all three IdPs the only problem left to solve is IdP
> discovery, no?
> -peter
> --
> 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/20111122/77188257/attachment.html 


More information about the users mailing list