The bottom tier in the EmpowerID RBAC model comprises technical roles, known as Access Levels. Access Levels are the system or application-specific roles used to connect the policies in EmpowerID to the actual permissions those policies grant to resources contained within external systems or applications. The most common Access Level is “Member,” which is used to give a person or an EmpowerID role membership in external systems groups or application roles. A more advanced example of an Access Level would be the Mailbox Publishing Editor Access Level, which would grant permissions to a mailbox delivered as ACLs within Office 365. Access Levels can grant these “Rights” within external systems and “push” them out via the provisioning engine.
Access Levels also define Compliant Access within EmpowerID as bundles of low-level permissions known as operations. User actions in EmpowerID’s web interfaces or APIs undergo real-time access checks to determine if they may perform the intended operation against the resource in the given context. These actions can range from requesting membership of an SAP Role in the IT Shop to assigning user accounts to Azure RBAC roles in a Microsoft Azure tenant. These same low-level checks govern the management of the EmpowerID RBAC model itself, with RBAC management activities represented as operations.
Access Levels are convenient bundles of Rights and Operations specific for a type of resource and are used for delegation. Rights are permissions used in an external system that EmpowerID can manage. Operations are code-based actions protected by EmpowerID (usually in workflows).
Operations are “protected bits of code” executed to perform these tasks in EmpowerID workflows or via its API. Operations can also be arbitrary, not performing any action just serving as a placeholder for applications to query and determine access.
Rights represent actual permissions used in an external system that can be granted in EmpowerID via Access Level assignments. The EmpowerID enforcement engine will “push” these permissions out into the external system on schedule for any user to which they have been granted. Examples of rights include NTFS permissions for shared folders and mailbox acls in Microsoft Exchange.
The Persona Worksheet will help uncover all the unique combinations of operations and rights for various managed object types (aka Resource Types). These combinations may already exist in the shipping Access Levels management roles defined for each type of resource. If not, new Access Levels can be created or existing Access Levels modified.
Related Docs Topics: