2.9 Graph Access Rules

Graph Access Rules define the access control policies for the Graph Security Layer. These rules determine which Target Entities, Properties, and Relationships specific users are authorized to view. The system applies these rules to every graph-related request made to the Linked Data API.

The access control model follows the Need-to-know principle, which ensures that users can only view data explicitly assigned to them. Any data not included in a user's assigned rules remains invisible. In other words, users without any Graph Access Rule assignments cannot access any graph data.

For comprehensive information about Graph Access Rules, refer to the Graph Security Layer chapter.

Define a Graph Access Rule

Graph Access Rules are currently managed through the GBS API's /api/graph-access-rule/* endpoints. Each Access Rule comprises three key components:

• Entities: The entities (nodes) that users are permitted to view (at least one entity is required per rule)
• Properties: The specific properties of each entity that users can access
• Relationships: The connections between entities that users are allowed to see

Users and Groups

Access rules can be assigned to Keycloak users, groups, and service accounts to control visibility of entities, properties, and relationships:

• Users: When a user is assigned to a rule, they gain access to view all objects defined within that rule.
• Groups: All members of a group assigned to a rule automatically inherit access to the objects defined in the rule, even if they are not explicitly listed as individual users.
• Service Accounts: To enable a Keycloak client to retrieve an access token, service accounts must be enabled for that client. This creates an internal user named service-account-<client-name>. Adding this service account to a rule grants the corresponding client access to the objects defined in the rule.

Property Value Conditions

Property value conditions allow the user to define specific criteria that must be met for users to access data. When multiple conditions are applied to a single property, all conditions must evaluate to true for the data to be returned.

List Comparisons

The user can define conditions as lists to compare against multiple property values simultaneously.

Example

Consider the following properties from an Entity:

Product	Market
"Product One"	"EU"
"Product Two"	"[EU, NA, SA]"
"Product Three"	"[OC, AS]"
"Product Four"	"[AF, SA]"

Note: Values can also be formatted as "['OC', 'AS']".

• any_in operator
  Use the any_in operator when a property value needs to match at least one condition from a predefined list. Example: $code:any_in("EU", "NA", "SA") This expression matches any Market property containing "EU", "NA", or "SA". The query returns Product One, Product Two, and Product Four.

• all_in operator
  Use the all_in operator when a property value must match all conditions from a predefined list.
  Example: $code:all_in("OC", "AS")
  This expression matches any Market property containing both "OC" and "AS". The query returns only Product Three.

To implement these operators in your property value conditions, use the format demonstrated in the configuration interface.

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 Linked Data API 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 ExternalLinkedDataSecurity workers for further filtering after which the result is provided as a response to the caller.

Graph Security Layer is only applied when the following requirements are fulfilled:

1. System configuration entry for group System and key graph-security-layer-mode is set to 1
2. Module dch-linked-data-security is licensed
3. At least one worker of type LinkedDataSecurity is 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 Linked Data Security worker and how many threads each worker should use.

Examples

The following examples should help understand how Access Rules work.

Prerequisite

• Keycloak group: Confidential-group
• Keycloak users: Alice, Bob (is a 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.