Role

The Role object (stored internally as a Bundle) groups entitlements into a business-meaningful unit so access can be granted, requested, certified and revoked as one thing rather than as dozens of individual permissions. Roles are the backbone of role-based access control and the single biggest lever for making access manageable.

• Business roles model job functions (“Branch Teller”) and are what users and managers understand.
• IT/technical roles bundle the technical entitlements a business role needs, often per application.

A common design nests them: a business role grants one or more IT roles, which in turn grant entitlements. This two-tier model keeps the business view clean while managing technical detail underneath.

• Automatically, via membership criteria matching identity attributes (the ABAC-drives-RBAC pattern).
• By request, chosen from the access catalogue and approved.
• Manually, assigned by an administrator.

Assigning a role provisions its entitlements; removing it revokes them. That reversibility is what makes lifecycle-driven least privilege possible.

An assigned role was granted deliberately. A detected role is inferred because an identity happens to hold all of a role’s entitlements, useful for role mining and for spotting access that should be formalised or removed.

Roles themselves need governance: an owner, a clear definition, and periodic review (role certification) to prevent them bloating over time. A well-scoped role is the minimum for a job; an over-broad role simply institutionalises over-privilege.

• Over-broad roles that grant far more than a job needs.
• Role explosion, so many narrow roles they are unmanageable.
• Unowned, unreviewed roles that drift out of alignment with the business.