Overview

Forefront Identity Manager (FIM) 2010 consists of the following components, grouped as shown in the following figure.
 
 FIM component architecture

IDM platform

Together the FIM Service (shown in the previous figure as FIM Web service) and the FIM Synchronization Service form the Identity Management (IDM) platform. The FIM Service provides a request pipeline for processing requests through workflows and largely controls what happens in the FIM Synchronization Service. The FIM Synchronization Service communicates with the various identity stores or connected data sources through its adapters known as management agents. Management agents (MAs) are code modules that reside on the computer running the FIM Synchronization Service and interface with the target systems, such as Active Directory Domain Service (AD DS), human resources (HR), lightweight directory access protocol (LDAP), and others.

For example, the HR department updates the title of an employee following their promotion. This update is made in the HR application, which writes the update to the HR database serving as an identity store or connected data source for FIM. Then, the FIM Synchronization Service runs an import through the MA for the HR database. This brings the data into a staging area in the FIM Synchronization Service database. The FIM Synchronization Service then synchronizes the update to the user’s title into a central area (the metaverse) and into the staging areas for AD DS, the enterprise resource planning (ERP) system, and the FIM Service. Next, the FIM Synchronization Service runs an export to the various connected data sources. After the export is complete, the update is visible to Microsoft Office Outlook® and ERP users.

Account creation with FIM

As the update to the user’s title is exported to the FIM Service, it places their user object or resource into a set of users known as Financial Managers. This, in turn, triggers a management policy rule (MPR), which instantiates an action workflow that tells FIM Synchronization Service to create a new account and sends an e-mail message to both the chief financial officer and the user’s manager. This message notifies them of the creation of the new ERP user account. Then, the account can be synchronized to the ERP system through the FIM Synchronization Service.

This could also invoke yet another MPR that updates a calculated group, making this user a member of the e-mail–enabled Finance Managers group in AD DS.

FIM Service

The FIM Service presents the Web service request pipeline and is responsible for the items outlined in the following table:

FIM Server service responsibilities

Responsibility Description

Request processing

All requests submitted to the Web service endpoint are processed by the FIM server and the built-in policy engine.

Host workflow

All Windows Workflow Foundation (WF) workflows that are instantiated by the policy engine are hosted in the FIM server, including the ability to persist idle WF, which allows long running approval requests to be completely removed from memory.

FIM service request pipeline

In the figure above, we see how the FIM Service processes requests through its request pipeline. Requests are submitted to the FIM Service through its Web service. All requests are evaluated to determine if the requester has the permissions needed to perform the necessary action. Permissions are granted through MPRs. MPRs can also be configured to trigger workflows.

Workflow type Purpose Examples

Authentication

To ensure that the user is who they say they are. If this fails, the request is denied.

In the self-service password reset scenario, a user must pass through a series of challenge questions. The user previously supplied the answers for these questions during registration. Answering these questions correctly proves, or authenticates, the user’s identity before they can be allowed to reset their password.

Authorization

To allow for a more sophisticated validation of the request beyond simple permissions to make a request. If this fails, the request is denied.

A filter validation can automatically authorize or reject requests based on the content of the request and on sophisticated rules.

Authorization workflow could also be sending approval request e-mail messages to various people related to the requester and/or the target of the request.

For example, you can allow users to request and update to their preferred first name, subject to a filter validation check for profanity and followed by an approval e-mail message to HR, the user’s manager, or to both.

Approval workflows can be configured with escalations.

Action

To allow FIM to take actions after the request has been performed (the resource has been created, updated, or deleted in the FIM Service database).

These actions could be to update other attributes on the same object and/or resources in the FIM Service database.

They could also be to send a notification e-mail message regarding the request fulfillment.

Action workflows could also be used to perform actions outside of the FIM Service database.

For example, the self-service password reset feature uses an action workflow to tell the FIM Synchronization Service to reset the password in real time.

All authentication workflows must be passed before authorization workflows can commence, and they must all pass before the update to the FIM Service database can take place. Once that is complete, the action workflows are instantiated.

FIM Service database

The FIM server uses the Microsoft SQL Server® 2008 database engine as the primary data store for managing the requests, workflow, policy, and objects. As requests are fulfilled, completed, and retained, objects managed by policy are transformed in SQL Server before being processed by the FIM Synchronization Service.

FIM Synchronization Service

