EmpowerID 2021 adds several 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 a 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.

Open

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.

Open

The All page displays all access request-related information.

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 request tasks for which they are an approver, and 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. 

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 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 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 provides managers with a view of their direct reports.

• My Department page 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.

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 to 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. 

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 were 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 “fulfillment.” Organizations can craft Approval Flow policies 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.

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.

How notifications now work in EmpowerID is as follows:

1. Each time a user submits 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 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. The below image shows the View page for a person that users see when viewing information about a person in EmpowerID.

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 types of operations.

New deployment options include:

• Batch deploy to a 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 describes 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.

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.