EmpowerID manages access to resources by using a combination of native system rights for applicable resource systems (such as Microsoft Exchange and Windows Servers) and EmpowerID Operations. Each EmpowerID Operation is a protected code object that when executed within an EmpowerID workflow allows a resource within EmpowerID or a custom application to be accessed in a way that is consistent with the operation and the type of resource being accessed. Some examples include adding users to groups, creating mailboxes, updating user attributes or even viewing certain objects such as EmpowerID pages and reports. Each of these tasks correspond to a specific operation for a specific resource type that must be delegated to users (via Access Level assignments ) for each object with which they with to interact. For example, the EmpowerID Operation that allows a person to view Web pages is the Use Operation. Because this operation applies to each EmpowerID Web page, the operation must be assigned to each user for each page your policy allows them to see or it will be invisible to them. So, if you have a user named "Robert" needing to view the user accounts for two users named "Sally" and "Ulrich," Robert will need to have the Use Operation for the Find User Account Page before he can view the accounts in the EmpowerID Web application. Similarly, Sally and Ulrich will need to have the Use Operation for the Find User Account Page before they can see Robert's account. If one or the other is missing the operation, no access occurs in that direction.
In the following image, Robert has the Use operation for the Find User Account Page allowing him to see both of these people's accounts. In similar fashion, Sally has the Use operation for the Find User Account Page, allowing her to see account information for Ulrich and Robert. Ulrich, however, does not have the Use Operation fro the Find User Account Page; thus, 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 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.
EmpowerID's default approval routing mechanism is called Rights-Based Approval Routing (RBAR) and routes requests based upon delegation of protected actions, called operations. Operation activities are activities based on the EmpowerID workflow authorization framework that are used in EmpowerID workflows to determine if the current user in a workflow process can execute the code for each operation in the Operation activity. These activities determine at runtime if the current user can perform the operation(s) being attempted against the target resources being affected by the operation(s). If the user does not have one or more of the operations allowed against those target resources, that operation is routed to a designated approver with the authority to approve or deny the operation. (Approvers can be any individuals, groups, roles, or query-based SetGroups that have been granted the ability to perform the operation against the target resource.) This process, known as "Rights-Base Approval Routing" (RBAR), 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).
EmpowerID provides multiple Operation activities to secure each operation that can be executed against resource objects associated with a resource type. For example, all security groups in EmpowerID are protected in workflows by the EditGroupMultiOperations Operation activity. This activity secures the following operations:
Anytime a user within an EmpowerID workflow attempts to edit one of the attributes of a security group, the EditGroupMultiOperations Operation activity in the EditGroup workflow checks to see if that person can perform that task at the current moment . If that person has the operation that pertains to specific task they are attempting, the Operation activity executes the operation. If the current person does not have the operation, the activity notifies the person that the operation requires approval, giving them the opportunity to submit the request or cancel the operation. If the person chooses to submit the request, RBAR routes the request to a designated approver and places the workflow into a suspended state until either a response or an escalation resumes it. If the current person decides not to submit the operation for approval, the workflow terminates with no changes to the group occurring.
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) DisplayOperationApprovalRequestMessage();
if (DisplayApprovalRequestMessage.SubmitOperation == true) NotifyApprover(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:
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();
If Michelle answers Yes, the process routes the operation to a designated approver:
if (DisplayApprovalRequestMessage.SubmitOperation == true) NotifyApprover(approver);
If the designated approver approves the operation, the Operation activity executes the operation:
if (approver.response == approve) EditGroupOperation.EditGroupDescriptionAndNote(HRTeam)
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 like this is derived from an operation approval base, the
OperationWorkflowBase activity, that exposes a number of methods and other members to allow for custom Operation activities to be created by workflow developers. EmpowerID provides the following templates (accessible in Workflow Studio) that can be used to quickly create new Operation activities.
An EmpowerID installment provides the following default Multi-Operation activities that secure specific resource types. A typical operation in a Multi-Operation activity provides security for edits against a few EmpowerID properties on a resource object, such as a user account. Generally, but not always, 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. If desired, organizations may further sub-divide the editing of specific attributes into even more granular operations in Workflow Studio.
EmpowerID maintains a record of all operations executed within any given workflow. You can view these records in the Workflow Operation Audit Log as well as in the AuditLogOperation table of the EmpowerID Identity Warehouse. In addition, each time a person attempts to execute an operation for which they do not have the delegations to perform, EmpowerID writes an event to the Windows Event Viewer with an EventID falling in the 419-435 range. These events are formatted as follows:
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 can see the following:
Each time a person attempts an operation for which they do not have the delegations, EmpowerID routes that operation to any and all people with the ability to approve the operation, placing a task on their dashboards as well as sending email notifications to those approvers. When an approver responds to the request, EmpowerID sends an email to the person making the request, notifying that person whether the request was approved or rejected. Each time a mail-enabled operation is executed, EmpowerID writes an event to the Windows Event Viewer with an EventID falling in the 436-439 range, indicating whether or not the email was successfully sent. These events are formatted as follows:
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 can see the following: