VOM Registration Service Architecture

A. Heavey

T. Levshina

J. Weigand

Overview

The Virtual Organization Membership Registration Service (VOMRS) is the major component of VOX project. VOMRS is a service that provides the means for registering members of a VO, and coordination of this process among the various VO and grid resource administrators. It consists of a database to maintain user registration and institutional information, server to handle members’ notification and synchronization with various interfaces, web services and a web user interface (web UI) for input of data into the database and manipulation of that data. This documentation describes the VOMRS Architecture.

Glossary of terms

Alias

A secondary Distinguished Name (DN) is considered an "alias" for the primary DN of a VO member (see Distinguished Name).

Applicant

An applicant (see Role) is a person associated with the VO's project that has submitted a request to join the VO, but for whom the request has not yet been approved. The applicant must possess a valid certificate from a VO-approved CA. An applicant is typically associated with one of the VO's member institutions.

Approved (membership status)

This membership status is given to approved VO members in good standing; this status is required in order for a member to perform any operations in the VOMRS.

Approved (authorization status)

This authorization status is granted to VO members during initial authorization process by various VO administrators (see Role). The “approved” status during “Representative” phase triggers automatic changes in membership status. Membership status becomes “Approved” as well. The authorization status "approved" set during “SiteAdmin” and “LRP” phases is required in order to access any grid resources.

Authentication

Authentication is the process of identifying an individual, and ensuring that the individual is who he or she claims to be. Authentication says nothing about the access rights of the individual (see Authorization).

Authorization

Authorization, in contrast to authentication, is the process of giving individuals access to system objects and resources based on their identity.

Authorization Status

Authorization status, as contrasted with membership status, refers to a VO member's authorization to use particular grid resources. There may be up to three levels of authorization status implemented in VOMRS; these levels are called "phases":

1. A representative has the authority to grant or deny, on an individual basis, authorization to use any grid resources recognized by the VO.

2. Once phase 1 is granted, a site administrator may grant authorization to use any resources located at his or her site.

3. Once phase 2 is granted, each local resource provider (LRP) may grant authorization to use his or her resource.

In VOMRS, only phase 1, the global authorization, is required to be a member of VO; the other two phases cannot be required from site administrator or local resource providers. Moreover the “Approved” status for the “SiteAdmin” and “LRP” phases does guarantee that member will be able to use grid resource on this particular grid site and cluster. The authorization statuses are New, Approved, and Denied.

Certificate Authority (CA)

A trusted third-party organization or company that issues digital certificates used to create digital signatures and public-private key pairs. The role of the CA is to guarantee that the individual granted the unique certificate is, in fact, who he or she claims to be.

Certificate Revocation List (CRL)

A CRL is a list of no-longer-valid certificates maintained by a CA (see CA) for the certificates it has issued. This list is used to determine the validity of a certificate at the time of a transaction. Certificates issued by a CA are considered valid unless they appear on the certificate revocation list.

Denied (membership status)

This status is given to applicants who do not meet membership requirements for any reason. Members with this status cannot perform any operations in the VOMRS beyond those available for applicants.

Denied (authorization status)

This status is given to applicants or VO members who are not eligible to access grid resources, for any reason. “Denied” authorization status set during “Representative” phase triggers changes in membership status. Membership status becomes “Denied” as well.

Distinguished Name (DN)

In a certificate issued by a CA, the DN is the string that uniquely identifies the individual.

Event

An event in the VOMRS is a change to the database. Some events require actions to be taken by particular VO members. Based on role, members can request to be notified when certain events occur (see Notification and Subscription).

Full Rights

Full rights refer to full (as opposed to limited) membership rights. A member with full membership rights is person who is planning to use grid resources.

Grid Admin roles

Grid Admin roles include LRP and Site Administrator. VO members with these roles control user access to grid computing resources at a site.

Grid Resource

A computing or storage node at a grid site that accepts and runs jobs (or stores output) for authorized VO members.

Grid Site

(see Site)

Group

An organizational entity, defined by the VO, which refers to a subdivision of the VO's overall project, and to which some subset of the VO's members are assigned. Each group has one group administrators, and members, all of whom are registered VO members. Groups are organized hierarchically.

Group Admin roles

Group Admin roles include Group Owner and Group Manager. See Group Owner and Group Manager. This is distinct from a Group Role.

Group Manager

A group manager may

- access a group member's public personal information

