Open Stack

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 hope this helps.

regards

David