EmpowerID 2021 adds several major new product features and usability enhancements.

New Features

EmpowerID Microservices

As part of its ongoing platform redesign to transform EmpowerID from a single monolithic application into a loosely coupled, but well-integrated suite of small services, this release of EmpowerID offers several new microservices, My Tasks and My Identity, as well as an updated IT Shop.

My Tasks Microservice

The My Tasks microservice provides a central location from which users can view the status of their access requests, make and respond to comments about those requests, and in situations where they are designated approvers, approve or reject access requests submitted by other users.

The My Tasks interface consists of several pages of task and request related information relative to the current user presented in an easy-to-navigate single page application experience. The main pages are the My Requests page, the To Do page and the All page. Users navigate from page to page by selecting the desired page from menus prominently displayed at the top of the application.

The My Requests page displays access requests submitted by the user or by another user on their behalf. From this page, users can view the status of their access requests, see who the approver is and add comments about their request.

Figure 1: The My Requests page of the My Tasks application

The To Do page displays access request related tasks for which the user is an approver. From this page, users with the authorization to do so can make decisions about those tasks, add comments to them, and delegate them to others.

Figure 2: The To Do page of the My Tasks application

The All page displays all access request related information.

Figure 3: The All Requests page of the My Tasks application

My Identity Microservice

The My Identity microservice provides a central location from which users can view relative information about themselves, create permanent delegations for business requests tasks for which they are an approver that route those tasks to others for approval, as well as allows them to personalize the number and frequency of email notifications they receive about those business tasks. The My Identity interface consists of several pages of task and request related information relative to the current user presented in an easy-to-navigate single page application experience. Users navigate from page to page by selecting the desired page from menus prominently displayed at the top of the application.

Figure 4: My Identity application

The My Identity interface includes a number of pages and features to include the following:

• Navigation sidebar that allows users to seamlessly navigate from My Identity to other EmpowerID applications.

• My Identities page that provides users with a single location for viewing all their EmpowerID identities. From this page, users can view detailed personal profiles and organizational charts related to their respective identities.

• All People page that provides users with a view of all the people internal and external to their organization they have the right to view.

• My Direct Reports page that provides managers with a view of their direct reports.

• My Department page that provides users with a view of all people in their department.

• Internals page that provides users with a view of people internal to their organization they have a right to view.

• Externals page that provides users with a view of all people external to their organization they have a right to view.

• Permanent Delegations page that provides users with the ability to permanently delegate tasks for which they are an approver to other people for approval. Delegated tasks, as well as those delegated to the person by another, can be viewed. Delegations created by the user can be edited and deleted from this page as needed.

IT Shop Microservice

The IT Shop brings a familiar shopping cart experience to the access request process. Users simply search for the resources they need and add items to their cart. Managers may shop on behalf of their direct reports as part of the onboarding process. When the user is done shopping, they simply submit their request. The workflow engine determines from your organizational rules, what approvals are needed, if any policies would be violated, and who must approve each request or violation. All participants are kept informed by email notifications and all requests, decisions and associated fulfillment actions are recorded and integrated into the audit process.

Figure 5: IT Shop application

Eligibility Policies

EmpowerID offers a powerful policy engine to control which users may see and request which roles and resources in the IT Shop. These policies are known as “Eligibility.” Eligibility policies may apply to users by attribute query, role, group, or other criteria, making it easy to target who receives which policies and have the assignment automated and maintained throughout their lifecycle. To further ease the administrative burden, Eligibility policies can be applied to all requestable items of a type by location in addition to one-by-one. This allows policies to be broader, granting or excluding eligibility using the EmpowerID Location tree. For roles, eligibility policies can be applied to their members to control what those members may see and request in the IT Shop. Policies also apply to the role itself as a possible IT Shop item to control who may see and request it.

