Keystone/VOManagement - Revision history

David Chadwick at 18:29, 11 December 2014

2014-12-11T18:29:17Z

Kwss at 12:13, 5 June 2014

2014-06-05T12:13:42Z

David Chadwick at 13:35, 23 April 2014

2014-04-23T13:35:28Z

Kwss at 20:47, 22 April 2014

2014-04-22T20:47:47Z

Kwss at 22:24, 15 April 2014

2014-04-15T22:24:50Z

David Chadwick: Created page with "

Introduction

A Virtual Organisation (VO) is a group of people who work together in a similar way to members of a real world organisation. However, in a VO the member..."

2014-03-25T17:41:00Z

Created page with "<h1>Introduction</h1> A Virtual Organisation (VO) is a group of people who work together in a similar way to members of a real world organisation. However, in a VO the member..."

New page

<h1>Introduction</h1>

A Virtual Organisation (VO) is a group of people who work together in a similar way to members of a real world organisation. However, in a VO the members may be a collection of users from multiple organisations who are collaborating together. Different users in the VO will typically have different access rights to the VO’s resources, so whilst they are all members of the same VO, they will typically not have the same roles within the VO.
<p>
Openstack services have the concept of groups – users can be assigned membership in a group, and a group can be granted OpenStack roles and permissions in a bulk manner. An administrator can create a role in a VO by assigning a group to a number of VO users and then setting the correct OpenStack roles and permissions for the group.

<h2>VO Role Naming and VO Administration</h2>

Typically different VOs will have different administrators. We therefore need to distribute the management of VO roles (group names) to different administrators. How is this possible in OpenStack?
<p>
One way would be to make each VO a separate Keystone domain, and have the domain name equal to the VO name, then the group name can equal the VO role name. Different VO administrators can then create different groups (VO roles) within their own Keystone domains.
<p>
If different domains is not desirable, then roles in VOs could be indicated by individual group names formulated as <VOname>.<RoleName>. A set of administrators for the (default) domain could be created, and users with both the admin role and <VOname>.<RoleName> could be given administrative rights for that VO role.

<h2>Identifying VO members</h2>

Regardless of the way VO roles are named and managed, in a large cloud deployment with federated authentication enabled the VO administrator might not know the identifier or identity attributes issued for each VO member by their respective IdPs. Because of this we propose that a management utility should be available for administrators to organise the membership of VOs, by inviting VO members to self-register. In this way, neither the administrator nor the VO member need be aware of either the identifier or identity attributes issued to him/her by their IdP.

<h2>Proposal</h2>

The proposed VO Management utility should consist of five API functions:
<li>1. The administrator should be able to create a new VO role and delete an existing VO role. A VO role is defined as a group name with a PIN number associated with it. The administrator can distribute the group name and PIN to proposed members of the VO role, so that they can request membership (i.e. self-register).</li>
<li>2. The members should be able to request membership of the VO role using the PIN and group name. They should also be able to request leaving any VO role they are a member of at any time (without using the PIN).</li>
<li>3. The administrator should be able to view, accept and deny VO role membership requests.</li>
a. View should list all outstanding membership requests.
b. Accept should create a mapping rule that assigns the group to the member in question, and remove the request.
c. Deny should simply delete the request.
<li>4. The administrator should be able to remove VO role members and modify VO role memberships e.g. Change a user from VO.role1 to VO.role2. (Note. This might be available already as an existing Keystone admin operation on groups.) </li>
<li>5. A user should be marked as blacklisted when he has made three attempts to join a VO role with the incorrect PIN. The administrator should be able to view blacklisted users, and delete them.</li>

<h2>New Entities</h2>

<h3>Virtual Organisation Role (VO-role)</h3>
Attributes:
<p>

“name’ (string) the VO role/group name
<p>

“PIN” (string) the secret PIN for group membership
<p>

“automatic_join” (boolean) whether users joining with a valid PIN should be joined to the VO role automatically or manually confirmed by an administrator. It should default to false (manual confirm).

<h3>Virtual Organisation Blacklist (VO-blacklist)</h3>
Attributes:
<p>

