Provisioning permissions using the new BHOLD Access Management MA


A couple of weeks ago, Microsoft released Service Pack 1 of FIM 2010 R2 and the Microsoft BHOLD Suite. With that release, a new FIM Sync management agent was introduced, which makes it much easier to provision users, org.units and permissions to BHOLD. In previous versions, we had to create three separate sql ma’s to provision intermediate tables. The new management agent, which was built using the ECMA 2.0 framework simplifies this process.

To enable people to implement this management agent, Microsoft published a test lab guide that describes how to install and setup the MA and how to provision users and org.units. Unfortunately (at the time of writing), this guide does not specify how to provision permissions, which is quite an essential step.

I adapted the code that was provided to provision users and org.units to also provision permissions (known as  ‘groups’ in the MA). Setting the ‘bholdDescription’ was not enough. It resulted in an ‘unknown error’. To solve this, I added flows for ‘bholdMaxRoles’ and ‘bholdMaxUsers’, which I’ve both set to a constant value of ‘0’. Also, I’ve added a flow for the ‘ApplicationDescription’ field. This field should contain the same value as the ‘Description’-field of the Application you want the permission to be a part of (in my case: ‘Active Directory’).

Image

 

Running an export on my BHOLDMA resulted in exactly the same behavior (unexpected-error). Next step was to add the ‘bholdTaskName’. While taking a look at the other imported groups, I noticed that, for the B1 roles, it always contains the same value as the bholdDescription field. I did some research on this and figured out that when I flowed the permission name to bholdTaskName, the exported was successful. While experimenting with this, I noticed that this value needs to be unique. It cannot even contain the value of a deleted permission in BHOLD Core. Altering the value (for example: when changing the name of an AD group) also resulted in some unwanted behavior: the object needed to be rejoined because FIM Sync does not detect this as a change, but as an entirely different object.

My solution for this? It turns out that that BHOLDTaskName is visible as the ‘Permission’ field in BHOLD Core, but apart from that, isn’t really a very useful field: an end user would not really see the value. To guarantee uniqueness, I altered my provisioning code to generate a guid and set it initially. Here’s how you see that value in BHOLD Core:
Image

As you can see in the below screenshot, BHOLD Core shows the description and doesn’t use the BHOLDTaskName value while searching a permission:

Image

 

Later on, I found out that there is only one inconsistency: viewing the permissions of a user shows the guid:
Image

But viewing it in any other location shows the correct permission description:
Image

 

Although, I must admit, I don’t feel comfortable by setting a non-descriptive value to this attribute, I think it’s the best option for now. It’s just too error-prone to use the description, because the field is not changeable.

Here’s my provisioning code:

public void Provision(MVEntry mventry)
{
try
{
if ((mventry.ObjectType.Equals(“person”)))
ProvisionToADUsers(mventry);
if ((mventry.ObjectType.Equals(“person”)))
ProvisionToAMCUsers(mventry);
if ((mventry.ObjectType.Equals(“user”)))
ProvisionToADUsers(mventry);
if ((mventry.ObjectType.Equals(“organization”)))
ProvisionToAMCOrgunits(mventry);
if ((mventry.ObjectType.Equals(“group”)))
ProvisionToAMCGroups(mventry);
}
catch (Exception ex)
{
throw ex;
}
}

 

 

private void ProvisionToAMCGroups(MVEntry mventry)
{
try
{
int numberofConnectors = 0;
ConnectedMA myMA = mventry.ConnectedMAs[“BHOLDMA”];
numberofConnectors = myMA.Connectors.Count;
if (0 == numberofConnectors)
{
CSEntry obCS = default(CSEntry);
obCS = myMA.Connectors.StartNewConnector(“Group”);
ReferenceValue DN = default(ReferenceValue);
DN = myMA.EscapeDNComponent(System.Guid.NewGuid().ToString());
obCS[“bholdTaskName”].Value = Guid.NewGuid().ToString();
obCS.DN = DN;
obCS.CommitNewConnector();
}
}
catch (Exception ex)
{
throw ex;
}
}

 

And my export flows:Image

 

 

If you have any questions on provisioning permissions (or should I say ‘groups’ :)?) to BHOLD Core, let me know!

 

Advertisements
This entry was posted in Uncategorized and tagged . Bookmark the permalink.

6 Responses to Provisioning permissions using the new BHOLD Access Management MA

  1. Mayank Vaish says:

    Hi,

    Will BHold be able to attest the users for applications which do not manage their roles using groups, but store role attributes at user’s profile of the application.
    As per my understanding, for attesting the applications, BHold stores users and groups for each application, in its own database. Groups store references to members of the group. BHold groups (or permissions) can be mapped to roles or permissions of applications.

    However, some applications simply store role information in some attribute(s) of user object. These applications do not have any separate role objects referencing users who carry that role. Hence we do not have any role object of application which can be mapped to BHold groups. So, for such applications how will BHold identify the roles which users have at the application as mapping application group and BHold group is not possible?

  2. Filipp says:

    Hi,
    Did you faced up with flowing group membership form FIM to BHOLD? My situation is that BHOLD doesn’t apply any changes to Users and there permissions and roll back changes in BHOLD MA during the next import run.

    • pdeloos says:

      Why would you want to export group memberships from FIM to BHOLD? It’s BHOLD’s task to calculate these memberships. I’m pretty sure this is not a supported scenario.

      Can you tell me a little more about what you’re trying to accomplish?

      Best regards,
      PIeter.

      • Filipp says:

        HI, Piter!
        For example someone, using selfservice and approval workflow joined to some security group (which is also a permisiion in BHOLD). So i need to flow these changes to BHOLD, but i can not.

      • pdeloos says:

        Filipp,

        I think you have a few options here:
        1. Don’t use the approval workflow of FIM, but enable an end user to request a role. BHOLD has its own self-service request possibility, which makes use of FIM to do some parts of the approval workflow.
        2. Combine the group members of BHOLD and FIM into the metaverse ‘members’-attribute through an advanced attribute flow. The FIM group members won’t be in BHOLD, but they will be exported to Active Directory.
        3. Automatically add the role to a BHOLD-user after FIM approval by using the BHOLD webservice.

        I would advise using the first approach, as this is the most simple one. Technically, but also to the end user. If I understand you correctly, right now you’re using two components to add an entitlement (group) to a user.

        Best regards,
        Pieter.

      • Filipp says:

        Pieter,
        Thank you! I will try working with BHOLD self-service instead of FIM one.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s