- assign and remove members to/from the group and to a group role within the group.

A group may have multiple group managers. A group manager of the parent group is automatically a group manager of all children groups in group’s hierarchy.

Group Member

A group member is a VO member who has been assigned to a group.

Group Owner

A group owner owns a group. A group owner is automatically a group manager of the group. In addition to the group manager functions, a group owner may

- add a new child group

- delete the group or any child group

- assign/de-assign group owners to the group or any child group

- assign/de-assign group managers to the group or any child group.

A group may have multiple group owners. A group owner of the parent group is automatically a group owner of all children groups in group’s hierarchy.

Group Role

A group role is an attribute of a group (and of the members of that group). Group roles may be used by LRPs to map users to local accounts. A Group Role is distinct from a Group Admin Role.

Institution

A university, laboratory or other body which participates in the VO's project and with which some of the VO's members are affiliated.

Limited Rights

Limited rights refer to limited (as opposed to full) membership rights. A member who requests limited rights at registration will not be able to access grid resources.

Local Resource Provider (LRP)

An LRP is a VO member associated with a particular grid site, who manages the authorization of VO members for a grid resource at the site. This authorization is one level finer than the site-level authorization managed by the site administrator.

Member

Once an applicant's request has been approved, the applicant becomes a VO member. At this point the member may be given additional roles in the VO and/or be assigned to groups and group roles. A member with full rights and appropriate authorization can use grid resources.

Member CA

The CA that issued a VO member's DN.

Member DN

The DN of a VO member.

Membership Rights

Membership rights represent the permissions granted to a VO member regarding use of grid resources. "Full" rights grant the member job processing rights (assuming authorization status permits) in addition to access to the VOMRS web UI; "limited" rights grant the user access to the VOMRS web UI only.

Membership Status

A field in the VOMRS indicating the standing a member has in the VO. Status can be New, Approved, Denied, Revoked, and Suspended.

New (membership status and authorization status)

This status is given to applicants to the VO; it remains in effect until the applicant's request is processed and either approved or denied.

Notification

All VO members and applicants may elect to receive email notification automatically when particular fields change in the database. These changes are called "events", this feature is called "subscribing to events", and the emails sent are the "notification". The events to which you can subscribe depend upon your role and membership status.

Notification Email Address

This field is for the email address to which the applicant or member wants the automatically generated notifications sent.

Phase

Authorization status as a concept thus has three "phases", meaning three levels of authorization for using grid resources. Each phase is tied to the role responsible for the corresponding level of authorization:

1. Representative grants a general, or global, authorization

2. Site administrator grants authorization for a particular site

3. LRP grants authorization for a given resource at a site

Primary DN

The DN under which you've registered with the VO. “Approved” member can put in DN &CA from the other certificates (alias) in addition to the primary DN & CA. Member that possesses multiple valid certificates can use any of them to connect to VOMRS. Member can replace primary DN & CA with an alias. This can be done if primary DN & CA become invalid for some reason.

Private Personal Information

Private personal data is not accessible to regular VO member; only VO Administrators and site administrators may view this information. A regular VO member can view and modify his own private personal data. VO Administrator has right to modify private data of any member of the VO.

Public Personal Information

Public personal data is accessible to the VO member with administrative role (Group Owner, Group Manger, Representative, LRP, Site Admin). A regular VO member can view and modify his own public personal data. VO Administrator has right to modify public data of any member of the VO.

Registration

The process of requesting membership in the VO via the VOMRS system. This is done using the Registration form.

Registration Form

The form used by VO applicants to register with the VO. VO administrators may use this form to register a third party.

Representative (role)

A representative is a VO member responsible for approving/denying applicants' requests for VO membership based on personal knowledge about each individual applicant's identity and institutional affiliation. In VOMRS a representative is not constrained to be affiliated with the same institution as the individual he or she represents.

Representative CA

The CA that issued the DN of a VO member's representative.

Representative DN

The DN of a VO member's representative.

Required Personal Information

Information that an applicant to the VO must provide in order to identify himself or herself to the VO. This information is stored for the duration of an individual's VO membership. Each individual information field is designated as public or private.

Revoked (membership status)

This status indicates that the VO member is in the CRL of the CA that issued the member's certificate. Members with this status cannot perform any operations in the VOMRS and will be denied access to any grid resources.

Role

