MS FIM 2010 - the good and the bad

Identity management is an area which has been growing in importance for some time.  There are numerous commercial products and a few decent open source options.  This post is mainly to document the issues we encountered with MS FIM 2010.

• Support
• There is very little FIM knowledge available.  You should expect to use MS consultants and because of the small number that know FIM you may encounter delays.  
• There is some online information available and I think there is now a course for FIM but there are substantial training needs just to understand the basics. 
• Premier support and MS consulting do try to do the best they can
• Architecture
• It requires SQLServer
• If you are not a SQLServer shop and are not prepared to support it then this can be a substantial issue.
• It is complex 
• Our implementation has various items coded in C# (by a MS consultant), setup in FIM portal and setups in FIM sync service.  I would not consider our identity needs very complex but we do have lots of information to manage.
• Do you need high availability?  Are you prepared to implement/manage/support SQLServer clustering? 
• Certain processes cannot run concurrently and generate various problems if they do collide.  This turns into a juggling act to handle peak times and provide a fast turn-around on additions/changes.  In the end, large implementations likely have to decide on trade-offs whether they want to or not.
• It is a somewhat painful fit into our disaster recovery infrastructure.  The root issue may be how the licensing code works in the overall product. In the end, we are not able to do a real DR test and can only document the steps which we think are required.
• Performance/scalability
• If you have *lots* of users then performance can be an issue
• Initial loading of data for hundreds of thousands to around a million users is pretty slow
• If you experience a high rate of provisioning or updating users then you may have some unpredictably long jobs
•  More server cores != improved performance.  Basically single threaded processing in certain areas of the application from what I can tell.
• We have an ERP as a source which has thousands of tables in the system catalog.  FIM doesn't handle this well at all - likely trying to populate drop down lists and such.  We ended up routing the ERP data through another DB system (provide views to the target tables over links) so the size of the DB catalog didn't cause problems. 
• The normal response to certain issues is "full sync".  This is sort of the "reboot" equivalent to OS problems.  With a large implementation, this will likely result in processing delays.
•  
• Stability/Quality
• We encountered some errors early on which required hacks to get around and required substantial time for MS to provide hot fixes
• We continue to have some issues which have no obvious source in production and have not been reproduced in non-production.  It is possible that currently unapplied updates and hot fixes may remedy the issues but we are in effect a guinea pig for some updates/fixes.
• 
  
• Ease of use.  
• The goal of a GUI is to improve ease of use but when there are items that if selected (or not selected) at the right time can result in massive delays as it tries to process the "mistake" aspect of a request. 
• The reporting capabilities are horrendous and MS knows it.  Maybe it will improv in 2010 R2 but I will wait and see.  If you are trying to research large number of errors you will find it beyond frustrating that you can't export a list of errors.  In the best case, you have to perform a good number of mouse clicks per entry to cut/paste what you need into Excel, etc.  In the worst cased, there are places where all we could do was perform a screen shot or manually transcribe data because you couldn't select it for cut/paste.  Error  messages are poor and misleading in some cases.
• Validation of data is painful.  You are not given (SQLServer) schema information for FIM so if your primary identity sources are a database you cannot simply write utilities to compare sources.  We are implementing custom utilities to try and compare one of our data sources to some data that ends up in active directory.  So we are able to compare the beginning and end but cannot see intermediate results when they don't match.
• Organization/Corporate culture
• If scope is increased above what is initially planned and you have hard deadlines - you likely will regret choices which end up rushed and lack enough forethought.
• If you don't have some (mostly) dedicated staff then expect a lot of unhappiness
• If customers(users of the data) are not fully involved early on to help determine the data needs and validate a data dictionary - expect thrashing later.  

Related commercial tools:

• http://www.oracle.com/us/products/middleware/identity-management/overview/index.html
•  http://www.quest.com/identity-management/
•  http://www.bmc.com/products/offering/Identity-Management.html
•  http://www-01.ibm.com/software/tivoli/products/identity-mgr/
•  https://www.pingidentity.com/products/pingone/
•  http://www.openiam.com
•  

Related open source tools:

• http://www.forgerock.org/
• http://developers.sun.com/identity/
• http://shibboleth.net/
• http://www.jasig.org/cas
• http://www.josso.org
• http://shiro.apache.org/
• http://static.springsource.org/spring-security/site/
• http://openid.net/
• http://www.sourceid.org/

As a note to self, I should keep an eye on the items at forgerock.org and maybe consider a proof of concept in case FIM doesn't work out.