For this article, consider the default Person object (which I will refer to as /Person to identify this as a FIM resource type) and some form of related meta data derived from their incumbent position(s).
When an HR feed can provide a position code attribute on a person, and you want to define FIM policy for provisioning group membership in AD based on this attribute, it is tempting to load this as a string attribute binding (say /Person.PositionCode) into FIM and define a set such as All People in position XXX using an xpath filter statement such as this: /Person[PositionCode=’XXX’]
This does the job, right?
Well yes, in some cases maybe, but consider the following
You have 100s or 1000s of positions and you want to automate the provisioning of a group per position with active incumbent employees, and the de-provisioning of a group when the last member (incumbent employee) is removed
A person can occupy more than one position at a time, and you wish to define groups or sets based on partial string matches on position code
You wish to define group or set membership based on some other property of a /Position (e.g. approval level, start/end date, reporting-to position)
You want to derive the manager reference based on reports-to-position
You want to define a “relative to resource” MPR “Managers can maintain selected attributes of their employees” based on the subordinates of a manager derived from the reports-to-position
In order to be able to satisfy ALL of the above requirements you will see that you are going to need to define a new /Position object, and assign bindings of its own (e.g. all of the above properties in #3 and some …) and then have a reference type binding on /Person, say Person.PositionID? What effort is involved in doing this, and is it worth the effort? I am going to show you that the answer is a resounding YES!!!
Let’s consider each of the above scenarios, firstly with the STRING binding model, using every ounce of lateral thinking I can muster ...
OK, so let’s say we’ve bitten the bullet and decided to implement a new FIM resource type Position, and define reference attribute bindings as required, populated using inbound sync rules as appropriate. In saying this, let’s just ignore the fact that getting our HR source to present these reference attributes is non-trivial … unless your HR source happens to be an LDAP directory ...
Now let’s consider each of the above scenarios, and how you would approach this:
We can now provision both a /Group (default schema – but with a new reference binding of PositionID) and a /Position resource to FIM, together with a PositionID binding on /Person. What I have then done is the following (I won’t go into the detail here):
Define FIM policy such that a /Group is provisioned for any /Position for which there is at least one /Person object occupying that position.
When provisioning the /Group object to FIM (where there is at least one person occupying the corresponding Position), use the Function Evaluator activity to set the Filter attribute to the following xpath: /Person[PositionID=’<guid of Group.PositionID>’]
Define FIM policy such that any /Group with a PositionID for which there are no /Person object occupying that position is deleted (deprovisioned).
By making the PositionID binding on a /Person a multi-value reference attribute, persons can effectively occupy multiple positions at the same time. The following is then an example of a filter definition(s) for a set or group matching on partial position code:
Set A (all positions starting with XX): /Position[starts-with(DisplayName,’XX’)]
Set/Group (all persons occupying a position starting with XX) B: /Person[PositionID = /Set[ObjectID=’<guid of Set A>’]/ComputedMember]
Similar to #2 above, the following is then an example of a filter definition(s) for a set or group matching on a particular property of position:
Set A (all positions with approval level 1): /Position[ApprovalLevel=’1’’]
Set/Group (all persons occupying a position with approval level 1) B: /Person[PositionID = /Set[ObjectID=’<guid of Set A>’]/ComputedMember]
You use the reports-to-position relationship to derive a single-value reference attribute “manager” in the authoritative HR source and import this to FIM via a (direct) inbound sync rule. This binding then allows you additional flexibility in defining FIM policy, such as use of the “Relative To Resource” style MPR.
You use the reports-to-position relationship to derive a multi-value reference attribute “subordinates” in the authoritative HR source and import this to FIM via a (direct) inbound sync rule. Again, this binding then allows you additional flexibility in defining FIM policy, such as use of the “Relative To Resource” style MPR.
OK – so I’ve over-simplified the role of the HR MA in magically generating reference attributes to directly import your reference data into FIM. As I said above, it would be wonderful if your HR source was an LDAP or DSML compliant directory, and not the relational database application that they tend to be in 99 times out of 100. The FIM Sync engine is optimised to work with LDIF or DSML data sources, and invariably you need to start building your own Extensible Connectivity Management Agents (ECMAs or XMAs) to derive the necessary features you need in your HR MA (multiple object classes, multi-valued attributes, reference attributes, delta imports, bi-directional attribute flows, etc.)
Secondly – if you’re trying to execute FIM run profiles on a repeated schedule, you will find that it takes many schedule executions to eventually see the desired effect of say a change in HR location and position for an employee translated to a change in OU and group membership in AD. It takes many sync cycles to achieve the necessary outcomes, including ERE and DRE creation. Far better to run FIM in an event-driven manner to achieve near-real-time outcomes.
How I use the above tools to achieve this might be the subject of a subsequent post, but for more information please check out this page on my company site.
I hope this article sheds some light on how traditional data modelling methods can be applied to FIM to model common enterprise IAM requirements, with the help of some complementary technologies to present HR data as an LDAP directory, and to “event enable” FIM synchronization policy delivered via the FIM sync service.
Ed Price - MSFT edited Revision 10. Comment: Removing TOC extra spaces
Ed Price - MSFT edited Revision 9. Comment: Title casing
UNIFYBob edited Original. Comment: formatting tidy
No sooner had I posted this article, someone piped up with this query here on the FIM forum ... social.technet.microsoft.com/.../3193d2b7-418e-4cbd-8bbd-3507619b7622 ... which is another good example of what can be accomplished when you go to the trouble of using reference attribute bindings instead of string bindings.
Related articles:
1. social.technet.microsoft.com/.../understanding-reference-attributes-processing-in-fim.aspx (wiki: Understanding Reference Attributes Processing in FIM)
2. download.microsoft.com/.../ReferenceAttributes.doc (download: Design Concepts for Managing Reference Attributes)
Very useful, thanks for sharing this!