Open Stack

Hi Tim

I was implying that the addRole operation would not be used or needed in
the federation case, because all user roles are initially created by
IdPs and then by attribute mappings.

I was not saying anything about the various admin roles that might exist
because as I understand it, there is no limitation on the number of
roles that can be defined in OpenStack.

regards

David

On 08/05/2015 15:52, Tim Hinrichs wrote:
> Hi David,
> 
> See below.
> 
> On 5/7/15, 1:01 AM, "David Chadwick" <d.w.chadwick at kent.ac.uk> wrote:
> 
>> Hi Tim
>>
>> On 06/05/2015 21:53, Tim Hinrichs wrote:
>>> I wondered if we could properly protect the API call for adding a new
>>> Role using the current mechanism.  So I came up with a simple example.
>>>
>>> Suppose we want to write policy about the API call: addRole(user,
>>> role-name).  If we¹re hosting both Pepsi and Coke, we want to write a
>>> policy that says that only someone in the Pepsi admin role can change
>>> roles for Pepsi users (likewise for Coke).  We¹d want to write something
>>> likeŠ
>>>
>>> addRole(<user>, <role>) is permitted for <caller> if
>>>     <caller> belongs to the Pepsi-admin role and
>>>     <user> belongs to the Pepsi role
>>>
>>> The policy engine knows if ³<caller> belongs to the Pepsi-admin role²
>>> because that¹s part of the token.  But the policy engine doesn¹t know if
>>> ³<user> belongs to the Pepsi role² because <user> is just an argument to
>>> the API call, so we don¹t have role info about <user>.  This helps me
>>> understand *why* we can¹t handle the multi-customer use case right now:
>>> the policy engine doesn¹t have all the info it needs.
>>>
>>> But otherwise, it seems, we could handle the multi-customer use-case
>>> using mechanism that already exists.  Are there other examples where
>>> they can¹t write policy because the engine doesn¹t have enough info?
>>>
>>
>> Your simple example does not work in the federated case. This is because
>> role and attribute assignments are not done by Keystone, or by any part
>> of Openstack, but by a remote IDP. It is assumed that the administrator
>> of this remote IDP knows who his users are, and will assign the correct
>> attributes to them. However, these are not necessarily OpenStack roles
>> (they most certainly wont be).
>>
>> Therefore, we have built a perfectly good mechanism into Keystone, to
>> ensure that the users from any IDP (Coke, Pepsi or Virgin Cola etc.) get
>> the right Keystone/Openstack role(s), and this is via attibute mapping.
>> When the mapping takes place, the user is in the process of logging in,
>> therefore Keystone knows the attributes of the user (assigned by the
>> IDP) and can therefore know which Openstack role to assign to him/her.
> 
> I understand the idea of mapping attributes from a remote IDP to
> OpenStack/Keystone roles.  But I don¹t understand the impact on my
> example.  In my example, the policy statement fails to work for one of 2
> reasons:
> 
> 1. there¹s no such thing as a Pepsi-admin role
> 2. The policy engine can¹t check if ³<user> belongs to Pepsi"
> 
> The policy statement fails to work because of (2) for sure.  But are you
> saying it also fails to work because of (1) in the federated case?  I
> would have thought that the Keystone roles used to represent the Pepsi IDP
> attributes would be separate from the Keystone roles used to represent
> Coke IDP attributes, and therefore there¹s be some role corresponding to
> Pepsi-admin and Coke-admin.
> 
> Sorry if this is obvious.
> 
> Tim
> 
>>
>> I hope this helps.
>>
>> regards
>>
>> David
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>