I will be delivering my “Auditing in Forefront Identity Manager” talk at TEC Europe later this month in Berlin. It’s largely the same talk I gave at TEC in Las Vegas this past March, but updated for the upcoming RC1 build of FIM 2010 (which sadly won’t be available for TEC Europe, but should be available not long after). In the process of updating my session, I exchanged (Hah! Get it?) some emails with Nima Ganjeh, Program Manager on the FIM product team and learned that there have been some substantial changes in the way FIM manages and exposes it’s object data.
Auditing FIM primarily involves pulling data from the FIM SOAP Enumeration endpoint, using a modified version of the WS-Enumerate protocol. In the RC0 build, FIM implemented the Infological data model [Langefors, 1973] in the object store, meaning that all relationships (attribute-value, object-attribute, etc.) were stored, indexed by time, and never deleted. Because data was never deleted or overwritten, it was possible to retrieve objects from the RC0 object store as it existed at any point in time. So if you wanted to know what the membership of the Administrators group was on March 30th last year, you could simply query for that object using the builtin XPath filter syntax function attime(), and voila!, you would see that group object as it existed at that point in time. This was in my mind one of the most significant benefits of FIM 2010. It provided what was in effect a builtin, automatic snapshot facility that answered the auditor’s question of “who was a member of this group back when the accounting data was compromised?”
Beyond the very cool data model, RC0 also maintained the transaction history for all object update operations by creating Request objects in the store. The Request objects, in addition to specifying the target object and operation, including the initiator of the update and the update parameters themselves. So not only could you look at the state of an object at any point in time, you could easily get a time-sequenced list of all of the changes made to that object, including what was changed, and by whom. This answered the auditor’s question of “who added Bob to this group back when our accounting data was compromised?”
But maintaining a complete history of the FIM object store had a price, or actually two prices: a rapidly growing database and insufficient performance. While RC0 would perform reasonably well on smaller datasets, it just wasn’t cutting it for larger environments. The FIM team decided that the performance impact of maintaining this historical data just wasn’t worth it, and in RC1, they have completely revamped the implementation of the object store. And sadly, RC1 has completely dropped the Infological data model and maintains no object history at all beyond the Request objects. The attime(), alltime(), and betweentime() XPath filter functions are gone, as is the ability to retrieve an object’s prior state through the web service. This is a big disappointment in my mind, but I can’t fault the FIM team for it… historical data or unworkably slow? It’s not a hard choice.
So how do you solve the audit problem in FIM 2010 RC1? I’ll discuss that in my talk at TEC in a couple of weeks and in this blog, but suffice it to say its not not as elegant as it used to be.
Nima will publish the specifics of the changes in the RC1 query facility in his blog soon, so keep an eye on it.
1. Langefors B. (1973) Theoretical Analysis of Information Systems