/wiki/spaces/E2D/pages/29982926 / Authorization RBAC / ABAC / EmpowerID Operations Overview

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.

Rights are native permissions used by the application or operating system to manage security for the resource type in question. Granting these rights enables capabilities for users in that system, apart from EmpowerID. Being granted rights does not give the user any abilities within EmpowerID nor does it make the user a potential approver for any workflow operations. EmpowerID provides the ability to inventory these rights and their assignments to users as well as the capability to assign or push these rights into and remove them from native systems through the enforcement process.

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 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 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:
```
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:

if (DisplayApprovalRequestMessage.SubmitOperation == true)
        NotifyApprover(approver);

The designated approver will see the request as a task with a Respond link in the EmpowerID Management Console or 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 (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.
```
CurrentWorkflow.Terminate();    
```

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.

Single Multi-Operation Activity template — This template can be used to create Operation activities capable of executing one or more operations against one resource type. An example of a single operation is resetting the password for a user account. To perform the operation, security is checked against one object: the user account.
Dual Multi-Operation Activity template — This template can be used to create Operation activities capable of executing one or more operations against two resource types. An example of a dual operation is adding a person to a group. To perform the operation, security is checked against two objects: the person and the group.
Triple Multi-Operation Activity template — This template can be used to create Operation activities capable of executing one or more operations against three resource types. An example of a triple operation is changing the primary Business Role and Location of a person. To perform this operation, security is checked against three resources: the person, the Business Role, and the Location.

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.

Operations and EmpowerID Windows Events

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:

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

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

Browser not supported