Open Stack

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