A technique of member-to-services mapping in which the permissions for performing particular services in the VOMRS are grouped into a role. Each role gets assigned to designated VO members, thereby allowing them to perform the associated services. In addition to the basic roles of Applicant and Member, there are three categories of administrative roles: Group Admin, Grid Admin and VO Admin.

Role (pertaining to Group)

(See Group Role.)

Rules

(See Usage Policy.)

Secondary DN

A DN other than the DN you use to access the VOMRS. (See Primary DN.) A secondary DN would be issued by a different CA than your primary, and to enter it into the VOMRS, the CA would need to be listed under Certificate Authorities. A secondary DN is also referred to as an alias.

Site (Grid Site)

Set of grid computing resources (compute and/or storage nodes) owned and managed by the same institution and by a single VO. There may be multiple computing resources within a site, and there may be multiple sites at a single institution.

Site Administrator

A site administrator, like an LRP, is associated with a particular grid site, and is responsible for granting VO members access to site resources (this authorization is one level higher than per-resource authorization, managed by the LRP). A site admin is responsible for maintaining the required site-specific personal information in VOMRS and may assign/de-assign members as LRPs or as additional site administrators.

Subscription

"Subscription to events" is the mechanism VOMRS uses for notifying VO members of changes in the registration process. Members choose the events that they wish to monitor (they "subscribe" to these events), and then notification emails get sent to them as corresponding changes occur. Notifications go only to the notification email address.

Suspended (membership status)

This status indicates that the VO member is currently not in good standing in the VO. Members with this status cannot perform any operations in the VOMRS and are denied access to any grid resources.

Usage Rules

A set of grid usage rules that make up a computing resources use policy. VO members are required to agree to these rules.

Virtual Organization (VO)

A Virtual Organization consists of members that may come from many different home institutions, may have in common only a general interest or goal (e.g., CMS physics analysis), and may communicate and coordinate their work solely through information technology (hence the term virtual). In addition, individual members and/or institutions may join and leave the organization over time; sometimes VOs are called dynamic virtual organizations for this reason.

Virtual Organization Membership Service (VOMS)

The Virtual Organization Membership Service (VOMS) is a system that manages user authorization information for a VO. VOMS is designed to maintain only general information regarding the relationship of the user with his VO, e.g., groups he belongs to, roles he has been assigned, and certificate-related information. It maintains no personal identifying information. VOMS is part of VOX, but separate from the VOMRS. VOMRS is capable to synchronize data from VOMRS database with VOMS database by using VOMS API. The following information may be synchronized with VOMS:

- group hierarchy

- group roles

- members (only member with “Approved” status will be added to VOMS, if member becomes “Suspended”, “Denied” or “Revoked” he will be purged from VOMS)

- member’s association with groups and group roles

More information can be found at

http://edg-wp2.web.cern.ch/edg-wp2/security/voms

VO

See Virtual Organization.

VO Admin (role)

The VO administrator is responsible for maintaining the VOMRS, and as such may view and change all member-related information. This person can add and delete institutions, sites, CAs, can modify the personal information required by the VO for each member, and can assign/de-assign roles to/from members (e.g., root group owner, site administrator). The VO administrator can assign/de-assign this same role to/from other VO members.

VO Administrator roles

VO Administrator roles include representative and VO Admin. People with these roles are responsible for the integrity of the VO, as maintained in the VOMRS.

VOM Registration Service (VOMRS)

The VOM Registration Service (VOMRS) is the major component of VOX. VOMRS is a server that provides the means for registering members of a VO, and coordination of this process among the various VO and grid resource administrators. It consists of a database to maintain user registration and institutional information, and a web UI for input of data into the database and manipulation of that data.

VOMS eXtension (VOX)

The VOX project is an extension of the VOMS project. VOX maintains additional information (relative to VOMS) on each VO member as required by individual grid resource providers. VOX provides an interface for entering information, stores it in its database, and populates the VOMS database via the VOMS administration package.

This is a subset of glossary terms. The complete glossary is written by A. Heavey and is available at http://computing.fnal.gov/docs/products/vomrs/glossary.html

VOMRS Components

The VOMRS includes the following components:

- VOMRS Server

o Java

- VOMRS database

o MySQL

- CLI

o GSI authentication (Java Cog Kit)

o SOAP/SSL authentication (EDG Trust Manager)

o Java

- WEB UI

o HTTP/SSL authentication (EDG Trust Manager)