As the central component necessary to synchronize data across multiple connected data sources, the synchronization service aggregates information about identities into the metaverse and provides an agentless method for connecting to each data source. The FIM Synchronization Service is the fulfillment mechanism, creating and maintaining identities in other systems whereas the FIMServer service enforces policy on those identities.

FIM Synchronization Service overview

Forefront Identity Manager 2010 metaverse

The FIM Synchronization Service uses the SQL Server 2008 database engine to store data from connected data sources in a local copy called connector spaces. Information is brought into the connector spaces so that the synchronization service can compare the current state against previously known states. The metaverse, in particular, stores the aggregated state of identities across all connected data sources. In this way, the FIM Synchronization Service enforces convergence across multiple connected data sources.

The FIM Synchronization Service is the mechanism by which identities (such as an account in AD DS) and information about those identities (name, status, department) are exchanged through object creation mechanisms known as provisioning and attribute flow mechanisms that control the flow of data.

Identity stores

Identity stores or connected data sources are the systems that FIM manages through MAs. Default MAs manage a number of systems, as shown in the following table. The MAs range from very simple but powerful text-based files to MAs that communicate with the target system’s exposed APIs. There is also an Extensible MA that is used to connect to custom data stores.

Type of system Management agents

Network operating systems and directory services

AD DS in Windows Server® 2008 R2 and Windows Server 2008. Active Directory directory service in Windows Server 2003 R2, Windows Server 2003, and Microsoft Windows® 2000.

Active Directory Lightweight Directory Services (AD LDS) in Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2, Windows Server 2003, and Windows 2000.

Active Directory global address list (GAL) in Microsoft Exchange Server 2010, Exchange 2007, Exchange 2003, and Exchange 2000.

IBM Tivoli Directory Server version 6.2, Novell eDirectory v8.7.3 and v8.8

Sun ONE and Netscape Directory Servers 5.1 and 5.2

Certificate and smart card management

FIM Certificate Management

E-mail and messaging

Exchange 2010 and Exchange 2007. (Use Active Directory MA to provision mailboxes and mail-enabled groups.)

Lotus Notes 6.5 and 7.0 (32-bit Lotus Notes client required)

Databases

SQL Server 2008, SQL Server 2005, and SQL Server 2000

IBM DB2 Universal Database Version 9.1 and Version 9.5 (64-bit client Version 9.5 FP5 or Version 9.7 FP1 required)

Oracle Database 10g (Requires 64-bit client)

File-based

Attribute value pairs

Comma-separated values (CSV)

Delimited

Fixed width

Directory Services Markup Language (DSML) 2.0

LDAP Interchange Format (LDIF)

These file formats allow for integration with a variety of applications, databases, telephone switches, X.500 systems, mainframe, and metadirectory products or underlying systems that can produce a file for import and export.

Other

SAP R/3 Enterprise Release 4.70 and mySAP 2004 (ECC 5.0) (32-bit client)

Extensible MA for custom connectivity to other systems

In the previous table, there are version numbers of different connected data stores. These are versions that Microsoft has tested and fully support. But, in many cases, it is possible to use the MAs to connect to newer versions where needed unless the connected data store has changed too much or the APIs have been deprecated.

FIM clients

In the earlier figure, several clients to the FIM Service are shown: The FIM Add-in for Outlook, the Password Reset Add-in, and the FIM Portal as well as custom clients. In addition, the FIM Synchronization Service and Exchange 2007 can be considered clients of the FIM Service.

FIM client types

Client type Description

FIM Synchronization Service

Most requests originate from the FIM Synchronization Service itself as updates are processed from connected data sources.

FIM Portal user

Users are allowed to interact with the FIM Portal directly by using a Web browser and, depending upon permissions, allowed to make requests, respond to approval requests, or cancel existing pending requests.

Exchange 2010, Exchange 2007 and Office Outlook 2007 (with the FIM Add-in for Outlook)

In organizations that have deployed at least one server running Exchange 2010 or Exchange 2007 with the mailbox role and the FIM Add-in for Outlook deployed and where approval requests can be approved or rejected directly from Office Outlook 2007 and requests to join or leave groups can be initiated without needing to leave the Office Outlook 2007 experience.

noteNote
The FIM Web service account’s mailbox must be hosted on the Exchange 2010 or Exchange 2007 server. To take advantage of the Office Outlook 2007 client, the mailboxes where approval and rejection take place must be on Exchange 2007. However, notifications may be sent to mailboxes on other types of e-mail servers including Exchange 2003 and Lotus Notes.

 

 

