What are EmpowerID Operations?

EmpowerID efficiently manages access to resources by combining native system rights for relevant resource systems, such as Microsoft Exchange and Windows Servers, with EmpowerID Operations. Each EmpowerID Operation is a protected code object that, when executed within an EmpowerID workflow, enables consistent access to a resource within EmpowerID or a custom application according to the operation and the resource type. Examples include adding users to groups, creating mailboxes, updating user attributes, or even viewing specific objects such as EmpowerID pages and reports. Each task corresponds to a specific operation for a particular resource type that must be delegated to users (through Access Level assignments) for each object they wish to interact with.

For instance, the EmpowerID Operation that allows a person to view web pages is the "Use" Operation. Since this operation applies to each EmpowerID web page, it must be assigned to each user for every page your policy allows them to see; otherwise, it will remain invisible to them. If you have a user named "Robert" who needs to view user accounts for two users, "Sally" and "Ulrich," Robert will require the "Use" Operation for the Find User Account Page to view their accounts in the EmpowerID Web application. Likewise, Sally and Ulrich will need the "Use" Operation for the Find User Account Page to see Robert's account. If either of them lacks the operation, access will not be granted in that direction.

Rights are the native permissions used by the application or operating system to manage security for a specific resource type. Granting these rights enables capabilities for users within that system, separate from EmpowerID. Having rights granted does not grant users any abilities within EmpowerID or make them potential approvers for any workflow operations.

In the example illustrated, Robert has the "Use" operation for the Find User Account Page, enabling him to see both Sally's and Ulrich's accounts. Similarly, Sally has the "Use" operation for the Find User Account Page, allowing her to see account information for both Ulrich and Robert. However, Ulrich does not have the "Use" Operation for the Find User Account Page, so he cannot see the account information for either Robert or Sally.

Many of the actions performed by users in EmpowerID will require more complex delegations than simply granting one user an operation that allows them to view another resource. Often tasks involve not only viewing an object, but altering the state of the object as well as performing actions with that object that affect other objects as well. For example, adding or removing an account to a group involves changing the state of two objects: an account and a group; while delegating to another user the ability to do the same involves changing the state of three objects: the person being granted the delegations, the account being added to a group, and the group to which the account is being added.

In the following image, Melissa has been granted three operations, each of which is necessary for her to add Ben's user account to the HR group:

The Use operation for the Find User Account Page, indicated by black, allows her to see to Ben's user account. She cannot add the account to the HR group if she cannot she him.
The AddAccountToGroup operation for Ben's account, indicated by purple, allows her to add the account to a group. She cannot add Ben's account to any group if she does not have this operation for the account.
The AddAccountToGroup operation for the HR Group, indicated by red, allows her to add an account to the group. She cannot add any account to the group if she does not have this operation for the group.

The green line flowing from Ben to the HR group indicates that Melissa has successfully added the account to the group.

Both of these examples show that the number of operations needed by a user to perform a task can vary greatly according to the number and type of objects affected by the task the user is attempting to perform. In the first example, each person required only one operation for one resource type: the List operation for a person. In the second example, the user needed four operations, two for each resource type: the List operation and the AddPersonToGroup operation for the person as well as the group. These operations, as well as all operations performed against objects in EmpowerID workflows are secured by special activities, known as Operation activities.

Operation Activities

Operation activities in EmpowerID are based on the workflow authorization framework and are used to determine if a user within a workflow process can execute the code for each operation in the activity. These activities assess at runtime whether the user can perform the attempted operation(s) on the target resources affected by the operation(s). The operation is not executed if the user lacks one or more of the required operations for those target resources. This process, known as “Has Access Check,” is baked into every workflow where the state of a resource object is being targeted for change by a person (as opposed to automated workflows initiated by a business process). Workflows can also be configured to always go for approval. In this case, the workflow will generate a Business Request regardless of whether the person has the operation for the resource.

EmpowerID offers multiple Operation activities to secure each operation executable against resource objects associated with a specific resource type. For example, all security groups in EmpowerID are protected in workflows by the EditGroupMultiOperations Operation activity, which secures several operations related to group editing and management.

Whenever a user within an EmpowerID workflow attempts to edit an attribute of a security group, the EditGroupMultiOperations Operation activity in the EditGroup workflow verifies if the user can perform that task at that moment. If the user has the relevant operation for the specific task, the Operation activity executes it. If the user lacks the operation, or the workflow is configured to always o for approval, the activity notifies them that the operation was sent for approval. The Approval Flow Policies for Business Request Items can use the same operation checks to route to approvers with the required operation(s) for the target resource(s).

From a coding perspective, this could look similar to the following example:

