Document control

AreaEGI Federation Operations
Procedure status

FINAL

Owner
Approvers
  • OMB
Approval status

APPROVED

Approved version and date

v14,  

Statement

The document describes the process of enabling a Virtual Organisation (VO) on the EGI infrastructure.

Next procedure reviewUpon request

Procedure reviews

The following table is updated after every review of this procedure.

DateReview bySummary of resultsFollow-up actions / Comments

 

Import from the wiki and refresher.

 

Alessandro Paolini specified to fill in also the registry info section; replaced (and updated) VOMS configuration info with registry info

 

added a step (6) about the creation of the vm_operator role

Table of contents

Overview

The document describes the process of enabling a Virtual Organisation (VO) on the EGI Infrastructure and the parties who are involved in process execution.
Users of EGI are organised into Virtual Organisations (VO). A VO is a group of people that have similar focus in their work and have a common objective to access a subset of EGI resources. Herein, access to these resources is granted by membership of a VO (or a group within that VO).  A typical VO provides some basic level access to the resources for all members of the VO, with some members having elevated privileges.

This document focuses on the tasks that VO representatives and the EGI staff have to accomplish in order to register and validate a new VO on EGI. The information presented here describes the VO registration workflow so that it can be learnt by VO representatives and EGI staff, as well as being modified to respond to new future needs.
For other aspects of VO management (e.g. operation support, resource/service allocation, decommissioning) please consult with the VO Manager, see the User_Documentation in EGI Wiki page or contact EGI User support group.

Definitions

Please refer to the EGI Glossary for the definitions of the terms used in this procedure.

  • Check-in: The EGI Check-in is a proxy service that operates as a central hub to connect federated Identity Providers (IdPs) with EGI service providers (SPs). Check-in allows users to select their preferred Identity Providers so that they can access and use EGI services in a uniform and easy way. Check-in is also working as an attribute authority to manage membership and roles using its COmanage component. Check-in can be used to grant access to SAML and OIDC based services (Web portals, cloud resources, ...) relying on assertions or tokens for authentication and authorisation.
  • PERUN: PERUN is an attribute authority allowing to grant access to cloud resources and using X.509.
  • VOMS: The Virtual Organisation Membership Service (VOMS) is an attribute authority which serves as central repository for VO user authorisation information, providing support for sorting users into group hierarchies, keeping track of their roles and other attributes in order to issue trusted attribute certificates and SAML assertions used in the Grid environment for authorisation purposes. VOMS is the legacy attribute authority, primarily intended for High Throughput Compute services, which have not yet moved to token mechanisms for authentication and authorisation.
  • The EGI Helpdesk: It is the primary means by which users request support when they are using the EGI Infrastructure.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Entities involved in the procedure

  • VO Manager (VM): person responsible for initiating the registration process.
  • VO supervisor (VS): person delegated from the EGI SDIS team to handle the process on behalf of EGI Federation and responsible for the approval of VO registration requests.

Triggers

  • A VO Manager requests the creation of a Virtual Organisation for managing access for their user community.
  • A member of the EGI CST team requests the creation of a Virtual Organisation on behalf of a user community.

Steps

Step# ResponsibleActionPrerequisites, if any
1
VO Manager

Submit VO registration request

Filling the VO ID card from the Operations Portal.

See documentation on Requirements for VO ID cards.

VO Manager must be able to authenticate with the Operations Portal (via EGI Check-in)
2
Operations Portal

Inform VO Supervisor about new VO registration request

  • A notification email to VO Supervisor is sent.
  • A Helpdesk ticket against Operations Support Unit is generated to track the request.

3
VO Supervisor

Check the correctness of VO registration request

  • Verify that there is no existing VO with significantly overlapping goals. This can be done through the VO list of the Operations portal. VOs with similar goals (e.g. image analysis) should be advised to join.
  • Check if the content of the VO ID card in Operational Portal is correct according to the Requirements for VO ID cards.
VO Supervisor must be able to authenticate with the Operations Portal (via EGI Check-in).
41VO SupervisorAsk for update of VO ID card
Send an update request to the VO Manager using the Helpdesk ticket.
Data are missing or incorrect in VO ID card.
5
VO Supervisor

Open a ticket against the GGUS Support Unit in the Helpdesk to request a new support unit for the VO

VO Manager asked to set a new EGI Helpdesk Support Unit up.
61VO SupervisorVerify with VO Manager if the new VO needs to be supported by a VOMS server, Check-in, or Perun

2VO Supervisor

