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.
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:
_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:
_BHOLD ROLE Management - Line Management Approval
_BHOLD ROLE Management - Role Management Approval
_BHOLD ROLE Management - Security Office Approval
_BHOLD ROLE Management - Without Approval
BHOLD_ROLE Title Generator
The following MPRs gets created:
_BHOLD_ROLE Line Management - Approval
_BHOLD_ROLE Line Management - Without Approval
_BHOLD_ROLE Role Management - Approval
_BHOLD_ROLE Security Office - Approval
BHOLD: Administrators can read and update BHOLD roles
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.
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.
Version=5.0.1992.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Finally, create a request MPR with the following settings.
Grant Permissions is checked
Target Resource Definition Before Request
All BHOLD_ROLE that starts with MyRole
Target Resource Definition After Request
bholdRequestItemId; Comment; Subject
The one we just created
Next time someone requests a role that starts with "MyRole", FIM will ask approval from the requestor's manager.
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.