Microsoft Forefront Identity Manager 2010 Technical Overview Abstract This document provides a technical overview of Microsoft Forefront Identity Manager 2010 product. The document focused on core scenarios of declarative provisioning and deprovisioning, self service management of users, groups, certificate and Smart Cards, user self-service management of passwords and policy based management. The topics covered include request processing, provisioning, self-service, customizing FIM, reporting, and overview of the deployment architecture. Authors: Brad Turner, Solutions Architect, Ensynch David Lundell, Practice Director, Ensynch Joe Zamora, Senior Developer, Ensynch Chris Calderon, Senior Consultant, Ensynch Reviewers: Mark Wahl, CISA, Software Architect, Microsoft Corporation Markus Vilcinskas, Technical Writer, Microsoft Corporation Brjann Brekkan, Technical Product Manager, Microsoft Corporation
Transcript
Microsoft Forefront Identity Manager 2010 Technical Overview
Abstract
This document provides a technical overview of Microsoft Forefront Identity Manager 2010 product. The document focused on core scenarios of declarative provisioning and deprovisioning, self service management of users, groups, certificate and Smart Cards, user self-service management of passwords and policy based management. The topics covered include request processing, provisioning, self-service, customizing FIM, reporting, and overview of the deployment architecture.
Mark Wahl, CISA, Software Architect, Microsoft CorporationMarkus Vilcinskas, Technical Writer, Microsoft CorporationBrjann Brekkan, Technical Product Manager, Microsoft Corporation
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Microsoft, Active Directory, Windows, Windows Server, SQL Server, Forefront Identity Manager, SharePoint, Visual Studio and Windows XP, Windows Vista, Windows 7 are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
Figure 1 FIM Component Architecture............................................................................................7Figure 2 - Synchronization Flow.....................................................................................................8Figure 3 - FIM Service responsibilities............................................................................................8Figure 4 FIM Service -- Request Pipeline.......................................................................................8Figure 5 - Workflow types...............................................................................................................9Figure 6 - FIM Synchronization Service Overview........................................................................10Figure 7 - FIM clients.................................................................................................................... 12Figure 8 - FIM Basic Deployment.................................................................................................13Figure 9 - FIM 2010 deployment with load-balanced FIM Service servers...................................14Figure 10 - Multitier topology........................................................................................................15Figure 11 - Advanced multitier topology........................................................................................16Figure 12 - Software prerequisites................................................................................................17Figure 13 Selecting Members for a Manually Managed Group.....................................................20Figure 14 Group Owner and Join Restriction................................................................................21Figure 15 User requesting to Join a Group...................................................................................21Figure 16 Manager Based Group.................................................................................................22Figure 17 Criteria-based group filter builder..................................................................................23Figure 18 - Creating a user not sourced from HR.........................................................................24Figure 19 End User experience....................................................................................................25Figure 20 Updating User profile....................................................................................................26Figure 21 Joining a Group through the Portal...............................................................................27Figure 22 Joining a group through the Outlook Client...................................................................27Figure 23 View user's own requests.............................................................................................28Figure 24 Approving requests.......................................................................................................28Figure 26 FIM Password Reset Client through login screen.........................................................30Figure 27 FIM Password Reset answering questions...................................................................31Figure 28 Password Reset AuthN Workflow Activities..................................................................32Figure 29 Lockout Gate Activity....................................................................................................32Figure 30 QA Gate Activity...........................................................................................................33Figure 31 FIM Synchronization Service.......................................................................................34Figure 32 FIM Adding the FIM Service Database to the Metadirectory Solution...........................37Figure 33 - Request object............................................................................................................38Figure 34 - FIM group types..........................................................................................................39Figure 35 - Filter builder................................................................................................................40Figure 36 – Request based MPR..................................................................................................42Figure 37 - Request and MPR relationship...................................................................................42Figure 38 - Set transition MPR......................................................................................................44Figure 40 Synchronization Rule Dynamics..................................................................................46Figure 41 Declarative Function Transformation...........................................................................46Figure 42 - FIM object visualization configuration verbs...............................................................47Figure 43 Search Scope Set Targeting........................................................................................47Figure 44 FIM Request Pipeline..................................................................................................48
4
Figure 45 FIM Detailed Status Change Process Flow.................................................................48Figure 46 FIM Extensibility Points................................................................................................49Figure 47 - RCDC verbs...............................................................................................................52
5
Document Overview
This document is intended for all Technical decision makers, including: Technical IT Managers, IT Architects, and IT Security Analysts. Decision makers are not required to have prior knowledge of Microsoft Identity Integration Server 2003, Microsoft Identity Lifecycle Manager 2007, ILM “2” (old code name for Forefront Identity Manager), or Microsoft Forefront Identity Manager 2010. This document will provide the technical decision makers a technical overview of declarative provisioning/deprovisioning, self-service management of users (and users managing their passwords), groups, certificate and Smart Cards, as well as the policy-based management capabilities provided by Forefront Identity Manager 2010.
6
Components of Forefront Identity Manager Architecture
This section focuses on the fundamental aspects of the architecture necessary for the management of identity and comprises the basic request management process that FIM provides.
Forefront Identity Manager consists of the following components grouped as show below in Figure 1 FIM Component Architecture.
Figure 1 FIM Component Architecture
IDM PlatformTogether the FIM Service (shown above in Figure 1 FIM Component Architecture as FIM Web Service) and the FIM Synchronization Service form the Identity Management Platform. The FIM Service provides a request pipeline for processing requests through workflows and largely controls what happens in the 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 are code modules that reside on the FIM Synchronization Server and interface with the target systems such as AD, HR, LDAP etc).
For example, the Human Resources department (HR) updates the title of an employee following her promotion. This update is made in the HR application which writes it to the HR database which serves as an Identity Store or Connected Data Source for FIM. Then the FIM Synchronization Service runs an import through the Management Agent 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 woman’s title into a central area (the
7
Metaverse) and into staging areas for Active Directory, the ERP system, and the FIM Service. Then the Synchronization Service runs an export to the various Connected Data Sources, following which it is visible to Outlook and ERP users.
Figure 2 - Synchronization Flow
Let us further suppose that as the update to her title is exported to the FIM Service that it places her user object or resource into a set of users known as Financial Managers. This in turn triggers a Management Policy Rule, which creates instantiates an action workflow which tells FIM Synchronization Service to create a new account and sends an email to both the CFO and the user’s manager, notifying them of the creation of the new ERP user account. Then the account can be synchronized to the ERP system through the Synchronization Service.
This could also invoke yet another Management Policy Rule that updates a calculated group making this user the member of the email enabled Finance Managers group in Active Directory.
FIM ServiceThe FIM Service presents the web service request pipeline and is responsible for the items outlined in the following table:
Responsibility Description
Request ProcessingAll requests submitted to the web service endpoint are processed by the FIM Server and the built-in policy engine
Host WorkflowAll Windows Workflow Foundation (WF) 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
Figure 3 - FIM Service responsibilities
8
HRQualifying state change from HR is processed (promotion--title change)
SyncFIM Synchronization Service processes title change, staging export to FIM and AD
ADNew title shows up in AD and Outlook
WFFIM Synchronization Service exports the change in title to the FIM Service DatabaseAction workflow to create new account in ERP
SyncFIM Sync Service creates new Account in ERP
ERPA new account for the newly promoted regional finance manager is created in the ERP system
Figure 4 FIM Service -- Request Pipeline
In Figure 4 FIM Service -- Request Pipeline we see how the FIM Service process requests through its request pipeline. Requests are submitted to the FIM Service through its web service. All requests are evaluated to determine if the requestor has the permissions needed to perform the necessary action. Permissions are granted through Management Policy Rules (MPRs). MPRs can also be configured to trigger workflows.
Workflow Type Purpose Examples
AuthenticationTo ensure that the user is who he says he is. If this fails the request is denied
In the Password Reset Self-Service scenario a user must pass through a series of questions, for which they supplied the answers during a registration, in order to prove or authenticate their identity, before being allowed to reset their password.
Authorization
To allow for 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 emails to various people in related to the requestor and/or the target of the request.
E.g. Allowing users to request and update to their preferred first name, subject to a filter validation looking for profanity followed by an approval email to HR or the user’s manager or 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 email that regarding the request fulfillment.
Action workflows could also be used to perform actions outside of the FIM Service database.
E.g. The Password Self-Service Reset uses
9
W S Req uest Perm issions Evaluation
A uthenticati on (Au thN )
A uthorization(Auth Z) FIM Service D B A ction
Workflow Type Purpose Examples
an Action workflow to tell the Synchronization Service to reset the password in real time.
Figure 5 - Workflow types
All Authentication workflows must be passed before Authorization workflows commence, and they must all pass before the update to the FIM Service database will take place. Once that is complete then the action workflows are instantiated.
FIM Service DatabaseThe FIM server utilizes the Microsoft SQL Server 2008 SP 1 database engine as the primary data store for the requests, workflow, policy and objects to be managed. As requests are fulfilled, completed and retained, objects managed by policy are transformed here before being processed by the synchronization service.
FIM Synchronization ServiceThe central component necessary to synchronize data across multiple connected data sources, the synchronization service aggregates information about identities into the Metaverse and provides an agent-less method for connecting to each data source. The FIM Synchronization Service is the fulfillment mechanism, creating and maintaining identities in other systems whereas the FIM Server service enforces policy on those identities.
HRMA ADMA
person
Metaverse
useremployee
connector space
connected data source
connected data source
connector space
FIM MA
FIM Service
Figure 6 - FIM Synchronization Service Overview
Microsoft Forefront Identity Manager 2010 MetaverseThe FIM synchronization service utilizes the Microsoft 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 in order for the synchronization service to compare the current state against previous known states. The Metaverse in particular stores the aggregated state of
10
identities across all connected data sources and in this manner the synchronization service enforces convergence across multiple connected data sources.
The synchronization service is the mechanism by which identities (like an account in AD) and information about those identities (name, status, department) are exchanged through object creation mechanisms known as provisioning and attribute flow mechanisms which control the flow of data.
Identity StoresIdentity Stores or Connected Data sources are the systems that FIM manages via management Agents (MAs). Out of the box MAs exist to manage a number of systems of different types from Directory Services, Databases, Applications to file based MA’s. The latest list of MA’s is available in the Technical documentation, http://technet.microsoft.com/en-us/library/ff608275(WS.10).aspx.
FIM ClientsIn Figure 1 FIM Component Architecture several clients to the FIM Service are shown: The FIM Add-in for Outlook, the Password Reset Add-in, the Portal as well as custom clients. In addition to those shown in the figure, the FIM Sync Service and even Exchange 2007/2010 can be considered clients of the FIM Service.
In the FIM architecture a client to the FIM Service can be any one of the items listed in the following table:
Client Type Description
FIM Synchronization Service
Most requests will originate from the synchronization service itself as updates are processed from Connected Data sources.
FIM Portal UserUsers are allowed to interact with the portal directly using a web browser and, depending upon permissions, allowed to make requests, respond to approval requests, or cancel existing pending requests.
Exchange 2007/2010 and Outlook 2007 (with the FIM Add-in for Outlook)
In organizations that have deployed at least one Exchange 2007/2010 Server with the Mailbox Role and the FIM Outlook Add-in for Outlook is deployed and approval requests can be approved or rejected directly from Outlook and requests to join or leave groups can be initiated without needing to leave the Outlook experience.
NOTE: the FIM web service account’s mailbox must be hosted on the Exchange 2007/2010 server; in order to take advantage of the Outlook 2007 client the mailboxes where approval and rejection will take place must be on Exchange 2007/2010. However, notifications may be sent to mailboxes on other types of email servers including Exchange 2003 and Lotus Notes.
Password Reset Client (with the FIM Client
installed)
When the FIM Client is deployed and integrated with the Windows XP SP2, Windows Vista SP1 or Windows 7 operating system, the logon process is modified to allow anonymous (unauthenticated) users to reset their password providing they have previously registered with an Authentication process; anonymous users may also directly interact with the Password Reset portal
PowerShellThe PowerShell client can be used to export management policy rules and other object types from the FIM Service database to be imported elsewhere. E.g. promoting rules from Development to Test and Test to Production.
Custom WCF ClientsDevelopers can take advantage of the rich extensibility points by creating their own PowerShell cmdlets or custom WCF clients can be written to interact with the web service and initiate requests.
Figure 7 - FIM clients
At the very least, a client is some process that is interacting with the web service request pipeline to perform update or query on resources in the FIM Service Database.
NOTE: The FIM Client packages are supported in both x64 or x86 distributions.
FIM Certificate ManagementThe FIM Certificate Management components are the Certificate Management Database which holds the workflows and certificate information, and Certificate Management Portal, the FIM CM CA modules that get installed on the Certificate Authority Servers, and various clients that interact with the Certificate Management Portal’s underlying web service. The FIM Certificate Management Services used to be called Certificate Lifecycle Manager (CLM).
FIM extends the current capabilities of ILM 2007 by adding support for third party Certificate Authorities as well as full support for Certificate Authorities running on Windows Server 2008. For more information on Certificate and Smartcard Management, please refer to the Technical Overview of Certificate and Smart Card Management with Microsoft Identity Lifecycle Manager 2007 technical whitepaper (Microsoft, Inc).
12
FIM Topology
In order to better understand the infrastructure footprint and the prerequisites for the various components several deployment diagrams will be presented ranging from a basic deployment to an advanced multitier-system deployment.
Basic DeploymentIn this example, the basic components are deployed on three to four servers running Microsoft Windows Server® operating systems.
In this deployment we have one dedicated SQL server for the FIM Service DB. The FIM Service and Portal is installed as a stand-alone server in an NLB cluster. Additional FIM Service and Portal servers can be added to the NLB cluster when needed. The FIM Synchronization Service has its own server. In this example, the FIM Synchronization Service SQL database has been co-located with the service but it could have been installed on another SQL server as well.
Figure 8 - FIM Basic Deployment
Load balancing the FIM ServiceIn some scenarios it is expected that one FIM Service server will have more requests than other servers. As an example the FIM Synchronization Service will contact one web service during export on the FIM MA. If there are very many operations, then end users connecting to the same server will experience performance degradation.
For this reason a separate FIM Service server has been installed. It is identified by having a different name, in this example FIM-Admin. The FIM Synchronization Service and other applications will connect to this instance and the users will use FIM-User FIM Service servers.
Using different external names for FIM Service will also allow server partitioning for workflows. When a workflow instance is created the external name of the server is added to the instance. Another server with the same external name can pick up and resume hydrated workflows. This partitioning will ensure that workflows started on the FIM-Admin instance never will be processed by the FIM-User instances ensuring responsive servers used by end-users.
13
Figure 9 - FIM 2010 deployment with load-balanced FIM Service servers
Multitier TopologyThe multitier topology is the most commonly used topology. It offers the greatest flexibility. The FIM Portal, FIM Service, and databases are separated into tiers and deployed on multiple computers. This topology adds flexibility in scaling the different FIM components. For example, you can scale the FIM Portal horizontally by adding additional servers in an NLB cluster. Similarly, you can scale the FIM service by using an NLB cluster and by increasing the number of computers (nodes) in the cluster as needed.
In the multitier topology, a dedicated computer to host each SQL database (one for the FIM Service and another for the FIM Synchronization Service) is allocated. The scalability of the performance of the computers that host the SQL databases can be increased by adding or upgrading hardware, for example, by upgrading the CPUs, adding additional CPUs, increasing random access memory (RAM) or upgrading the RAM, or upgrading the hard drive configurations to increase read and write access and decrease latency.
14
Figure 10 - Multitier topology
In this configuration, the FIM Synchronization Service and its database are hosted on the same computer. However, you should be able to achieve similar performance if there is a one-gigabit dedicated network connection between the FIM Synchronization Service and its database when they are hosted on separate computers.
Multitier Topology with Multiple FIM ServicesSynchronization of data with external systems can add a considerable load to the system and run over an extended period of time. If the synchronization configuration results in triggering policies with workflows, these policies contend for resources with end-user workflows. Such issues can be pronounced with authentication workflows, such as password resets, which are done in real time with an end user waiting for the process to complete. By providing one instance of the FIM Service for end user operations and a separate portal for administrative data synchronization, you can provide better responsiveness for end-user operations.
15
Figure 11 - Advanced multitier topology
16
FIM Architecture PrerequisitesFor the latest updated prerequisites, see the Forefront Identity Manager 2010 Installation Guide (http://go.microsoft.com/fwlink/?LinkId=134023).
Server Components Standard or Enterprise editions of Windows Server 2008 x64 or Windows Server 2008 R2 .
FIM Synchronization Windows Installer 4.5
Windows PowerShell 1.0 or Windows PowerShell 2.0 if provisioning to Exchange 2010
.NET 3.5 SP1 Framework
(Optional) Exchange 2007 SP1 Management Console (Console not needed if using Exchange 2010)
FIM Synchronization SQL Server
SQL Server 2008 SP1 x64 Standard or Enterprise
FIM Service Windows Installer 4.5
PowerShell 1.0 or 2.0
.NET 3.0 Features
.NET 3.5 SP1 Framework
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 SP2
Microsoft Windows Server 2008All FIM services require x64 versions of Microsoft Windows Server 2008 or Windows Server 2008 R2 for the base operating system. Due to the requirements for .NET Framework 3.5, Server Core is not supported for the deployment of FIM.
Microsoft Active Directory Domain ServicesMicrosoft Active Directory Domain Services (AD DS) must be present in the organization in order for the server services to communicate with each other, their respective databases, as well as allow for the interaction of users for self service actions within the portal. AD DS is not a required endpoint for the synchronization service, it is only required to host access to the portal application.
Web ServerSome of the clients discussed require interaction with a web services tier in order to present an interface via a web browser. Microsoft's Internet Information Server 7.0 (IIS) 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. Internet Explorer 7.0 and newer are supported browsers.
Windows SharePoint Services 3.0 SP1 or SP2The FIM architecture uses Windows SharePoint Services 3.0 in conjunction with IIS 7 in order to host the FIM applications as native SharePoint solutions (WSP). In this manner, SharePoint provides the basic authentication, content indexing, and application hosting platform required.
Microsoft SQL Server 2008 SP1All FIM services utilize the Microsoft SQL Server 2008 SP1 x64 database engine.
.NET Framework 3.5FIM makes use of the latest in features available in the Windows .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 the write custom code as 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 builds upon a solid metadirectory synchronization platform to provide a rich policy based request framework. It is the request framework that 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.
18
FIM Feature Walkthrough
Forefront Identity Manager 2010 enables great facility with managing groups, users, resetting passwords, policy management and extensibility.
Group ManagementIdentity Manager enables administrators to manage Distribution Groups and Security Groups (whether mail enabled or not), and 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
19
Manually managed membership
Members are placed into manually managed groups by the owners of the group as shown in Figure 13 Selecting Members for a Manually Managed Group. 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 email to approve or reject the request.
Figure 13 Selecting Members for a Manually Managed Group
This depends on the Join Restriction (see Figure 14 Group Owner and Join Restriction) set on the group and then one of the owners (there can be more than one) can approve or reject the request via a simple click of the Approve or Reject buttons inside the message in Outlook 2007 (only one owner need respond). Additionally, the request could be approved in the portal itself.
20
Figure 14 Group Owner and Join Restriction
Users can also request to join groups as shown in Figure 15 User requesting to Join a Group. Such requests are automatically rejected if made for Manager based or Criteria based groups.
Figure 15 User requesting to Join a Group
21
Manager based membership
A group can also be created to automatically maintain the membership based on who reports to a particular manager. This will automatically add all of the manager’s direct reports. If a subsequent import from HR (or another authoritative data source) modifies someone’s manager they will be removed from this group and possibly placed in another group. Figure 16 Manager Based Group illustrates that the principal step is to select the manager upon which to base the group. Note that the manager is included in the group as well as his or her direct reports.
Figure 16 Manager Based Group
Indirect reports are not included nor are dotted line relationships. This also assumes that accurate, timely data is being imported and that the manager information is flowing into the manager attribute on the person.
22
Criteria-based membership
Groups based on more advanced criteria can also be created. The criteria 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 ‘Fred Flatstone’”. Figure 17 Criteria-based group filter builder shows how the Filter Builder can be used to set up these conditions.
Figure 17 Criteria-based group filter builder
Criteria based groups are one possible approach to role based access control with FIM.
23
User ManagementWhile users will typically be created based on data from HR, users can also be created through the portal. This permission can be delegated or not, to any set of users within FIM. Figure 18 -Creating a user not sourced from HR shows the first screen in this process.
Figure 18 - Creating a user not sourced from HR
24
End User ExperienceWith FIM the End User has a whole new experience, the ability to edit their own profile, request membership in groups, approve/reject requests and reset passwords.
When end-users login in to the portal they will see something similar to Figure 19 End Userexperience.
Figure 19 End User experience
25
Self-Service User Profile ManagementUsers can also be delegated the permission to update some of their own data as shown below in Figure 20 Updating User profile. 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 manager or HR.
Figure 20 Updating User profile
Requesting membership in groupsUsers can request membership in groups through the FIM Portal as shown in Figure 21 Joining aGroup through the Portal or through the Outlook client as displayed in Figure 22 Joining a groupthrough the Outlook Client.
26
Figure 21 Joining a Group through the Portal
With the FIM Outlook Addin installed users don’t have to access the portal in order to join and leave distribution lists.
Figure 22 Joining a group through the Outlook Client
Managing RequestsEnd Users can view the status of their own requests to see its current state.
27
Figure 23 View user's own requests
End users can also approve or reject requests that are sent to them for approval. Requests are sent to them through email and if using Outlook 2007 or later and Exchange 2007 or later, requests can be approved or rejected right from within the email. Additionally, requests for approval can be dealt with through the portal as shown here with Figure 24 Approving requests or from Outlook as show in Figure 25 - Approving request from Outlook.
Figure 24 Approving requests
28
Figure 25 - Approving request from Outlook
Self-Service Password ResetAfter 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 and hence the ability to reset their passwords by answering some or all of the questions answered during registration.
The FIM Password Reset Addin is integrated with the Windows login screen as see in Figure 26FIM Password Reset Client through login screen.
29
Figure 26 FIM Password Reset Client through login screen
After clicking on the Reset password link the user answers questions like in Figure 27 FIMPassword Reset answering questions
30
Figure 27 FIM Password Reset answering questions
Administrators can determine how password reset is going to work by modifying the Password Reset AuthN Workflow. There are three activities in the workflow shown in Figure 28 PasswordReset AuthN Workflow Activities: Password Authentication Challenge, Lockout Gate, and the QA Gate. The Password Authentication Challenge is only used during the registration process to ensure that someone doesn’t walk to a temporarily unoccupied but logged in computer and register to be able to change that user’s password in the future.
The Lockout Gate as shown in Figure 29 Lockout Gate Activity prevents denial of service attacks by limiting how many times someone can attempt to answer the password reset questions incorrectly.
Figure 29 Lockout Gate Activity
With the QA Gate activity the administrator can determine the list of questions and how many questions will be presented during the registration process, as well as how many questions will be presented during the reset process and how many have to be answered correctly to permit the user to reset their password, as shown in Figure 30 QA Gate Activity.
32
Figure 30 QA Gate Activity
Careful thought and consideration should go into developing questions that balance security and ease of use – questions that have definitive answers, don’t change, can’t be researched easily and are relevant to your users.
A question with definitive answers, like the last name of your first grade teacher are important so that during reset the user doesn’t wonder whether they registered with last name, first name or full name of their first grade teacher.
For security sake it is crucial to select questions that can’t be researched easily by Binging for the information (like your home address) or questions that are easy to guess based on statistics like the name of your first dog (it is possible that in some regions Rex or Fido may be the name of 20% of dogs).
Irrelevant questions force your users to make up answers to your users. For example if you have a question like “first name of your prom date” for users in Japan, they may not know what prom is much less have attended it. In order to avoid forcing users to answer irrelevant questions you can 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 during registration, allowing them to skip irrelevant questions.
A careful balance between security and ease of use must also be struck. Will your users complain if required to answer fifteen questions? Will the Chief Information Security complain if users only have to answer 2 questions?
If you want to have users answer at least one question each from different banks of questions you can setup multiple QA gate activities with each one containing the bank of questions.
After the user answers the questions in order to reset their password The Forefront Identity Manager Service makes a real-time WMI request to the FIM Synchronization Service in order to complete the password reset.
33
Key Concepts for FIM Synchronization Service
Figure 31 FIM Synchronization Service
Following in the footsteps of MIIS and ILM 2007 the synchronization service in FIM continues to provide the platform for connecting to data sources, synchronizing data between them, 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 synchronization service; the application of policy will be discussed immediately after this one.
Management AgentWhile 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; rather they are installed on the FIM Synchronization Service server. Hence 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 require agents .
The MA provides the agentless ability to converse using remote system protocols instead of relying on the deployment of specialized agents. This translates to decreased risk and deployment times, especially when dealing with critical applications and systems.
In the figure above, the Management Agent (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 the need to understand how to connect to each system natively when using rules extensions
34
to customize data transformations. Imports and exports only occur when scheduled allowing for further insulation from changes occurring within the system as changes do not automatically propagate to the connected data source. In addition, developers may also create their own management agents for connecting to virtually any data source these are called eXtensible Management Agents (XMAs).
Attribute FlowIn the figure above, attribute flow is depicted using the 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 executed.
Connector SpaceIn the figure above, the connector space (CS) is depicted as the outer ring of the diagram. Each connected data source (CD) is represented as a filtered subset of the objects and attributes in the CS. 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 management 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. It is the CS that insulates the CD from changes propagating automatically by requiring that the MA schedule imports and exports; this added insurance allows for peace of mind while testing, previewing or confirming the next update.
The synchronization service also contains a very valuable ability to preview changes and perform simple “what if” scenarios. Using the preview ability in conjunction with Visual Studio allows developers to debug their custom extensions line by line, object by object to isolate and identify issues without impacting any remote systems due to the insulation that the CS provides. Additionally, the statistical results of an import or a synchronization can be interrogated programmatically, providing the ability to examine how many imports have been deleted, or are about to be exported and deciding if manual intervention should be employed.
MetaverseThe Metaverse (MV), represented by the center portion of the donut in Figure 31, 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 and 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 which do not require reevaluation for each synchronization run. This means that FIM does not have to locate the
35
matching remote object each time and prevents the need for costly agents from preventing changes to attributes that would normally be responsible for correlating the objects.
When discovering new data sources that may have pre-existing objects that need to be managed, FIM utilizes a process called a join rule to evaluate potential candidates for establishing a connector with. Once the join is established this evaluation does not reoccur and normal attribute flow can occur between the remote CD, and the MV.
ProvisioningWhen an authoritative source projects a new object into the MV and either through a provisioning rules extension or a synchronization rule, a new CS object can be created in another MA representing a downstream CD. This inherently establishes a connector and attribute flow can proceed bi-directionally. Whenever a rule determines that a new CS object needs to be created it is called provisioning; however, as this operation only takes place within the CS it does not carry over into the CD until an export is performed.
The 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 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 ManagementAfter delving deeper into the Synchronization Service it is time to delve into how the FIM Service handles policy management, and how that policy management in turn drives the FIM Synchronization Service.
36
Figure 32 FIM Adding the FIM Service Database to the Metadirectory Solution
As shown in Figure 32 FIM Adding the FIM Service Database to the Metadirectory Solution, the FIM Service is connected to the 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 synchronization service to apply policy through custom .NET rules extensions, this being the classic ILM 2007 method, 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 are key concepts to understand for the application of policy and the transformation of objects in the FIM Service Database:
SchemaThe FIM Service Database contains its own extensible schema in order to 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.
37
Expiration TimeAll objects in the FIM Service database, including the requests themselves can be expired by setting an Expiration Time on the object and it is this core functionality in conjunction with the request management system and policy engine that allow for built-in reconciliation of any object type – not just identities.
FilterThe filter attribute is available on several object types but most notably groups, sets, and search scopes. Filters allow for data-driven queries to be saved up and reevaluated at runtime 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 utilize the W3C open standard XML Path (XPath) language syntax to define the query and all object references utilize the XPath syntax (//Target/EmployeeStatus). The XPath Filter dialect is a subset of the XPath 2.0 specification.
RequestsWhen a user performs a task in the FIM Portal, FIM Add-in for Outlook or exports data through the FIM MA, it is represented in form of a request object, which is used to indicate the request to perform that task. Each request object has common components that include:
Requestor – the resource that requests to perform an operation
Operation - the operation the requestor wants to perform
Target – the resource that is the target of the requested operation
Logically, a request object is an implementation of the following statement:
"The requestor attempts to perform the following operation on this target"
The following figure shows the general architecture of a request object:
Figure 33 - 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 of another user to join a group. In addition to a manual interaction, you can also configure FIM to automatically process a specific request without the need of a human interaction.
38
GroupsThe Group object type is also provided as a default object type which allows for 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 application of policy:
Group Type Description
Named (static) Groups where the membership is controlled via owner or automatic approval
Manager Derived groups which are built from direct reports of a manager
Calculated (dynamic) Groups where the membership can be determined through the use of a filter
Figure 34 - FIM group types
UsersBy default, the FIM Service Database includes a Person/User object type which provides the basis for user interaction with the application. (Person is the name of the object type and User is the object type’s display name). Once someone has a user resource in the portal they can then take advantage of the self service capabilities of the product like password reset, group or account management.
Setting expiration times on group objects provides the foundation for reconciliation of group membership and when combined with the built-in approval mechanisms, owners can automatically extend or expire groups they own.
SetsSets 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, you can manually add resources to a Set and you can define a criteria 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 and 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:
39
Figure 35 - Filter builder
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 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 will evaluate the objects in the system automatically and add them to this set on a daily bases.
At the heart of management policies are a series of sets that define who the requestor is, what types of the objects the policy covers, and whether or not the object is transitioning between states in order for the policy to be triggered. Through the combination of filters and static membership, sets provide the building blocks necessary for which Management Policy Rules 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 RulesIn the FIM architecture, management policy rules represent the core component to implement your policy statements. Management policy rules define the proper response to a condition. FIM defines two basic types of management policy rules:
Request based management policy rules
Set Transition based management policy rules
The following sections provide more details about both management policy rule types.
40
Request based management policy rulesAs indicated by the name, a request based management policy rule (RMPR) is evaluated and applied against incoming requests to perform operations. Request based management policy rules consist of a condition and a response.
When you configure a request based management policy rule, the requestor is in the Set that want to perform an operation.
The FIM architecture defines 6 different operations a request based management policy rule can be defined for:
Create resource
Delete resource
Read resource
Add a value to a multi-valued attribute
Remove a value from a multi-valued attribute
Modify a single-valued attribute
When you define a Request based MPR, you must select at least one of these operations. The operations are always defined in the context of the requestor. 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 – the state the object satisfies before the operation and the state after the operation.
You can also express the related resources relatively to the requestor (such as the requestor’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 response to a condition in a request based management policy rule. In the FIM architecture, these operations are defined in form of workflows. At the time, when a given request based management policy rule is processed, the system might not have enough information to grant permission. In this case, you can define in your request based management policy rule 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 illustration outlines the complete architecture of a request based management policy rule:
41
Figure 36 – Request based MPR
When a new request object is created in FIM, the system queries the configured request based management policy rules for matching objects by comparing the request conditions with the configured conditions in your management request based management policy rules.
If matching request based management policy rules are located, they are applied to the queued request object.
The following illustration outlines this process:
Figure 37 - Request and MPR relationship
42
In FIM, permissions for operations must be explicitly granted. In other words, unless granted by a request based management policy rule, all operations on resources are denied. In other words, each request object requires at least one request based management policy rule that grants permission to perform the requested operation on a target.
Request based management policy rules provide a very flexible mechanism to address all 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, on what attributes and what approvals need to be obtained as part of that process. You can implement all these various requirements with related request based management policy rules.
Set transition based management policy rulesSet transition based management policy rules represent the second class of management policy rules.
The objective of set transition based management policy rules 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 FTE got hired, enable access to the corporate network to them"
In this case, the appropriate response to this Set transition is to provision a new account to Active Directory, which enables the new hire to access the corporate network.
As indicated by the name, Set transition based management policy rules are tied to a specific Set. In the FIM terminology, this Set is called transition Set.
In case of Set transitions, you have two important types that are relevant:
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 request based management policy rule and a state transition based management policy rule is the actual state of the condition. A request based management policy rule is invoked before a requested operation has been performed. The objective of the related management policy rule is to define the access policy for right response to the request, which is an answer to "how the request is handled".
In case of a set transition based management policy rule, the response is a reaction to an applied state change. When the related management policy rule is invoked, the condition has already been applied, which means the affected resources have already transitioned into or out of a transition set. In this scenario, the objective of 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 Set transition based management policy rule it is irrelevant how a state was reached; what matters is what the consequences of a state change are.
43
When you configure a Set transition based management policy rule in FIM, you have to specify the following three settings:
1. The transition Set
2. The Transition Type
3. The 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 illustration outlines the complete architecture of a Set transition based management policy rule:
Figure 38 - Set transition MPR
Set transition based management policy rules are activated by requests. When a request is processed and approved by a request based management policy rule, the FIM service also determines whether an approved request results in a state transition and whether a state transition bases management policy rule that handles the state change exists.
The following illustration outlines the relationship between a request and a set transition based management policy rule.
Figure 39 – Set transition based MPR process
44
Workflow ProcessesFIM allows for the assembling of various workflow tasks or building block activities into a Workflow Process which can be assigned collectively to a MPR to execute. By grouping WF into the three phases (AuthN, AuthZ, and Action) frequently used processes can be reused by many policies.
Workflow ActivitiesThe underlying component of the Workflow Process is an assemblage of WF activities, either from the underlying Workflow Foundation, out of the box 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 WSS which allows portal administrators to link together pre-built activities into sequential workflow processes without the need for Visual Studio or any development experience.
45
Synchronization Rules
Figure 40 Synchronization Rule Dynamics
Synchronization Rules (Synchronization Rule) provide the foundation for declarative provisioning of objects into other connected data sources without the need for legacy rules extensions. The Synchronization Rule also provide the ability to map and apply basic data transformation functions much like attribute flow mappings do in the Management Agents; however, unlike MA attribute flows, most flow definitions in
Synchronization Rule 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 using a flow definition or a custom Function can be added.
In Figure 32 - FIM 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
Figure 41 Declarative Function Transformation
Functions provide for 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 ConfigurationWhen interacting directly with the portal request processes the requestor 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 per object type and per operation as discussed in the following table:
46
Attribute Flow
Provision
Join
Synchronization Rules
(SR) provide the
foundation for
declarative provisioning
of objects into other
connected data sources
without the need for
legacy rules
Source FirstName = "JOHN
LastName = "SMITH"
Func
tion ProperCase(Firstname) +
" "+ProperCase(LastName) Destin
ation displayName = "John
Smith"
Verb Description
CreateControls the user experience for Create operations requested through the 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
EditControls the user experience for Edit operations requested through the portal; they are similar to Create operations but may reveal additional controls not present during the initial creation of the object
ViewControls the user experience for View operations requested through the portal; these operations appear in popup dialogs and provide a read-only view of the object
Figure 42 - FIM object visualization configuration verbs
RCDC definitions render controls that allow the user to complete the request using familiar mechanisms like radio buttons, drop down lists, and object pickers. Controls are defined by binding them to attributes and grouped onto tabs.
Search Scopes
Figure 43 Search Scope Set Targeting
Search Scopes provide a convenient union between Sets and saved queries by allowing for portal administrators to define pre-built search criteria and binding 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 illustrated in the above figure, 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. It is this framework that makes available the self-service capabilities for object management. 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 which 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.
47
Person ObjectsActive
Expire within 7 days
Figure 44 FIM Request Pipeline
Example Process Flow
In the figure above, a request from the FIM portal enters the pipeline as a WS Request and is then processed by the policy engine. The policy engine is responsible for assessing Management Policy Rules and then instantiating any assigned workflows which may affect the state of the request, the requestor's account, the target object itself, or descendent objects like manager of the requestor or target. To better understand these operations and the various components a detailed walkthrough is necessary to illustrate how an HR status change (like 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 figure below, 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 Management Policy Rules and workflows to transform the target of the web service request and then the updated object is passed back to the FIM synchronization service where the updates are processed and exported to Active Directory.
Figure 45 FIM Detailed Status Change Process Flow
48
W S Request Perm issions Evaluation
Authentication (AuthN)
Authorization(AuthZ) FIM Service DB Action
HRQualifying state change from HR is processed (terminated employee)
SyncFIM Sync Service processes status change
WFFIM Service commits the change in status to the FIM Service DatabaseAction workflows complete processing of the object to disable the account
SyncFIM Sync processes the updated Person object disabled status
ADThe account belonging to the terminated employe is disabled in Active Direcory
Policy Engine
Customizing and Extending FIMThe 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 following extensibility points:
Figure 46
FIM Extensibility Points
Extensible Management Agents (XMAs)
XMAs can be built in .NET using interfaces provided in order to manage new systems for which there aren’t out of the box MAs. With this capability, FIM can be extended to manage just about any system.
XMAs are created following well established patterns and by implementing published interfaces. XMAs can communicate directly with connected data sources using their API’s or via files making use of file import and export mechanisms available in the directory or application being managed.
49
The FIM Identity
Management portal
provides the basis for request
generation, approval
gathering and lifecycle
management right out of
the box.
FIM
Workflow
Request Framework
Web Services
SchemaRules Extensions
Extensible Management
Agents
Portal
Rules Extensions
In FIM as in prior versions the ability exists to write .NET code to program sophisticated business rules into the Synchronization Service. The need to use rules extensions had been greatly diminished because of declarative provisioning.
Extending FIM through Workflows
FIM comes with several standard workflow building blocks (activities) pre-packaged. For example, there are activities for e-mail notifications, codeless attribute manipulation, approvals that require human interaction, etc. 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 brings to the table is that the request processing is built on Windows Workflow Foundation. Workflow Foundation is a very intuitive and powerful tool that developers may leverage to extend the capabilities of FIM. For starters, Workflow Foundation 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 flowchart, 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 ask the user to authenticate by picking three points on an image instead of the standard question-answer gate. A custom authorization workflow might require a SmartCard as an added layer of security. A custom action workflow might edit an attribute on the requestor's object whenever the requestor creates a new user 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 portal.
Extending the Request Framework
The FIM Identity Management portal provides the basis for request generation, approval gathering and lifecycle management right out of the box. The product allows for easy extension of this framework allowing customers to develop specialized object lifecycle management beyond the scope of just identity. Consider the following:
Any object that can be expressed in the portal can have its lifecycle 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)
50
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 extensions of the FIM web service is necessary, only that the client interact 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:
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
Attribute Flexibility – attributes may be created and bound to multiple object types and Regular Expression validation rules can be applied to enforce consistency.
Security – both object creation and attribute manipulation may be delegated via policy and controlled via flexible sets of objects as well as relationships often difficult to model in pure RBAC scenarios like “delegate the right to modify this attribute if the requestor is the target’s manager”.
Extending the FIM Identity Management Portal
The FIM Portal user interface is extended through the Resource Control Display Configurations (RCDC). The RCDC is closely connected with the schema as its intent is to allow the administrator 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
Figure 42 - FIM object visualization configuration verbsBy customizing the RCDC configuration for say, the creation of a user, the administrator can tailor the request process to better suit the business requirements at hand.
RCDC Verb Type Purpose
CreateDetermine 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. (Typically more items are read only then they were on Create)
View Determine how the end user experience should be
51
RCDC Verb Type Purpose
presented when someone is viewing an object of this type. Viewing is always read only.
Figure 47 - RCDC verbs
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 it by
modifying the RCDC. The RCDC is an XML object, and each resource type (user, group, request,
etc) has three: 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 about to expire users can be obtained through supported WMI calls or through 3rd party solutions.
Information from the FIM Service databases about who approved what request, how and when did someone join a group, how and when did someone leave a group can be obtained in the Portal using built in search capabilities, the PowerShell client, or through web service queries (various 3rd party tools exist that help create the needed XPATH queries and return the results from simple free ones to fairly sophisticated solutions with pre-canned 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 existence of accounts, and group memberships. Resource types can be extended to contain an expiration attribute or attestation renewal time. Sets, custom Workflows and Management Policy Rules can be crafted to send out notifications requiring approvals to continue membership in groups and continue keeping accounts. Furthermore, they can be setup to evaluate on different cycles or to require attestation as a result of job title, department, or location change. Indeed several 3 rd parties have already extended FIM in this fashion.
Role Based Access Control (RBAC)
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 etc, 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.
52
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 the resource type of set can function as a role. Some may choose to build their roles by using groups. Other may choose to extend the FIM Portal and Service to have even more sophisticated Role resource types. The bottom line is that FIM can implement RBAC with out of the box functionality through Sets and Groups which is what several of the FIM partners already have done.
53
Summary
FIM 2010 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 don’t come through HR (or won’t 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 provides workflows and experiences to support the creation and management of X.509 certificates.
From the eXtensible Management Agents (XMA’s) 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 box for small organizations, providing a very reasonable footprint, but can also scale out to multiple tiers with multiple boxes in each tier if performance or high availability targets require it.
By building on the .NET Framework and Languages, especially Windows Communication Framework (WCF), and Windows Workflow Foundation (WWF), 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 the administrators and reduces the need for developers to maintain the system.
54
Additional Resources See FIM product page for more general information and more links to resources at
http://www.microsoft.com/FIM
Visit the main FIM TechNet page for Forefront Identity Manager 2010 IT Pro Documentation
Visit the FIM 2010 web forum on Microsoft TechNet at http://social.technet.microsoft.com/Forums/en-US/ilm2/threads
This forum is very active and there are a number of resources available as part of the forum. For example the ScriptBox is a collection of scripts and tools that can help in deployments.
![Civic Reception House Nagoya EntranceTechnical Tour2 Technical Tour3 Technical Tour4 Technical Tour5 [12] Technical Tour6 Technical Tour7 Technical Tour8 Technical Tour9 Technical](https://static.documents.pub/doc/80x56/60511276b5492f765a3fd03c/civic-reception-house-nagoya-entrance-technical-tour2-technical-tour3-technical.jpg)
