Building custom activities in Forefront Identity Manager (now Microsoft Identity Manager) required an understanding of programming in C# or VB.Net and how Windows Workflow Foundation functions.
Microsoft has recently released the MIMWAL (MIM Workflow Activity Library) which allows you to do many of the things a custom activity could do without needing to know how to program a .Net language.
It’s a great tool but there is a bit of a learning curve to understanding how to use it. I’ve been lucky to be working recently on a project with the author of the MIMWAL and thought I would share a few common scenarios to help familiarize people with its use.
Reading a Resource
When creating custom workflows, one of the first things everyone needs to do is read a resource. In order to do this in the MIMWAL you actually use the “Update Resources” activity. This activity is used very heavily in MIMWAL projects as it lets you read resources and add values to workflow data that can then be used to update a resource.
In the update resource activity below, the “Queries” part of the activity is setting the XPath to query the location object called “Default.” And putting that XPath query in the “DefaultLocation” key.
Then, in the “Updates” section, that XPath is used via [//Queries/DefaultLocation] to put the value from executing the XPath query into the variable $DefaultLocation. $DefaultLocation is then set (on the second line) to be the value of the [//WorkflowData/DefaultLocation]. This allows the value to be used in subsequent activities in the workflow by calling [//WorkflowData/DefaultLocation].
The above graphic also shows that a variable can be set by directly giving it a string value.
“@domain.com” will be the value stored in [//WorkflowData/SMTPDomain]
Another way to set attributes is to use and XPath filter in the “Updates” section in the “Value Expression”.
Will return the value in the Location attribute of the target if it is present, if not it returns the string “Default”.
Effective and Delta Lookups
There are two useful look up functions that I used in a workflow to validate if a country code was present on a user. The country code attribute was new to accommodate a requirement that a country code be present if the phone value was present. However, lots of users already had a phone attribute. The authorization workflow needed to handle these scenarios:
- User with an existing phone attribute adds a country code.
- User enters a new phone attribute (or modifies an existing one) and country code.
- User enters a phone attribute (or modifies an existing one) and no country code.
- User removes a phone attribute.
The Delta look up will provide the value for the attribute that is in the request parameter.
The Effective look up works in AuthZ workflows to return the value the attribute would have after the request is committed (this would be the same value as Delta if the attribute is changed during this request, otherwise it will be the value currently on the Target).
So, the first stage of the AuthZ workflow is to use an Update Resources activity to set some variables:
The Value Expressions are setting Boolean values for whether there is data on the Delta (what is in the request), the Target (what is currently on the user) and Effective (what the country code will be after the request is processed).
Additionally, we are checking to see if there is an Office Phone value after the request has been processed. We use this in the next step: the Verify Request in the Activity Execution Condition.
Here is the Verify request:
The Activity Execution Condition checks that the phone attribute will have a value after the request is submitted (the Effective value). If it won’t have a value, the verify request passes. If it will, then the Required Request Conditions are checked.
Here is the Activity Execution Condition:
The required request conditions will be used to determine if the data is valid. If the condition fails, the message in the “Denial Message” is returned and the access is denied.
The request conditions above are checking first that either the delta country code or target country code are present. If either is then the request is valid for that condition:
The next validity check is that the effective country code is present or the office phone isn’t present (because if the phone is being deleted, the country code isn’t required).
If both of these condition checks pass the authorization passes. If either fail, the request is denied and the value in the “Access Denied” message that is returned is the value from the first request that failed.
The MIMWAL is a super handy tool that makes complex workflows much easier and faster to create. I’m looking forward to using it in future projects.