Archiving Requests and Approvals by Email

Posted on by Carol

I just had a request to do with auditing activity in the FIM Portal, and as the solution was quite neat and easy to implement I thought I’d share it.

The security team need to archive information about who makes changes in AD and other applications, and now they need to be able to audit the FIM Portal too. While you can search the Requests history in the Portal, by default it only keeps 3 months worth, and this customer needs 7 years.

I had already been dumping the requests history to a SQL table but I had nothing about who approved the requests. However before I could rethink my sql scripts the guy said “Actually is there any way we could have it by email? We’re already well set up for archiving and searching emails.” So this is how I managed to satisfy their audit requirements using just the standard Notification activity.

Archive all Requests that change Person objects

First I need an email template that reports the essential information about the request.

Subject IAM Portal Request [//Request/ObjectID]
Body 
<html>

<p> RequestID: [//Request/ObjectID]</p>
<p>Requestor: [//Requestor/DisplayName] ([//Requestor/Email])</p>
<p>Target: [//Target/DisplayName] ([//Target/Email])</p>
<p>Request submitted on: [//Request/CreatedTime] (GMT)</p>

<p>Request details:</p>
<p>
<table style="width: 80%">
 <tr class="HeadingStyle">
  <td>Attribute</td>
  <td>Old Value</td>
  <td>New Value</td>
 </tr>
[//RequestParameter/AllChangesAuthorizationTable]
</table>
</p>

<p>Possible Approvers: [//Request/ComputedActor]</p>

</html>

Next I create a workflow that uses the email template to send a notification to the archiving mailbox.

I also created a Set called “All Portal Users” which excludes the Built-In Sync Account and a couple of other service accounts. This will allow me to just send emails based on changes made by actual people.

And finally I create an MPR:

  • Type = Request
  • Requestors = “All Portal Users
  • Operation = All
  • Grants Permission = False
  • Target Resources = “All People”
  • Action WF = The notification activity I just created.

This now sends an email to the archiving mailbox whenever a user makes a change to themselves or another person in the FIM Portal.

Archive Approvals

This particular implementation of FIM relies heavily on approvals. Approval requests may be sent to multiple people but only one need approve, therefore it is important that  the approver also be captured.

I can’t get all the info about request and approval in one email as not all requests have approvals, and there’s no link to the Approval Response from the person object. But the customer is happy with the two emails, and this email about Approvals cites the resource ID of the Request, so they have a way of linking the two.

Here’s the Email Template:

Subject IAM Portal Approval for Request [//Target/Approval/Request/ObjectID]
Body 
<html>
<p>RequestID: [//Target/Approval/Request/ObjectID]</p>

<p>Approver: [//Target/Creator/DisplayName]
</p>

<p>Approval Time: [//Target/CreatedTime] (GMT)</p>

<p>Approval Response: [//Target/Decision]</p>

</html>

Again the Workflow is just a simple notification using the template.

I created a set called “All Approved Approval Responses”. You could use the existing “All Approval Responses” set if you wanted to archive rejections as well, but here we only wanted to archive successful requests.

The rule for the Set is “All approval response where Decision = ‘Approved'”

Finally I created the MPR as follows:

  • Type = Set Transition
  • Transition In Set = “All Approved Approval Responses”
  • Action Workflow = the notification workflow just created.

Emails are now sent to the archiving mailbox whenever an approval completes with an “Approved” status.

I've been doing IT for 30 years, and IdM for 15. I live in Australia and build IdM solutions based on Microsoft Identity Manager. I also play the violin, but that doesn't help much with the IdM solutions.

3 Replies to “Archiving Requests and Approvals by Email”

  1. Hi Carol,

    Nice and simple – just one question – what is volume of requests there? I was looking into something similar and actually I found one drawback for that kind of solution.

    For each request made to person object You will trigger additional MPR and workflow which will retain in the FIM database as per default retention policy. With high volume of requests and objects this might have impact on database size etc. Of course it also depends on retention policy in particular environment.

    For now we’ve solved it with pulling all objects to our reporting solution – however your approach is interesting and simple in implementation.

  2. It will of course add load in running Workflows and Workflowinstances will have to be created. One reason I exceluded the Sync Service, FIM Service and other service accounts was so I wouldn’t be sending emails based on every single sync update, and every single request spawned by another request. Sometimes one change made by a user launches a whole bunch of other requests, but they’re all made by the FIM Service so no emails get sent about them – just the one email about the actual change made by the actual user, which is what security really cared about.

  3. Great stuff Carol, I like it and i will use it to archive requests to create user objects in the FIM Portal.

Leave a Reply

Your email address will not be published. Required fields are marked *

CAPTCHA Image

*