Roles
Multitenant Access Control enables a solution to manage authorization for their resources using RBAC (Role Based Access Control). The definition and rules for the creation, management and sharing of roles are explained in this section.
In a RBAC based system, roles are a first class citizen and control how data can be accessed by a set of users of an organization. In combination with an application’s access control list, roles enable authorization for protected resources. The authorization domain model specifies how roles interact with other entities in the system.
How roles interact with the rest of the system
Roles are assigned to users, applications (e.g. for service-to-service authentication) and groups.
-
Groups, users and applications can have multiple roles assigned.
-
Roles assigned to groups are inherited to subgroups.
-
Roles need to be assigned to applications to access other applications.
-
Roles indicate a certain job / position / area of work in an organization (e.g. software-developer, project-manager, …)
-
Very specific and fine-grained roles like "dashboard-reader" can
-
lead to a huge amount of roles and
-
make it tough to assign all required privileges to a user for a new job / position.
-
Resource Access Permissions grant resource privileges to roles.
-
This means that roles define who gets to access what
-
Access to resources is transitive: Resources are protected by resource access permissions, resource access permissions are granted to roles, roles are assigned to users and/or clients
ACL Entries are derived from roles
-
In contrast to a traditional RBAC approach, where roles are defined on a protected resource of the software (e.g. a role defined on a specific REST controller or controller method) and matched against the roles of a user, Multitenant Access Control allows for a more flexible authorization. In order to do this, the required role to access a protected resource is defined in Multitenant Access Control itself - separately for each tenant. The information about which role is allowed to access which protected resource is transferred to the resource servers via an ACL.
-
The access control lists (ACL) allow applications to decide whether access to a protected resource should be granted based on a subject’s roles. To decide if a subject is permitted to access a protected resource, resource servers need to match the subject’s roles against the roles which are specified in the set of ACL entries for the requested resource.
Roles consist of a name and a description, with the name being a unique identifier. To ensure the uniqueness of a role, a URN specification which includes a custom Multitenant Access Control namespace and tenant identifiers is used.
Types
There are two types of roles.
- Application roles
-
Application roles are a convenience functionality which allow applications to pre-define roles which grant access to static resources.
Especially for applications with many fine-grained resources it might make sense to use this functionality in order to help users manage access to the application’s functions on a coarser level.Example:
An application can restrict the access to its data (like "all measurements") or functionality (like reporting) by registering them as resources.
In addition, the application can register application roles like 'Admin' which allow access to the registered resources.
A contract can be used to provide the application role including the related resources to other tenants. - Tenant/Organization roles
-
Organization (= Tenant) roles are used to grant access to resources in an individual way in addition to the predefined application roles.
They can also be used to grant access to dynamic resources (like measurements of a specific machine) in contrast to application roles. Organization roles are individual to a organization (tenant) and not connected to a single application, thus they cannot be part of a contract.
Identifier
The URN for Multitenant Access Control roles is defined as follows:
| URI scheme type | Namespace identifier | Owning Tenant | Application | Organizational Unit (optional, not supported currently) | Role name |
|---|---|---|---|---|---|
urn |
macma-tenant-role |
tenant’s ID |
- |
unit name For uniqueness of similar roles in different units of the same tenant (e.g. "Software Developer FE" and "Software Developer IMB"). |
sanitized role name |
urn |
macma-application-role |
tenant’s ID |
application name |
- |
sanitized role name |
Examples
| Type | Role Name | Role URN (in ACL) | Corresponds to |
|---|---|---|---|
Tenant/Organization Role |
esw:operator |
urn:macma-tenant-role:898d3d4c-1264-4577-b1e5-b142323b4aad:esw-operator |
The operator of the ESW group for the tenant 898d3d4c-1264-4577-b1e5-b142323b4aad |
Application Role |
admin |
urn:macma-application-role:898d3d4c-1264-4577-b1e5-b142323b4aad:sample-application:admin |
Administration functionality of the application 'sample-application' in the tenant 898d3d4c-1264-4577-b1e5-b142323b4aad |