Password reset extension to Windows (with the FIM client installed)

When the FIM Add-in and Extension software is deployed and integrated with the Windows client operating system, the logon process is modified to allow anonymous (unauthenticated) users to reset their password, providing that they have previously registered with an authentication process in FIM. Anonymous users may also directly interact with the password reset portal to initiate the request from a browser.

Windows PowerShell™

The Windows PowerShell client can be used to export MPRs and other object types from the FIM Service database to be imported elsewhere. For example, promoting configuration from Development to Test and Test to Production.

Custom Windows Communication Foundation (WCF) clients

Developers can take advantage of the rich extensibility points by creating their own Windows PowerShell cmdlets or by writing custom WCF clients to interact with the Web service and initiate requests.

At the very least, a client is a process that is interacting with the Web service request pipeline to perform updates or to query resources in the FIM Service database.

noteNote
When installing FIM, there are specific software packages for the Add-in for Outlook and the password reset extension in Windows called FIM Add-in and Extensions. These are supported in both x64 or x86 distributions.

 

 

FIM Certificate Management

The FIM Certificate Management (FIM CM) consists of the Certificate Management database, which holds the workflows and certificate information, the Certificate Management Portal, the FIM CM certification authority (CA) modules that are installed on the CA servers, and various clients that interact with the Certificate Management Portal’s underlying Web service. Previous versions of FIM CMservices were named Microsoft Certificate Lifecycle Manager (CLM).

FIM extends the current capabilities of ILM 2007 by adding support for non-Microsoft CAs as well as full support for CAs running on Windows Server 2008. For more information about certificate and smart-card management, see the Certificate Managementdocumentation.
 

FIM topology

So that you can better understand the infrastructure footprint, the scalability of FIM, and the prerequisites for the various components, several deployment diagrams will be presented ranging from a single-system deployment to a completely separated-out deployment.

FIM single server deployment

The FIM single-server deployment (see the figure above) is useful for lab deployments and for smaller organizations that do not have large processing needs.

Separated FIM Service from Sync Service

The deployment depicted in the figure above, is putting the new components of FIM on its own server. This allows the FIM Synchronization Service to be managed in much the same way that it was managed in ILM 2007. This also distributes some of the load and ensures that the FIM Portal is more likely to be responsive to a higher volume of users while simultaneously synchronizing.

Three-tier, load-balanced FIM topology

The approach shown previously in the figure above, shows how network load balancing or other load balancers may be used to scale out the FIM Portal as well as the FIM Service. Also worth noting is the static load balancing at the database layer with two SQL servers, one for the FIM Service database and the other for the FIM Synchronization Service database.

Two-tier, load-balanced FIM topology

In the figure above, the high-availability goal is met through SQL clustering at the database layer and load balancing the combined FIM Service-FIM Portal layer. Also, deploying a service partition of the FIM Service on the computer running the FIM Synchronization Service provides it with exclusive access. This reduces the risk of denying or throttling performance for users.

All components separated FIM topology

The figure above does not illustrate a recommended approach, but rather shows each of the components separated to help you visualize each of the individual components.
 

FIM architecture prerequisites