“user_id” (string) The user ID who tried to join
<p>

“idp” (string, FK) The IdP which authenticated the user
<p>

“group_id” The ID of the VO role/Group the user tried to join
<p>

“count” The number of incorrect attempts. (max three)
<p>

<h3>Virtual Organisation Request (VO-request)</h3>
Attributes:
<p>

“user_id” (string) The user ID who wishes to join
<p>

“idp” (string, FK) The IdP which authenticated the user
<p>

“group_id” The ID of the VO role/Group the user requests membership in.

@@ Line 1: / Line 1: @@
 <h2>Introduction</h2>
 <p>A Virtual Organisation (VO) is a group of people who work together in a similar way to members of a real world organisation. However, in a VO the members may be a collection of users from multiple organisations who are collaborating together. Different users in the VO will typically have different access rights to the VO’s resources, so whilst they are all members of the same VO, they will typically not have the same roles within the VO.</p>
-<p>Openstack services have the concept of groups – users can be assigned membership in a group, and a group can be granted OpenStack roles and permissions in a bulk manner. An administrator can assign users to a VO role by assigning group membership to them, and then setting the correct OpenStack roles and permissions for the group.</p>
+<p>Openstack services have the concept of groups – users can be assigned membership in a group - and different groups can be granted different OpenStack access rights through Keystone roles. Consequently there is a significant similarity between a VO role and a Keystone group. A Keystone administrator can effectively assign users to a VO role by assigning a group membership to them, and then setting the correct OpenStack roles and permissions for the group.</p>
 <h2>VO Role Naming and VO Administration</h2>
-<p>Different VOs may have the same VO role names, but these would need to be different groups in OpenStack. How is this to be implemented?</p>
+<p>Different VOs may have the same VO role names, e.g. member or manager, but these need to be different groups in OpenStack. How is this to be implemented?</p>
-<p>Typically different VOs will have different administrators. We therefore need to distribute the management of VO roles (group names) to different administrators. How is this possible in OpenStack?</p>
+<p>Fortunately Keystone has the concept of domains, and groups are created within domains. So if we equate a Keystone domain to a VO, and a VO role to a group within that domain, we can have an easy mapping from VO roles to groups.</p>
-<p>One way would be to make each VO a separate Keystone domain, and have the domain name equal to the VO name, then the group name can equal the VO role name (assuming that groups are bounded by domains). Different VO administrators can then create different groups (VO roles) within their own Keystone domains.</p>
-<p>If different domains is not desirable, then roles in VOs could be indicated by individual group names formulated as <VOname>.<RoleName>. If group names are not bound to domains, then group names will have to be <VOname>.<RoleName> in order to keep them globally unique.  A set of administrators for the (default) domain could be created, and users with both the admin role and <VOname>.<RoleName>  could be given administrative rights for that VO role.</p>
+<p>Typically different VOs will have different administrators. If a VO administrator is a domain administrator, then different VO administrators can create different VO roles (as groups) within their own Keystone domains.</p>
 <h2>Identifying VO members</h2>
-<p>Regardless of the way VO roles are named and managed, in a large cloud deployment with federated authentication enabled the VO administrator might not know the identifier or identity attributes issued for each VO member by their respective IdPs. Because of this we propose that a management utility should be available for administrators to organise the membership of VOs, by inviting VO members to self-register. In this way, neither the administrator nor the VO member need be aware of either the identifier or identity attributes issued to him/her by their IdP. The proposed system will take the name of the IdP and the unique ID assigned to the user by the IdP as the inputs to the mapping function, and will automatically create a mapping rule for this user.</p>
+<p>In a large cloud deployment with federated authentication enabled the VO administrator might not know the identifier or identity attributes issued to some or all VO members by their respective IdPs. Because of this we propose that a management utility should be available for administrators to organise the membership of their VO roles, by inviting VO role members to self-register. In this way, neither the administrator nor the VO role member need be aware of either the identifier or identity attributes issued to him/her by their IdP. The proposed system will take the name of the IdP and the unique ID assigned to the user by the IdP as the inputs to the mapping function, and will automatically create a mapping rule for this user, to map him or her into the appropriate group in the appropriate domain.</p>
-<p> If the VO administrator does know the identity attributes that will characterize his VO members, then he can create the mapping rules using the existing mapping API and none of this new functionality is needed.</p>
+<p> If on the other hand, the VO administrator does know the identity attributes that will characterize his VO role members, then he can create the desired mapping rules using the existing mapping API and none of this new automatic mapping functionality is needed.</p>
 <h2>Proposal</h2>
