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