Difference between revisions of "Keystone/VOManagement"

Revision as of 20:47, 22 April 2014

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?

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.

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:

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).
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).
3. The administrator should be able to view, accept and deny VO role membership requests.
1. View should list all outstanding membership requests.
2. Accept should create a mapping rule that assigns the group to the member in question, and remove the request.
3. Deny should simply delete the request.
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.)
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.

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.