Thursday, December 27, 2012

Learning About FIM Authentication Activities

The FIM Service’s policy engine has three types of workflows:

  • Authentication
  • Authorization
  • Action

Most of the work I’ve done with FIM has used Authorization and Action workflows which are relatively straight forward (especially when you use PowerShell!).  Until recently I’ve respected that AuthN workflows were mostly there to enable FIM’s Self-Service Password Reset functionality, and marveled at Jeremy and Ikrima when they demonstrated custom AuthN WF solutions at TEC (RIP TEC BTW, so sad). 

Recently I’ve been lucky enough to have an opportunity to do some prototyping work for a design I’m working on, and the thing I have to prove is that AuthN workflows in FIM can handle the manner in which I plan to abuse them.  This prototyping has been a ton of fun because AuthN workflows are SO different than the other workflow types but are still hosted and managed by FIM.  The fall-back would be to use a custom service with a backing store, which I really prefer to avoid because it introduces more moving parts which then have to be automated, tested and managed.  So the added complexity of AuthN WF can be justified.

Over the coming weeks I expect to post more about this, including the PowerShell scripts I’ve been using to automate the setup and testing of the prototype.  

3 comments:

JaBbA said...

Did you ever figure out how to create a custom AuthN activity?

Craig Martin said...

Yes we did figure it out and it has been in production for a couple years. It is a neat integration point there are good reasons to not do it:
Support - not officially supported by Microsoft. It works but if you run into trouble it will be a difficult experience getting help.
Complexity - requires pretty heavy customization, meaning cost and maintenance will be a pain
Client Support - custom AuthN activities are not supported by the Portal, and are not supported by the Self Service Password Reset client. You're on your own to create the client experience. In our case it was a web app.

Treating MIM like an application platform doesn't play to its strengths. MIM is much better when used for the features it provides out of the box (minimal customization). In short I would avoid this scenario and level of customization.

JaBbA said...

Thanks for the quick response. We don't have time to build a custom UI integrated with the current portal. I have an ancient reset portal that I'll need to use for now while I figure this out.