Documentation – Users and roles

Internal: Approving/revoking accounts, roles and other actions

Mon, 01 Jan 0001 00:00:00 +0000

Approving role and change requests

When a registered user applies for a role, the request has to be validated by someone who has the proper permissions to grant such a role. If you request a role on a given entity, any user with a valid role on that entity or above will be able to approve your request.

Example - If you request a “site administrator” role on site X, then the following users can approve your request:

site administrators and security officers of site X
regional operations staff, managers and deputies of the Operations Centre to which site X belongs
GOCDB admins

Role requests you can approve are listed on the Manage roles page (accessible by clicking the Manage roles link in the user status panel in the sidebar).

In order to approve or decline role requests, simply click on the accept or deny links in front of each role request.

Revoking roles

If a user within your scope has a role that needs to be revoked, you can do this from the user’s page, where user’s details are listed along with his/her current roles. To revoke a role, simply click on the role name then on the revoke link at the top right of the role’s details page.

Note: This works for other users within your scope but also for yourself. However just note that if you revoke your own roles you may not have proper permissions to recover them afterwards.

Internal: Understanding and manipulating user accounts

Mon, 01 Jan 0001 00:00:00 +0000

Authentication

The EGI Configuration Database UI attempts to authenticate you in one of two ways (the REST style API applies X.509 only):

First, by requesting an IGTF accredited user certificate from your browser. If a suitable certificate is detected, you will be asked to confirm selection of your certificate in your browser. Note: if a client certificate has been provided, it will take precedence over any IdP based authentication.
Second, if you do not have a user certificate or you hide your certificate from (e.g. by starting a new/anonymous private browser session or pressing ‘Cancel’ when prompted for a certificate), you will be redirected to the landing page where you can authenticate with the EGI Identity Provider Service (IdP) and your chosen institution (if available). If authentication is successful, you will be redirected back to the Configuration Database. Please note, not all logins available in the EGI IdP provide a sufficient level of assurance (LoA) to login (the LoA must be ‘Substantial’).

Editing your user account

The editing process is the same as the registration process. To edit your user account, simply follow these steps:

click on the “view details” link in the “User Status” panel on the sidebar. You should get a page showing your user account information.
Click on the “edit” link on top of it.

Viewing users

Each user account has its own user details page which is accessible to anyone with a valid certificate.

There is currently no facility for listing all users in the database. List of users that have a role on a given site appears on site details pages (see section about sites). It is also possible to search for a user’s account using the search feature on the sidebar.

Deleting your user account

If you wish to unregister from the Configuration Database, follow these steps:

click on the view details link in the “User Status” panel on the sidebar. You should get a page showing your user account information.
Click on the “delete” link on top of it.
Confirm your choice.

Your account will then be deleted along with any roles the account has.

Lost access to your account

Under the following circumstances it is possible to lose access to an account:

You use your IGTF X.509 certificate to access and renew or change certificate, it is possible that the certificate’s distinguished name (DN) has also changed. This is what the Configuration Database uses to identify your account.
You have authenticated with EGI Check-in, but via a different underlying IdP (i.e. You usually log in with your institutional credentials, but today you logged in with EGI SSO).
You have changed the way you log in (i.e. X.509 to EGI Check-in)

In these situations, it is usually possible to regain access using to your certificate based account by following one of the following procedures:

If for any reason you were unable to complete the relevant procedure (e.g. mail confirmations problems) please open an EGI Helpdesk ticket addressed to the “Configuration and Topology Database (GOCDB)” support unit.

You have a new certificate and have lost access to your account

Install your new certificate in your browser.
Go to EGI Configuration Database. If you are already logged in, then clear your caches and restart your browser or start a new private browser session.
When prompted, select your new certificate.
You should be able to access, but since you are authenticated with your new certificate, it is as if you had no user account.
In the User Status panel in the sidebar, click on the Link Identity/Recover Account link.
Specify in the form:
- Authentication type: X.509
- The DN of your old certificate previously used to authenticate to your X.509 based account.
- The email address associated to your account.
Submit and, upon validation, an email will be sent to the specified address, which has to match the one registered with your account. This is to avoid identity theft. The email contains a validation link.
Click on the validation link or copy/paste in your browser. Once validated, changes are immediate.

You can only associate one X.509 DN with your account at any given time.

You have authenticated with EGI Check-in, but via a different Identity Provider

It’s possible to link this identity with your “other” EGI Check-in identity at the level of the EGI Check-in, see account linking documentation.

Once your identity is linked at the EGI Check-in level, if you are still having problems accessing, please reassign the ticket to “Configuration and Topology Database (GOCDB)”

You have changed the way you log in (i.e. X.509 to EGI Check-in)

You can link these identities at the EGI Configuration Database level by following these steps. The steps assume an existing X.509 based account and that you are currently authenticated via EGI Check-in, though the steps should hold for any pair of supported authentication methods.

In the User Status panel in the sidebar, click on the Link Identity/Recover Account link.
Specify in the form:
- Authentication type: X.509
- The DN of your certificate used to authenticate to your X.509 based account
- The email address associated to your X.509 based account.
Submit and, upon validation, an email will be sent to the specified address, which has to match the one registered with your X.509 based account. This is to avoid identity theft. The email contains a validation link.
Click on the validation link or copy/paste in your browser. Authenticate with your EGI Check-in identity. Once authenticated/validated, changes are immediate and you will be able to access your account with both your X.509 and EGI Check-in identities.

Internal: Using roles

Mon, 01 Jan 0001 00:00:00 +0000

Roles definition

Registered users with a user account will need at least one role in order to perform any useful tasks.

