Difference between revisions of "Keystone/VOManagement"
m |
|||
| Line 1: | Line 1: | ||
<h2>Introduction</h2> | <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>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 | + | <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> | <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>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> | <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> |
| + | |||
| + | <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> | ||
<h2>Proposal</h2> | <h2>Proposal</h2> | ||
| Line 17: | Line 19: | ||
The proposed VO Management utility should consist of five API functions: | The proposed VO Management utility should consist of five API functions: | ||
<ol> | <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> | <li>The administrator should be able to view, accept and deny VO role membership requests.</li> | ||
<ol type="a"> | <ol type="a"> | ||
Revision as of 13:35, 23 April 2014
Contents
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 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.
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.
VO Role Naming and VO Administration
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?
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?
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.
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.
Identifying VO members
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.
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.
Proposal
The proposed VO Management utility should consist of five API functions:
- 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).
- 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).
- The administrator should be able to view, accept and deny VO role membership requests.
- View should list all outstanding membership requests.
- Accept should create a mapping rule that assigns the group to the member in question, and remove the request.
- Deny should simply delete the request.
- 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.)
- 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.
New Entities
Virtual Organisation Role (VO-role)
Attributes:
"id" (string) The ID of the VO role
“vo_name" (string) the VO role/group name
“vo_role" (string) the VO role/group role
"description" (string) the description of the VO role <p>"group_id" (string, FK) The ID of the group which has this role
"enabled" (boolean) Whether the VO role is active
“pin” (string) the secret PIN for group membership
“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).
Virtual Organisation Blacklist (VO-blacklist)
Attributes:
"id" (string) The ID of the blacklist entry
“user_id” (string) The user ID who tried to join
“idp” (string, FK) The IdP which authenticated the user
“group_id” The ID of the VO role/Group the user tried to join
“count” The number of incorrect attempts. (max three)
Virtual Organisation Request (VO-request)
Attributes:
"id" (string) The ID of the VO join request
“user_id” (string) The user ID who wishes to join
“idp” (string, FK) The IdP which authenticated the user
“group_id” The ID of the VO role/Group the user requests membership in.
