Hi David, See below.
On 5/7/15, 1:01 AM, "David Chadwick" <d.w.chadw...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev