2.11 Graph Access Rules
The Graph Access Rules define rules for the Graph Security Layer. Through these definitions a certain user is allowed to see the selected Entities, Properties and Relationships. Rules are applied on each graph related EBS request. The applied access control here is the Need-to-know principle, which describes that only assigned data can be viewed by a user. Data that is not assigned cannot be seen by the user or in other words, if a user is not assigned to a Graph Access Rules he cannot see anything.
The details to the Graph Access Rules can be found in chapter Graph Security Layer.
Define a Graph Access Rule
New Graph Access Rules are created in the GBS UI by pressing the + Create new button. An Access Rules consist of
following parts:
- Entities: Entities a user is allowed to see (at least one entity must be added to a rule)
- Properties: Properties per entity a user is allowed to see
- Relationships: Relationships a user is allowed to see
- Users and Groups: Keycloak users, groups, and service accounts allowed to see entities, properties, and relationships
- Users: A user assigned in a rule is allowed to see objects defined in the rule.
- Groups: All users assigned to a group, that is defined in a rule, are allowed to see objects defined in the rule even if the user itself is not explicitly added to the rule.
- Service Accounts: If a Keycloak client should be able to retrieve an access token, it has to have service
accounts enabled. In that case an internal user named
service-account-<client-name>is created. If such a service account is added to a rule it means that the corresponding client is allowed to see objects defined in the rule.
- Access Level: Currently only view permission is supported.
- Property Value Condition: Allows to define a condition on Properties which have to be met in order for a user to see the corresponding data.
Evaluation of Access Rules
Based on which objects are added to an Access Rule, evaluation is done differently
- Entities: If only an entity (without any corresponding properties) is added to an Access Rule, a user is allowed to see the node without properties.
- Properties: If properties are added to an Access Rule, a user is allowed to see the node and all configured properties.
- Relationships: If relationships are added to a rule, a user is allowed to see the relationship only if both nodes, building the relationship, are allowed.
- Property Value Condition: If a condition is added to a rule, a user is allowed to see nodes where the specific property matches the value for a certain entity. If no condition is set for an entity, the user is allowed to see all nodes of the entity.
Graph Security Layer
The Graph Security Layer allows defining fine-grained rules for data visibility. When the Data Context Hub Backend
Services (EBS) receives a graph related request it loads the corresponding rules and delegates filtering to a Graph
Security specific Worker. The remaining nodes and relationships, if any, are then sent to all registered
ExternalGraphSecurity workers for further filtering after which the result is provided as a response to the caller.
Graph Security Layer is only applied when following requirements are fulfilled:
- System configuration entry for group
Systemand keygraph-security-layer-modeis set to 1 - Module
xpl-graph-security-layeris licensed - At least one worker of type
GraphSecurityis configured
Configuration
The following Graph Security Layer configurations can be made in the SysConfiguration table:
| Group | Key | Description |
|---|---|---|
| System | graph-security-layer-mode | Toggle Graph Security Layer (0 = inactive, 1 = active). |
| System | ebs-graph-security-worker-threads | Defines the number of threads per Graph Security Layer worker. |
| System | ebs-graph-security-worker-partition-size | Number of objects that are passed to a Graph Security Layer worker at once. |
The latter two can be used to tweak the performance since they directly influence how many requests will be sent to each
GraphSecPy worker and how many threads each worker should use.
Examples
Following examples should help understand how Access Rules work.
Prerequisite
- Keycloak group: Confidential-group
- Keycloak users: Alice, Bob (is member of confidential-group), Max
- Nodes and relationships
- Rules
| Rule | Entities | Properties | Relationships | Property Value Condition | Users and Groups |
|---|---|---|---|---|---|
| A-rule | A | Title, status | CONTAINS, DEFINES | - | Alice, confidential-group |
| B-rule | B | Title, Description | - | Title = "B1" | Bob |
Example 1: Alice
Because Alice is part of A-rule she is able to see all A nodes and properties Title, and status on these nodes.
Additionally she is also able to see CONTAINS relationships as defined in the rule.
She cannot see the DEFINES relationship because she is not allowed to see B nodes.
Example 2: Bob
Bob is a member for confidential-group, which again is part of A-rule, so he is allowed to see A nodes and properties Title and status.
He is also allowed to see B nodes and properties Title and Description because he is part of B-rule.
But the only B nodes he is allowed to see are those whose title is exactly "B1" because of the property value condition defined in the rule.
Additionally he can also see CONTAINS and DEFINES relationships as defined in A-rule.
Example 3: Max
Max is not allowed to see any nodes, properties or relationships because he is neither part of a rule nor member of any groups.