User Management Service documentation

Forewords

Grid’5000 User Management Service (abbreviated to UMS) is the information system that manages the accounts and related information of Grid’5000 users.

It is composed of a frontend web interface provided to users to let them handle their account information, and of a backend providing a REST API which allows automated operations (home directories management, coupling with OAR, …).

The frontend is to be used by

• simple Grid’5000 users ;
• managers of groups of Grid’5000 users ;
• managers of Grid’5000 sites ;
• administrators of Grid’5000.

Account information includes

• the user’s identity, contact information ;
• the user’s affiliations evolution over time (team, lab, institute, employer, …) ;
• the user’s membership to groups, and especially groups which grant access to the platform ;
• the user’s system information (unix identifiers, …), quotas for home directories, ssh keys, VPN certificates, membership to Grid'5000 mailing lists, external identifiers...

The interface allows

• users to request changes to the information regarding their accounts ;
• managers to handle users.

Groups granting access to the platform

This document puts an emphasis on the groups granting access to the platform (abbreviated to GGA), which is a major new feature in the Grid’5000 account management, deployed in April 2020.

GGAs allow a dispatch of the management and reporting tasks for the usage of the platform to closer managers than the Grid’5000 site managers.

Managers of the GGAs

Each group defines an owner, who is responsible for the group, and is in charge of managing the group. The owner is possibly helped by delegates to manage the GGA. Management tasks include:

• handling the membership of users ;
• being responsible for the usage of the managed users ;
• maintaining the most accurate information regarding the affiliations of the managed users.

GGA owners must be in the capacity to provide a reporting on the use of the testbed by the members of their GGA, for instance when activity reports for the platform are requested by the funding parties.

Scope of GGAs

GGA are most likely named after:

• either a small entity such as research teams or research projects, ... ;
• or a more general grouping entity, such as labs, an institute, a company or a community.

The size of the entity which the GGA is named after, depends on the count of users and overall usage intensity of the resulting group. The goal is to keep groups manageable: have neither too big groups, nor too many groups of Grid'5000 users.

Note

Despite the fact that a group is named after an formal entity (research team, lab...), this does not mean that the membership to the group is strictly defined by a formal membership to that entity. While the formal situation of a user must be given in the affiliation part of the user's Grid'5000 account, the user can be a member to any group as long as the group owner accepts to be responsible for the resulting usage of the platform, e.g. because part of a tight collaboration.

Sites and GGAs

Every GGA belongs to 1 and only 1 Grid’5000 sites (i.e., Grenoble, Lille, Luxembourg, Lyon, Nancy, Nantes, Rennes, Sophie, Toulouse). This choice might be arbitrary if multiple sites would be possible. A Guest site also exists, when there is no good fit. Each site manager has a role of supervision over the GGAs of his site. For instance, he is in charge of requesting the creation of a new GGAs for the site and of choosing the owner. The site manager is responsible for the gathering of information at the site level from all GGAs of the site, soliciting help from the GGA owners.

Please note that being a member of a GGA of one site has no impact on what sites of Grid'5000 can be used in term of experimentation and hardware (e.g. a member of a GGA of Grenoble can submit job in the site of Rennes for instance).

Privileges associated to GGAs

Every GGA has a privilege level (gold or silver or bronze), which defines some properties for the usage of the platform. This is explained in Grid5000:UsagePolicy.

New platform access scheme with the GGAs

Regarding the usage of the platform, the GGAs change the life-cycle of accounts as well as the experimental resources access:

Accessing resources now requires a user to be a member of a GGA

This means that being able to submit a job to OAR requires being a member of a GGA. All OAR jobs will now be attached to a GGA (GGAs are known as projects in the OAR semantics). OAR jobs and thus, the usage of the platform, will be counted by GGA.

Account validity and expiration are tied to membership to GGAs

This means that a GGA manager, by granting a membership to a GGA, activates the account of the user who requested membership. Site managers are not (anymore) necessarily in the loop (but they can still have a look). This also means that accounts which do not belong to any GGA anymore will be evicted from the platform. First of all, no job can be submitted, but after a grace period of one month (which lets access the user’s home directories), the account will be retired, closing all access for the user.

