A Lap Around Microsoft Identity Lifecycle Manager "2"
Let me start my discussion about Microsoft Identity Lifecycle Manager "2" with a quick overview of the different major components. Realize that the way I break down ILM "2" may be different than how other people view the product. I joined the product team a couple of years ago after shipping the Windows Communication Foundation. It was natural for me to work on the new web services layer. Since then I have been immersed in the Policy Service portion of Microsoft Identity Lifecycle Manager "2" and, thus, have a view of the product that is centered on the web services as well as scenarios that consume those services. Further, this is going to be a very high level (thus, over simplified) view of the Microsoft Identity Lifecycle Manager "2" product. If I were to dive into any depth with each of these components this blog post would threaten to turn into a book. So to keep this to an appropriate length, I will be staying very high level. I will use later blog posts to dive into depths of certain portions of a few components. That disclaimer being said let me walk you around the Microsoft Identity Lifecycle Manager "2" product.
I break the Microsoft Identity Lifecycle Manager "2" product into four major components: Synchronization Engine, Certificate Lifecycle Manager, Policy Service, and client applications. The Synchronization Engine and Certificate Lifecycle Manager refer to the next versions of these components that shipped in Microsoft Identity Lifecycle Manager 2007. The Policy Service and client applications refer to brand new components shipping first with Microsoft Identity Lifecycle Manager "2". Let's look at each of these components in turn.
Synchronization Engine
The Synchronization Engine component of Microsoft Identity Lifecycle Manager "2" is the next version of the Synchronization Engine that shipped with Microsoft Identity Lifecycle Manager 2007. It was previously known as Microsoft Integrated Identity Server (MIIS). It is responsible for synchronizing, provisioning, and deprovisioning data across heterogeneous data stores. What does that mean? Well the Synchronization Engine is intended to sit between two different data stores that contain data that relates to each other and make sure that the two different stores remain synchronized when data changes in one or the other. For example, many large enterprises store their HR data in a special data store like SAP. That store maintains data related to personnel (payroll, contact information, etc). There are additional data stores in the enterprise that also maintain data about employees. Microsoft Active Directory (AD) maintains domain logon and access credentials for network users. It is desired (if not required) that the data within the HR system and the data within AD stay in sync. This is where the Synchronization Engine of Microsoft Identity Lifecycle Manager "2" comes into play.
Sitting between the Synchronization Engine and the various data stores are Management Agents (MAs). An MA knows how to transfer data between the Synchronization Engine and the data store to which it is connected and back. Enterprises then register, and configure, these MAs with a Synchronization Engine instance and schedule how frequently to run imports and exports of the data.
In addition to simply synchronizing data I mentioned the concepts of provisioning and deprovisioning data. To over simplify these concepts, this essentially refers to creating or deleting new data in a data store in response to data changes in a second data store. For example, when a new employee is added to an HR system the enterprise may need a new AD account to be created for that user. Likewise, when an employee is removed from an HR system the enterprise would want that user's AD account to be deleted as well. These examples describe basic provisioning and deprovisioning of an AD account in response to data changes in the HR data store.
Certificate Lifecycle Manager
The Certificate Lifecycle Manager (CLM) component of Microsoft Identity Lifecycle Manager "2" is the next version of CLM that shipped with Microsoft Identity Lifecycle Manager 2007. It is responsible for managing the lifecycle of certificates within an enterprise and managing the lifecycle of the relationships between those certificates and users. The CLM component includes its own web services and web portal providing the functionality for managing certificates. With enterprises relying more and more on certificates, such as smart cards, for controlling access to resources ranging from physical building access to network login managing those certificates has become critical. CLM provides enterprises the ability to issue, revoke, audit, suspend, and perform other actions on certificates. Admittedly this is a portion of the ILM "2" product with which I am least familiar.
Policy Service
The Policy Service (ILM-PS) component is brand new functionality first shipping with Microsoft Identity Lifecycle Manager "2". This is the portion of the Microsoft Identity Lifecycle Management product that I know the best (due to the fact that my code ownership for this product lies within the heart of this service). This is also the component I will be focusing on long term with this blog. For that reason, let me keep this description brief and very conceptual. The Policy Service component is responsible for managing the lifecycle of "resources" within Microsoft Identity Lifecycle Manager "2". Further, it exposes the management of these "resources" through a set of WS-STAR compliant web services. You may ask: what is a resource? Well I am glad you asked that. A resource is just a set of related data describable in a flat XML schema. Think of it as an object. In fact, you could think of a "resource" as the Microsoft Identity Lifecycle Manager "2" platform's version of System.Object.
The WS-STAR compliant web services are built on top of the Windows Communication Foundation. This allows enterprises to leverage Windows Communication Foundation knowledge in building custom client solutions on top of the Policy Service. Further, the Policy Service allows for enterprises to highly customize business processes involved with managing the lifecycle of resources. The Policy Service makes use of the Windows Workflow Foundation as its underlying orchestration engine. This, again, allows enterprises to leverage existing knowledge when customizing the Policy Service for solving custom business solutions. I know this is a very thin description of the Policy Service, which is a very complex and rich component within the Microsoft Identity Lifecycle Manager "2" product. However, it is because of that complexity and richness that I would rather provide a thin description here and dedicate an entire posting to just this component next week.
Client Applications
The client applications component includes the client experiences for the new Policy Service in Microsoft Identity Lifecycle Manager "2". This includes three different client applications: Outlook add-on, self-service password reset client, and resource management web portal. The Outlook add-on allows information workers within an enterprise to manage group membership directly from within Outlook. Users can join or leave groups themselves as well as add or remove other members from one or more groups without ever leaving Outlook. Additionally, the Outlook add-on integrates the ILM-PS approval mechanism so that users may approve or reject requests for which their approval is required from email without need for logging onto the resource management web portal. These approval request mails come into an inbox in the same way that Outlook meeting requests arrive. Just as you accept or reject a meeting request through special buttons on that email, you can approve or reject an approval request with special buttons on the email.
The password reset client is actually a set of clients; a GINA plugin client for XP clients and a cred man plugin for Vista clients. These plugins add a new button to the login screen of Windows clients that allows users to request a password reset themselves. These clients then walk the user through the authentication gates configured by an enterprise's management policy rules (more on these in a later post) to confirm their identity. Once their identity is confirmed the clients then prompt the user for a new password and interact with the ILM-PS appropriately to reset the users password according to an enterprise's password policy.
That is a (very) brief lap around the Microsoft Identity Lifecycle Manager "2" product. I hope that this has provided the basis for an understanding of the various components of the Microsoft Identity Lifecycle Management and how they interact with each other to provide the rich set of functionality offered by the product. Next, I will continue to dive deeper into the product, specifically the Policy Service, eventually working towards walking through building some custom solutions on top of the Microsoft Identity Lifecycle Manager "2" platform.
Next week: "Microsoft Identity Lifecycle Manager "2" Policy Service: A Look Behind the Curtain"