Understanding flow / federation
Nate Klingenstein
ndk at internet2.edu
Sun Sep 23 19:22:28 EDT 2012
Bo,
> As some of You properly already have noticed, I have been trying to
> setup an SP and an idP, and I now have a working setup that I more and
> less understand. But my goal is the join my system with an ADFS2 setup
> outside our system (isolate a large MS environment). I am sure there
> are
> some documentation somewhere that I either have not been reading
> properly or I plain have overlooked, and any points in the right
> direction would be really appreciated.
The main Wiki area discussing how Shibboleth works is:
https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth
> But in my struggle to understand Shibboleth, I also missed some
> information on the flow of the system, so I try to illustrate by
> listing
> the flow, as far as I have understand it at the moment. Understanding
> just this basic central flow in the beginning would have been a big
> help, when I started out on this quest.
>
> Is this correct ?
You might find this link helpful.
https://wiki.shibboleth.net/confluence/display/SHIB2/FlowsAndConfig
I appreciate that it's useful for understanding. Is there somewhere
that you would have expected to find this information, but didn't?
> SP
> * Resource protected by SP
> * SP don't know the user
> * SP finds an idP that may provide this
> * use single default idP
> * use mapper to map more then one resource to more idP's
> * use discover to make some kind of auto idP selection
> * get claim/assertion response from idP
>
> idP
> * get auth request from SP
> * look for a way to resolve it
> * use the LoginHandler (in my case)
> * What else are possible here ?
There's the entire attribute authority, of course. Beyond that,
there's a variety of other things the IdP can do, but defaults for
virtually all deployments. You would need to describe what you want
to accomplish.
> * pack the SAML response, and post it back to SP
>
> Regarding the idP my only understanding is that it gets an request
> from
> the SP, and direct it to the LoginHandler, but how will it work if I
> added another idP (and how is this done in relaying-party.xml), how
> will
> it know when to use the current idP or direct it to some of the other
> idP's in the federation (or have I misunderstood how federation setup
> works) for authentication ?
There's a variety of ways to associate a user with the right IdP.
There are many ways to do it, and there is no single best way, so it
requires some understanding by deployers. The problem space is known
as "discovery". You might find this section of the NET+ Identity
Guidance for Services useful:
https://spaces.internet2.edu/display/NetPlusIDG/NET+Plus+Identity+Guidance+for+Services
#NETPlusIdentityGuidanceforServices-1.DiscoveryandAuthentication
> I have left out any info on meta data at first, to focus on the
> request
> flow.
Metadata is generally just exchanged out of band using flat files that
are typically vetted and published by federations, in today's world.
All of that is subject to evolution.
Hope this helps,
Nate.
More information about the users
mailing list