Open Stack

On 24/08/2012 01:49, Adam Young wrote:
> 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...

The issue is this. Keystone and the cloud service providers do not know 
who these administrators are. So they cannot be listed in Keystone. Only 
the IDP knows which current users have this role. And this set of users 
can dynamically change as people are hired and fired, promoted and 
demoted. So at the time of using the cloud, the IDP issues an assertion 
to Keystone saying that the current user, PID=12344565, has the role of 
contract_administrator. Since contract_administrator is already set up 
as a tenant in Keystone, then this user gets all the rights of this 
tenant. However, for audit purposes, the logs record that it is user 
PID=12344565 who performed the current actions, so there is full 
accountability. If this user is subsequently fired, his PID will never 
appear in the Keystone logs again. Another PID will appear next time, 
denoting it is a different person. If Keystone wants to know the real 
world identity of an administrator, then it must contact the IDP (with 
which it has a contract) informing it that it was user with PID=12344565 
who performed a certain action. So there is joint responsibility for 
applying sanctions.

.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.

No, there is no need for userids in the policy engine if permissions are 
given to the group of administrators. If however, you want to give 
different permissions to different administrators, then you have to 
differentiate these users based on one their unique identifying attributes.

  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.

Exactly

>
>
> 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.

I still dont think you have the right model in mind.
Resources are owned by SPs, not IdPs.
IdPs give attributes to users, and SPs give permissions (to their 
resources) to attributes.
Its the classic ANSI RBAC model.

  Then the other IdM maintains a list of remote users, from
> multiple domains.

Not necessary.

regards

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