FIM 2010 R2 BHold: Non-BHOLD Approval Process

FIM 2010 R2 BHold: Non-BHOLD Approval Process


Introduction

The BHOLD/FIM integration component introduces a self-service portal to request proposed roles. Proposed roles are those that are not yet activated for a user, still available for the user to request them. The request to activate a role in BHOLD/FIM integration leverages FIM approval workflows. This is a big plus, since FIM Administrators will deal with a familiar interface (FIM Portal) to manage their workflows and requests. In addition to that, all user requests can be found in one place under "Manage My Requests".

In this post, we will discuss what is available out of the box from BHOLD (after installing the integration component) and where to find information about that. We will also discuss how to create a Non-BHOLD approval process for BHOLD role requests.

This post assumes you know how to configure FIM policies including Management Policy Rules, Workflows, and Sets. If you don't, the links below are good introduction to know more about this topic.

Also, the post assumes you have the basic knowledge of creating a BHOLD role and link it to an OU.

Out of the box objects

The FIM Service schema gets extended, and "BHOLD_ROLE" is a new resource type that gets created in FIM Service. When a user submit a request to activate a role, a new "BHOLD_ROLE" objects is created or an existing object is modified.

"BHOLD_ROLE" resource type has attributes bound to it. Some of those attributes will determine the authorization workflow that FIM will execute. Those attributes are highlighted in the image below:


 

The following links discuss the role approval process in BHOLD FIM Integration. They provide a details on how you can configure approval the BHOLD way.

The above attributes are then used in sets filters. The following sets gets created. They use the above highlighted attributes:

Set's DisplayName

Criteria

_BHOLD ROLE Management - All roles with approval


_BHOLD ROLE Management - All roles with line management approval


_BHOLD ROLE Management - All roles with role management approval


_BHOLD ROLE Management - All roles with security office approval


_BHOLD ROLE Management - All roles without approval


The following workflows gets created:

DisplayName

Workflow stage

_BHOLD ROLE Management - Line Management Approval

Authorization

_BHOLD ROLE Management - Role Management Approval

Authorization

_BHOLD ROLE Management - Security Office Approval

Authorization

_BHOLD ROLE Management - Without Approval

Authorization

BHOLD_ROLE Title Generator

Authorization

The following MPRs gets created:

Display Name

Action Type

Disabled

Grant Right

AuthN

WF

AuthZ

WF

Action WF

_BHOLD_ROLE Line Management - Approval

Modify

No

Yes

No

Yes

No

_BHOLD_ROLE Line Management - Without Approval

Modify

No

Yes

No

No

No

_BHOLD_ROLE Role Management - Approval

Modify

No

Yes

No

Yes

No

_BHOLD_ROLE Security Office - Approval

Modify

No

Yes

No

Yes

No

BHOLD: Administrators can read and update BHOLD roles

All

No

Yes

No

No

No

BHOLD_ROLE Title Generator

Modify

No

Yes

No

Yes

No

 The reason I'm showing you all those MPRs and workflows is for you to get a notion of what's going on here. It's the same exact approach we have been using for so long in FIM. The same way you configure a workflow to approve creating a new group, can be used when requesting to activate a role. In the next section, we will discuss how to create a non-BHOLD approval process for BHOLD.

Non-BHOLD Approval Process

First off, you need to do is to group together similar "BHOLD_ROLE" objects in a set. The above sets are useful and can be used, however, we will use different attributes. For the sake of this post, we will use the attribute DisplayName. The set criteria will be (DisplayName starts with "MyRole").


Second, you need to create the approval workflow. For the sake of this example, the approver will be the [//Requestor/Manager]. After the workflow has been created, you will need to modify the XOML to include the BHOLD DLL in the definition. Here's how it needs to look like. If you didn't add this reference to this DLL, the approval process will be triggered, however the role will not be activated in BHOLD.

1.<ns0:SequentialWorkflow ActorId="00000000-0000-0000-0000-000000000000" RequestId="00000000-0000-0000-0000-000000000000"    x:Name="SequentialWorkflow" TargetId="00000000-0000-0000-0000-000000000000" WorkflowDefinitionId="00000000-0000-0000-0000-000000000000" ........ xmlns:ns3="clr-namespace:BHOLD.Workflow.Activities;Assembly=BholdFimActivities, Version=5.0.1992.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
2. 
3.       <ns0:ApprovalActivity  ......>
4.              <ns2:ReceiveActivity.WorkflowServiceAttributes>
5.                     <ns2:WorkflowServiceAttributes ConfigurationName="Microsoft.ResourceManagement.Workflow.Activities.ApprovalActivity" Name="ApprovalActivity" />
6.              </ns2:ReceiveActivity.WorkflowServiceAttributes>
7.       </ns0:ApprovalActivity>
8.</ns0:SequentialWorkflow>

Finally, create a request MPR with the following settings.

Attribute

Value

Requestor

All People

Operation

Modify

Permission

Grant Permissions is checked

Target Resource Definition Before Request

All BHOLD_ROLE that starts with MyRole

Target Resource Definition After Request

All BHOLD_ROLE that starts with MyRole

Resource Attributes

bholdRequestItemId; Comment; Subject

AuthZ Workflow

The one we just created

Next time someone requests a role that starts with "MyRole", FIM will ask approval from the requestor's manager.

 Note
You can modify the out of the box workflows. When you do that, make sure the XOML has the BHOLD DLL referenced.

Final Remarks

You can configure approvals for BHOLD in so many different ways. The BHOLD way is discussed here Understanding the role-approval process in BHOLD FIM Integration. It is recommended to use this approach. The Non-BHOLD approach I'm demonstrating here is not a replacement, and I'm not trying to compare the two. FIM is a powerful platform and we can configure it in so many different ways. For example, I can add the manager's approval as an extra step for one of the default BHOLD approval workflows. This way I will end up with two level of approvals, which might meet some clients requirements.

I observed one limitation with BHOLD approvals. It is limited to three type of role approvals (Role Managers, Line Managers, and Security Officers). You can also combine different BHOLD role approvers in the same workflow. For example, your workflow can ask approval from the Line Managers, then ask approval from Role Managers. If your client needs more than three level of approvals, then you will end up short and you will have to find a different way to get your approvers.

Sort by: Published Date | Most Recent | Most Useful
Comments
  • Please contact me at nnosonovsky at gmail dot com if you want to be interviewed by me for the TechNet Wiki blog

Page 1 of 1 (1 items)