Skip to content

Resources lifecycle and eligibility

The Resource Portal is part of the Authorization Service. In these pages, we use "Resource Portal" to refer to the subset of the Authorization Service that deals with resources lifecycle and eligibility, not only to the computing resources web application.

The Resource Portal offers the following functionalities:

  • Provides service managers a way to implement an eligibility criteria for their service, i.e. define which users are eligible or subscribed to their service.
  • Manages the lifecycle of computing resources, such as websites and accounts, including reassignment on conclusion of a CERN contract or other changes in the eligibility status of a user for a certain resource.

This page explains the general concepts and data model proposed by the service.

Warning

This is a work in progress. The current version of the API (September 2024) does not yet support all the concepts described here. Most notably, Resource Groups and Organizational Units are not implemented.

Definitions

Service

A IT service run by the CERN IT Department or other entity.

Resource

An element provided by a service for which we want to track lifecycle and ownership individually. The granularity of the resource is defined by the service itself. A website, a DBOD instance, an EOS project, a mailbox, a software license are examples of a different types of resource.

A Resource defines:

  • Resource type (required): Openstack Project, Website, Account...
  • Name (required): a unique identifier for the resource within the given Resource Type.
  • Owner (required): the person owning the resource.
  • Administrators (optional): a group with administrative rights on the resource.
  • Resource Category (required): official, personal.
  • Validity Limit (optional): a time at which the resource will automatically enter the Blocked state.
  • Resource Group (optional): the resource group to which the resource belongs. If a resource belongs to a resource group, its owner and administrators are overridden by the owner and admistrators of the resource group.

Both owner and administrators of a resource have full control over the resource in the Resources Portal.
Access rights for owner and administrators in the concrete resource depend on the service providing the resource.

The resource category determines the resource lifecycle. A service can provide only official or personal resources, or both.

A personal resource is a resource whose lifecycle should be bound to the owner.
Please note that this does not necessarily imply that the resource is for personal usage.
For example, a mailbox or a software license are assigned to a specific person even if they are for professional usage.
A personal resource cannot be transferred to a new owner.

An official resource is a resource whose lifecycle should be bound to a service or application.
All official resources should belong to a Resource Group.
An official resource can be moved to another resource group.
Note: currently it is possible to assign official resources to a new owner, but this option will be removed when resource groups are fully implemented.

Each resource that does not belong to a Resource Groups has an individual lifecycle, managed by the Resource Portal.
See the resources state diagram for more information.

Resource Group

Logical grouping of any types of resources, for a common operational purpose. All the resources that make up a service or an application would typically belong in the same Resource Group.

For example, a Resource Group could include all the resources needed by the "ZZ Data Processing" application, i.e. an Oracle Database, an Openstack Project and a Service Account, as shown in the image below.

Resources in a resource group do not have an individual lifecycle.

A Resource Group defines:

  • Name (required): a unique identifier for the resource group.
  • Owner (required): the person owning the resource group.
  • Administrators (required): a group with administrative rights on the resource group.
  • Organisational Unit (required): the Organisational Unit to which the Resource Group belongs.
  • Additional metadata: to be defined.

Users can create new official resources in any Resource Group of which they are owners or administrators, provided that they have the permissions required by the service providing the resource.

Organisational Unit

Organisational Unit with budgetary responsibility that owns a set of Resource Groups. Examples of an Organisational Unit are a CERN Department or a CERN Experiment.

In the previous example, the "ZZ Experiment" organisational unit included several Resource Groups, each for a different application or service related to the experiment.

An Organisational Unit defines:

  • Name (required): a unique identifier for the organisational unit.
  • Owner (required): the person owning (main responsible for) the organisational unit.
  • Administrators (required): a group with administrative rights on the organisational unit.
  • Additional metadata: to be defined.

Organisational Unit owners and administrators can create new Resource Groups within their Organisational Unit.

Model