Roles, Entitlements, and Role Modeling
From entitlement to role
Entitlements are values on applications marked as managed/entitlement attributes; they are the raw material of role modeling. A role aggregates one or more role profiles, and each profile ties an application to specific entitlements or to constraints (a filter that matches entitlements dynamically). Roles are usually typed - business roles for organizational meaning, IT roles closer to the technical access, and organizational roles for grouping. Hierarchy lets a business role contain or trigger IT roles.
Assigned versus detected
Assigned roles come from a person, request or rule; detected roles are inferred by matching an identity's current entitlements against role profiles during refresh. Role assignment rules can assign roles automatically from identity attributes. The role index supports searching and role mining, so after bulk role changes it must be refreshed before users can find the new roles in the request UI.
Traps
- Confusing profiles with entitlements: editing the profile's constraint changes what the role matches, editing the application's schema changes the entitlement itself.
- Assuming a role assignment provisions immediately; it provisions on the next refresh with provisioning enabled.
- Expecting a detected role to grant access - detection is informational until the role is assigned and provisioned.
- Forgetting to re-index after importing roles, so searches return stale results.
Worked example
A finance analyst role should grant a finance folder in a file share. Mark the folder attribute as an entitlement on the application, create an IT role whose profile references that entitlement, create the business role containing the IT role, then refresh with provisioning enabled. Verify by checking detected roles first, then the identity's account operations.
Rule of thumb
Model upward: entitlement, profile, role, assignment, provisioning - and test each level separately.