Within the new paradigm of Forefront Identity Manager 2010, there are really three different ways to deploy the synchronization engine. These are:
- Classic – This is the old school way of doing things since the days of MIIS 2003. We configure everything within the synchronization engine including our provisioning rules. For those of us who have worked with MIIS and ILM in the past, we know that this can take quite a bit of coding to get it to work right and can be difficult to track down all the changes later on.
- Hybrid – This model is something that I’ve been using quite a bit. Some of the stuff I used to do in code is now done in a declarative sense (especially provisioning/deprovisioning and attribute flows were it was simple string concatenation) however, more complex flows are still managed within the synchronization engine itself and the highly flexible .NET programming environment.
- Declarative – This is the fully “new” school model of provisioning and attribute flow where you’re working 100% within the capabilities of the declarative provisioning. The MAs in the synchronization engine have their basic configuration but the attribute flows and provisioning are all managed through the synchronization rules objects that get developed in the FIM Service and portal.
Personally, I’ve found that I’ve really not encountered an environment where I can use a fully declarative model. I have however fallen in love with the simple means to provision and deprovision users from within the portal based on a visible and easily examined policy without delving into code and all the intricacies required there.
A few notes when developing the deployment strategy for your FIM environment. You should examine the overall functionality of each management agent and what configuration options you’re going to use the most. I’ve given examples below of where you may want to look at the classic, hybrid and declarative approaches for individual MAs:
- Classic – This scenario is ideal for when you have a high level of complex workflows and very few simple workflows. If there is no requirement for provisioning (which greatly simplifies the equation), I prefer to build my MA in a fully classic mode. I like this because the attribute flows are all configured in one place, I don’t have to worry about MPR’s applying outbound synchronization rules and that associated overhead and can still maintain an efficient MA operation.
- Hybrid – This scenario is ideal when there is provisioning and a lot of simple attribute flows that you just don’t want to code that can be defined declaratively. There may be a half dozen or more attribute flows that have to be done classically however, the trade off with the simplicity of provisioning and deprovisioning is seen as a real boon for me here. This can be harder to troubleshoot however as the attribute flows are spread across two areas so maintaining a consolidated view and understanding of what flows are configured where is essential.
- Declarative – Outside of lab environments, I have yet to really see a good real world example of where the declarative model fits. Most of my management agents have required some form of complicated data manipulation which just isn’t possible in the declarative rules. That said, I don’t preclude that there will be situations where this is possible and so long as there is provisioning and deprovisioning involved, I really like this scenario. The obvious benefit over the hybrid model is that all the attribute flows and provisioning logic are configured within the FIM service and therefore, reviewing the configuration, like the classic model, only needs to be reviewed in the one place.
A reminder about the object counts in the metaverse when working with the declarative model. It has been proven that classic models are faster in operation than the declarative model due to how the external synchronizationRule objects have to read and processed. Remember the following chart:
|# of MAs||# of Users||# of Inbound Rules||# of Outbound Rules||# of EREs||Total MV Objects|
- The table assumes that each MA has both declarative inbound and outbound synchronization rules applied and there is only one of each type present (this could be reduced from two objects to one object by using the “inbound and outbound” rule type)
- All users with the table are in scope of the inbound rule scoping parameters.
- All users have been mapped to use the outbound synchronization rule by the MPRs in the FIM service.
- This does not take into consideration multiple synchronization rules that have been built out to use a variety of different rules based on configured policy.
I only add this in here to make sure that you’re prepared for the appropriate sizing requirements of the database when using declarative rules.