Forefront Identity Manager 2010 (FIM 2010) Data Cache

Hi, Syam Pinnaka here. I am a Sr. SDE on the Information Security Tools Team. In one of the recent projects there is a requirement to build an audit trail of “Group” object related activities in Forefront Identity Manager 2010 (FIM 2010). FIM provides a WCF interface to program against it but building audit trail is not obvious at first look. In this blog post I will try explain how to program against FIM 2010 and also how to build audit trail of “Group” object related activities in FIM 2010.

Programming against Forefront Identity Manager 2010:

FIM provides an API in terms of a set of WCF end points to program against FIM objects. These FIM WCF endpoints are extensions to WS-* in order to enhance usability of these WCF endpoints by the client applications. One of the endpoint is “Enumeration Endpoint” using which we can query FIM objects. Queries can be constructed using “XPath Filter Dialect”. Enumeration Endpoint returns the FIM objects in xml serialized format.

More details about programming against FIM using WCF services can be found here.

Caching audit trail of activities on a FIM “Group” object:

All the requests made by different users in FIM are captured and stored as “Request” objects. Each request object contains the information about who made the request, request status indicating whether it’s a successful/failed request and some additional information required to change the state of targeted object. This additional information is passes and stored as “RequestParameter” in xml format. A sample request parameter XML for a create request looks like this.

<RequestParameter xmlns:xsi="" xmlns:xsd="" xsi:type="CreateRequestParameter"><Calculated>false</Calculated><PropertyName>DisplayedOwner</PropertyName><Value xmlns:q1="" xsi:type="q1:guid">21387668-baf1-42c9-84ab-ab68a3872311</Value></RequestParameter>

Each create “RequestParameter” has a PropertyName, Value elements and value type as an attribute.

Similarly an example update request parameter will be like this.

<RequestParameter xmlns:xsi="" xmlns:xsd="" xsi:type="UpdateRequestParameter"><Calculated>false</Calculated><PropertyName>MailNickname</PropertyName><Value xsi:type="xsd:string">amk123</Value><Mode>Modify</Mode></RequestParameter>

Each UpdateRequestParamter has a PropertyName, Value, Mode elements and value type as an attribute.

Delete request parameter will be similar to update request parameter with mode being ‘Remove’.

Each request that’s submitted to FIM can have one or more of these request parameters. These request parameters can be used to identify all the modifications that have happened to the object.

In order to find out all the changes that has ever happened to any object in FIM, we need to carry out the following the steps.

  1. Find out all the requests that are targeted at the object that we wanted to keep track of. Use XPath query dialect to specify the object. We can specify an object meaning that we wanted to find all requests aimed at “Group” type objects.
  2. After we find out all the requests, inspect all request parameters with each request to find out all the requested modifications.
  3. Make a note of all these changes requested and request status in order to report back as part of the audit trail.
  4. If we wanted to keep track of current status of an object, we need to incrementally apply all the changes (request parameter values) as we see them with each request. This is how we can incrementally re-construct an objects state by reading through request, request parameter combinations.

We are able to successfully follow this approach to construct the audit trail and keep an objects state up to date in a local database and report back all these changes to the users.

This is just an approach to follow and can be implemented in a variety of ways.

Happy coding and do ping me if you need more information.