[openstack-dev] [Keystone] Federated design from Kent

Adam Young ayoung at redhat.com
Thu Aug 23 18:59:26 UTC 2012


On 08/23/2012 02:28 PM, David Chadwick wrote:
>>>   A user has
>>>> to get a role to effect a change to a resource inside the tenant.  
>>>> That
>>>> role has to be assigned by the administrator of the tenant. THat won't
>>>> come out of the users Identity Management System, but out of the 
>>>> IdM for
>>>> the Domain.
>>>
>>> It could come from attribute mappings (as stated above). The domain
>>> manager can have a rule which states "a user with this attribute from
>>> this IDP gets this role in this tenant"
>> I am not thrilled with that.  Say I am using my Facebook (really big
>> organization) account to validate against a tenant managed by the IdP
>> for MomAndPopsLaundry.  I can't get Facebook to modify its set of
>> attributes for me.  Instead, I need MomAndPopsLaundry to enable my
>> account in their tenant.
>
> I did not quite follow that, sorry. What we have done is used Facebook 
> as the IDP to authenticate the user and provide a set of attributes to 
> the SP, which then grants the user limited access. We have built this 
> into a cloud demo here
>
> https://authz.tas3.kent.ac.uk/proxyS3/
>
> which we showed at Boston last year
>
> and also into university services where we have a public demo here
> https://persistence.kent.ac.uk/logins4life/
>
> In fact all our demos are available from here
> http://sec.cs.kent.ac.uk/demos/ 


If two users have identical attributes, with the exception of their 
username and userId number, and only one of them should get access to  
MomAndPopsLaundry,  then the Admin at MomAndPopsLaundry  has to grant 
the permissions to that userid. This works, but it doesn't scale.  
Instead, the user should be put into a grouping from the 
MomAndPopsLaundry's IdP that then provides the roles.

I'll take a look at the demos above and see if they meet my concerns.





More information about the OpenStack-dev mailing list