Skip to content

Using the Role based Access Model

Jump to bottom
Thomas Bassler edited this page Jan 24, 2024 · 14 revisions

Using the Role-based Access Model

This page presents the role-based access model and give suggestions on how to best use it.

Role-based Access Control

Of the many approaches to control access to a software system, its functions and its data, "Role-based Access Control" (RBAC) provides a good balance between flexibility of control and ease of use (and implementation). Its basic approach is not to assign privileges individually to users (or accounts), but to group privileges according to organizational roles and assign those roles to individual users. This allows for easier checking of the appropriateness of granted privileges for a specific user (by comparing the roles to the actual tasks the user is expected to execute), and for easier assignment of privileges to a user.

The general approach for RBAC is to

  • Determine the granularity, to which functions of the system shall be managed by low-level privileges,
  • Define the low-level functional privileges and assign the system functions to them,
  • Define organizational roles and grant functional privileges to them,
  • For any new user, select and assign the appropriate organizational roles.

prosEO does not implement any form of hierarchy in its role-based access model, neither at the level of privileges nor at the level of roles (which are termed "groups" in prosEO in accordance with the database schema for Spring JDBC Authentication).

Functional Privilege Levels

prosEO has a large number of low-level functional privilege levels, which generally follow a common approach:

  • Privileges for general access to a part of the system (e. g. the CLI or the GUI),
  • Privileges granting read-only access to some part of the data model ("reader" privileges),
  • Privileges granting create, update and delete access to some part of the data model ("manager" privileges),
  • Privileges granting monitoring access to some part of the system.

Functional privileges are not overlapping. So having "manager" privileges does not entail having "reader" privileges on the same object.

The granularity of these privileges corresponds roughly to the divers microservices, which in turn each cover a specific part of the data model. Thus, privileges exist for the following parts of the data model:

  • Mission data (including spacecrafts, payloads and orbits),
  • Processing orders (including jobs, job steps and product queries),
  • Product classes and selection rules,
  • Products and product files,
  • Processor classes and processors (including tasks),
  • Configurations and configured processors,
  • Workflows,
  • Product archives,
  • Processing facilities,
  • Users and groups.

Apart from these there is a special bootstrap privilege ROOT, which is intended for mission creation/deletion and for creating the first user of a mission. In a newly installed prosEO system, this (and only this) privilege is assigned to a pre-configured user (called sysadm having the same as password, unless username and/or password are overridden in the application.yml configuration file of the User Manager service).

Users and Groups

Users in prosEO are always created per mission. So the same username in a different mission technically speaking is a different user in prosEO. This implies that the passwords will be different, unless the users themselves keep them synchronized, and that privileges granted for one mission do not apply to any other mission. It also entails the need to authenticate for a specific mission (see Authentication Methods below), no matter whether the CLI, the GUI or any of the APIs is used.