@@ Line 19: / Line 19: @@
 The proposed VO Management utility should consist of five categories of API functions:
 <ol>
-<li>The administrator should be able to create a new VO role, list existing VO roles, and delete an existing VO role. A VO role is defined as a group name with a PIN number or password associated with it, to be used for user self-registration to the VO role. The administrator can distribute the group name and PIN/pw to proposed members of the VO role, so that they can request membership (i.e. self-register).</li>
+<li>The administrator should be able to create a new VO role, list existing VO roles, and delete an existing VO role. A VO role is defined as a domain/group name with a PIN number or password associated with it, to be used for user self-registration to the VO role. The administrator can distribute the VO role (domain/group name) and PIN/pw to proposed members of the VO role, so that they can request membership (i.e. self-register).</li>
-<li>The members should be able to request membership of the VO role using the PIN/pw and group name. They should also be able to request leaving any VO role they are a member of at any time (without using the PIN). In addition they should be able to list the VO roles they are a member of and also get a list of fellow members of a VO role.</li>
+<li>The members should be able to request membership of the VO role using the PIN/pw. They should also be able to request leaving any VO role they are a member of at any time (without using the PIN). In addition they should be able to list the VO roles they are a member of and also get a list of fellow members of a VO role.</li>
 <li>The administrator should be able to view, accept and deny VO role membership requests.</li>
 <ol type="a">
 <li>View should list all outstanding membership requests.</li>
-<li>Accept should create a mapping rule that assigns the group to the member in question, and remove the request.</li>
+<li>Accept should create a mapping rule that assigns the domain/group to the member in question, and remove the request.</li>
-<li>Deny should simply delete the request.</li>
+<li>Deny should simply delete the membership request.</li>
 </ol>
 <li>The administrator should be able to remove VO role members and modify VO role memberships e.g. Change a user from VO.role1 to VO.role2. (Note. This might be available already as an existing Keystone admin operation on groups.) </li>
-<li>A user should be marked as blacklisted when he has made three attempts to join a VO role with the incorrect PIN. The administrator should be able to view blacklisted users, for all VO roles or for a single VO role, and delete them to allow them to again attempt to join VO roles.</li></ol>
+<li>A user should be marked as blacklisted when he has made three attempts to join a VO role with the incorrect PIN/password. The administrator should be able to view blacklisted users, for all VO roles in his domain, and remove them from the blacklist to allow them to again attempt to join one or more VO roles.</li></ol>
@@ Line 37: / Line 37: @@
 <p>Attributes:</p>
 <p>"id" (string) The ID of the VO role</p>
-<p>“vo_name" (string) the VO role/group name</p>
+<p>“vo_name" (string) the VO/domain name</p>
-<p>“vo_role" (string) the VO role/group role</p>
+<p>“vo_role" (string) the VO role/group name</p>
-<p>"description" (string) the description of the VO role
+<p>"description" (string) the description of the VO role</p>
-<p>"group_id" (string, FK) The ID of the group which has this role</p>
+<p>"group_id" (string, FK) The ID of the group which is this VO role</p>
 <p>"enabled" (boolean) Whether the VO role is active</p>
-<p>“pin” (string) the secret PIN for group membership</p>
+<p>“pin” (string) the secret PIN/password for VO role membership</p>
 <p>“automatic_join” (boolean) whether users joining with a valid PIN should be joined to the VO role automatically or manually confirmed by an administrator. It should default to false (manual confirm).</p>
