School me on hub and spoke federations

[Mike Flynn]

Currently, we authenticate at the enterprise level - when a request comes in, we use the IDp's entityID to look up the associated account and log the user in under that, then use the user specific attributes to personalize the user's experience.  In this hub and spoke scenario, would I need to have an attribute passed that indicates the specific enterprise attempting access since I only have the single federation based entityID?


________________________________
 From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net> 
Sent: Monday, May 13, 2013 11:28 AM
Subject: Re: School me on hub and spoke federations
 

On 5/13/13 2:12 PM, "Mike Flynn" <shibbolethlynda at yahoo.com> wrote:

>Was recently asked to look at Kennisnet.nl as federation for another
>client.  Looking at their fed they call it a "hub and spoke" federation.
>Their metadata only consists of a single SP/Idp pair that Kennisnet
>maintains.  Does not look to work like the
> more traditional federations (a'la InCommon etc).
>
>Google has been pretty worthless trying to get information on how this
>type of federation works.  Can anyone enlighten me?

There's no single model. Most of them tend to be opaque and you're dealing
with just that one IdP for everything, so it may well look like a single
IdP. Some are more complex and are capable of simulating an end to end
federation so that you're effectively seeing the same thing you normally
would. It's likely given that metadata that it's more the former.

-- 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/20130513/d93676af/attachment-0001.html