Difference between revisions of "Keystone/VOManagement"

Latest revision as of 18:29, 11 December 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 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.

VO Role Naming and VO Administration

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?

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.

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.

Identifying VO members

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.

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.

Proposal

The proposed VO Management utility should consist of five categories of API functions:

1. 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).
2. 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.
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 domain/group to the member in question, and remove the request.
3. Deny should simply delete the membership 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/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.

New Entities

Virtual Organisation Role (VO-role)

Attributes:

"id" (string) The ID of the VO role

“vo_name" (string) the VO/domain name

“vo_role" (string) the VO role/group name

"description" (string) the description of the VO role

"group_id" (string, FK) The ID of the group which is this VO role

"enabled" (boolean) Whether the VO role is active

“pin” (string) the secret PIN/password for VO role 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 IdP asserted ID of the user who tried to join

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

“group_id” The ID of the group the user tried to join

“count” The number of incorrect attempts before being blacklisted (configurable, default three)

VO Role Request (VORole-request)

Attributes:

"id" (string) The ID of the VO join request

“user_id” (string) The IdP asserted ID of the user who wishes to join

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

“group_id” The ID of the group the user requests membership in.