@@ Line 48: / Line 48: @@
 <p>Attributes: </p>
 <p>"id" (string) The ID of the blacklist entry</p>
-<p>“user_id” (string) The user ID who tried to join </p>
+<p>“user_id” (string) The IdP asserted ID of the user who tried to join </p>
 <p>“idp” (string, FK) The IdP which authenticated the user </p>
-<p>“group_id” The ID of the VO role/Group the user tried to join</p>
+<p>“group_id” The ID of the group the user tried to join</p>
-<p>“count” The number of incorrect attempts. (max three)</p>
+<p>“count” The number of incorrect attempts before being blacklisted (configurable, default three)</p>
-<h3>Virtual Organisation Request (VO-request)</h3>
+<h3>VO Role Request (VORole-request)</h3>
 Attributes:
 <p>"id" (string) The ID of the VO join request</p>
-<p>“user_id” (string) The user ID who wishes to join</p>
+<p>“user_id” (string) The IdP asserted ID of the user who wishes to join</p>
 <p>“idp” (string, FK) The IdP which authenticated the user</p>
-<p>“group_id” The ID of the VO role/Group the user requests membership in.</p>
+<p>“group_id” The ID of the group the user requests membership in.</p>

@@ Line 17: / Line 17: @@
 <h2>Proposal</h2>
-The proposed VO Management utility should consist of five API functions:
+The proposed VO Management utility should consist of five categories of API functions:
 <ol>
 <li>The administrator should be able to create a new VO role, list existing VO roles, and delete an existing VO role. A VO role is defined as a group name with a PIN number or password associated with it, to be used for user self-registration to the VO role. The administrator can distribute the group name and PIN/pw to proposed members of the VO role, so that they can request membership (i.e. self-register).</li>
-<li>The members should be able to request membership of the VO role using the PIN/pw and group name. They should also be able to request leaving any VO role they are a member of at any time (without using the PIN).</li>
+<li>The members should be able to request membership of the VO role using the PIN/pw and group name. They should also be able to request leaving any VO role they are a member of at any time (without using the PIN). In addition they should be able to list the VO roles they are a member of and also get a list of fellow members of a VO role.</li>
 <li>The administrator should be able to view, accept and deny VO role membership requests.</li>
 <ol type="a">
@@ Line 28: / Line 28: @@
 </ol>
 <li>The administrator should be able to remove VO role members and modify VO role memberships e.g. Change a user from VO.role1 to VO.role2. (Note. This might be available already as an existing Keystone admin operation on groups.) </li>
-<li>A user should be marked as blacklisted when he has made three attempts to join a VO role with the incorrect PIN. The administrator should be able to view blacklisted users, and delete them.</li></ol>
+<li>A user should be marked as blacklisted when he has made three attempts to join a VO role with the incorrect PIN. The administrator should be able to view blacklisted users, for all VO roles or for a single VO role, and delete them to allow them to again attempt to join VO roles.</li></ol>

@@ Line 1: / Line 1: @@
 <h2>Introduction</h2>
 <p>A Virtual Organisation (VO) is a group of people who work together in a similar way to members of a real world organisation. However, in a VO the members may be a collection of users from multiple organisations who are collaborating together. Different users in the VO will typically have different access rights to the VO’s resources, so whilst they are all members of the same VO, they will typically not have the same roles within the VO.</p>
-<p>Openstack services have the concept of groups – users can be assigned membership in a group, and a group can be granted OpenStack roles and permissions in a bulk manner. An administrator can create a role in a VO by assigning a group to a number of VO users and then setting the correct OpenStack roles and permissions for the group.</p>
+<p>Openstack services have the concept of groups – users can be assigned membership in a group, and a group can be granted OpenStack roles and permissions in a bulk manner. An administrator can assign users to a VO role by assigning group membership to them, and then setting the correct OpenStack roles and permissions for the group.</p>
 <h2>VO Role Naming and VO Administration</h2>
+<p>Different VOs may have the same VO role names, but these would need to be different groups in OpenStack. How is this to be implemented?</p>
 <p>Typically different VOs will have different administrators. We therefore need to distribute the management of VO roles (group names) to different administrators. How is this possible in OpenStack?</p>