o Java

o Java script

- Web Admin

o Java

o Axis

o Tomcat WEB service

Figure 1: VOMRS Architecture

Server Internals

A VOMRS Server is a multithreaded daemon process that is capable of performing the following tasks:

- Handling remote client request to perform VO membership service

- Handling event and interface notification

- Synchronizing VOMS with VOMRS database

Server behavior is controlled by configuration written in xml and described in Appendix A.

Client Manger

A Client Manager is a thread of the VOMRS Server that is listening for connection from remote clients. As soon as connection is established, a Client Manager starts a temporary new thread (ClientIF) that authenticates remote client and processes client’s requests to execute VO membership services (see VOMRS Services). A ClientIF authenticates a client by using GSI authentication mechanism. It returns information regarding the success or failure of a requested service as well as the execution result of this service if any. The remote client request fails due to the following reasons:

- Authentication failed

- Client is not authorized to perform the requested service

- Requested service is unknown

- Request has incorrect syntax

- Requested information is not in database

- Database error (should not happen)

The thread will be stopped either when client closes the connection or the allowed connection time is expired whichever comes first. The allowed connection time can be set up in configuration.

The API for submitting service requests and member’s roles that are authorized to perform a particular service are described in Appendix B.

In order to permit remote client connection the VOMRS configuration should be set accordingly. The VOMRS server should be started by user “root” on the host that has a host certificate located in “/etc/grid-security” directory.

Event Manager

An Event Manager is a thread of the VOMRS Server that processes all the notification events stored in VOMRS database (see list of available events in Appendix C). An Event Manager setting is controlled by a VOMRS configuration. An Event Manager runs periodically and performs the following tasks:

- Checks database for any event that is ready to be processed

- Determines current subscribers to this event

- Formats and sends e-mail notification

- Updates database with the outcome of event processing and notification (“Completed”/”Failed”)

Interface Manager

An Interface Manager is a thread of the VOMRS Server that processes all the events that are relevant to a particular interface and are stored in the VOMRS database. An Interface Manager setting is controlled by the VOMRS configuration. It runs periodically and performs the following tasks:

- Checks database for any interface event that is ready to be processed

- Determines current interface subscribers to the event

- Formats event and contacts a subscribed interface by using appropriate API

- Updates database with the outcome of event processing and notification (“Completed”/”Failed”)

Only an interface to VOMS Admin is currently implemented.

VOMS Synchronizer

A VOMS Synchronizer is a thread of the VOMRS Server that transfers information from the VOMRS database to the VOMS database using EDG VOMS Admin API. A Synchronizer behavior is controlled by the VOMRS configuration. A Synchronizer has two modes of operations. In one mode (“event driven” - level 4) it is using an Interface Manager to handle each event relevant to VOMS (subscribed by VOMS interface). The other mode allows a Synchronizer to synchronize the VOMRS and VOMS databases. There are four levels of synchronization:

1. Addition of all “approved” VOMRS members to a root group of the VOMS database (level 0)
2. Addition of all “approved” VOMRS members to a root group and deletion of all “suspended” VOMRS members from the of VOMS database (level 1)
3. Synchronization of all members (level 2). This includes deletion of all members that are listed in the VOMS database but do not exists in the VOMRS database.
4. Complete synchronization (level 3). This includes synchronization of groups and roles, member assignment to the subgroups and member role within subgroups.

VOMRS Admin Internals

