User Management Service documentation

From Grid5000
Revision as of 19:06, 20 April 2020 by Pneyron (talk | contribs)
Jump to navigation Jump to search

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 granting 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.

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.

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 platform by the members of their GGA, for instance when activity reports for the platform are requested by the funding parties.

The GGAs split most likely matches
  • either small entities such as research projects / research teams / ... ;
  • or more general grouping entities such as labs, institutes, company or community.

The related entity size which a GGA refers to depends on the user count of the resulting group, so that groups keep being manageable. The goal is to have neither too big groups, nor too many groups.

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. 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 electing 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.

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

  • How are handled account creations
  • How are handled account expirations
  • How are handled new GGA memberships ?