Eligibility policies can be defined as either inclusion rules or exclusion rules. Inclusion rules define the items a user is authorized to see and request in the IT Shop and ensure these are only the ones that would make sense for them to request. An application example could be rules that filter resources available for Field Sales employees and developers. The catalog of requestable roles and resources available to each of those employees should be different ensure that unwarranted access requests are not generated, creating unnecessary approval tasks. Additionally, inclusion and exclusion rules help organizations provide employees a more pleasant user shopping experience as they are shielded from

Inclusion rules include the following:

• Eligible – Users can request items in the IT Shop, and the request will go for approval unless the requesting person has the RBAC delegations needed to grant the access being requested.

• Pre-Approved – Users assigned the policies are pre-approved for the items to which the policy is applicable. When the IT Shop user later requests access, it will not require an approval step before being fulfilled. 

• Suggested – The IT Shop item will show a “Suggested” additional item they may request because of their existing roles or in the context of a role they are currently requesting. The item will still follow standard approval routing rules. 

Figure 6: Eligibility Policy applied to a person

Approval Flow Policies

When users shop for resources in the IT Shop, they put resource items for which they are eligible to receive in their shopping carts. When ready, they submit the items in their cart to the EmpowerID system. These cart submissions are known as “Business Requests.” Each Business Request can contain one or more resource items, depending on the number of items that was in a user’s cart when submitted. The Business Request, including all the items in that request, route for approval based on the configuration of Approval Flow policies. Approval Flow policies are user-defined policies that organizations can create to direct Business Requests through an approval process that can involve multiple levels of approval from numerous designated approvers before users receive the items in a Business Request, known as “fulfilment.” Organizations can craft Approval Flow polices that are as simple or as complex as their needs dictate. Approval Flow policies have a number of key components that can be configured to specify how this occurs.

Figure 7: Approval Flow view for a Business Request in the IT Shop

Approval Flow components include the following:

• Business Request Type – Business Request Type is a workflow property used to group workflows by the type of business request they represent. An example of a Business Request Type is the IT Shop Business Request Type. This type represents anything that is published to the IT Shop, such as Application Roles (Groups), Business Roles, Management Roles and Azure Roles and Licenses. Approval Flow policies can be configured to specify that requests of a certain Business Request Type must go through three levels of approval, for example, before fulfillment occurs.

• Approval Flow Steps – Approval Flow Steps are added to Approval Flow policies to specify how many approvals are required for fulfillment. Approval Flow policies can have as many Approval Flow Steps as needed. Each step is a sequential step that must be approved at that level to proceed to the next step. Each step can have its own approval flow as well.

  • Item Level Approval – Each step can be configured to allow for Item Level approval. Item Level represents the individual items in a business request, such as requesting an Office 365 mailbox or an Application Role. With Item Level approval enabled for a step, the step approver can elect to make item-by-item approvals rather than being forced to approve or reject the entire request in toto. These items

  • Approver Resolver Rules – Approver Resolver rules specify to whom the Approval Flow Step needs to route for approval. These can be routed to various actors in EmpowerID

  • Items Types – Item Types are the individual resources that can be requested, such as membership in an Application Role or group.

  • Item Type Actions – Item Type Actions are in essence EmpowerID Operations and represent actions that can occur against an item (resource). Examples of Item Type Actions include Add Account To Group or Assign Azure License.

Notification Policies

Part of the approval process involves notifications. Approvers and initiators of requests , as well as all delegated users received notifications of these events. As part of the redesign of the approval process, EmpowerID has reconfigured how notification occurs, giving organizations and users the ability to tailor the amount and type of notifications they receive to their personal preferences.

 Figure 8: Notification Preference settings available to users in the My Identity application

How notifications now work in EmpowerID is as follows:

1. Each time a user submits a Business Request a Business Request Event is raised.

2. Business Request Events are submitted to the Business Request Notification Policy engine.

3. The Business Request Notification Policy engine determines if the event needs to be added to the Business Request Notification Inbox. To determine this, the engine first performs a granular scan of each person’s notification preferences, then falls back to the default system notifications if there are no personal notification preferences set.

4. Notifications are then sent to Business Request participants based on those notification settings.

Full FIDO2/WebAuthN support for Passwordless and Usernameless login

