Assignment × inducement × entitlement
In midPoint, inducement, entitlement, and assignment are distinct but interconnected concepts within its role-based access control (RBAC) framework. This is a quick primer to help you understand the differences between these concepts as they can be easy to confuse.
Definition, meaning, and construction
First, let us briefly define the meaning and purpose of each of these concepts, including the mechanisms they use in midPoint.
Assignment
-
Definition: A direct association between a user (or other focal object) and a resource object (e.g., an account, role, organizational unit). Assignments define the desired state of the system.
-
Purpose: Grants access rights or provisions resources directly to a user. For example, assigning a role to a user grants them the rights defined by that role.
-
Mechanism:
-
Direct assignment: A user is explicitly assigned a role, account, or organizational unit.
-
Construction assignments: Define how a resource object (e.g., an LDAP account) should be created for the user.
-
Inducement
-
Definition: A role-based mechanism that applies to users who are assigned the role. Inducements are indirect assignments embedded within roles. The end-goal of an inducement is the state achieved by a direct assignment.
-
Purpose: Enables roles to define access policies that propagate to users. For example, a role might include inducements to create accounts or assign entitlements to users.
-
Mechanism:
-
Role hierarchy: Inducements in a role apply to users who inherit the role (directly or via hierarchy).
-
Indirect application: Inducements are not applied directly to the user but to the role, which then affects the user.
-
Alice] UserEnd[User
Alice] RoleA[Role
Team manager] RoleB[Role
Team member] EntlA[Entitlement
Manager access rights] EntlB[Entitlement
Member access rights] User --> |is assigned| RoleA --o |induces| RoleB RoleA --> |leads to| EntlA --> |for| UserEnd RoleB --> |leads to| EntlB --> |for| UserEnd
Entitlement
-
Definition: A resource-specific access right (e.g., group membership, privilege, or application role) provisioned on a target system (e.g., LDAP, Active Directory, etc.).
-
It is important to realize that entitlements are fundamentally different because they are the desired business outcome of inducements and assignments which make entitlements actually happen.
-
-
Purpose: Represents the actual access granted to a user on a resource. Entitlements are often managed via assignments or inducements.
-
Mechanism:
-
Entitlement associations: Roles or assignments can define entitlements (e.g., group memberships) that are synchronized to the resource.
-
Schema handling: Entitlements are defined in the resource schema (e.g., LDAP group schema) and are provisioned based on the synchronization logic in midPoint.
-
Key differences
| Assignment | Inducement | Entitlement | |
|---|---|---|---|
Scope |
Direct link between user and object |
Role-based, applies to users of the role |
Resource-specific access right |
Application |
Direct (user → object) |
Indirect (role → user) |
Managed via assignments/inducements |
Example |
Assigning a role to a user |
Role creates an LDAP account for users |
LDAP group membership for a user |
Configuration |
Defined in user objects |
Defined in role objects |
Defined in resource schema |
How they interact
-
Assignments directly link a user to a role or resource object.
-
Inducements in the role define what happens when the role is assigned (e.g., create an account or entitlement).
-
Entitlements are the result of inducements or assignments, representing actual access on the resource.
Alice"] RoleMgr["Role: Manager"] RoleTL["Role: TeamLead (induced)"] Account["Account (Alice@HR)"] EntMgr["Entitlement: Managers Group"] EntTL["Entitlement: TeamLead Group"] %% Direct assignment from user to account User -- "1️⃣ Assignment
(resourceRef=HR‑DB, kind=account)" --> Account %% User assigned the Manager role User -- "assigned role" --> RoleMgr %% Inducement inside Manager role that *induces* the TeamLead role RoleMgr -- "2️⃣ Inducement (role‑to‑role)" --> RoleTL %% Inducements inside each role that create entitlements RoleMgr -- "3️⃣ Inducement
(resourceRef=HR‑DB, kind=entitlement)" --> EntMgr RoleTL -- "3️⃣ Inducement
(resourceRef=HR‑DB, kind=entitlement)" --> EntTL %% ==== Brand‑aligned styling ==== classDef user fill:#ffffff,stroke:#14205F,color:#14205F; classDef role fill:#265DA6,stroke:#14205F,color:#ffffff; classDef acct fill:#767171,stroke:#14205F,color:#ffffff; classDef ent fill:#FF9B05,stroke:#FF9B05,color:#14205F; class User user; class RoleMgr,RoleTL role; class Account acct; class EntMgr,EntTL ent;
|
How to read the diagram
|
Example workflow
-
A user is assigned the Customer Admin role (assignment).
-
The role contains an inducement to create an LDAP account and assign group membership.
-
MidPoint provisions the entitlement (LDAP group membership) on the resource.
Use cases
-
Assignment: Directly assign a role to a user for immediate access.
-
Inducement: Define reusable access policies in roles (e.g., "All sales managers get CRM access").
-
Entitlement: Ensure users have specific group memberships or privileges on external systems.
This structure enables midPoint to manage complex access policies efficiently, leveraging RBAC principles while maintaining flexibility through dynamic mappings and synchronization.
Further reading
To get more technical insight into the concepts of assignment, inducement, and entitlement, continue with the following articles:
To get a hands-on knowledge, take the self-paced MidPoint Deployment: Group Synchronization course.