Ask the VO Manager if:

  • the vm_operator role is needed.
  • this role should be assigned automatically to the VO members or should be managed by the VO Manager and assigned upon request.
In general, the vm_operator role might be needed if the VO is going to use cloud resources (in which case the attribute management solution will be either Check-in or Perun).
71VO Supervisor

If the VO needs a VOMS server, verify with VO Manager which VOMS server should be used

VO Supervisor may open a Helpdesk ticket requesting a VOMS server for the new VO, and asking to be assigned to the EGI Catch-all Services support unit.

VO Manager has an agreement with an EGI Resource Center to provide a VOMS server or asked to set a VOMS server for the VO up.

2VO Supervisor

If the VO membership should be managed in EGI Check-in with COmanage:

Open a ticket to Check-in (AAI) Support Unit in the Helpdesk to request the creation of a group in COmanage, with the VO Manager in copy. Specify in the ticket who should get the administrator role of the new group. Specify the details about the vm_operator role. Report this ticket in the general one created at Step 2.

VO will use services that do not require authentication with X.509 certificates (e.g. cloud services).

3VO Supervisor

Verify with VO Manager if the new VO should be managed in PERUN

If so, open a ticket to Perun Support Unit in Helpdesk to ask for support for the VO.

In the ticket, provide the following information:

  • Name of VO (English alphabet) + short name of VO (usually 2-10 characters).
  • Who should be the VO managers.
  • Inform whether the VO is going to be used for EGI Check-in only, or for some other end services as well.
  • Provide either the desired user life cycle, or at least which events should trigger a notification for VO managers (new registration to VO, registration changes state, etc.)
  • Inform whether VO registrations should be approved manually (by VO managers) or automatically.
  • Inform what fields should be in the VO registration form and which of them must be mandatory (the bare minimum is required name + required email).
  • Inform if the vm_operator role is needed and how it should be managed.

If VO is going to use cloud resources and needs X.509 certificates.

8

VO Manager

VO Supervisor

Fill in the enrolment URL in:

  • the "General Information" section
  • the VOMS server / COmanage (or other registry) details in the "Registry Info" section of the VO ID card

The enrolment URL can be pointing to VOMS, Check-in (COManage), PERUN or to an external attribute authority according to the attribute authority selected for the VO. The enrolment URL will only be known once the VO has been properly configured in the chosen attribute authority.

In the "Registry Info" section, it is possible to add details about: the VOMS server, COmanage, Perun, and any other external registry. This section is also used by the Operations Portal to count the users in the registry.

VO has been enabled in the chosen attribute authority.
9
VO Supervisor

Review and approve new VO ID card

If the VO ID card is valid, mark the VO as active from the incoming VO(s) list.

The VO status is moved to PRODUCTION in the Operations Portal.


10
Operations Portal

Inform VO Supervisor about new PRODUCTION VO

Send notification email to:

  • VO Supervisor
  • VO Manager
  • EGI Community

About Virtual Organisations (VO)

VO lifecycle - VO states

A VO is in one of the following states:

  1. NEW: this is the initial state when the VO creation is requested. It is automatically assigned.
  2. PRODUCTION: the target state of a VO. It is manually given to a VO by the VO supervisor as a result of this procedure.
  3. SUSPENDED: this state is entered when the VO no longer has valid information in VO ID card. This state may be temporary or the preparation of VO de-registration. Manual intervention is needed to put a VO into this state.
  4. DELETED: state for VO that has been terminated.

Note that manual state changes can only be made either by people having the VO Supervisor role on the Operations portal or by the Operations portal team itself. This document covers the VO lifecycle from "non-existing" through NEW to PRODUCTION.

Requirements for VO ID cards

The following compulsory and optional fields must be filled out by the VO Manager as part of the registration process and will be verified by the VO Supervisor:

