Page Comparison

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.

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.

...

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: 

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

   Code Block
   language c#
   if (CurrentPerson.IsAllowedEditGroup.EditGroupDescriptionAndNote)

2. Because Michelle has not been delegated the operation, the process bypasses the code that executes the operation, proceeding to the next block:
   

   Code Block
   language c#
   else if (CurrentPerson.IsAllowedEditGroup.EditGroupDescriptionAndNote == false) DisplayOperationApprovalRequestMessage();

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

4. If Michelle answers Yes, the process routes the operation to a designated approver:
   

   Code Block
   language c#
   if (DisplayApprovalRequestMessage.SubmitOperation == true) NotifyApprover(approver);

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

6. If the designated approver approves the operation, the Operation activity executes the operation:
   

   Code Block
   language c#
   if (approver.response == approve) EditGroupOperation.EditGroupDescriptionAndNote(HRTeam)

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

   Code Block
   language c#
   CurrentWorkflow.Terminate();

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:

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

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

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

...