Entitlement
The Entitlement object: a single permission on an application.
An entitlement is one granular permission, a group membership, role or privilege, on a specific application.
- What the Entitlement object represents
- Key attributes and relationships
- How it is created and maintained
- Where it appears in governance
An Entitlement is the atomic unit of access in SailPoint: a single permission on a single application, such as membership in an Active Directory group, an SAP role, or a database privilege. Everything above it, roles, policies, certifications, is ultimately built from entitlements.
Where entitlements come from
Entitlements are discovered by aggregation, they are the assignable values (group memberships, roles, privileges) read from each target application’s schema. Raw, they are often cryptic (CN=APP_GRP_0472), which is why enriching them matters.
From raw entitlement to Managed Attribute
Promoting an entitlement to a Managed Attribute adds an owner, a plain-language description and a classification. This is the difference between a certification a reviewer can act on and one they rubber-stamp because they cannot tell what APP_GRP_0472 grants. Enrich at least your sensitive entitlements.
How entitlements are governed
- Grouped into roles, the usual and recommended way, so access is managed in business terms.
- Requested and certified individually where role membership does not fit.
- Evaluated by policy, SoD rules are defined over combinations of entitlements.
Detected access
Entitlements granted directly in a target system, outside SailPoint, are discovered at aggregation as detected access. This is exactly where risk hides, so aggregating and reviewing entitlements is how you catch out-of-band grants.
Common pitfalls
- Governing thousands of raw entitlements instead of grouping into roles.
- Undescribed entitlements that reviewers cannot meaningfully certify.
- Ignoring detected/out-of-band entitlements.