FIM 2010 Technical Overview

Applies To: Forefront Identity Manager 2010

Abstract

This document provides a technical overview of Microsoft® Forefront® Identity Manager (FIM) 2010. The document focuses on the core scenarios of declarative provisioning and deprovisioning, self-service management of users, groups, certificates and smart cards, user self-service management of passwords, and policy-based management. The topics covered include request processing, provisioning, self-service, customizing FIM 2010, reporting, and an overview of the deployment architecture.

Document Overview

This document is intended for all technical decision makers, including technical information technology (IT) managers, IT architects, and IT security analysts. Decision makers are not required to have prior knowledge of Microsoft Identity Integration Server 2003 (MIIS 2003), Microsoft Identity Lifecycle Manager 2007 (ILM 2007), or FIM. Technical decision makers will get a technical overview of declarative provisioning and deprovisioning, self-service management of users (and users managing their passwords), groups, certificates, and smart cards, as well as the policy-based management capabilities provided by FIM.

Components of Forefront Identity Manager Architecture

This section focuses on the fundamental aspects of the architecture necessary for you to know to manage identity and comprises the basic request management process that FIM provides.

FIM consists of the following components, grouped as shown in the following figure.

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.

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.

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.

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. Note 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.

Note

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.

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.

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.

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.

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.

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 (https://go.microsoft.com/fwlink/?LinkId=134023).

Server component	Prerequisites Note 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.

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.

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.

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.

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 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.

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.

Self-service user profile management

Users can also be delegated the permission to update some of their own data as shown in the figure below. Users can either be granted permission to update some attributes of their own data outright, or policies can be configured so that changes to some attributes may require approval by a manager or by HR.

Requesting membership in groups

Users can request membership in groups through the FIM Portal as shown in the figure below, or through the Office Outlook 2007 client as displayed in the second figure below.

With the FIM Add-in for Outlook installed, users do not need to access the FIM Portal to join and leave distribution lists.

Managing requests

End users can view the status of their own requests to see the current state.

End users can also approve or reject requests that are sent to them for approval. Requests are sent to them through e-mail messages and, if using Office Outlook 2010 or Office Outlook 2007 and Exchange 2010 or Exchange 2007, requests can be approved or rejected right from within the e-mail. Additionally, requests for approval can be addressed through the FIM Portal as shown in the figure below.

Self-service password reset

After long weekends and vacations, users have a tendency to forget their passwords. FIM provides the capability for users to register for self-service password reset. This allows users to reset their passwords by answering some or all of the questions answered during registration.

The FIM password reset add-in is integrated with the Windows logon screen. The figure below shows an example logon screen from Windows Server 2008.

After clicking the Reset Password link, the user answers questions like those shown in the figure below.

You can test the password reset behavior by modifying the password reset AuthN workflow. There are three activities in the workflow shown in the figure below; password authentication challenge, lockout gate, and QA gate. The password authentication challenge is only used during the registration process to ensure that someone does not use a temporarily unoccupied but logged-on computer and register to be able to change that logged-on user’s password in the future.

The lockout gate as shown in the figure below prevents denial of service attacks by limiting how many times a user can attempt to answer the password reset questions incorrectly.

As shown in the figure below you can permit the user to reset their password through QA gate activity by determining a list of questions and how many questions are:

• Presented during the registration process

• Presented during the reset process

• Required to be answered correctly

Careful thought and consideration should go into developing questions that balance security and ease of use. These questions should have definitive answers, do not change, cannot be researched easily, and are relevant to your users.

Using questions with definitive answers, for instance, “What is the last name of your first grade teacher,” is important. With definitive answers in the self-service password reset process, the user does not wonder whether they registered with last name, first name, or full name of their first grade teacher.

For security, it is crucial to select questions that cannot be researched easily by searching for the information (like your home address) or questions that are easy to guess based on statistics such as common dog names. If the name of the user’s first dog is a common dog name such as Rex or Fido, the password may be easily guessed.

Irrelevant or culturally based questions force your users to make up answers. For example, users in other countries may not know what a prom is, much less have attended one, and will be unable to answer a question like “What is the first name of your prom date.” To avoid forcing users to answer irrelevant questions, you should have a large set of questions that users are prompted to answer during registration, but have a lower number that they are required to answer, allowing them to skip irrelevant questions.

You must also strive for a careful balance between security and ease of use. Will your users complain if required to answer 15 questions? Will the Chief of Information Security complain if users only have to answer two questions?

If you want to have users answer at least one question each from different banks of questions, you can set up multiple QA gate activities with each one containing the bank of questions.

After the user answers the questions required to reset their password, FIM password reset makes a real-time Windows Management Instrumentation (WMI) request to the FIM Synchronization Service to complete the password reset.

Key concepts for FIM Synchronization Service

FIM builds upon a solid metadirectory synchronization platform to provide a rich policy-based request framework. The request framework provides the foundation for the application of workflow, the application of policy, and the ability to provide self-service capabilities to end users. The following section introduces the concepts for metadirectory synchronization.

Building upon MIIS and ILM 2007, the FIM Synchronization Service provides the next platform for connecting to data sources, synchronizing data between data sources, as well as the provisioning and deprovisioning of identities. With the release of FIM, the Synchronization Service now operates solely as a 64-bit application offering increased performance on very large datasets. The following sections detail aspects of the FIM Synchronization Service. The application of policy will be discussed in the Customizing and Extending FIM section.

Management agent

While the code modules that are used to communicate with a connected data source are called management agents (MAs), these agents are not installed on the connected data source systems. Instead, they are installed on the computer running the FIM Synchronization Service. The FIM architecture is generally agentless, despite having components that are called management agents (the Password Change Notification Service used for password synchronization does install and require agents).

The MA provides the agentless ability to converse by using remote system protocols instead of relying on the deployment of specialized agents. This means decreased risk and deployment times, especially when dealing with critical applications and systems.

In the figure below, the MA is synonymous with the connector space but encompasses all communication with the external system (the solid double-arrow lines).

The MA is responsible for all import and export functionality to the system and frees developers from needing to understand how to connect to each system natively when using rules extensions to customize data transformations. Imports and exports only occur when scheduled, allowing for further insulation from changes occurring within the system, since changes do not automatically propagate to the connected data source. In addition, developers may also create their own MAs, called extensible management agents (XMAs), for connecting to virtually any data source.

Attribute flow

The metaverse is the consolidated view of all joined identities from neighboring connector spaces.

In the figure below, attribute flow is depicted by using dotted lines for both inbound and outbound flow.

Attribute flow is the process of copying or transforming data from one system to another and all attribute flows (inbound or outbound) are defined as part of the MA definition. Attribute flow occurs between the connector space and the metaverse bi-directionally when synchronization (full or delta) operations are scheduled to run. Attribute flow only occurs when these synchronizations are run.

Connector space

In the figure below, the connector space is depicted as the outer ring of the diagram. Each connected data source is represented as a filtered subset of the objects and attributes in the connector space. This allows the synchronization service to operate locally without the need to contact the remote system when synchronizing the objects and restricts interaction to imports and exports only. When the data source and the MA have the ability to provide a list of changes (a delta import), then the operational efficiency increases dramatically as only changes since the last polling cycle are exchanged. The connector space insulates the connected data source from changes propagating automatically by requiring that the MA schedule imports and exports. This added insurance grants you peace of mind while testing, previewing, or confirming the next update.

The FIM Synchronization Service also contains a very valuable ability to preview changes and perform simple “what if” scenarios. By using the preview ability in conjunction with Visual Studio, developers can debug their custom extensions line-by-line and object-by-object to isolate and identify issues without impacting any remote systems due to the insulation that the connector space provides. Additionally, the statistical results of an import or a synchronization can be interrogated programmatically, giving you the ability to examine how many imports have been deleted or are about to be exported and to decide if manual intervention should be employed.

Metaverse

The metaverse, represented by the center portion of the donut in Figure 27, FIM Synchronization Service, is the consolidated view of all joined identities from neighboring connector spaces. As identities are joined together and authority is assigned for various attributes through import flow mappings, the central metaverse object begins to aggregate information from multiple systems. From this object attribute flow, mappings carry information to outbound systems.

Objects are created when an authoritative system projects them into the metaverse. As soon as all connections are removed, the metaverse object is deleted. Unlike some products, objects in the metaverse cannot be edited directly. All data in the object must be contributed through attribute flow.

The metaverse maintains persistent connectors with each connector space. These connectors do not require reevaluation for each synchronization run. This means that FIM does not have to locate the matching remote object each time. This avoids the need for costly agents to prevent changes to attributes that would normally be responsible for correlating the objects.

When discovering new data sources that may have preexisting objects that need to be managed, FIM uses a process called a join rule to evaluate potential candidates with which to establish a connector. Once the join is established, this evaluation does not reoccur and normal attribute flow can occur between the remote connected data source and the metaverse.

Provisioning

When an authoritative source projects a new object into the metaverse and either through a provisioning rules extension or a synchronization rule, a new connector space object can be created in another MA representing a downstream connected data source. This inherently establishes a connector, and attribute flow can proceed bi-directionally. Whenever a rule determines that a new connector space object needs to be created, it is called provisioning. However, because this operation only takes place within the connector space, it does not carry over into the connected data source until an export is performed.

The FIM Synchronization Service continues to be the backbone of the identity management system and serves as the fulfillment mechanism for the application policy. As policies are applied, the FIM Synchronization Service is responsible for maintaining the objects in the respective systems. The following section details how the application of policy and workflow integrate with the metadirectory framework.

Key concepts for policy management

In this section, you will learn about how the FIM Service handles policy management and how that policy management, in turn, drives the FIM Synchronization Service.

As shown in the figure above, the FIM Service is connected to the FIM Synchronization Service through the FIM Web service request pipeline. This connection is provided through the FIM MA which is responsible for translating the object updates into Web service requests.

While it is possible for the FIM Synchronization Service to apply policy through the classic ILM 2007 method of custom .NET rules extensions, FIM adds additional power and flexibility through the application of its policy engine to allow for the application of policy through workflow activities. The following section discusses key concepts to understanding the application of policy and the transformation of objects in the FIM Service database.

Schema

The FIM Service database contains its own extensible schema so that it can describe object types and model the relationship between attributes and objects through bindings. New object types can be created or existing object types may be extended and customized to include company or process specific attributes. Furthermore, validation (through the application of regular expressions) rules may be applied at both the attribute and binding levels to ensure data integrity during request processing. The primary object types discussed here are requests, groups, users, sets, management policy rules, workflow processes, workflow activities, synchronization rules, functions, and search scopes.

Expiration time

All objects in the FIM Service database, including the requests themselves, can be expired by setting an expiration time on the object. It is this core functionality, in conjunction with the request management system and policy engine, that allows for built-in reconciliation of any object type and not just identities.

Filter

The filter attribute is available on several object types, but most notably on groups, sets, and search scopes. Filters allow for data-driven queries to be saved and reevaluated at run time so that when a filter is built to return all person objects that have an inactive employee status, the result set is automatically updated whenever a new object meets the search criteria. All filters in FIM use the W3C open standard XML Path (XPath) language syntax to define the query and all object references use the XPath syntax (//Target/EmployeeStatus). The XPath filter dialect is a subset of the XPath 2.0 specification.

Requests

When a user performs a task in the FIM Portal or the FIM Add-in for Outlook, or exports data through the FIM MA, it is represented in the form of a request object, which is used to indicate the request to perform that task. Each request object has common components that include the following:

• Requester – Resource that requests to perform an operation.

• Operation – Operation the requester wants to perform.

• Target – Resource that is the target of the requested operation.

Logically, a request object is an implementation of the statement, "The requestor attempts to perform the following operation on this target."

The following figure shows the general architecture of a request object.

Each request object has a status property to indicate the processing state.

Processing requests may require manual interaction to complete a request. For example, the owner of a group might be required to manually approve the request to join a group made by another user. In addition to a manual interaction, you can also configure FIM to automatically process a specific request without the need of human interaction.

Groups

The group object type is also provided as a default object type that allows FIM Portal users to participate in group self-service operations like the request and management of Active Directory distribution lists or security groups. Users can request any of the following or be restricted by the application of the policy.

FIM group types

Group type	Description
Named (static)	Groups where the membership is controlled by an owner or automatic approval
Manager	Derived groups that are built from direct reports of a manager
Calculated (dynamic)	Groups where the membership can be determined through the use of a filter

Users

By default, the FIM Service database includes a Person/User object type that provides the basis for user interaction with the application. (Person is the name of the object type. User is the object type’s display name.) Once someone has a user resource in the FIM Portal, they can then take advantage of the self-service capabilities such as password reset and group or account management.

Setting expiration times on group objects provides the foundation for the reconciliation of group membership. When combined with the built-in approval mechanisms, owners can automatically extend or expire groups that they own.

Sets

Sets provide the foundation for the policy engine to evaluate simple collections of objects or model complex transitions between states.

The membership in a set is manually managed or criteria-based. This means that you can manually add resources to a set and that you can define criterion that automatically adds resources to a set, based on a filter statement. When a resource fulfills the filter criteria, it is automatically added to the related set.

In the simplest case, a filter can be based on an attribute of a resource such as the employee type. For example, when your filter statement enables all users with an employee-type attribute value of “Contractor” to become members of a set, FIM automatically adds a user to this set when the employee type has been set to “Contractor.” The following screenshot shows an example for the related filter statement.

The criteria-based membership in a set can be based on static values of resource attributes or it can be based on dates. For example, you can define a filter statement that automatically transitions resources into a set on a specific date. Examples for date-based attributes are the Employee Start Date or the Expiration Time. The set membership is flexible enough to allow you to define filter conditions that are relative to the date values. For example, you can define a filter that is based on “x days from today.”

Sets that are based on relative dates are also known as temporal sets. Each filter statement can be based on a collection of individual statements where either all filter conditions must be met or only one of them must be met to qualify a resource for transitioning into and out of a set.

Temporal sets provide a mechanism that can fully automate the process of transitioning into or out of a set based on the passage of time. An example temporal set is defined for all groups that expire one week from today. The system evaluates the objects automatically and adds them to this set on a daily basis.

At the heart of management policies is a series of sets that defines who the requester is, what types of objects the policy covers, and whether or not the object is transitioning between states to trigger the policy.

Through the combination of filters and static membership, sets provide the building blocks necessary on which MPRs are built. Sets can be combined together to create the intersection of the result sets allowing for greater flexibility should the definition of a such concepts as user and contractor evolve over time.

Management policy rules

In the FIM architecture, MPRs represent the core component to implement your policy statements. MPRs define the proper response to a condition. FIM defines two basic types of MPRs:

1. Request-based MPR

2. Set transition–based MPR

The following sections provide more details about both types of MPRs.

Requester MPRs

As indicated by the name, a requester management policy rule (RMPR) is evaluated and applied against incoming requests to perform operations. RMPRs consist of a condition and a response.

When you configure an RMPR, the requester is in the set that needs to perform an operation.

The FIM architecture defines six different operations for which an RMPR can be defined:

1. Create resource

2. Delete resource

3. Read resource

4. Add a value to a multivalued attribute

5. Remove a value from a multivalued attribute

6. Modify a single-valued attribute

When you define an RMPR, you must select at least one of these operations. The operations are always defined in the context of the requester. Each condition requires the definition of a target. An operation that is applied to a target can result in a state transition of the target resource. To effectively characterize the target of your condition, FIM allows the configuration of two states for the policy:

1. State that the object satisfies before the operation

2. State after the operation

You can also express the related resources relative to the requester (such as the requester’s own user object, a target user's manager, or a target group's owner).

The simplest form of a response to a condition is to grant permissions to perform the requested operation. In addition to granting permissions, you can also define other operations as a response to a condition in an RMPR. In the FIM architecture, these operations are defined in the form of workflows. At the time when a given RMPR is processed, the system might not have enough information to grant permission. In this case, you can define in your RMPR additional authentication steps and authorization steps that should apply to the person performing a given request. For example, to grant permission to perform the requested operation, you might require manual interaction of a user to approve it.

The following figure shows the complete architecture of an RMPR.

When a new request object is created in FIM, the system queries the configured RMPRs for matching objects by comparing the request conditions with the configured conditions in your management RMPRs.

If matching RMPRs are located, they are applied to the queued request object.

The following figure shows this process.

In FIM, permissions for operations must be explicitly granted. In other words, unless granted by an RMPR, all operations on resources are denied. Each request object requires at least one RMPR that grants permission to perform the requested operation on a target.

RMPRs provide a very flexible mechanism to address your policy requirements. For example, you will likely have a different process when an end user creates a group from when a group administrator performs the same operation. The process can be different in terms of the type of permissions that are available and which attributes and approvals need to be obtained as part of that process. You can implement all of these various requirements with related RMPRs.

Set Transition-based management policy rules

Set Transition management policy rules (TMPRs) represent the second class of MPRs.

The objective of TMPRs is to invoke the operations that are required in case of state transition to enable the resource to function efficiently. For example, you may want to express the following business requirement:

“When a new full-time employee is hired, enable access for them to the corporate network.”

In this case, the appropriate response to this Set Transition is to provision a new account to AD DS, which enables the new hire to access the corporate network.

As indicated by the name, Set Transition management policy rules are tied to a specific set. In FIM, this set is called the transition set.

There are two relevant types of Set Transitions:

1. Transition in – when a resource becomes a member of the transition set

2. Transition out – when a resource leaves the transition set

The main logical difference between a RMPR and a TMPR is the actual state of the condition. An RMPR is invoked before a requested operation has been performed. The objective of the related MPR is to define the access policy for the right response to the request, which is an answer to “how the request is handled.”

For TMPRs, the response is a reaction to an applied state change. When the related MPR is invoked, the condition has already been applied. This means that the affected resources have already transitioned into or out of a transition set. In this scenario, the objective of the response is not to define the reaction to a requested operation, but to define the response to an applied operation. In other words, for a TMPR, it is irrelevant how a state was reached. What matters are the consequences of a state change.

When you configure a TMPR in FIM, you have to specify the following three settings:

1. Transition set

2. Transition type

3. Policy workflows

The policy workflows are definitions of the processes that need to be invoked in response to the state change. The most common use cases for state-based MPRs are granting or revoking of entitlements and provisioning and deprovisioning in external data sources.

The following figure shows the complete architecture of a TMPR.

TMPRs are activated by requests. When a request is processed and approved by an RMPR, the FIM service also determines whether an approved request results in a state transition and whether a state transition-based MPR that handles the state change exists.

The following figure shows the relationship between an RMPR and a TMPR.

Workflow processes

FIM allows for the assembling of various workflow tasks or building block activities into a workflow process, which can be assigned collectively to an MPR to run. By grouping WF into the three phases, AuthN, AuthZ, and Action, frequently used processes can be reused by many policies.

Workflow activities

The underlying component of the workflow process is an assemblage of WF activities, either from the underlying WF workflow foundation, default FIM activities, or through custom activity development. These activities provide the building blocks necessary to operate on requests.

FIM exposes its own workflow process designer in Windows SharePoint Services, which allows FIM Portal administrators to link together prebuilt activities into sequential workflow processes without the need for Visual Studio or any development experience.

Synchronization rules

Synchronization rules provide the foundation for declarative provisioning of objects into other connected data sources without the need for legacy rules extensions. Synchronization rules also provide the ability to map and apply basic data transformation functions much like attribute flow mappings do in the MAs. However, unlike MA attribute flows, most flow definitions in synchronization rules do not require rules extensions in Visual Studio. When custom transformations are required, they can be written either as WF activities that manipulate attributes on the target objects and then flow over as-is by using a flow definition, or you can add a custom function.

In the earlier figure, Adding the FIM Service database to the metadirectory solution, the synchronization rules are represented by the large yellow arrows and the absence of the orange arrows, which previously depicted attribute flow. With synchronization rules, attribute flow mappings are no longer added statically in the MA—they are dynamically defined.

Functions

Functions provide the ability to declaratively manipulate and transform data during synchronization. Flow definitions can call upon existing functions to manipulate data as it is mapped from attribute to attribute.

Resource control display configuration

When interacting directly with the FIM Portal request processes, the user is taken through a wizard-like process to make the request. The experience is controlled by a series of XML definitions called resource control display configurations (RCDC) which allow customization of the user experience for each object type and each operation as defined in the following table.

FIM object visualization configuration verbs

Verb	Description
Create	Controls the user experience for Create operations requested through the FIM Portal. Allows for a subset of attributes to be defined at creation time while hiding others that may be seen through the application of policy.
Edit	Controls the user experience for Edit operations requested through the FIM Portal. They are similar to Create operations but may reveal additional controls not present during the initial creation of the object.
View	Controls the user experience for View operations requested through the FIM Portal. These operations appear in dialog boxes and provide a read-only view of the object.

RCDC definitions render controls that allow the user to complete the request by using familiar mechanisms like option buttons, drop-down lists, and object pickers. Controls are defined by binding them to attributes and then grouping them onto tabs.

Search scopes

Search scopes provide a convenient union between sets and saved queries by allowing FIM Portal administrators to define prebuilt search criteria and bind them to RCDC controls. Search scopes can be used anywhere a search control is exposed by defining usage keywords that link the scope and control together. As shown in the figure above, search scopes can be used to save useful queries for frequent usage.

FIM provides the Web service request framework for which the application of policy through workflow becomes possible. This framework makes the self-service capabilities for object management available. The following section discusses the request management architecture.

Request management architecture

FIM extends the functionality of the traditional metadirectory synchronization scenario by providing a robust policy engine that can be customized through the FIM Portal. The interface to this policy engine is through a Web service. The FIM Web service is comprised of components that allow for the evaluation and application of policy to resources in the FIM Service database. The path that a request takes through the Web service pipeline traverses the entire request management architecture. This section will detail the key components and concepts of this architecture.

Example process flow

In the figure above, a request from the FIM Portal enters the pipeline as a Web service request and is then processed by the policy engine. The policy engine is responsible for assessing MPRs and then instantiating any assigned workflows that may affect the state of the request, the requester's account, the target object itself, or descendent objects such as the manager of the requester or target. To better understand these operations and the various components, a detailed walkthrough is necessary to show how an HR status change (such as the termination of an identity) is processed through the FIM Synchronization Service and then becomes a request to be processed in the request pipeline.

In the following figure, a change originates from HR and is processed by the FIM Synchronization Service. The status change update is then sent as a Web service request through the request pipeline to be processed by the policy engine. The policy engine applies MPRs and workflows to transform the target of the Web service request. Then, the updated object is passed back to the FIM Synchronization Service where the updates are processed and exported to AD DS.

Customizing and Extending FIM

The FIM extensibility story has grown significantly with the addition of Web services and workflows. All custom code to extend FIM must be written using Visual Studio 2008. Consider the extensibility points shown in the following figure.

Extensible management agents

Extensible management agents (XMAs) can be built with the .NET Framework by using the provided interfaces. These XMAs can be used to manage new systems for which no default MAs exist. With this capability, FIM can be extended to manage just about any system.

XMAs are created by following well-established patterns and by implementing published interfaces. XMAs can communicate directly with connected data sources using their APIs or by using files that use file import and export mechanisms available in the directory or in the application being managed.

Rules extensions

In FIM, as in prior versions, the ability exists to write .NET code to program sophisticated business rules into the FIM Synchronization Service. The need to use rules extensions had been greatly diminished because of declarative provisioning.

Extending FIM through workflows

FIM comes with several prepackaged standard workflow building blocks (activities). For example, there are activities for e-mail notifications, codeless attribute manipulation, approvals that require human interaction, and so on. While these building blocks may be suitable for most of your business requirements, FIM contains a very straightforward method through which you may incorporate more complex workflow activities.

An added benefit that FIM includes is that the request processing is built on WF. WF is a very intuitive and powerful tool that developers may use to extend the capabilities of FIM. WF is built into the .NET Framework, so custom workflows are written in the same standard languages that developers across the globe are already familiar with. Custom workflows are developed in Visual Studio, which provides a visual designer that renders the workflow in a flow chart, proving to be an invaluable tool for designing and documenting workflow process.

Custom workflows may be targeted for each of the three steps in the request processing: authentication, authorization, and action. A custom authentication workflow might prompt the user to authenticate by picking three points on an image instead of the standard QA gate. A custom authorization workflow might require a smart card as an added layer of security. A custom action workflow might edit an attribute on the requester's object whenever the requester creates a new user, thus creating a backlink (maintaining what is, in effect, denormalized data). Custom workflows may enforce internal policy at a request level or simply provide a robust mechanism to manipulate data on objects in the FIM Portal.

Extending the request framework

The FIM Portal provides the basis for request generation, approval gathering, and life-cycle management by default. The product allows for easy extension of this framework, allowing users to develop specialized object life-cycle management beyond the scope of just identity. Consider the following:

• Any object that can be expressed in the FIM Portal can have its life cycle tracked

• Reconciliation features are accessible through policy

• No custom approval mechanisms are required to interact with the approval system

Extending FIM Web services

The FIM Web services allow any application to be identity-driven. Any application that can be made to interact with the Web service can perform any Create, Read, Update, or Delete (CRUD) operation. For instance:

• SharePoint Web parts can be created to provide a custom, tailored process for object creation in a departmental portal (using Create and Put requests)

• Reporting interfaces or pages can be built to query the Web service to return historical or current attribute information for past and present workers (using Read and Enumerate requests with XPath filters)

• Self-service customization could be added to any application by interacting with the Web service (using Put and Modify requests)

• When combined with custom authentication or authorization workflows, specialized password reset solutions can be realized.

No actual extension of the FIM Web service is necessary, only that the client interacts with the Web services.

Extending the FIM Service schema

The FIM Service database has a default schema that is fully extensible. The following features are available:

1. Object Extensibility – new object types can be created to model virtually any entity, not just identities. Policy and the self-service experience can be extended to any object.

2. Attribute Flexibility – attributes may be created and bound to multiple object types and regular expression validation rules can be applied to enforce consistency.

3. Security – both object creation and attribute manipulation may be delegated by using policy and controlled through flexible sets of objects as well as relationships that are often difficult to model in pure role-based access control (RBAC) scenarios, for example, “delegate the right to modify this attribute if the requester is the target’s manager.”

Extending the FIM Portal

The FIM Portal user interface is extended through the RCDC. The RCDC is closely connected with the schema because the intent is to allow you to control how objects are created, viewed, and edited. Each object type maintains its own RCDC configuration for each of the three operation verbs (see the table, "FIM Object Visualization Configuration Verbs” in the section, Resource control display configuration).

By customizing the RCDC configuration for, say, the creation of a user, you can tailor the request process to better suit the business requirements at hand.

RCDC verb type	Purpose
Create	Determine how the end-user experience should be presented when someone is creating an object of this type.
Update	Determine how the end-user experience should be presented when someone is updating an object of this type.
View	Determine how the end-user experience should be presented when someone is viewing an object of this type. Viewing is always read-only.

If you need to change the options and the information users see in the FIM Portal when they create new users, groups (security or distribution), or edit or view these resources, you do this by modifying the RCDC. The RCDC is an XML object, and each resource type (user, group, request, and so on) has three options: Create, Edit, and View.

Reporting

Information from the FIM Synchronization database about unmatched (orphaned objects), password synchronization, recently added users, terminated users, expired users, and users that are about to expire can be obtained through supported Windows Management Instrumentation (WMI) calls or through non-Microsoft solutions.

Information from the FIM Service databases about who approved what request, how and when someone joined a group, and how and when someone left a group, can be obtained in the FIM Portal using built-in search capabilities, the Windows PowerShell client, or through Web service queries (You can use various non-Microsoft tools to help create the needed XPath queries and return the results from simple free ones to fairly sophisticated solutions with predefined reports that are hosted in SQL Server Reporting Services).

Attestation

Many organizations need to periodically attest to existing access rights and permissions. Managers and access permission owners need to confirm or attest that those rights and permissions are still needed.

FIM can be extended to provide attestation processes around the existence of accounts and group memberships. Resource types can be extended to contain an expiration attribute or attestation renewal time. Sets, custom workflows, and MPR can be crafted to send out notifications requiring approvals to continue membership in groups and continue keeping accounts. Furthermore, they can be set up to evaluate on different cycles or to require attestation as a result of job title, department, or location change. Several third party companies have already extended FIM in this fashion.

Role-based access control

Even though the word role does not appear in the FIM Portal, FIM does address role-based access control (RBAC) needs. Sets can be configured to have automatically calculated memberships based on attributes collected from the various data sources. In other words, users can be automatically placed in sets based upon their role (job code, department, job title, location, or a combination of these). Becoming a member of a set or leaving a set can trigger workflows that add or remove access within FIM and within systems managed by FIM.

Furthermore, membership in groups can be calculated based on those same attributes as well as based on membership in sets or other groups. In effect, a resource set can function as a role. Some may choose to build their roles by using groups. Others may choose to extend the FIM Portal and FIM Service to have even more sophisticated role resource types. The bottom line is that FIM can implement RBAC with default functionality through sets and groups.

Summary

FIM provides a configurable, extensible, self-service portal for password resets, profile management, and group management. With FIM, organizations can empower their users to update their contact info, request the automated creation of users who do not come through HR (or will not come until it is too late), request membership in groups (security and distribution), and if they have been delegated the permission, create and manage their own groups and distribution lists.

FIM also continues to provide workflows to support the creation and management of X.509 certificates.

From the XMAs created to manage new systems to the schema customizations and portal configurations and the ability to create custom workflows and workflow activities, Microsoft has provided an almost infinitely extensible identity management solution in FIM.

FIM can be deployed on one computer for small organizations, providing a very reasonable footprint, but can also scale to multiple tiers with multiple computers in each tier, if the performance or high-availability targets require it.

By building on the .NET Framework and languages, especially Windows Communication Framework, and Windows Workflow Foundation, Microsoft has ensured that learning new proprietary languages is not necessary.

The addition of declarative provisioning increases the ease of use, diminishes the need for custom code, and, along with the encapsulation design for workflows and workflow activities, empowers administrators and reduces the need for developers to maintain the system.

Additional resources

FIM 2010 Product Site (https://go.microsoft.com/fwlink/?LinkId=187552)

FIM 2010 Web Forum (https://go.microsoft.com/fwlink/?LinkId=163230)

Technical Resources (https://go.microsoft.com/fwlink/?LinkId=187554)