For the latest prerequisites, see the FIM Installation Guide (http://go.microsoft.com/fwlink/?LinkId=134023).

Server component Prerequisites
noteNote
All require the 64-bit editions of Windows Server 2008 or Windows Server 2000 R2 Standard or Enterprise

 

 

FIM Synchronization Service

Windows Installer 4.5

Windows PowerShell 1.0 or Windows PowerShell 2.0, if provisioning to Exchange 2010

Microsoft .NET Framework 3.5 Service Pack 1 (SP1)

Exchange 2007 SP1 Management Console if provisioning to Exchange 2007

FIM Synchronization SQL Server

SQL Server 2008 SP1 x64 Standard or Enterprise

FIM Service

Windows Installer 4.5

Windows PowerShell 1.0 or Windows PowerShell 2.0

.NET Framework 3.0 Features

.NET Framework 3.5 SP1

FIM Service SQL Server

SQL Server 2008 SP1 x64 Standard or Enterprise with full-text search

FIM Portal

Windows SharePoint® Services 3.0 SP1 or Service Pack 2 (SP2)

.NET Framework 3.0 features

.NET Framework 3.5 SP1

Windows SharePoint Services 3.0 Language Pack

FIM Password Reset Portal

Same as FIM Portal

Software prerequisites

Windows Server 2008 - All FIM services require the 64-bit editions of Windows Server 2008 R2 or Windows Server 2008 for the base operating system. Because of the requirements for .NET Framework 3.5, the Server Core installation of Windows Server 2008 is not supported for the deployment of FIM.

Active Directory Domain Services - AD DS must be present in the organization for the server services to communicate with each other and their respective databases, as well as to allow for the interaction of users for self-service actions within the FIM Portal. AD DS is also required to provide users access to the FIM Portal.

Web server - Some of the clients discussed require interaction with a Web services tier to present an interface through a Web browser. IIS 7.0 is required to host the Web site and services. In the FIM architecture, a Web server is not required to interact with the Web services directly, but is required if users or administrators are expected to work with the FIM Portal application. Windows Internet Explorer® 8 and Internet Explorer 7 are supported browsers.

Windows SharePoint Services 3.0 SP1 or SP2 - The FIM architecture uses Windows SharePoint Services 3.0 in conjunction with IIS 7.0 to host the FIM applications as native SharePoint solutions. In this way, Windows SharePoint Services 3.0 provides the basic authentication and application hosting platform required.

Microsoft SQL Server 2008 SP1 - All FIM services use the SQL Server 2008 SP1 64-bit database engine.

.NET Framework 3.5 - FIM makes use of the latest features available in the.NET Framework 3.5, most notably:

  • Windows Workflow Foundation – Workflow activities can be tailored to run in the FIM policy engine allowing for customization of the request processing. FIM uses the normal WF activities defining its own types: Authentication, Authorization, and Action. The encapsulation used here in the phases of the request management pipeline make it easier for IT managers to express business policy without the need to understand or write custom code. Instead, they can take advantage of workflows and workflow activities that are out of the box as well as those created by others.

  • Windows Communication Foundation – WS-* Web services are the cornerstone of the FIM policy engine.

       

FIM Feature Walkthrough

With FIM, managing groups, users, resetting passwords, policy management, and extensibility is easy.

Group management

You can use FIM to manage distribution groups and security groups (whether mail-enabled or not), regardless of scope: Universal, Global, or Domain local.

Groups can be configured with more than one owner.

The ability to create groups can be delegated to any set of users within the FIM Portal.

Membership in the groups is managed in one of three ways:

  • Manual

  • Manager

  • Criteria-based

Manually managed membership

Members are placed into manually managed groups by the owners of the group as shown in the figure below. Alternatively, users can request to join a group. The request is either granted automatically or is subject to owner approval. The owners are sent an e-mail message asking them to approve or reject the request.

Member selection for manually managed group

This depends on the join restriction (see the figure below) set on the group. One of the owners can approve or reject the request by performing a simple click of the Approve or Reject buttons inside the message in Office Outlook 2007. While there can be more than one owner, only one owner need respond to the request. Additionally, the request could be approved in the FIM Portal itself.

Group owner and joint restriction

Users can also request to join groups as shown in the figure below. Such requests are automatically rejected if made for manager-based or criteria-based groups.

User requests to join a group

Manager-based membership

A group can also be created that automatically maintains the membership based on who reports to a particular manager. This automatically adds all of the manager’s direct reports. If a subsequent import from HR (or another authoritative data source) modifies someone’s manager, they are removed from this group and possibly placed in another group. The figure below illustrates that the principal step is to select the manager upon which to base the group. The manager is included in the group as well as their direct reports.

Manager based group

Criteria-based membership

Groups based on more advanced criteria can also be created. The criterion is based on attributes and is compared with literal values provided by the group owner. So a group could be based on the following rule, Department is ‘Sales.’

Additional rules can also be included such as Department is ‘Sales’ and Manager is not ‘Terry Adams.’ The figure below shows how the filter builder can be used to set up these conditions.

Criteria-based group filter builder

Criteria-based groups are one possible approach to role based access control with FIM.

User management

While users are typically created based on data from HR, users can also be created through the FIM Portal. This permission can be delegated or not delegated to any set of users within FIM. The figure below shows the first screen in this process.

Creating a user not sourced from HR

End-user experience

With FIM, the end user has a whole new experience—the ability to edit their own profile, request membership in groups, approve and reject requests, and reset passwords.

When end users log into the FIM Portal, they see something similar to the figure below.

FIM end-user experience