Controlling access with ABAC and Role assignments
This article explains our authorization system, which provides customers with flexible and precise control over user visibility and permissions within the platform.
The system's logic is based on the interaction between Role Assignments and ABAC (Attribute-Based Access Control) attributes. This framework ensures consistent management of both permissions (what a user can do) and population visibility (who a user can see).
A key component of this system is how subject attributes are managed. They are now categorized into two distinct types, each evaluated differently to achieve granular control:
Cohort Definers
Inclusion / Exclusion Overrides
Cohort Definers
Cohort attributes establish the base population a user can access. They are evaluated using the following logic:
AND logic is applied between different attributes. This ensures that a user's access is narrowly defined, as a user must meet all specified criteria.
OR logic is used within a single attribute's values. This provides flexibility by allowing access to multiple items (e.g., several countries or organizational units).
Example:
Consider a user with the following cohort attributes:
OrgItemIds = [Sales, Marketing]
WorkerCountry = [Ireland, UK]
EmploymentStatus = [Active]
This will include workers who are:
(In Sales OR Marketing)
AND
(located in Ireland OR UK)
AND
(have an Active employment status).
Supported subject attributes:
- OrgItemIds
WorkerCountry
WorkerPerformanceEligibility
EmploymentHomeCountry
EmploymentLegalEntity
EmploymentStatus
EmploymentCostCenter
EmploymentMaterialRiskTaker
EmploymentGlobalMobilityFlag
EmploymentHostCountry
EmploymentHostCountryLegalEntity
EmploymentHostCountryCostCenter
EmploymentJobLevel
EmploymentJobTitle
EmploymentJobFamily
EmploymentJobCategory
EmploymentJobFunction
GlobalGrade
LocalGrade
WorkRegion
Inclusion / Exclusion Overrides
These attributes are evaluated separately from the cohort logic and allow for specific individuals or organizational units to be explicitly added to or removed from a user's visibility.
| Attribute | Type | Logic | Description |
|---|---|---|---|
| IncludeEmployeeIds | Additive | OR | Explicitly adds specific employees to the visibility scope, overriding cohort rules. |
ExcludedEmployeeIds | Subtractive | Final exclusion | Removes specific employees from visibility |
ExcludedOrgItemIds | Subtractive | Final exclusion | Removes all employees within specific organizational units. |
This is an attention message.
All exclusion rules are applied last, after both cohort and inclusion evaluations have been completed.
Scenarios and Expected Behavior
The table below outlines how different combinations of Roles and ABAC attributes determine a user's permissions and visibility.
| Scenario | Permissions (Actions) | Population Visibility | Notes |
|---|---|---|---|
No Roles, No ABAC | Employee-level only | Entire company population | This is the default case. The user is granted the "Employee" default role, providing basic access with full company visibility. |
Roles assigned, No ABAC | As per assigned roles | No visibility | The user can perform actions based on their roles but will have no population to apply them to. Population visibility must be explicitly assigned. |
No Roles, ABAC assigned | Employee-level only | Restricted by ABAC attributes | The user cannot perform privileged actions and their visibility is limited to the population defined by the ABAC attributes. |
Roles, ABAC assigneds | As per assigned roles | Restricted by ABAC attributes | This is the full authorization state, where both a user's actions and their visible population are controlled. Export to Sheets |
This is an note/information message.
Permissions are granted exclusively through Roles. A user without an assigned role will not have elevated permissions.
Population visibility is controlled by ABAC (Attribute-Based Access Control). When ABAC attributes are present, they are always used to restrict the population a user can see.
Default behavior: In cases where no roles or ABAC attributes are assigned, the user is given the "Employee" default role. This provides the broadest visibility, typically giving them access to all users within the company.
Examples
Example 1: Standard Cohort
OrgItemIds = [Sales, Marketing]
WorkerCountry = [Ireland]
EmploymentStatus = [Active]
Result: This user can see all active employees in either the Sales or Marketing departments who are located in Ireland.
Example 2: Adding a Specific Employee
OrgItemIds = [Sales]
EmploymentStatus = [Active]
IncludeEmployeeIds = [1234]
Result: This user can see all active employees in the Sales department, plus the employee with ID 1234, even if they are not in Sales.
Example 3: Excluding a Person and Org Unit
OrgItemIds = [All Company]
ExcludedEmployeeIds = [5678]
ExcludedOrgItemIds = [Finance]
Result: This user can see all employees in the company, except for the employee with ID 5678 and all employees within the Finance organizational unit.