Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc. - Role Assignment

2015-05-09 Thread David Chadwick
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


Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc. - Role Assignment

2015-05-08 Thread Tim Hinrichs
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


Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc. - Role Assignment

2015-05-07 Thread David Chadwick
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

__
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