This minor release includes several enhancements to the EmpowerID Policy-Based Access Control (PBAC) engine and the business request process to give organizations more options for controlling user access.

Enhancements

Policy-Based Access Control

Policy-Based Access Control (PBAC) is an access control model that combines the best features of RBAC and ABAC to allow organizations to make real-time decisions on whether users can access a given resource. These decisions are made on the fly based on whether the current user has one or more required attributes. These attributes can be brought into the system either through the inventory of PBAC rights in an external system, or manually assigned to any EmpowerID actor and application through attribute “tagging.” As any EmpowerID actor can be tagged with an attribute, the complexity behind crafting access control is simplified, auditable, and more accessible to business users. See What is Policy-Based Access Control? for a deeper discussion of PBAC in EmpowerID.

PBAC Membership Policies

PBAC Membership policies are policies you create to specify the conditions under which an EmpowerID actor, such as a person or a Business Role and Location can be added to or potentially added to Management Roles, groups, Business Roles and Locations, or Query-Based Collections. PBAC Membership policies are comprised of Attribute-Based Membership policies, which contain rules defining the field types, field type values, and rights needed for the system to add users as members of the policy target. When the PBAC engine compiles PBAC Membership policies it looks to see if any EmpowerID actors have the attributes specified by the policy, adding them to the target of the policy if they do. See PBAC Membership Policies for an example of how to create and apply these types of policies in EmpowerID.

PBAC Enabled Applications

Applications created in EmpowerID now have an option to be “PBAC Rights Model Enabled.” This classifies the application as a “PBAC app,” which EmpowerID treats differently than other types of applications. PBAC apps are registered as “Resource System Modules,” which can have any number of PBAC resources attached to them like app projects, pages, contracts, invoices, and so on. Access to these resources can then be controlled by the rights you create for those resources. Often these rights are inventoried from external applications, but you can also arbitrarily create rights for each specific type of PBAC resource. These rights are then used in PBAC membership policies to control access to the resource.

Open

Figure 1: Using PBAC to control access to applications

Other Enhancements

• The IT Shop now alerts users submitting business requests whether those requests would cause an SoD violation with their current access assignments.
  
  

  Open

  

   

• Users who submit business requests can now delete those requests in the My Tasks application when the items in the request are no longer needed and the request has yet to be approved.
  
  

   

• Users assigning resources to persons can now run risk violation simulations to determine the risk level associated with potential access assignments to those people.

• Users can configure global functions to aggregate related local functions in the system.

• Users can configure global risks to aggregate related local risks in the system.

• Role owners can now classify Management Roles as sensitive.

Deprecated Features

Deprecated Management Roles

• UI-IT-Shop-Limited-Access

• UI-IT-Shop-Full-Access

• UI-Workflow-Task-Participant-Full-Access

• UI-Workflow-Task-Participant-Limited-Access

• Compliance User

• Tasks and Requests Full-Access

• Tasks and Requests Limited-Access

• UI-Audit-Participant

• UI-Risk-Policy-Violation-Reviewer