FIDO2 WebAuthn is a set of Web APIs that attempts to alleviate the problems users and organizations can encounter managing an ever-growing list of passwords. The problems are obvious as passwords can become compromised and users can forget which password they use with which site. WebAuthn is a major step forward in that it uses public-key cryptography and digital signatures to enable passwordless authentication between servers, browsers and authenticators. WebAuthn can also be used as an additional MFA factor.

To use FIDO2 WebAuthn with EmpowerID, you simply decide what flows you want to use, configure a few system settings, and apply the flow(s) to one or more targets. Targets can include Password Manager policies, applications, and individual users (EmpowerID Persons).

EmpowerID supports the following WebAuthn flows:

• MFA – Users authenticate by presenting their username, password and FIDO2 credential

• Passwordless Login – Users authenticate by presenting their username, FIDO2 credential and a PIN / biometric

• Usernameless Login – Users authenticate by presenting their FIDO2 resident key credential and a PIN/biometric

New Workflow Approval Routing Model

EmpowerID has enhanced the workflow approval routing process process to give organizations more control over approvals. All workflows now have a new property called “Never Send for Approval” and most workflows have that property set to true out of the box.

When set to true, EmpowerID verifies whether the current person in the workflow process has access to perform the workflow operations. If the person has access, the workflow continues; if the person does not have access, EmpowerID notifies the person that they do not have access and the workflow exits. Approval routing never occurs. There are several benefits to this, including the following:

• This limits the number of approval tasks generated by the system and removes actions from the approval process that should not be there in the first place.

• The workflows and the operation base no longer generate Business Process Tasks (Business Process is a workflow and all the operations in it are Business Process Tasks) when a person does not have the RBAC delegations to execute the workflow.

If the setting is false, the workflow must be configured with a Business Request Type and it will always go for approval, even if the person has access to execute the workflow operations. The Business Request Type property allows workflows to be classified for the purpose of providing greater flexibility in approval routing and the grouping together of related access requests. Rather than having a default approval routing that simply routes unrelated approvals to all users with the delegations to approve requests, organizations can this property along with new Access Request and Approval Flow policies to group together related access requests into a single consolidated “approval bundle,“ specify to whom approval tasks should go, and how many approvals need to occur before fulfillment occurs.

Enhancements

Redesigned Resource View Pages

The View pages that users see when looking at the details for a given resource have been completely redesigned to present users with a more visually appealing and intuitive experience. Figure 14 below shows View page for a person that users see when viewing information about a person in EmpowerID.

Figure 9: Person View page

Workflow Studio Enhancements

Workflow Studio Deployment Service

The Workflow Studio Deployment Service is a new feature in Workflow Studio that replaces the legacy patching and batch build options that developers needed to perform previously when patching environments or compiling multiple objects. These options have been streamlined into a single deployment feature, making it easier and quicker to perform these type of operations.

New deployment options include:

• Batch deploy to local folder – This is the default build action in Workflow Studio. This action compiles and publishes each workflow, activities, class libraries, user interfaces and other selected items selected to the _Assemblies folder, as well as a .pub file to the _PublishedItems folder on a target machine. This action makes no changes to the EmpowerID SQL-based database. All changes occur on the target system only.

• Create and update manifest files – Manifest files contain metadata that describe all development objects required for a specific application that you develop in Workflow Studio. When developers create a manifest, they select the items required by their application. The manifest can then be used for deployment to other users.

• Package for deployment – Developers who create numerous custom items or updated objects in EmpowerID can create a single deployment file from their manifests that can be handed off. The deployment file is a ZIP file that contains all the objects in your manifest.

• Publish to EmpowerID environment – When developers are ready to deploy their development work to a testing or production environment, they log in to the EmpowerID Web interface as a user with the appropriate access to run the PublishWorkflowStudioItem workflow and upload the .pub file for the workflows or other objects they want to publish. Once the workflow completes the publishing process, their work is available to users in the environment.

MS Build Integration

