Open Stack

On 08/23/2012 03:41 PM, David Chadwick wrote:
>
>
> On 23/08/2012 19:59, Adam Young wrote:
>
> CUT
>
>>
>> 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.
>
> correct. Username and userID are simply attributes such as role and 
> favouriteDrink. The only difference is that each uniquely identifies 
> the user in the domain whereas the others do not. So they are 
> identifiers. The Admin can select another differentiating attribute 
> such as email address (which is also an identifier). It is unlikely 
> that two users will have all their attributes identical.
>
>> This works, but it doesn't scale.
>
> If MomAndPop want to give different permissions to each individual 
> user, then it is their model that does not scale. Its not the FIM model.
> If MomAndPop want to select individual users from different IDPs then 
> of course they will need to use attributes that are identifiers, 
> otherwise they will select a group of users with each attribute. I am 
> pretty sure that all IDP protocols can send a unique PID for each user 
> with the attribute assertions, so there is always a way to uniquely 
> identify each individual user.
>
>
>> Instead, the user should be put into a grouping from the
>> MomAndPopsLaundry's IdP that then provides the roles.
>
> But this may not uniquely identify a single user

Right.  What I would assume is that they would have some grouping, say 
"contract_administrators"  and each user would get listed in 
there....but perhaps that is really no different than
what you are sugggesting:  the policy engine would just have a list of 
userids instead of storing them inside the IdM database.  But seems like 
it should go in IdM, and be served by IdP, instead of being maintained 
as part of the policy.  Typically, you don't want to deploy new policy 
rules just because a user was added to or removed from a group.


In a Kerberized system, this would be done via a service ticket issued 
using a cross domain trust.  I think that is the right model:  you have 
to go to the other IdP in order to get a credential for their 
resources.  Then the other IdM maintains a list of remote users, from 
multiple domains.





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