There are two ways of accessing the VOMRS besides VOMRS client described above: via web UI (HTTP+SSL authentication) or web services (SOAP+SSL authentication) where both of them are using the same implementation of business logic. The EDG Trust Manager (http://edg-wp2.web.cern.ch/edg-wp2/security) provides the authentication.

The detailed description of WEB UI is available on the web http://computing.fnal.gov/docs/products/vomrs/#manual.

Web Services list can be found on (one should have a valid certificate in order to access this information):

https://vomrs_host:8443/vo-<VO_NAME>/services/VOMRS?wsdl

The behavior of WEB UI is controlled by configuration file (see Appendix A). The following parameters can be defined in <web> part of the VOMRS configuration:

- The duration of the session

- The name of organization that oversees all grid resources for a particular VO

- The url location of usage rules for this organization

VOMRS Services

The VOMRS has a notion of services. Each service is characterized by the action it performs within VOMRS database. Each service is associated with the set of administrative roles and list of input and output arguments. The VOMRS Service will failed if the service requester does not have an appropriate role within the VO, or supplies invalid set of arguments. The definition of various roles is provided in Glossary section of this document. The list of services, authorized roles and corresponding input and output arguments can be found in Appendix C. There are additional authorization restrictions that are currently implemented in the code of a particular service, e.g. if service is allowed to be performed by Site Admin, the action will be allowed only on the entities that are associated with the same site as this site administrator is affiliated. For example, Site Admin can assign a role of LRP to a member of the VO. This member should be affiliated with the same site as Site Admin. Similar restrictions are applied to Group Owner and Group Manger: they can perform action only upon group they owned or managed. See comments in Appendix C for more details.

VOMRS Database schema

The database schema for VOMRS cat be categorized in the following manner:

1. Core tables

These contain the basic VOMRS data related to the VO and VO members.

2. Code related tables.

These tables are fairly tightly coupled with the application’s code and should only be changed in conjunction with the code. They are not affected by the available VOMRS services.

3. Log tables

These tables are essentially log type tables used to notify members and interfacing systems of changes in a member’s registration status. They actually represent ‘instances’ of an event/event type.

Core VOMRS tables: These tables are maintained through the available services of the VOMRS.

VO related tables
certificate_authority	List of known Certificate Authorities
institution	List of institutions and sites
personal_data	Superset of personal information that should be provided by user in order to register with VO
site_personal_data	List of personal information required by site authorities
group	List of groups within the VO.
role	List of known roles within VO.
Member related tables
member	List of members’ internal ids, institution, representative and status
notification_method	List of methods used to notify VO members of changes in their registration data
member_dn	Member’s distinguished names for multiple certificate authorities
member_identity	Member’s personal information
member_group	List of groups a member belongs to for a particular role.
member_role	List of member’s roles within the VO.
member_subscriber	List of registration events a member has subscribed to for a particular role.
registration	Provides information on a member’s registration status.

Code related tables: These tables are fairly tightly coupled with the application’s code and should only be changed in conjunction with the code. They are not affected by the available VOMRS services.

Services related tables
service	List of available services, arguments and return values.
service_role	List of roles and the services they can perform. This satisfies a many-to-many relationship between roles and services.
Event related tables
event	Identifies an activity that has occurred in the registration process that requires some form of notification to a VO member or an interfacing system.
event_type	A subset of an event providing more specific information regarding changes occurring in the registration process/status of a VO member. It is specific to the person/system receiving the notification.
role_event	Defines the specific roles that an individual event type is associated with.
interface	List of external systems interfaced with VOMRS.
interface_subscriber	List of the events that a system interface is subscribed to.

Log related tables: These tables are essentially log type tables used to notify members and interfacing systems of changes in a member’s registration status. They actually represent ‘instances’ of an event/event type.

Event tables
event_log	Represents an ‘instance’ of an event.
event_value	Contains all the data values associated with an event. This may include ‘old’ and ‘new’ values, who performed the update, etc.
event_type_log	Represents an instance of an event type table that has occurred.
Notification tables
member_event_recipient	Contains an entry for each member that has been subscribed to and notified that a VOMRS event has occurred for each event type.
interface_event_recipient	Contains an entry for each interfacing system that has been subscribed to and notified that a VOMRS event has occurred for each event type.

Entity Relationship Diagram

Disclaimer: The above ER diagram was created using the Oracle Designer tool. It does not include all the data relationships present in the VOMRS database, but only the most relevant. This is a variation from the normal use of this tool and was done so intentionally to simplify the diagram. Since this was originally designed for use in a MySql DBMS, the foreign key relationships are in the software rather than the DDL.

Core VOMRS tables

VO Related Tables

certificate_authority

This table stores information about all Certificate Authorities known to the VO. This information includes CA name and description.

Field	Type	NULL	Default	Extra
ca_id	integer	No		auto_increment
certificate_auth	VARCHAR(250)	No
certificate_auth_descr	VARCHAR(250)	No

Indexes/Keys	Name	Columns
Primary key	ca_pk	ca_id
Unique key	ca_uk	certificate_auth

institution

This table stores information about institutions / sites that make up VO. The information includes institution id, the institution’s name and an indicator if that institution provides grid resources or not.

Field	Type	NULL	Default	Extra
i_id	integer	no		auto_increment
institution_name	VARCHAR(100)	no