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.
- Managing approval for BHOLD organizational units with role-approver roles
- BHOLD and FIM – Part 4 – A Basic Role Model
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.
- Understanding the role-approval process in BHOLD FIM Integration
- Managing approval for proposed roles with role-approver roles
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.