In my overview of FIM 2010, I gave a brief run-down of how FIM got to where it was today. I’ve always been a bit more curious about the finer details though, so I went out and did a bit of research to produce this history of Forefront Identity Manager 2010.
Microsoft Forefront Identity Manager started life in November 1996 when a Canadian company called Zoomit released a product named VIA. VIA was originally designed as a meta-directory service which made the revolutionary step of providing directory integration services to combine meta data from a variety of sources into a unified view of identity objects, known as the Metaverse. These objects could then be accessed and controlled through a standard web browser, utilising an in-built security model, with the changes being distributed across the integrated directories.
On June 30, 1999, Zoomit Corporation was acquired by Microsoft, with 12 members of the core development team moving to Redmond to relaunch the product as Microsoft Metadirectory Services (MMS), an early version of what is now the FIM Synchronization Service, and which was only available through Microsoft Professional Services. MMS featured the same Management Agent interface, now with an Active Directory Management Agent, allowing it to connect into a variety of Microsoft and non-Microsoft directories out-of-the-box. The Metaverse was also still accessible through a stand-alone client (Compass Client), an ActiveX client, direct LDAP-compliant user agents and also through a web browser. In MMS, however, support for a number of different protocols was removed, such as its ability to act as a DHCP or DNS server, or to act as an SMTP gateway, as the product evolved to focus on the management of user identities.
On July 2, 2003, Microsoft released a stand-alone product named Microsoft Identity Integration Server (MIIS) 2003. Not to be confused with Microsoft Internet Information Services (Microsoft IIS), MIIS 2003 represented a complete re-write of the VIA product and while it was written by the same team, and incorporated many of the same features and concepts, it was completely new. The Extensible Management Agent (XMA) and provisioning and data flow operations were all now extended using the .NET framework, which retired the previously-used Zscript. MIIS 2003 also introduced support for Active Directory Application Mode (ADAM), DSML 2.0 and even featured the “Identity Management Solution Accelerator” that allowed for easier creation of IAM provisioning solutions using MIIS 2003.
Worth noting is that as of MIIS 2003, access to the Metaverse was now strictly controlled through the MIIS client. The web browser and LDAP connectivity had been removed, and all data flows were now dictated by rules defining authoritative source and attribute flow precedence.
In September 2005, Microsoft acquired a company called Alacris, who had a smart cart and certificate management product known as IDNexus.
In May 2007, Microsoft rebranded and relaunched MIIS 2003 as Identity Lifecycle Manager (ILM) 2007, which now incorporated IDNexus under the name “Certificate Lifecycle Manager” and offered the ability to manage smart cards and provided credential management features to both Windows Server and 3rd party certification authorities (CAs). Minor changes and upgrades were made to the underlying synchronization service provided in MIIS 2003, but this remained mostly unchanged.
In early 2010, Microsoft again re-branded its IAM offering, this time under the name Forefront Identity Manager which we know today. The key feature in this release was the addition of a new portal that allowed codeless provisioning, user self-service, group management and a dynamic request/approval workflow engine. Outlook integration and Self Service Password Reset were also added into this release, the latter of which only available to users through domain-joined Windows machines.
In September 2011, Microsoft acquired ‘certain assets’ of BHOLD, an Identity & Access Governance (IAG) suite that competed with Omada Identity Manager in the ILM/FIM space.
In October 2012, Microsoft released FIM 2010 R2, which added BHOLD to the FIM suite and which also added an improved cross-browser password reset and registration portal, as well as various other improvements and enhancements. Through BHOLD came the ability to provide Role Based Access Control and Attestation, as well as Reporting and Analytics.
So what’s next?
In the last 15 years, we’ve seen FIM evolve from a simple metadirectory to the powerful enterprise level Identity and Access Management platform that it is today. In the short term, some hypothesise that BHOLD will be rebranded and further integrated into the FIM product and this is probably true, though it’s clear that Microsoft is looking to continue to expand its footprint in the Identity space.
With the trend towards Cloud Computing and distributed systems, Microsoft has made a bold move with its Windows Azure platform, which provides Windows Azure Active Directory to further round-out its offerings. That’s not to mention Office 365, and its hosted Exchange platform, which has signfiicantly changed the way organizations manage their e-mail services. Both of these services now have the capability to integrate with FIM 2010 via their respective connectors and Management Agents, and FIM itself is also now supported as installable in the cloud.
Active Directory Federation Services (ADFS), Microsoft’s federated identity and Single Sign-On (SSO) offering is still around, though seems to have taken a back seat with all the hype around “Cloud”. That said, it’s quite possible this product may see a resurgence once Azure Active Directory gains market share.
Personally, I’d like to see Microsoft turn its focus inward and improve upon the existing products in its suite – a more customisable user interface for the FIM Portal, a more powerful and configurable FIM Synchronization Service, greater integration between the separate products, etc. As a specialist ILM and FIM Consultant since 2008, there’s a lot of basic features that myself and others have always felt need to be added into the product if it’s really to compete with other enterprise Identity and Access Management solutions on the market. Well, here’s hoping…
“which now incorporated IDNexus under the name “Certificate Lifecycle Manager” and offered the ability to manage smart cards and act as a certificate authority for Windows 2003.”
CLM, and now FIM CM, acts as a registration authority and certificate/smart card management system. It is not now, nor has it ever been, a certification authority.
Thanks Paul – CM is actually the area I’m least knowledgable on, but what you’ve said makes complete sense when I stop to think about it. I’ve updated the text as follows:
“which now incorporated IDNexus under the name “Certificate Lifecycle Manager” and offered the ability to manage smart cards and provided credential management features to both Windows Server and 3rd party certification authorities (CAs)”
Hopefully that’s a bit more accurate.
That looks good Ross, though the pedant in me can’t help but point out that support for 3rd party CAs wasn’t actually introduced until the release of FIM CM R2. 🙂
Well, I have a few quibbles with this version, but it’s basically correct. First, version 1.0 of Zoomit VIA was released in November of 1996. Second, MMS was just a rebranded version of Zoomit VIA, the management agent interfaces you mentioned and the Compass LDAP client, browser access, and ActiveX control were all present already. The only things added were a new Active Directory MA, and a strange beast called TAMA, which stood for Together Administration Management Agent, and which was neither really Together, nor allowed Administration, and was not really a management agent per se. The acquisition and signing of the deal happened on June 30 1999, the day before the July 1st Canada Day holiday. Zoomit VIA also had some extras that were taken out before it became MMS. It could act as a DNS and DHCP server, an SMTP gateway, in fact lots of additional protocols. In those heady days, protocols were thick on the ground and we had a framework to add different protocol listeners on top of the base server. I wrote a CDDB protocol listener for it. (Because I could.)
Also, Microsoft did not just buy the product, it hired the core development team. There were twelve of us that moved to Redmond to work on the next generation.
I think the biggest faux pas is saying the MIIS 2003 was a re-packaged MMS. MIIS represents a complete re-write and re-design of the metadirectory. There is not a single line of code in MIIS that is a holdover from MMS/Zoomit VIA. It was developed by the same team (with a lot of new team members added of course), and had many of the same concepts, but it was totally new and different. From there on, it’s pretty much as you describe it.
You say you’d like a more powerful and configurable sync engine, but I’m not exactly sure what that means. It’s pretty solid, and has been since 2003. I’d like to see it multi-threaded, and there was a version of that done, but it would only work with direct flows. The way the .net hosting works in the core server for extensions is not fully re-entrant, and that’s a pretty fundamental design point that I do not expect to see Microsoft tackle anytime soon.
Cheers,
James
Thanks a lot James – your feedback is fantastic. It’s great to get some clarification from someone who’s really been there for the whole journey.
We’ll have to have a catch-up next time I’m in Brisbane and talk about the joys of being Canadians living in Australia. I definitely don’t miss the cold!
Anyway, I’ve updated the article, so hopefully it’s a bit more accurate now. If I missed anything, please let me know.
With regards to the Sync Engine, it’s mainly small things. Eg, because of the way the connector space data is stored (and I understand the reasons for it), it’s not really possible to add search criteria. I’d also like the ability to over-ride attribute precedence on initial provisioning so I can set default values when provisioning objects. Better handling of multivalue attributes and more flexibility in what you can do with object references (the latter we’ve seen start to come in with the FIM Portal). I guess it would just be neat to see what other elements could be incorporated into the Sync Engine itself. It’s been 10 years since MIIS 2003 came out, it would be interesting to see how FIM Sync would be designed if another code re-write was done today.
I’d like to learn more about the ‘odd duck” version of FIMS that ships with SharePoint — In SharePoint 2010 the light weight version of FIMs permitted us to import a management agent that provided capabilities to synch off of ADLDS ( where we use it as a attribute store to augment the SAML claims on some of our external users).. Use pulled some of that attribute data into the SharePoint user profile. Now with SharePoint 2013, the version of FIMS (still with the 2010 version) has omitted the ability import Management Agent configurations – so we are pretty well stuck and out of luck on our existing attribute store/user profile synchronization process.. SharePoint apparently does not permit the full version of FIMS to be used for user profile synch….