[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