After you have read our introduction article, you will have a good understanding of what exactly Identity Management is and what benefits a good implementation of an Identity Management system can have for a company. In this article, we’ll be focusing on the Identity Management system that these series of articles will be all about, which is Forefront Identity Manager 2010 which we, from now on, will be referring to as FIM 2010. The key takeaways of this article are to get a good understanding of the evolution and the architecture of FIM 2010. In addition, as we stated in the introduction article, this all based on FIM 2010 and we will cover all new features and improvement inside the R2 release in separate article.
The evolution of FIM 2010
A good method to get understanding of the capabilities of a software platform in general is to first look at its predecessors. Looking at the name, FIM 2010, you might think that it evolved from something like FIM 2009 or FIM 2008. Unfortunately, it is less obvious and a little bit more complex.
Over 10 years ago, Microsoft acquired Zoomit Via and turned that into a product called MMS (Microsoft Metadirectory Services). This product was offered for free by Microsoft with the advice to always hire Microsoft Consulting Services to do the actual implementation. Using MMS, it was possible to connect different directory services and perform a basic synchronization of objects and attributes.
The next big step was the introduction of Microsoft Identity Integration Server 2003 (MIIS). MIIS 2003 was rebuild from scratch completely. But although no original MMS source resides in MISS, MIIS was built on the ideas behind MMS. MIIS also started the support of .NET framework integration for the first time, which enabled customizations to the product using APIs.
For the next step in the evolution, Microsoft acquired a company that offered the product IdNexus. Idnexus was capable of managing X.509 certificates and smartcards. Microsoft renamed this product into Certificate Lifecycle Manager (CLM), integrated this into MIIS 2003 and thereby introducing Identity Lifecycle Manager (ILM) 2007. Therefore, ILM 2007 is actually a merge of both MIIS 2003 and CLM.
With ILM 2007, a stable synchronization engine was introduced that was also capable of managing certificates and smartcards. However, as we have learned in the introduction article, Identity Management is more than a synchronization engine. Microsoft soon realizes this and puts in a great amount of effort to build a complete platform on top of ILM 2007 to create a platform that satisfies all of today’s needs on Identity Management. To accomplish this, In 2010 Microsoft releases Forefront Identity Manager (FIM) 2010. FIM 2010 consists of the MIIS 2003 / ILM 2007 synchronization engine and additional features like, self-service portal, self-service password reset and codeless provisioning. With the introduction of FIM 2010, Microsoft also stops the support for the x86 platform as FIM 2010 is only available in a 64-bit version. So the FIM Sync Service (which we’ll talk about in a bit) can be thought of as the x64 version of the MIIS / ILM synchronization engine. With the release of FIM 2010 (and R2 being the latest release) Microsoft creates a complete Identity Management platform that not only serves the need of synchronization, but also adds great capabilities regarding self-service and many forms of extensibility.
Now that we’ve looked at the predecessors of FIM 2010 we have a clear view on how FIM 2010 evolved in the product that it is today. In the second part of this article, we will start to explore FIM 2010 by looking at the architecture, the different roles and its extensibilities.
The FIM Architecture
What better way to start explanation of the FIM 2010 architecture then by referencing the official Infrastructure Planning and Design (IPD) guide on Forefront Identity Manager 2010. Figure 2.1 below shows the complete architecture of FIM 2010, taken from version 1.0 of the Microsoft’s IPD. The full IPD can be downloaded free of charge here http://technet.microsoft.com/en-us/library/ff630889.aspx. We recommend anyone to explore the most recent IPD before implementing any Microsoft product in general. The IPD’s help clarify and streamline design processes for Microsoft infrastructure technologies, with each guide addressing a specific infrastructure technology or scenario.
Figure 2.1 FIM Synchronization Service
We will start our architecture walkthrough by explaining the part evolved from ILM 2007, the FIM Sync Service. We will continue by looking at the FIM Service and FIM Portal, which are brand new. We will finish of by talking about the different FIM Add-ins and extensions that come with FIM 2010. We will discuss the FIM Certificate Management in a high overview only because, as explained in the introduction, there is no focus on FIM certificate management in these series as we feel it is a very different subject and usually implemented separately.
FIM Synchronization Service
The FIM Synchronization Service (short FIM Service) can be considered the heart of the FIM 2010 platform. As explained before, the FIM Sync service is inherited from ILM 2007 and is basically the x64 version of the ILM 2007 Sync service. The FIM Sync Service contains a series of different components. First the FIM Sync Service database. This database is hosted on a Microsoft SQL Server instance preferable the latest which, at this point, is SQL Server 2012. The database contains all objects and attributes of the identities and also contains the management agent configurations split into different Connector Spaces and a MetaVerse (two terms that we will cover further on). Then there is the FIM Sync Service itself which is basically a Windows Service running under a (preferably Active Directory) service account that is responsible for the actual synchronization process between FIM and the different external systems. The FIM Sync Service is able to communicate with external system using a set of different Management Agents, which are also a component of the FIM Sync Service. The last component is the FIM Password Change Notification Service (PCNS), which is responsible for synchronizing password changes that occur on Active Directory to other external systems that are connected to FIM. This requires the installing of a FIM PCNS service on every domain controller in the Active Directory Forest.
Figure 2.2 FIM Synchronization Service
Before addressing the next set of components of the architecture (the FIM Service), it’s important to understand how FIM Sync is built up. We’ll do this by representing the FIM Service as Microsoft does this on TechNet, the “donut-shape”.
Figure 2.3 FIM Sync “the donut”
Figure 2.3 shows above, clearly shows how FIM Sync connects the external systems together. An external system that FIM Sync communicates with (in other words provisions) is always connected to FIM Sync using a Management Agent (MA). Let’s take Active Directory as an example here. The Active Directory Management Agent (ADMA) is used to connect to the Active Directory Forest or domain. The ADMA maintains objects and attributes of the external system inside it’s Connector Space (CS). The CS can be thought of as a snapshot of (part of) the Active Directory. Inside the ADMA you define, amongst some other details that we’ll get into later in these series, the name of the forest to connect to, the different OU’s to connect to and the objects and attributes you want to synchronize to the CS. Another example of an external system could be a HRM system. The same way as with Active Directory, the FIM Sync Service uses a Management Agent to provision objects to and from the HR Connector Space. To be able to actually synchronize objects from one external system to the other FIM needs to join objects of different Connector Spaces together to one identity that contains a merge of the attributes of all the related external systems. The FIM Sync Service does this by making use of what is called the MetaVerse. The MetaVerse is the identity store that FIM Sync uses to merge attributes of objects from different connector spaces into one identity.
The third external system that we see in figure 2.3 is the FIM Service. The FIM Service is a new component (not included in ILM 2007) and is, amongst other things, used to create extended synchronization rules and different types of workflows. Later on in this article we’ll discuss the FIM Service in more detail and we’ll see that the FIM Service is actually maintained using the FIM Portal. For now it’s enough to understand that the FIM Service is nothing more than an external system that communicates with the FIM Sync using a MA and a CS just as any other external system would.
FIM Service and FIM Portal
Now that we discussed the FIM Sync and understand, what is does in basic it’s time to take a more detailed look at the FIM Service. In the previous section, we learned that the FIM Service is actually nothing more than just another external system seen from the FIM Sync point of view. But, what exactly is the function of the FIM Service?
Figure 2.4 FIM Service
In figure 2.3 zooms in on the architecture of the FIM Service and all the other components that it can communicate with. First of all, the FIM Service uses a database which is hosted on a Microsoft SQL Server instance preferable the latest which, at this point, is SQL Server 2008 R2. The database contains all objects that the FIM Service uses which are in fact created using the FIM Portal. The most important function of the FIM Service is to actually extend the synchronization that the FIM Sync performs. The FIM Sync can be used to define very complex authorization, authentication and action workflows that, combined with Sets and Management Policies Rules, are able to run Extended Synchronization Rules that will be used by the FIM Sync during the actual synchronization. The FIM Service is one of the FIM Extensibilities that make FIM 2010 very flexible. Later on in this article, we will see that there are many more FIM Extensibilities. To be able to actually create and define all the objects, the FIM Sync uses a Graphical Interface (GUI) which is provided by default in FIM 2010. The FIM Portal is the GUI that is used to configure the FIM Portal. As can be seen in figure 2.3 the FIM Portal is based on Windows SharePoint Services (WSS). To be more precise it uses WSS 3.0 SP2. As we’ve learned the FIM Service is an external system to the FIM Sync. So does the FIM Service also contain objects like users and groups? Correct. In fact, these objects can also be maintained, even on a delegation of control basis, using the FIM portal. The FIM Portal is also the base for delivering the Self-Service options that we’ve seen earlier. The FIM Password Reset Portal, also based on WSS, is the last component that communicates with FIM Sync and is used to provide users the ability to reset passwords , which is a big part of the Self-Service strategy.
FIM Add-ins and Extensions
The next set of components in the architecture is the FIM Add-ins and its extensions as shown in figure 2.4. We’ll discuss the components that make up the Add-ins one by one in more detail. The first one is the FIM Add-in for Outlook. This is a client component that can integrate with Outlook 2007 and communicates with Exchange 2007 or 2010 using MAPI calls. Using the Add-In, end-users are able to request access to a new authorization group without even having to open the FIM Portal. Using the FIM Add-in, workflows created in the FIM Portal, can be configured to send approval e-mails to managers to let them approve or decline a specific workflow. With the FIM Add-in for Outlook manager can perform the approve or decline using a single click.
Figure 2.5 FIM Add-ins and Extensions
The second part is the FIM password and authentication client service. And the last part is the FIM Password and Authentication Extension. This extension can be used on clients using Windows XP, Vista or Windows 7. When the extension is installed an option to request a password reset is integrated in login screen of the clients operating system. The first time a user logs in after the password reset extension has been installed, the users will be prompted with some security questions that he has to answer once. In the event that he wants his password to be reset, he will be prompted with the questions for which he entered the answer earlier and is, if he answers them correctly, able to request a password reset without having to contact a helpdesk or support desk.
FIM Certificate Management
The last piece in the FIM Architecture puzzle is FIM Certificate Management (CM). We mentioned earlier that we would not be covering FIM CM in these series in detail, so we’ll quickly go through the basics. As you might recall from the beginning of this article Certificate Management was brought into ILM 2007 and also became part of FIM2010. Basically FIM CM is just another external system just like i.e. Active Directory or the FIM Service. Therefore, the FIM CM has its own Management Agent with a corresponding Connector Space. The FIM CM is used to managed user certificates and to accomplish this it communicates with Active Directory as well. Figure 2.5 shows the architecture in details.
Figure 2.6 FIM Certificate Management
FIM Extensibilities
As we mentioned earlier FIM 2010 provides extensibilities options in many areas, this is part of what FIM 2010 makes very flexible. In this section, we look at all the different extensibility areas that FIM provides. The figure below shows the FIM Architecture laid out in a way that so that the different areas are easy to point out.
Figure 2.6FIM Extensibilities
- Using PowerShell cmdlets Create, Read, Update, Delete, and Enumerate operations can be performed on the FIM Service helpful for performing imports and exports in migration scenarios. A complete guide on all the cmdlets and examples on how to use them go beyond the scope of these series but can easily be access on technet here:http://technet.microsoft.com/en-us/library/ee534906(WS.10).aspx
- The Portal, as we learned based on WSS, is the GUI that can be used to manage objects and attributes. This GUI is fully customizable when it comes to configuring who (what group) sees what (which objects and attributes) in what way (layout). Being able to modify the schema that is used by FIM Service is also part of the extensibility.
- The password reset that can be integrated on a client workstation is an example of customization on the windows platform.
- The webservices API enabled you to build your own webservice client which would for example enable you to fully replace the FIM Portal or integrate it into an existing portal.
- The schema that FIM uses can be altered as well. Using XML you are able to modify the exiting schema by adding, changing or removing existing attributes of object or even create new objects as well.
- Activities that are used to identify a user making a particular request is called a authentication workflow. These can be created using the FIM Portal
- An example of an authorization workflow is the Approval workflow that we mentioned earlier. To create new or extend existing approval workflows authorization workflows can be used.
- An example of an action workflow is adding a synchronization rule to an userobject, which in turn will be used by FIM Sync to do provisioning based on the configuration in that syncrule. Another example of an action workflow can be a notification (i.e. via e-mail).
- The last form of customization is inside the FIM Sync. As we talked about earlier FIM Sync uses management agent to communicate with other external system. Out of the box FIM 2010 contains several management agents. Using the Extensible Connectivity Management Agent (ECMA) it is possible to create your own Management Agent for a particular external system that you cannot connect with using one of the default management agents.
Default Management Agents
As we saw in the FIM Extensibilities section FIM 2010 contains several Management Agents out the box to communicate with different types of external systems. Currently FIM 2010 Update 1 comes with Management Agents for the External Systems show in table 2.1 below. This list is of course subject to change. For the most up to date list, we refer to http://technet.microsoft.com/en-us/library/ff608275(WS.10).aspx.
| Management Agent Name | Versions Supported |
| Active Directory Domain Services | Active Directory 2000, 2003, 2003 R2, 2008, 2008 R2 |
| Active Directory Lightweight Directory Services (ADLDS) | Active Directory Lightweight Directory Services (ADLDS) |
| Active Directory Global Address List (GAL) | Active Directory Global Address List (GAL) – Exchange 2000, 2003, 2007, 2010 |
| Attribute-Value Pair text file | Attribute-value pair text files |
| FIM Certificate Management | Forefront Identity Manager 2010 Certificate Management |
| Delimited text file | Delimited text files |
| Directory Services Mark-up Language (DSML) | Directory Services Markup Language (DSML) 2.0 |
| Extensible Connectivity | Any call-based or file-based data source |
| Fixed-Width text file | Fixed-width text files |
| FIM Service | Forefront Identity Manager 2010 |
| IBM DB2 Universal Database |
Support Client versions:
|
| IBM Directory Server | IBM Tivoli Directory Server 6.0 or 6.2 |
| LDAP Data Interchange Format (LDIF) | LDAP Data Interchange Format (LDIF) |
| Lotus Notes | Lotus Notes Release v6.5 or v7.0 |
| Novell eDirectory | Novell eDirectory version 8.7.3 or 8.8.5 |
| Oracle Database | Oracle Database 10g, 11g |
| SAP R/3 |
|
| Microsoft SQL Server | SQL Server 2000, 2005, 2008 |
| Sun and Netscape Directory Servers | Sun Directory Server 5.x and 6.x |
No comments:
Post a Comment