Section General information

  • Name (Mandatory): The VO name must be unique and in DNS style. It should be clarified whether the VO Manager is authorised to make use of it. The VO Supervisor should confirm with the VO Manager if it is not obvious that the owner of the domain and the VO Manager are the same person. It is not considered sufficient that the VO Manager's email address is in the same domain as the VO name's one, nor that the VOMS server or VO home page address is in that domain. Doubts about the ownership of the domain do not prevent VO registration, as the responsibility for acquiring the domain name lies with the VO Manager, but the VO Manager should consider that if the domain is acquired by someone else, it could lead to confusion and legal problems with regard to the trademark. In case no proper domain can be used it's possible to use the VO name suffixed by vo.egi.eu.
  • Description (Mandatory): The Description of the purpose of the VO must be in English and should either describe a scientific or technical activity, or be related to education. The text is also used to delimit the appropriate use if the resources in the infrastructure, so it should be meaningful for this purpose, i.e. saying “VO giving access to the resources” is a poor description whereas “VO giving access to the resources for training purposes” is acceptable.
  • Discipline (Mandatory): Scientific Discipline(s) of the VO activities. There should be not contradiction between the Description field and this one.
  • Supported Middleware (Mandatory): There are options to choose which grid middleware or cloud resources the VO will access. The Operations Portal automatically checks that at least one option was chosen by the VO Manager.
  • Acceptable Use Policy (AUP) (Mandatory): This is about having a specific Acceptable Use Policy for the VO. On the “New VO registration web page” the registering VO Manager can choose between a text automatically generated from the Description, but in which at least some words have to be updated, or a text or PDF file uploaded by the manager containing the VO AUP. In the former case, it has just to be checked if the update has been done; the words to be replaced are “owner body”, enclosed in brackets “[ ]”, which must be replaced by a text that specifies the authority enforcing the VO AUP. Otherwise, the VO will remain in the NEW state. If the AUP is uploaded, the complete text has to be verified to ensure that it corresponds to a valid VO AUP. In case of doubt, in addition to contacting the VO Manager, the EGI SPG can be asked for advice.
  • VO homepage (Mandatory): A link to the VO homepage. It will be verified if the homepage contains information about the ongoing/planned activity and if this information corresponds to the VO’s Description.
  • Enrolment URL (Mandatory): URL allowing new users to register with the VO. This URL will only be known once the VO has been created in one of the Attribute Authorities (VOMS, Check-in, PERUN, ...). It must be checked whether this field is functional or simply an optional service for the VO. Additionally, the information available on the enrolment Web page could inform about the purpose and scope of the VO, as well as privacy and security considerations (availability of AUP, reminder of correct resource usage etc.).
  • Support procedure URL (Optional): The support procedure URL describes how support is provided for this VO and how users should communicate in order to report an issue or request assistance.

Section Registry Info (mandatory)

If the information is already available, the registrant can add details about the VOMS server, the Comanage URL, Perun URL, or an external registry URL (more than one type of registry is allowed).

If no registry information is available at the moment of the registration request, the registrant can comment on the kind of registry that would be needed, asking the support team to take care of it.  

Section VO SU at GGUS

  • Check box (Optional) - There are two options the VO Manager can choose, being "No" the default one. If the VO Manager checks a box, the new ticket will be created for the GGUS support unit and the VO Supervisor will follow up the process.

Section Generic Contacts

Most fields (VO managers, Security, VO Users) are mandatory, and registration requests must contain a valid address in these fields. This list is shown on the VO ID card, and the Operations contact is the only non-mandatory contact on it. The adequacy of emails will be verified. For VO created and managed by EGI CST on behalf of a user community, the User support field should be support@egi.eu, the security field should be ism@mailman.egi.eu, and the other field can use the email of the EGI CST member.

Scope of the VO

Managed by the VO Supervisor.

As part of the VO approval workflow, the scope of the VO must be defined by the VO Supervisor based on information provided by the VO Manager either in the VO ID card, or through additional channels (e.g. by email). The scope must be one of the following:

  • GLOBAL: the VO is supported by sites from multiple countries and all of these countries are represented by its National Grid Infrastructure (NGI); comprises an international user community and/or has international resources coming from sites of different countries represented by their National Grid Infrastructures (NGIs).
  • NATIONAL: i.e. sites and users are located within the same country. Users might come from elsewhere, but they are working inside the scope of the same National infrastructure where the sites are. The associated National infrastructure is part of the scope, like, for example, “NGI - Italy” or “NGI - France”.

Section Change status & scope

  • Pull down list Scope: Information from all the VO ID Card can be used to determine the value to be selected for Scope. In case of doubt - which is the normal case here, a suggestion should be made to the VO Manager. The field must be updated only after their confirmation. Assigning a correct value is important to: (i) limit confusion, especially in the list of National Infrastructure managers (in case of National VOs), and also to (ii) determine support responsibilities in case of additional resource requests made by the new VO. If it is a National VO, this field should be updated before the Status field. Updating this field triggers notifications to the VO Services group list and to the National Infrastructure managers list in all cases.
  • Pull down list Status: If all fields contain valid values, the status can be changed from NEW to PRODUCTION. The VO will be then active and in production state. Notifications are sent to the VO Service group list in all cases and to the National Infrastructure managers list in all cases except in the case of Regional VOs, where only the corresponding National Infrastructure is informed.