MS Build is the build platform for Microsoft and Visual Studio. Workflow Studio integrates with MS Build to build any manifest items that have been developed in Visual Studio. This operation occurs behind the scenes; Visual Studio will not start up.

Redesigned User Interface

The Workflow Studio user interface has undergone a major revision to present users with a modern, cleaner look and feel.

Figure 10: Redesigned Workflow Studio

New UI for Managing Application Role (Group) RBAC and Eligibility Assignments

RBAC and eligibility assignments to Application Roles (Groups) for Business Role and Location combinations and Management Roles can now be managed on the View pages for each of those resource types. Eligibility can be set to mandatory, pre-approved, suggested and eligible. Each eligibility type can have time constraints added to limit access to specific dates and times.

Figure 11: Access to Application Roles

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 in to 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 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 type 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 rights you create for those resources. Often these rights are inventoried in 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.

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.
  

  

  
  

• 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

Release Date: 8/8/2021

Release notes for EmpowerID version 7.190.0.0

New features:

Tivoli Access Manager

EmpowerID IBM Security Verify Access connector is a bi-directional connector that talks to TAM SCIM Microservice for inventory and write back functionality of users, groups, group membership and organizational units. The request and response of the microservice is SCIM compliant.

1. Account Inventory: The IBM Security Verify Access accounts are inventoried in the EmpowerID Account table by the inventory job. The connector supports both full and incremental inventory for Accounts.

   

2. Group Inventory: The IBM Security Verify Access groups are inventoried in the EmpowerID Group table by the inventory job. The connector supports both full and incremental inventory for Groups.

   

3. Organizational unit Inventory: The IBM Security Verify Access OUs are inventoried in the EmpowerID ExternalOrgZone table by the inventory job. The connector supports both full and incremental inventory for Organizational units.

   

4. Create an IBM Security Verify Access account store: On the navbar, expand Admin > Applications and Directories and then click Account Stores and Systems.
   On the Account Stores page, select the Actions tab and then click Create Account Store.
   Under System Types, search for IBM.
   Click the record for IBM Security Verify Access to select the type and then click Submit. This opens the IBM Security Verify Access form, which is where you enter the information needed to connect EmpowerID to the system.

   

5. Verify Resource System Parameters: On the navbar, expand Admin > Applications and Directories and select Account Stores and Systems.
   On the Find Account Store page, select the Account Stores tab and search for the IBM Security Verify Access account store you just created.
   Click the Account Store link for the account store.

   

6. User Account: Create Account  - TAM User Accounts can be created from EmpowerID using the workflow “Create User (Person Optional)” or using RETs (Resource Entitlement policies).  Update account - TAM User Accounts can be updated from EmpowerID by navigating to Identity Administration à User Accounts à Search and click on the Account à Go to Edit mode à Make changes and Save. Enable and Disable Account - TAM User Accounts can be enabled/disabled from EmpowerID by navigating to Identity Administration à User Accounts à Search and click on the Account à Actions accordion à “Enable Account” or “Disable User Account”. Reset Account Password - TAM User Account’s password can be reset from EmpowerID by navigating to Identity Administration à User Accounts à Search and click on the Account à Actions accordion à “Reset Account Password” 

7. Group: Create Group - TAM Groups can be created from EmpowerID using the workflow Create Group. The JSON template added in the AccountStore setting “CreateOrUpdateGroupJsonTemplate” is used while creating the group.  Update Group - TAM Groups can be updated from EmpowerID by navigating to Identity Administration à Groups à Search and click on the Group à Go to Edit mode à Make changes and Save. Delete Group - TAM Groups can be deleted from EmpowerID by navigating to Identity Administration à Groups à Search and click on the Group à Actions accordion à “Delete Group”

8. Organizational Unit: Create OU - TAM OUs can be created from EmpowerID using the workflow Create OU. The JSON template added in the AccountStore setting “CreateOrUpdateOUJsonTemplate” is used while creating the OU. Update OU - TAM OUs can be updated from EmpowerID by running the workflow “Edit ActiveDirectory OU”.   Delete OU - TAM OUs can be deleted from EmpowerID by running the workflow “Delete OU and Child objects”. This action will delete the selected OU and it’s child objects in TAM if the LDAP allows deletion of non-empty containers. 

