Security¶
Authorization scheme¶
The following class diagram describes the authorization scheme applied in platform providing with the access control mechanism to the resources provided by the platform.
Authorisation Scheme Class Diagram¶
The following defintions supports this scheme:
- User and Group are defined according the regular convention that a group is a set of users.
- A Domain is an organizational unit to regroup User, Group and Resources.
- A Role defines the set of Privileges that are granted to a User or a Group for a specific Domain or globally.
- The assignement of a Role to a User or a Group is called a “Role Grant”. A Role Grant can be associated to a Domain and is therefore called “Domain Role Grant”. A Role Grant taht is not associated to any Domain is a “Global Role Grant”.
- A Resource can belong to a Domain. If not, the Resource is considered as global.
- A Privilege is an access control for a given Resource Type.
- A Permission is a specific Privilege for a User or a Group for a given Resource.
And the following rules applies:
- Users and Groups with a Domain Role Grant on a certain Domain have all the Privileges defined by that Role on all Resources belonging to that Domain.
- Users and Groups with a Global Role Grant have all the Privileges defined by that Role on all Resources of that Resource Type, whether belonging to a Domain or not.
- A specific Permission for a specific Resource is granted to a specific User or Group.
The authorisation consists of two phases:
- a generic phase where the current User ‘s access privileges are compared to the necessary privileges for the accessed object according to the domain or the global.
- an optional specific phase where the same check is performed for the requested operation. This phase is specific to the entity object in question as the possible operations are entity-specific.
The authorisation for a specific operation must be ensured by the code of the Entity object. The central authorisation model supports this task by initialising the properties corresponding to the operation privilege that are applicable to the entity subclass.
Role, Privileges and Permissions¶
Basic Privileges¶
For all resources, there are 6 basic privileges and permisions: “Can Create”, “Can Change”, “Can Delete”, “Can View”, “Can Search” and “Can Manage”. The following table describes the access to a resource type for a given privilege according to the software component providing the service. If a combination is not listed then no access is granted.
| Resource | Privilege | description |
|---|---|---|
| Catalogue | Can View | Allow discovering the indices present in the Catalogue |
| Catalogue | Can Manage | Allow Modifying global configuration element of the catalogue |
| Collection | Can Create | In the portal, allow creating a new collection |
| Collection | Can Change | In the portal, allow modifying an existing collection |
| Collection | Can Delete | In the portal, allow delete an existing collection |
| Collection | Can View | In the portal, allow viewing an existing collection |
| Collection | Can Search | In the portal, allow searching for an existing collection [CanView] |
| Collection | Can Manage | In the portal, allow granting privilege and permissions for an existing collection [CanView&CanChange] |
| Data Package | Can Create | In the portal, allow creating a new data package |
| Data Package | Can Change | In the portal, allow modifying an existing data package |
| Data Package | Can Delete | In the portal, allow delete an existing data package |
| Data Package | Can View | In the portal, allow viewing an existing data package |
| Data Package | Can Search | In the portal, allow searching for an existing data package [CanView] |
| Data Package | Can Manage | In the portal, allow granting privilege and permissions for an existing data package [CanView&CanChange] |
| Dataset | inherited form the parent Repository | |
| Entry | inherited form the parent Index or Series | |
| Index | Can Create | In the catalog, allow creating a new index (other than personal index) |
| Index | Can Change | In the catalog, allow modifying an existing index (other than personal index) |
| Index | Can Delete | In the catalog, allow deleting an existing index (other than personal index) |
| Index | Can View | In the catalog, allow viewing an existing index (other than personal index) |
| Index | Can Search | In the catalog, allow searching for an existing index (other than personal index) [CanView] |
| Index | Can Manage | In the catalog, allow granting privilege and permissions for an existing index [CanView&CanChange] (other than personal index) |
| Job | Can Create | In a sandbox or cluster, allow executing a new job from a process |
| Job | Can Delete | In a sandbox or cluster, allow deleting an exisitng job |
| Job | Can View | In a sandbox or cluster, allow viewing the status or the results of a job |
| Job | Can Search | In a sandbox or cluster, allow searching for an existing job |
| Process | inherited form the parent Processing Service | |
| Processing Service | Can Create | In the portal, allow creating a new processing service |
| Processing Service | Can Change | In the portal, allow modifying an existing processing service |
| Processing Service | Can Delete | In the portal, allow delete an existing processing service |
| Processing Service | Can View | In the portal, allow viewing an existing processing service |
| Processing Service | Can Search | In the portal, allow searching for an existing processing service [CanView] |
| Processing Service | Can Manage | In the portal, allow granting privilege and permissions for an existing processing service [CanView&CanChange] |
| Repository | Can Create | In the storage, allow creating a new dataset |
| Repository | Can Change | In the storage, allow annotating an existing dataset |
| Repository | Can Delete | In the storage, allow overwriting/delete an existing dataset |
| Repository | Can View | In the storage, allow reading an existing dataset |
| Repository | Can Manage | In the storage, allow granting privilege and permissions for an existing dataset [CanView&CanChange] |
| Series | Can Create | In the catalog, allow creating a new series (other than personal index) |
| Series | Can Change | In the catalog, allow modifying an existing series (other than personal index) |
| Series | Can Delete | In the catalog, allow deleting an existing series (other than personal index) |
| Series | Can View | In the catalog, allow viewing an existing series (other than personal index) |
| Series | Can Search | In the catalog, allow searching for an existing series (other than personal index) [CanView] |
| Series | Can Manage | In the catalog, allow granting privilege and permissions for an existing series [CanView&CanChange] (other than personal index) |
Basic domains & roles¶
Keep in mind that the aboved table describe only the privileges, they are most of the ime combined with a role in a domain.
Some domains are automatically created based on users, their organizations and their objectives on the platform:
- One domain is created for every new user registered on the platform with an access to The Terradue Cloud Platform.
- One domain is created for any organisation represented on the platform that provides with data, processor or ICT resources.
- One domain is created for every laboratory in which a processing service is integrated. A laboratory is often the same domain as the organization but sometimes, it may englobe many of them or a subset depending on the project scope.
When combined in a role and a domain, the included user or the group have different level of access to the resource. The following table lists the most basic combination implemented on the platform.
| Role | Domain(s) | Privilege(s) | User(s) and group(s) | Resources |
|---|---|---|---|---|
| Owner | username | All | User with the corresponding username | Data Package, Index, Repository, Series |
| Owner | organisation | All | User that initiated a community or a thematic group | Collection, Data Package, Index, Repository, Series, Processing Service |
| Administrator | all domains in a community | All | Portal Administrators | Collection, Data Package, Index, Repository, Series, Processing Service |
| Content Authority | all domains in a community | CanView & CanSearch & CanCreate & CanDelete | Scientific Communicators | Collection, Data Package, Index, Repository, Series |
| Member | organisation | CanView & CanSearch | User or group invited in a community or a thematic group | Collection, Data Package, Index, Repository, Series |
| Staff | organisation | CanView & CanSearch & CanCreate & CanDelete | User or group part of an organisation | Collection, Data Package, Index, Repository, Series, Processing Service |
| Expert | laboratory | CanView & CanSearch & CanCreate & CanDelete | Users that access the Developer Cloud Sandbox | Sandbox |
The roles are obviously not limited to the previous list. Any combination of domain and privileges as a new role can be defined in the platform.