if (CurrentPerson.IsAllowedEditGroup.OperationName)
       EditGroupOperation.OperationName(HRTeam);
    else if (CurrentPerson.IsAllowedEditGroup.OperationName == false)
        GenerateBusinessRequestAndNotifyApprover(approver);
        if(approver.response == approve)
            EditGroupOperation.OperationName(HRTeam)
    else
        CurrentWorkflow.Terminate();

Using this pseudo-code as an example, let's consider what happens when a person named Michelle attempts to edit the Description attribute for a security group, the HRTeam group, for which she does not have the appropriate delegations. Michelle has operations that allow her to see the HRTeam group in EmpowerID and initiate the EditGroup workflow but does not have an operation that allows her to edit the Description attribute for the group. When Michelle runs the workflow in EmpowerID and the process reaches the EditGroupMultiOperations Operation activity, the activity proceeds to the Edit Group Description and Note operation, bypassing the other operations in the activity because Michelle is not attempting to execute them (see operations above).

The process flows in the following way:

The process checks to see if Michelle has the Edit Group Description and Note operation:

if (CurrentPerson.IsAllowedEditGroup.EditGroupDescriptionAndNote)
Because Michelle has not been delegated the operation, the process bypasses the code that executes the operation, proceeding to the next block:

else if (CurrentPerson.IsAllowedEditGroup.EditGroupDescriptionAndNote == false) DisplayOperationApprovalRequestMessage();
This opens the Approval Request form in the EmpowerID user interface to notify Michelle that the operation requires approval, giving her the opportunity to submit the operation or cancel the task.
If Michelle answers Yes, the process routes the operation to a designated approver:
The designated approver will see the request as a task with a Respond link in the web interface. Clicking on the link allows the approver the opportunity to approve or reject the request.
If the designated approver approves the operation, the Operation activity executes the operation:
If the approver rejects the request or Michelle decides not to submit the request, the workflow terminates without any changes made to the HRTeam group.

Each Operation activity in EmpowerID is derived from an operation approval base called the OperationWorkflowBase activity. This base exposes various methods and members, allowing custom Operation activities to be created by workflow developers. EmpowerID offers the following templates in Workflow Studio to quickly create new Operation activities:

Single Multi-Operation Activity template - This template is used to create Operation activities capable of executing one or more operations against a single resource type. For example, resetting a user account password requires security checks against only the user account.
Dual Multi-Operation Activity template - This template is used to create Operation activities capable of executing one or more operations against two resource types. For example, adding a person to a group requires security checks against both the person and the group.
Triple Multi-Operation Activity template - This template is used to create Operation activities capable of executing one or more operations against three resource types. For example, changing a person's primary Business Role and Location requires security checks against the person, the Business Role, and the Location.

EmpowerID includes default Multi-Operation activities that secure specific resource types. Generally, an operation in a Multi-Operation activity provides security for edits against a few EmpowerID properties on a resource object, such as a user account. Often, each EmpowerID property corresponds with an attribute of an Active Directory or LDAP object and is mapped to that object in a one-to-one relationship. Organizations can further subdivide the editing of specific attributes into even more granular operations in Workflow Studio if desired.

Operations and EmpowerID Windows Events

EmpowerID maintains a record of all operations executed within any given workflow. These records can be viewed in the Workflow Operation Audit Log as well as in the AuditLogOperation table of the EmpowerID Identity Warehouse. Furthermore, each time a person attempts to execute an operation for which they do not have the necessary delegations, EmpowerID writes an event to the Windows Event Viewer with an EventID falling in the 419-435 range. These events are formatted as follows:

Event 435: Person: Vince LoPresti (PersonID: 3128) does not have access to the operation: Add Account To Group for the following resources: ResourceID: 1733569; ResourceTypeID 2; Name: Vince LoPresti; ResourceID: 1733999; ResourceTypeID: 10; Name: HR New York *(Workflow Execution AppDomain) - /EmpowerIDWorkflowService_WorkerProcess.exe.

In this format, we see the following:

The person who attempted the operation without proper access
The operation attempted
The resources involved in the operation

Event 437: Sent email to VinceLoPresti@tdnfdemo.com Subject RequestID: 223 Approved - Add Account: Vince LoPresti to Group: HR New York *(Workflow Execution AppDomain) - /EmpowerIDWorkflowService_WorkerProcess.exe

In this format, we see the following:

The email was successfully sent to a specific email address, which is bound to the person making the request
The operation(s) approved; in this case, the request to join Vince LoPresti's account to the HR New York group was approved.

This information helps organizations monitor and audit activities within EmpowerID, providing insights into attempted and approved operations, as well as the resources and individuals involved.