Role Types

A role: Unregistered users
B role: Registered users with no role
C role: Users with a role at site level (site admin)
C’ role: Users with a management role at site level (site operations manager, site security officer…)
D role: Users with a role at regional level (regional staff support staff, ROD, 1st Line Support)
D’ role: Users with a management role at regional level (NGI manager or deputy, security officer)
E role: Users with a role at project level

The only difference between C and C’ users is that:

C can NOT approve/reject role requests.
C’ can only approve/reject role requests for their SITE.

The difference between D and D’ users is that:

D can NOT add/delete sites to/from their NGI.
D can NOT update the certification status of member sites.
D can NOT approve or reject role requests.

Roles

At Site level

Site Administrator - person responsible of maintaining a site and associated information in the EGI Configuration Database (C Level)
Site Security officer - official security contact point at site level (C' Level)
Site Operations Deputy Manager - The deputy manager of operations at a site (C’ Level)
Site Operations Manager - The manager of site operations (C’ Level)

At NGI/Regional level

Regional First Line Support - Staff providing first line support for an NGI (D Level)
Regional Staff (ROD) - staff involved in Operations Centre activities such as user/operations support (D Level)
NGI Security officer - official security contact point at regional level (D' Level)
NGI Operations Deputy Manager - Deputy manager of NGI operations (D’ Level)
NGI Operations Manager - Manager of NGI operations (D’ Level)

At Project level

COD staff - COD staff (E Level)
COD administrator - People administrating Central COD roles (E Level)
EGI CSIRT Officer - official security contact point at project level (E Level)
Chief Operations Officer (COO) - The EGI Chief Operations Officer (E Level)

Permissions associated to roles

Roles and permissions are based on whether the considered object is owned or not. In the table below the following definitions apply:

Owned group: a group on which the role applies (ROC, NGI, project)
Owned site: a site on which the role applies, or belonging to an owned group
Owned service endpoint: a service endpoint belonging to an owned site

Each role has a set of associated permissions which apply on the role’s scope (site, region or project). Main permissions are summarised in the table below

Action	A) Unregistered users	B) Registered users with no role	C) Site level users	C’ ) Site Management Level Users	D) NGI level users	D’ ) NGI Management Level Users	E) Project level users
Add a site to an owned group	irr.	irr.	irr.	irr.	no	yes	irr.
Add a site to a non owned group	no	no	no	no	no	no	no
Add a service endpoint to an owned site	irr.	irr.	yes	yes	yes	yes	irr.
Add a service endpoint to a non owned site	no	no	no	no	no	no	no
Add a downtime to an owned service endpoint	irr.	irr.	yes	yes	yes	yes	irr.
Add downtime to a non owned service endpoint	no	no	no	no	no	no	no
Update information of an owned site	irr.	irr.	yes	yes	yes	yes	irr.
Update information of a non owned site	no	no	no	no	no	no	no
Update certification status of an owned site	irr.	irr.	no	no	no	yes	yes
Update certification status of a non owned site	no	no	no	no	no	no	yes
Update information of a owned service endpoint	irr.	irr.	yes	yes	yes	yes	irr.
Update information of a non owned service endpoint	no	no	no	no	no	no	no
Update information of an owned group	irr.	irr.	irr.	irr.	yes	yes	irr.
Update information of a non owned group	no	no	no	no	no	no	no
Update own user account details	irr.	yes	yes	yes	yes	yes	yes
Update other user’s account	no	no	no	no	no	no	no
Update a downtime on an owned service endpoint	irr.	irr.	yes	yes	yes	yes	irr.
Update a downtime on a non owned service endpoint	no	no	no	no	no	no	no
Delete an owned site	irr.	irr.	no	no	no	no	no
Delete a non owned site	no	no	no	no	no	no	no
Delete an owned service endpoint	irr.	irr.	yes	yes	yes	yes	irr.
Delete a non owned service endpoint	no	no	no	no	no	no	no
Delete an owned group	irr.	irr.	irr.	no	no	no	irr.
Delete a non owned group	no	no	no	no	no	no	no
Delete a downtime on an owned service endpoint	irr.	irr.	yes	yes	yes	yes	irr.
Delete a downtime on a non owned service endpoint	no	no	no	no	no	no	no
Delete your own user account	irr.	yes	yes	yes	yes	yes	yes
Delete other user’s account	no	no	no	no	no	no	no
Register a new user account	yes	irr.	irr.	irr.	irr.	irr.	irr.
Request a new role	no	yes	yes	yes	yes	yes	yes
Approve a role request on an owned group	irr.	irr.	no	no	no	yes	yes
Approve a role request on an owned site	no	no	no	yes	no	yes	irr
Approve a role request on a non owned site or group	no	no	no	no	no	no	no
Reject a role request on an owned group	no	no	no	no	no	yes	irr.
Reject a role request on an owned site	no	no	no	yes	no	yes	irr
Reject a role request on a non owned site or group	no	no	no	no	no	no	no
Revoke an existing role on an owned object	irr.	irr.	no	yes	no	yes	irr.
Revoke an existing role on a non owned object	no	no	no	no	no	no	no
Retrieve an existing account/ change certificate DN	yes	yes	yes	yes	yes	yes	yes

Requesting roles for your account

There are 2 ways to request new roles.

By clicking on the manage role link (sidebar, user status panel)
- the first form allows you to choose the entity (site or group) on which you want to request a role
- the second form lets you choose the role you want to apply for
By clicking on the request role link from site detail pages or group detail pages.
- displayed form lets you choose the role you want to apply for

Once made, role requests have to be validated before the role is granted to you. This part of the process is described in the next section.