Page Comparison

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 for 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 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 and Rights-Based Approval Routing

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:

• Edit AD Group Name Attributes – This operation grants users the ability to edit the Name, Display Name, and Logon Name attributes of a group.

• Edit Group Type – This operation grants users the ability to change the group type.

• Edit Mail Enable Group – This operation grants users the ability to enable a group to receive mail.

• Edit Mail Disable Group – This operation grants users the ability to disable a group from receiving mail.

• Edit Group Description and Note – This operation grant users the ability to edit the group description and note attributes.

• Edit Hide Group in GAL – This operation grants users the ability to hide a group in the Global Address List.

• Edit Show Group in GAL – This operation grants users the ability to show a group in the Global Address List.

• Edit Exchange Settings – This operation grants users the ability to edit Exchange settings for mail-enabled groups.

• Edit Group Extension Attributes – This operation grants users the ability to edit extension attributes for mail-enabled groups.

• Edit Group Advanced Settings – This operation grants users the ability to edit EmpowerID advanced settings for a group, such as hiding the membership of the group.

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 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, and as a result, 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). If the user lacks one or more of the required operations for those target resources, the operation is directed to a designated approver who has the authority to approve or deny it. Approvers can be individuals, groups, roles, or query-based collections known as “SetGroups,” granted the ability to perform the operation on the target 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, the activity notifies them that the operation requires approval, providing the option to submit the request or cancel it. If the user opts to submit the request, EmpowerID routes it to a designated approver and suspends the workflow until it receives a response or experiences an escalation. If the user decides not to submit the operation for approval, the workflow terminates with no without any changes made 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: 

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 like this in EmpowerID is derived from an operation approval base , the OperationWorkflowBase activity, that exposes a number of methods and other members to allow for called the OperationWorkflowBase activity. This base exposes various methods and members, allowing custom Operation activities to be created by workflow developers. EmpowerID provides offers the following templates (accessible in Workflow Studio) that can be used Studio to quickly create new Operation activities. :

1. Single Multi-Operation Activity template

...

1. - This template

...

1. is used to create Operation activities capable of executing one or more operations against

...

1. a single resource type.

...

1. For example, resetting a user account

...

1. password requires security checks against only the user account.

2. Dual Multi-Operation Activity template

...

1. - This template

...

1. is used to create Operation activities capable of executing one or more operations against two resource types.

...

1. For example, adding a person to a group

...

1. requires security checks against both the person and the group.

2. Triple Multi-Operation Activity template

...

1. - This template

...

1. is used to create Operation activities capable of executing one or more operations against three resource types.

...

1. For example

...

1. , changing a person's primary Business Role and Location

...

1. requires security checks against the person, the Business Role, and the Location.

An EmpowerID installment provides the following includes default Multi-Operation activities that secure specific resource types. A typical 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. Generally, but not alwaysOften, 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 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. You can view these records These records can be viewed in the Workflow Operation Audit Log as well as in the the AuditLogOperation  table table of the EmpowerID Identity Warehouse. In additionFurthermore, each time a person attempts to execute an operation for which they do not have the necessary 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:

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

  email was successfully sent to a specific email address. This email address 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.
  

Event 437
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

  . This email address

  , which is bound to the person making the request

  .

• The operation(s) approved

  . In

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

...