A general decision should be taken beforehand on whether personalized users shall be used or functional user names. While the former is recommended from an information security perspective, the latter is often done to avoid problems regarding the storage and processing of personalized user data (with all its implications due to the EU's General Data Protection Regulation [GDPR] and similar legal requirements), since user activities are logged to some extent in prosEO.

The data stored per user is kept to the minimum possible:

  • username: The (unique) user name, consisting of the mission code, a hyphen ("-") and the actual user name (which can thus be used across missions); only the part after the hyphen is used for authentication
  • password: The user's password (BCrypt encoded)
  • enabled: A flag indicating whether the user account is enabled
  • expirationDate: The expiration date for the user account
  • passwordExpirationDate: The expiration date of the password
  • quota: Data download quota for this user (if not set, no quota applies), consisting of:
    • assigned: Monthly data volume allowance in bytes
    • used: Data volume in Bytes used in the last recorded calendar month
    • lastAccessDate: Date of last recorded download (determines calendar month, for which the used volume count is valid)

Users can be created directly in the prosEO CLI, entering the password interactively and leaving the remaining fields to their default values:

prosEO (PTM)> user create ptmoper
Checking for missing mandatory attributes ...
Password (unencrypted; empty field cancels): 
Repeat Password: 
(I6246) User account PTM-ptmoper created

prosEO (PTM)> user show ptmoper
---
username: "PTM-ptmoper"
password: null
enabled: true
authorities: []
expirationDate: "2123-12-31"
passwordExpirationDate: "2123-12-31"
quota: null

We see that although the user is created as ptmoper, the confirmation message and the user detail view report the user name as stored in the database, namely PTM-ptmoper including the mission prefix. Of course, the password is masked out before the user detail information is shown.

While it is possible to grant privileges to users individually, as stated above the recommended approach is for users to become members of one or more appropriate groups (representing roles in the RBAC model). Groups may be defined along typical task assignments in an Earth observation mission, for example:

  • Production Operator: Monitor real-time production status, create, plan and release orders (but not “approve”, that is left for the Moderator), analyse job step logs, resume failed job steps and so on;
  • Archive Operator: Monitor archive usage, ingest products, delete product files from processing facility, delete product metadata;
  • Engineer: Configure missions, product classes, selection rules, processor classes, versions and configurations, processing facilities etc., low-level failure analysis (e. g. access to system logs);
  • Service Manager: Monitor real-time production status, query event history, monitor KPIs;
  • Moderator: Approve orders (this could be an external entity, e. g. the customer during a Reprocessing campaign);
  • External Entity: Product query, product download (only via PRIP, no GUI or CLI access);
  • User Manager: Manage user, groups and privileges.

The sequence of commands below would create a group named operator, assign manager privileges on processing orders to it, and add the user ptmoper to this group:

group create operator
group grant operator ROLE_ORDER_MGR
group add operator ptmoper

Note that although in the data model the role is given as ORDER_MGR, the grant command must prefix all privileges with ROLE_ resulting in a grant of ROLE_ORDER_MGR (this again is due to the implementation being based on Spring Security). A more extended example of privilege assignments to groups can be found in the Mission Configuration tutorial in the section Setup Users and User Groups.

Authentication Methods

The methods of authentication for prosEO differ depending on the type of interface used:

  • Graphical User Interface (GUI): A login prompt is presented, where the username (without a mission prefix) and the password must be entered, and the mission to log in to must be selected.
  • Command Line Interface (CLI): Authentication is always by username, password and mission code (users with ROOT privilege can omit the mission code), but there are two ways of authenticating to the CLI (and a third, which is a combination of both):
    • Authentication with a credential file at CLI startup: This requires the creation of a two-line credential file containing the username in the first and the password in the second line, like so: 
      ptmoper
ptm123.OPER
      Note that on Unix-like systems the credentials file must be readable for the file owner only. With a credential file name of ptmoper.cred the command line on the terminal shell would be something like 
      $ java -jar proseo-ui-cli.jar -iptmoper.cred -mPTM
    • Interactive authentication: The login command within the CLI allows for interactive entering of username and password: 
      prosEO (no mission)> login PTM
Username (empty field cancels): ptmoper
Password for user ptmoper: 
(I6094) User ptmoper logged in
prosEO (PTM)>
    • Interactive authentication with credential file: A combination of the two approaches above using the -i option for the login command: 
      prosEO (no mission)> login -iptmoper.cred PTM
(I6094) User ptmoper logged in
prosEO (PTM)>
  • Core Application Programming Interface (Core API): All requests to the core API (everything outside the ESA-defined APIs) must authenticate using Basic Authentication, where the username is given with the mission prefix (e. g. PTM-ptmoper). A command-line request to a prosEO API with the example credentials above might therefore read: 
    $ curl --user 'PTM-ptmoper:ptm123.OPER' 'https://localhost:8080/proseo/order-mgr/v1/orders'
    where the mission to log in to would be inferred from the mission prefix of the user name.
  • ESA-defined Application Programming Interface (ESA API): Requests to the ESA API (currently only the ODPRIP API) should use OAuth2 authentication as per the applicable ICD (e. g. the ODPRIP ICD, ESA-EOPG-EOPGC-IF-3) and its mission-specific applicable tailoring. However for testing purposes Basic Authentication is also available, where the username is given with the mission prefix, but separated by a backslash ("\") character (e. g. PTM\ptmoper).

For any user to authenticate at the GUI, the CLI or the ESA API the respective privileges need to be assigned (GUI_USER, CLI_USER or PRIP_USER). No special privileges are required to access the Core API, but of course the domain-specific privileges applicable for the specific request must be assigned.

Multi-mission Considerations

Since the underlying Spring Security framework has no concept of tenancy (or "multi-mission usage" in prosEO terms), implementation of a strict mission separation in prosEO has not been straightforward. Below is a summary of the multi-mission aspects of prosEO's role-based access model:

  • At database level users must be differentiated between missions, that is, the same database entry ptmoper could not be used for multiple missions. Therefore the username at database (and at Spring Security) level is prefixed with the mission code, e. g. PTM-ptmoper or S5P-proseo or the like.
  • The mission prefixes from the database show up, when usernames are displayed in the CLI, but they are not used, when entering user-related commands (the mission context is clear from the mission, to which the user manager is logged in).
  • Any authentication must be against a mission (except for users with ROOT privileges in order to be able to create a new mission, especially the first one after installation of prosEO, or to delete a mission). Depending on the interface there are different methods for choosing the intended mission (see Authentication Methods above).
  • User passwords are mission-specific. If an alignment between the mission is desired, it is up to the user to ensure this.
  • Group memberships and individual privilege assignments are mission-specific. The (apparently) same user may have different privileges depending on the mission.

Reference Information

Tutorials

Clone this wiki locally