-<p>One way would be to make each VO a separate Keystone domain, and have the domain name equal to the VO name, then the group name can equal the VO role name. Different VO administrators can then create different groups (VO roles) within their own Keystone domains.</p>
+<p>One way would be to make each VO a separate Keystone domain, and have the domain name equal to the VO name, then the group name can equal the VO role name (assuming that groups are bounded by domains). Different VO administrators can then create different groups (VO roles) within their own Keystone domains.</p>
-<p>If different domains is not desirable, then roles in VOs could be indicated by individual group names formulated as <VOname>.<RoleName>.  A set of administrators for the (default) domain could be created, and users with both the admin role and <VOname>.<RoleName>  could be given administrative rights for that VO role.</p>
+<p>If different domains is not desirable, then roles in VOs could be indicated by individual group names formulated as <VOname>.<RoleName>. If group names are not bound to domains, then group names will have to be <VOname>.<RoleName> in order to keep them globally unique.  A set of administrators for the (default) domain could be created, and users with both the admin role and <VOname>.<RoleName>  could be given administrative rights for that VO role.</p>
 <h2>Identifying VO members</h2>
-<p>Regardless of the way VO roles are named and managed, in a large cloud deployment with federated authentication enabled the VO administrator might not know the identifier or identity attributes issued for each VO member by their respective IdPs. Because of this we propose that a management utility should be available for administrators to organise the membership of VOs, by inviting VO members to self-register. In this way, neither the administrator nor the VO member need be aware of either the identifier or identity attributes issued to him/her by their IdP.</p>
+<p>Regardless of the way VO roles are named and managed, in a large cloud deployment with federated authentication enabled the VO administrator might not know the identifier or identity attributes issued for each VO member by their respective IdPs. Because of this we propose that a management utility should be available for administrators to organise the membership of VOs, by inviting VO members to self-register. In this way, neither the administrator nor the VO member need be aware of either the identifier or identity attributes issued to him/her by their IdP. The proposed system will take the name of the IdP and the unique ID assigned to the user by the IdP as the inputs to the mapping function, and will automatically create a mapping rule for this user.</p>
 <h2>Proposal</h2>
@@ Line 17: / Line 19: @@
 The proposed VO Management utility should consist of five API functions:
 <ol>
-<li>The administrator should be able to create a new VO role and delete an existing VO role. A VO role is defined as a group name with a PIN number associated with it. The administrator can distribute the group name and PIN to proposed members of the VO role, so that they can request membership (i.e. self-register).</li>
+<li>The administrator should be able to create a new VO role, list existing VO roles, and delete an existing VO role. A VO role is defined as a group name with a PIN number or password associated with it, to be used for user self-registration to the VO role. The administrator can distribute the group name and PIN/pw to proposed members of the VO role, so that they can request membership (i.e. self-register).</li>
-<li>The members should be able to request membership of the VO role using the PIN and group name. They should also be able to request leaving any VO role they are a member of at any time (without using the PIN).</li>
+<li>The members should be able to request membership of the VO role using the PIN/pw and group name. They should also be able to request leaving any VO role they are a member of at any time (without using the PIN).</li>
 <li>The administrator should be able to view, accept and deny VO role membership requests.</li>
 <ol type="a">

@@ Line 35: / Line 35: @@
 <p>Attributes:</p>
 <p>"id" (string) The ID of the VO role</p>
-<p>“name" (string) the VO role/group name</p>
+<p>“vo_name" (string) the VO role/group name</p>
 <p>"description" (string) the description of the VO role
 <p>"group_id" (string, FK) The ID of the group which has this role</p>
 <p>"enabled" (boolean) Whether the VO role is active</p>
-<p>“PIN” (string) the secret PIN for group membership</p>
+<p>“pin” (string) the secret PIN for group membership</p>
 <p>“automatic_join” (boolean) whether users joining with a valid PIN should be joined to the VO role automatically or manually confirmed by an administrator. It should default to false (manual confirm).</p>