Difference between revisions of "Keystone/VOManagement"
(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...") |
(No difference)
|
Revision as of 17:41, 25 March 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 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.
VO Role Naming and VO Administration
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.
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.
Proposal
The proposed VO Management utility should consist of five API functions:
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.
New Entities
Virtual Organisation Role (VO-role)
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).
Virtual Organisation Blacklist (VO-blacklist)
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>
Virtual Organisation Request (VO-request)
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.