So I was asked by my boss to take a look at a MS Virtual Lab for Forefront Identity Manager (FIM) 2010, MS latest and greatest in the series of Identity lifecyle management tools. The lab essentially consisted of 3 sections, one dealing with account creation and provisioning, another dealing with self-service, approval-style group management, and another using a password reset utility to show off workflow capabilities. I must admit, that I did approach this lab with a bit of skepticism and contempt as I have already developed a web-based application for creating and provisioning accounts and have a hard time seeing the value in spending thousands of dollars on something that we basically already have and give up the ability to change/customize it. Anyway, this is my analysis and takeaway on what I have experienced.
Interface
The FIM interface is basically a web interface... and a poky one at that, unless that is just the virtual lab slowing everything down, but it did seem relatively intuitive, which is not surprising since MS has been at this for awhile now.
Section 1: Account Creation and Provisioning
The first section of the lab dealt with basic account creation and provisioning. Not very impressive, as what we already have does more in some areas and in areas that are lacking, could easily accomplish or exceed with a few minor modifications. The lab basically had you fill out a form with all of the particular account details, leaving room for data entry errors, etc and based on certain options selected from a dropdown list or two, automatically adds the user to a group or set of groups. All of this data apparently goes into a database backing the FIM somewhere, because the lab then has you fire up a script, which runs every 30 seconds, to synchronize the FIM with Active Directory. Two questions, why not interface directly with AD and second, why wait so long to synchronize. The issue I see with this is that there is no immediate feedback of success, and this could ultimately slow down the account creation process in a high demand environment. The application we have interfaces directly with AD as well as global account list and provides direct feedback of success/failure, as well as logging all of the attributes that have been set during the account creation process. As far as adding the account to specific groups based on options selected from dropdown lists, that framework essentially already exists, is easily extensible, and just needs to be implemented.
The other question that comes to mind is security trimming and customization. Sure it is nice to have a neat web interface that can be used to create accounts, but is the interface security trimmed or can it be? The current application is and the security trimming that exists can be extended and modified. What about customizations? The environment that exists does not lend itself well to working with FIM out of the box. The advantage to the current application is that it is built around the unique account creation/provisioning process, as well as other needs with regard to modifications, moves, and deletions, and because of this, is more agile with respect to modifications dictated by the process, instead of modifying the process to deal with inflexibility in the app.
Section 2: Self-Service Group Management
I have to admit this concept is pretty cool, and I do like the approach that MS has taken here as far as patterning goes. Basically, an AD group is created and ownership is given to a manager. It appears as though FIM serves as a broker or gatekeeper for the group membership. Somehow through the process of setting this up, an add-in is created for MS outlook whereby users, can apply to be members of a group. When a user applies for membership, a message is sent to the group owner and they can approve or deny, which in turns informs the original requester.
So this is a pretty neat process. However, I find a bit of a problem in the implementation of the process via an Outlook add-in. The add-in may only be specific to Outlook 2007+, which is not consistent in the environment, and it seems that it will more than likely require user training. Windows SharePoint Services (WSS) allows an option for requesting access to SharePoint groups, which basically uses the same workflow process, but it is web-based.
Other questions I have about this feature that FIM implements revolves around the groups themselves. Are the end users limited to which groups they can even see to apply to? I'm thinking about role-based access control (RBAC) here... There could be a whole list of groups that one set of people could apply for membership to that would be superfluous to another group of people. The current application that we have does not offer this capability, but certainly could, and it could do it while keeping RBAC trimming in mind as well. So although FIM offers a cool feature here, it is not something that is beyond the reach of extending the current application and doing it in a much easier to use web-based user portal that could exert some RBAC trimming.
Section 3: Password Reset Utility
Okay, so when I saw this in the lab outline my first though was "oh please... this is already being done", then I got into it... The lab assumes that the user forgets their password at the login screen and needs to reset it. The utility works essentially the same as any other password reset utility that you encounter on the web for any secure site, but most like banking sites. The lab first walks through the process of the user setting up the utility by picking specific questions and providing answers. It then walks you through as an admin to view the workflow that is actually associated with, or generates the utility program. Finally we log out of the system and run the utility from the log in prompt. Very cool! The user is able to reset their own password without any request for intervention. This could be a handy tool.
The current application does not have this exact feature, and even though it could easily enough, if there is not a way to place a link or call to the reset utility on the welcome/logon screen, it is a mute point. The only question/issue I have with this again goes back to software requirements. Is this something that can be done on WinXP or is it strictly Vista+.
Summary
Overall, my impressions from this lab left me with more questions than an feeling to be drawn to FIM 2010. However it did give me some cool ideas that I feel could easily be implemented in the web-based application that we currently use. The only thing that I do not think could be possible is a password reset from the welcome screen, and this is just because I'm not familiar with the possible hooks from that part of the OS. A systems engineer may be able to help shed light on this. However with the licensing cost that I have found for FIM 2010 @ $15,000 per server and $18 per CAL, I wonder if a password reset utility is worth that when the rest can be done in the current web application at a fraction of the cost, while remaining flexible to the demands of business processes.
No comments:
Post a Comment