Other Groups

Other groups exist and are managed by UMS as well. Those other groups include the storage group which can give access to several users to a shared storage space.

Other groups are managed in UMS as well, with quite the same procedures, but they do not grant access to the platform.

Summary of the changes with GGAs

With the GGA mechanism,

• The Grid’5000 account manager concept disappears. Users do not have an account-manager anymore. The GGA managers have in charge users that belong to their GGA.
• Account creations are not required to specify an account manager. Instead the user needs to select the GGA in which he wants to belong.
• Account creations do not need anymore to have the approval of both an account manager and a site manager. Now only GGA managers (owners or delegates) validate the account creation without further validation.
• Users’ affiliations are much simpler: no more manager, no more validation but need to keep accurate.
• Users are now grouped by GGA.
• Any usage of the platform is now linked to a membership to a GGA. Accounting by GGA will be performed, and GGA managers will be accountable for it.

Description of the main workflows

New user → account creations

The creation of an new Grid'5000 account begins by the user following the Grid5000:Get an account procedure.

1. The user fills one of the forms: regular account or open-access
   1. For a regular account, a GGA is chosen by the user.
   2. For open-access, the target GGA is automatically set to the open-access GGA
2. The user receives an email in order to validate the provided email address. The user must click on the confirmation URL which is provided in that email, to let the procedure continue. If not, the request is automatically deleted from the system after 24h.
3. The GGA manager (or managers) receive a notification by email of a membership request of the user, and can handle it in the UMS web interface

At this stage, the GGA manager can accept or refuse the GGA membership

• If the membership is refused, it cancels the account creation as well. The user account is not created and the request is removed from the system.
• If the membership is accepted, the user account is first created (the user is now known in the system), and becomes a member of the GGA (the user can now access the platform thanks to that membership)

The membership to a GGA can be for a limited time or permanent, depending on the expiration date filled by the user in the account creation form and then confirmed by the GGA manager when approving the request.

Later, a user may quit the GGA (because his membership is expired, or because of an action from a GGA manager or from the user himself). In that case, the user won't be able to access the platform anymore, unless a new GGA is joined.

Position change → new GGA memberships

Whenever a Grid'5000 user changes position (change of team, lab, job), two actions must be considered:

1. The affiliation information of the Grid'5000 account must be updated, to reflect the new position
2. If the former GGA membership expired or is not relevant with regard to the new position, a new GGA can be joined.

At any time, a Grid'5000 user can request to join a new GGA. A user can be a member of multiple GGAs, even if it is mostly not common.

In particular, a user who is not anymore a member of any GGA has to request a membership to a new GGA (or re-request a membership to the previous GGA), in order to regain access to the platform.

When a user requests joining a new GGA, the GGA manager (or managers) receives a notification by email of the membership request, and can handle it in the UMS web interface. The request can be approved or rejected.

Quitting Grid'5000 → saving data

Whenever a user does not belong to any GGA anymore for more than one month, the account will be retired: no access to the account and associated data (sites' home directories) will be possible anymore. It is up to the user to make sure to retrieve any important data stored in any of the Grid'5000 sites before the account is retired.

Returning to Grid'5000 → retrieving a former account

A non-permanent account is automatically retired when not a member of at least one GGA for one month. In the case the user account is retired, it is however possible to contact support-staff to have the account reactivated'.

Once reactivated, the account appears as expired (back to its state before it was retired). The user must then request a new GGA membership from the User Management System web interface.

Note that the user must remember his account password to access the web interface, or at least be able to receive emails sent to the email address registered with his account, in order to retrieve a new password.

In any case, the user account must be updated and provide:

• the user's current valid email address,
• and an up to date affiliation information.

Group granting access managers → renewing

• Managers of group granting access (owner and delegates) are elected by the Grid'5000 site manager of the site the group is attached, then are set by the Grid'5000 staff in the user management interface.
• Managers of group granting access may have their account expire. In such a case, requests of users to join the group won't be handled and stay waiting until a new manager takes charge of the group.
• The site manager to which a group is attached is notified whenever one of their group lacks a manager. Such a group should have new managers in a short term.