The bottom tier in the EmpowerID RBAC model is comprised of Technical Roles, which are 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 knows 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.
Users using the EmpowerID workflows or API may perform secure management of objects that exist in external systems as well as EmpowerID. Examples of external objects are Azure AD User Accounts, SAP Roles, File Shares, SharePoint sites, etc. Users may also manage objects that only exist in EmpowerID: people, management roles, Business Roles, etc. In both cases, a real-time authorization engine leveraging RBAC and ABAC security controls who may manage which objects and which actions or tasks they may perform against those objects. The system also handles logging, automatic approval routing, and workflow task generation in the event a user tries an action they are not authorized to perform.
The bottom tier of the 3-tiered EmpowerID RBAC model are the Access Levels which are EmpowerID’s Technical Roles. Access Levels define which actions, known as operation, and which native system permissions, known as rights, the recipient of the Access Level would be authorized to perform for any resources for which they have that Access Level. Access Levels can be directly assigned to people but most often are assigned to RBAC Actors in one of the higher tiers (i.e. Business Roles and Locations, Management Roles, etc.)
Operations are “protected bits of code” that are 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 are representations of actual permissions used in an external system which 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.