Page tree
Skip to end of metadata
Go to start of metadata

Document control

AreaEGI Federation Operations
Procedure status


  • OMB
Approval status


Approved version and date



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

Table of contents


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 wish to share access to a subset of EGI resources. Membership of a VO (or a group within that VO) is how access is granted to those resources.  A typical VO provides some base-level access to the resources for all VO members, with some members having elevated privileges.

The focus of this document is 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 purpose of this page is to capture the VO registration workflow so it can be learned by VO representatives, by EGI staff as well as it can be improved in order to meet new requirements.
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.


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. 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 X509.
  • 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 mainly meant for High Throughput Compute services, that have not yet moved to token 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 key words "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.


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


Step# ResponsibleActionPrerequisites, if any
VO Manager

Submit VO registration request

Filling the VO ID card from in 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)
Operations Portal

Inform VO Supervisor about new VO registration request

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

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)
VO SupervisorAsk for update of VO ID card
Send an update request to the VO Manager using the Helpdesk ticket.
Data is missing or incorrect in VO Id card.
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 setup a new EGI Helpdesk Support Unit.
61VO Supervisor

Verify with VO Manager which VOMS server should be used

VO Supervisor may open an 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 setup a VOMS server for the VO.

2VO SupervisorVerify with VO Manager if the new VO should be managed in EGI Check-in with COmanage
If yes 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. Report this ticket in the general one created at step 2.
VO will use services that don't require authentication with X509 certificates (e.g. cloud services)

3VO Supervisor

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

If yes 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
  • whether the VO is going to be used for EGI Check-in only, or for some other end services as well
  • 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.)
  • whether VO registrations should be approved manually (by VO managers) or automatically
  • what fields should be in the VO registration form and which of them should be required (the bare minimum is required name + required email)

If VO is going to use cloud resources and needs X509 certificates

VO Manager

Fill in the enrolment URL in the "General Information" section and 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 the the attribute authority selected for the VO. The enrolment URL will only be known once the VO will have been properly configured in the chosen attribute authority.

Currently, 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.
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.

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 by people registered in 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 should be unique and in a 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 mail address is in the same domain as the VO name’s one, nor that the VOMS server or VO home page address are of that domain. Doubts on domain ownership are not stopping VO registration, as the responsibility of acquiring the domain name is with the VO Manager, but the VO manager should consider that if the domain gets purchased by someone else it could lead to confusion and legal problems with regards branding.
  • Description (Mandatory): The Description of the purpose of the VO should be in English and should describe a scientific or technical activity, or should be related to education. The text is also used to delimit proper resource usage on the infrastructure, so it should be significant 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 fine.
  • 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 allowing to choose which grid middleware or cloud resources the VO will be accessing, 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 VO-specific Acceptable Use Policy. On the “New VO registration web page” the registering VO manager has the choice between a text automatically generated from the Description but where at least some words have to be updated, or a file in text or pdf format uploaded by the manager containing a VO written AUP. In the former case it has just to be checked whether the update has been done; the words to be replaced are “owner body”, included in brackets - “[]” - , and the replacing text must specify the authority enforcing the VO AUP. If not the VO will get stuck in the NEW state. If the AUP is uploaded, the complete text has to be verified to ensure it corresponds to a VO AUP. In case of a 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 on-going/planned activity and if this information corresponds to the VO’s Description.
  • Enrolment URL (Mandatory): URL allowing new users enrol in the VO. This URL will only be know once the VO will have been created in one of the Attribute Authorities (VOMS, Check-in, PERUN,...). This field must be verified whether it is functional or simply an optional service to the VO. Additionally, the information available on the enrolment web page might give some indications on the purpose and scope of the VO as well as on the attitude concerning security (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 requester can add details about the VOMS server, the Comanage URL, Perun Url, or an external registry url (filling more than one registry type is allowed).

If no registry information is available at the moment of the registration request, the requester can leave a comment about on the kind of registry they would need and 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 from: one is a default – No. If VO Manager will check a box, the new ticket will created for GGUS support unit and VO Supervisor will keep track of the process.

Section Generic Contacts

Most fields (VO Managers, Security, VO Users) are mandatory and currently, new registration requests must contain a valid address in these fields. There is only one not mandatory contact in the list of this section shown on the VO ID card, Operations contact. It will be verified if the email looks appropriate. For VO created and managed by EGI CST on behalf of a user community, the User support field should be 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 step (Step 5 in the table above) 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. in 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 a doubt - which is the normal case here - a suggestion is made to the VO manager. The field is then updated only after their confirmation. Assigning a correct value is important for limiting the noise especially on the National Infrastructure managers list in case of National VOs and also to determine responsibilities for support in case of additional resource requests made by the new VO. If the VO is a National one, 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 for Regional VOs where only the corresponding  National Infrastructure is informed.