9. Add and Remove TAM Group Membership - TAM User accounts can be added to and removed from TAM groups using EmpowerID workflows and can also be automated using RBAC delegations.  

   Group memberships can be added and removed from the Account page by adding or removing the group from the “Group Membership” accordion as shown in the below illustration: 

   

Other new features:

1. All requestable resources should be using Dynamic Mapper structures: All requestable resources is loaded/fetched using IncludedPropertiesapproach and deserialized using the Dynamic Mapper. This normalizes our data retrieval strategy on both ITShop and MyTasks side.

2. Show application owner's phone number and email to users: When a user logs into IT Shop and selects "Applications" to shop for and the user clicks on the "Request Access" button for the desired application then the item request screen is displayed which includes the contact details for the application owner.

3. Workflow Studio: Workflow Studio now supports .NET 5 Azure Functions. Workflow Studio now supports .NET 5 Microservices. Workflow Studio now supports Azure Web Jobs v3. Workflow Studio ships with a new template for creating SCIM Microservices in .NET 5.

4. Azure: Added the ability to list, get ,add ,update, delete azure applications. Added the ability to list, get, add, update, delete azure conditional access policies. The SharePoint Online (SPO) connector contains multiple Azure services including microservices, web jobs and Azure functions used for inventorying and managing SharePoint Online in EmpowerID.

Improvements:

1. Removed dependency of length of skip token for deletedUsers, deletedGroups, NewOrUpdatedDeletedGroups endpoints.

2. Improved workflow studio integration with Visual Studio.

Deprecated:

1. Microservices in NET 4.0, .NET Core 2.1 and 2.2

2. Azure Functions .NET 4.0, .NET Core 2.1 and 2.2

Release Date: 11/6/2021

Release notes for EmpowerID version 7.195.0.0

New features:

ITSHOP - Azure Roles, unifications for all group types (RBAC, Admin etc.)
ITSHOP - Assigned resources filtering by direct/inherited assignment
ITSHOP - Quick search improvements
ITSHOP - Management roles granted, when assigning a new management roles
ITSHOP - Filtering of resources by application selection
ITSHOP - Location tree with full-path tooltip
ITSHOP - Access levels (resourceTypeRoles) exposed for assigned resources
ITSHOP - Cart item justification dropdown with pre-selected default options
ITSHOP - Applications as a resource type (listing of requestable and already assigned EID and azure applications)
ITSHOP - Applications section "more info" box (localizable)
ITSHOP - Running EID Workflows (partly done)
ITSHOP - Computers resource type listing (partially done)

MYTASK - Process steps diagram improvements

RESADMIN - Listing of owned applications (EID and azure applications where logged in user is access manager)
RESADMIN - Application details with runnable EID actions (edit, delete etc.)
RESADMIN - Azure application onboarding workflow
RESADMIN - Application "more info" box (localizable)

ALL MICROSERVICES - Single sign-on/sing-out improvements (including token refresh)
ALL MICROSERVICES - Docker containers updated (build steps simplified, base/build images version updates)

Workflow Studio - New template for SCIM Microservices targeting .NET 5.

Workflow Studio - New template for Azure Functions targeting .NET 5.

Workflow Studio - New template for Microservices targeting .NET 5.

Business Request Engine:

• Added Approval Flow Step Auto Approval Rule: which allows to get a step approved if you can do it without including the person that can do it as a potential approver.

• Added ResourceOwnerAssignee to control approval

Assignee Member Policies

Resource Attestation (recertification)

We started all the changes in BusinessRequestItemResourceAttestation. WIP

---

Added new grid to see notifications

Added these to various assignee viewone pages

Improvements:

Workflow Studio - Deep integration with Visual Studio 2019.

Workflow Engine - Support for externalizing Workflow Data.