Resources
This section describes the two types of resources known to Multitenant Access Control and their identifiers.
The resource registration is strongly oriented towards the existing UMA, Keycloak and Bosch MES Access Control specifications and is considered a good approach which will still be able to support different authorization servers in the future:
| Attribute | Description | Examples |
|---|---|---|
id |
Unique identifier in combination with resource type, application and tenant |
dafdd949-80c3-459a-b94c-5d6398840e07 |
type |
URN referencing the resource type. |
urn:isan:0000-0000-9E59-0000-O-0000-0000-2 |
name |
Human-readable display name of resource. |
Machine 42 |
description |
Human-readable resource description. |
The machine used to create part 42 |
iconUri |
URI referencing the resource’s icon. |
https://application.example/icons/machine.png |
privileges |
List of privileges for the resource. The following privileges are available: add, read, modify, delete, execute |
["read", "write"] |
| Currently, there is no support for defining or evaluating access permissions on entities in a hierarchical fashion (e.g. Parent[READ] ⇒ Child[READ]). |
Kinds of resources
Static resources
-
Are usually created on application startup.
-
Can be assigned to application roles and tenant/organization roles.
-
Can be shared to other tenants.
-
General resources like "all machines" are typically static resources and exist for every tenant an application has been shared to.
Dynamic resources
A specific machine exists only once owned by a single tenant. Such individual resources are called dynamic resources.
-
Usually created at runtime triggered by a user action or an event (from another application).
-
Can only be assigned to tenant/organization roles due to being dynamic.
-
Should be named well to allow a user to search for a resource when assigning permissions (e.g., not calling the first station of every line "Station 1" but rather ExamplePlant/Area51/Line2/Station1)
Dynamic resources enable Fine-Grained Access which describes the ability of applications to not only restrict access based on broad concepts like "All Machines" or "My Tickets", but instead create and manage resources dynamically that denote a specific entity (or group of entities) and are unique to the tenant they are created by.
Examples: "Area 1", "Machine 47/11", Station "1.52"
Resource Type Naming
Assuming a ticket(s) resource has to be protected. A general access level based on static resources like "all tickets", "own tickets", "other tickets" or "late tickets" as well as more fine-grained dynamic resources like "Tickets for Station 1 of Line A", "Tickets for Area 1" could be defined.
In this case the following naming scheme for resource types is proposed:
| Resource Name | Resource ID | Resource Type | dynamic/static |
|---|---|---|---|
All Tickets |
all |
urn:com:bosch:bci:your-app:entity:tickets |
static |
Own Tickets |
own |
urn:com:bosch:bci:your-app:entity:tickets |
static |
Late Tickets |
late |
urn:com:bosch:bci:your-app:entity:tickets |
static |
Tickets BaP/Area51/Line1/StationA |
see below |
urn:com:bosch:bci:your-app:entity:ticket |
dynamic |
Tickets for Area 1 |
see below |
urn:com:bosch:bci:your-app:entity:ticket (hint: singular) |
dynamic |
| Resource Types must be unique across dynamic and static resources. |
|
Excessive resource count can cause performance degradation. Therefore, try to minimize number of dynamic resources (and access permissions) created for your use case. Actual limitations are listed in the operations manual. |
Resource identification
A resource can be uniquely identified by the quadruple of
-
application ID of the owning application (= resource server)
-
owning tenant ID (= owner)
-
resource ID
-
resource type
Resource IDs
Given an exemplary equipment hierarchy with different entities and a hierarchical relation:
| Faciltiy-ID | Facility-type | … |
|---|---|---|
AREA-1 |
Area |
|
STAT-1 |
Station |
|
DEV-1 |
Device |
To manage access to quality data for a device:
| Facility-ID | Q-Data-ID |
|---|---|
DEV-1 |
Q1 |
The ID of the resource registered in Multitenant Access Control could be:
-
implicit: the actual Q-Data ID: Q1;
-
implicit: a combination the related data’s IDs: AREA-1:STAT-1:DEV-1:Q1;
-
explicit: a dedicated ID stored with the Q-Data: eef610a5-cd62-469b-b556-6259bfbb147f.
Re-using another (existing) ID of the entity to protect is allowed (if the name conforms to the mentioned restrictions). However, Multitenant Access Control encourages you to consider assigning unique IDs and storing them in your persistence (see "explicit" in the example above).
Assigning explicit IDs
-
allows using one Multitenant Access Control resource for multiple own resources;
-
is independent of changes to the entity’s id itself (if that can change at all);
-
allows for easy tracking which (Multitenant Access Control-)resources have already been created and which haven’t (migration or lazy creation scenarios);
-
might perform better when joining a cached ACL against your dataset to show "everything a user is supposed to see", especially if using (long) string based identifiers.
Resource separation
There is a common desire for easy separation of certain permissions based on applicable (dynamic) resources.
The desired permissions assignments can be modeled as
It is to be interpreted as "Access KPIs of Line A", "Start/Stop of Line B", and so on should be granted. If the resources are created as [Access KPIs, Start/Stop, Setup, Shift Book, Line A, Line B, LineC, Line D], and tenant/organization roles are created having the matrix combination of resources of
-
"Access KPIs" and "Line A"
-
"Start/Stop" and "Line B"
-
"Setup" and "Line B"
-
"Access KPIs" and "Line D"
-
"Shift Book" and "Line D"
and those tenant/organization roles are assigned to the user,
then the actual result is
This results in undesired permission grants like
-
Access KPIs of Line B
-
Start/Stop of Line A
and so on.
With the current restriction of MACMA not supporting deny permissions the only way is to create resources for each field of the matrix, e.g.
-
Access KPIs of Line A
-
Access KPIs of Line D
-
Start/Stop of Line B
-
Setup of Line B
-
Shift Book of Line D
