FIM – Multiple MAs and Attribute Precedence

Recently, I have been involved in several client projects that involve the distribution and synchronization of user accounts between multiple organizations. This is a little different than the standard synchronization scenario, which assumes that there is one organization, and data flows from an authoritative source, such as an HR data store. An example of this basic synchronization can be seen in Figure 1; assume that we have three domains in our organization, and domain A is authoritative.

In this basic scenario, attribute precedence is not a consideration, because there is only one import flow for all person object attributes (see Figure 2).

Obviously, things are rarely that simple – even in a basic environment. Typically, you have at least a few attributes that have import flows from more than one source. A simple example of this might be displayName. “William” may be his official name, but everyone knows him by “Bill”, and no one can find him in the address book. So the HR feed may populate that attribute at first, but after that, your AD domain will update the displayName attribute based on user preference.

In the Figure 3 example above, you might make domain A authoritative for the displayName attribute on the initial load (or provision), and then make domain B authoritative for that attribute after that by moving the MA for B above A in the Flow Precedence configuration for that attribute (see Figure 4).

This kind of attribute precedence is easy to configure as long as you have user attributes flowing in one direction.

Before I go any further, I think it is important to be reminded of when attribute precedence is determined in FIM synchronization:

Precedence is determined on the inbound flow into the FIM Metaverse

It is important to remember that attribute precedence is not determined during export from the Metaverse, but on import to the Metaverse. Understanding this is key!

So, what about attribute precedence when you have user objects that need to be cross-populated via the sync?

In Figure 5 above, each domain has its own set of unique user objects which need to be synched to the other domains.

Using simple attribute precedence will now no longer work; each domain is authoritative for its user’s attributes. For instance, if you have simple attribute precedence setup A, B, C, a Metaverse person object that came from domain A will work great: the person object would be updated by domain A (because it is precedent) during import – and those attributes would be exported to domains B and C (see Figure 6).

But what happens when you want a unique user object from domain B synched to domain A? Once the object is connected to both domains, domain A will become precedent for attributes. Notice below in Figure 7, that even though the user originated from domain B, domain A is now authoritative for the displayName attribute because of its position in the precedence configuration in Figure 6.

There are a couple different approaches to handle this:

One approach is to write extension code for every single import flow into the FIM Metaverse.

The advantage is that you only have to deal with one object (person) on your export flows to each connected MA. This can be handy if you have 20 or 30 other MAs (I had a client recently who had over 60).

The disadvantage is that you are now dealing with advanced flows (and the obligatory extension coding) for every import flow. If you want to add or modify a flow down the road, you will need to modify the extension code for every affected source MA. This makes it a little difficult to hand off to your maintenance team.

Another approach is to create a “person” object for every MA.

The advantage here is that there is only one import into each object (the source domain); therefore attribute precedence is a non-issue.

The disadvantage is that you now have to define every object in your export flows. Again, a real issue if you are dealing with a large number of connected MAs (see Figure 11).

Also, if you want to add an attribute to the synchronization flows (let’s say you now wanted to flow ipPhone from/to all domains) you would need to potentially modify [number of MAs]² configuration items.

…

Each of the solutions is viable, and each has pros and cons. But there is another solution that is a bit of a hybrid that will avoid both extension coding for direct imports and also negate the need to define an object for every single MA.

Now if the situation is that every single source has unique objects that must be synced to every other MA, then one of the above options is the only way to do it. But if you have a scenario where the majority of the sources need to be synced to only a subset of the other MAs (typical during acquisitions and mergers, as well as umbrella company relationships), then this next approach may save some time.

In this example, let’s say that company “C” acquired companies “A” and “B”. Here, all users must be provisioned into domain C for email and application access, and domain C users need application access to domain A and domain B (figure 12, below).

Looking at the Figure 12 diagram, you would create a Metaverse “person” object for every MA that had multiple inbound arrows; so in this case, domain C (see Figure 13).

The advantages here are that you would be able to:

• Avoid extension coding for direct flows (remember, that even though the person object has import flows from both A and B, they will never be connected to each other, so precedence is a non-issue)
• Only need to define export flows for the person object and those few MAs that you need to create a unique Metaverse person object for (in this case domain C)
• Lessen the complexity of future changes.

As you can see, if you now wanted to flow the ipPhone attribute in this scenario, instead of modifying the square of the MAs involved, you would only need to modify [number of person objects] x [number of MAs] configuration items (6 items instead of 9).

Again, probably not a huge issue if you are dealing with three or four MAs – but if you are in a situation where you are dealing with more than a few, then this technique might save some time; if you have 14 MAs and add an attribute to your scope, making 28 changes sure beats making 196.

(14² = 196 , but 14×2 is only 28!)