Académique Documents
Professionnel Documents
Culture Documents
This Whitepaper from Oxford Computer Group examines some of the features which can be expected from a modern Identity Management platform, and makes use of an example scenario to examine Microsofts new software: Forefront Identity Manager (FIM) 2010. In conclusion, we establish that FIM 2010 fulfills these broad requirements, and has the support of complimentary 3rd parties to further enhance the solution.
www.oxfordcomputergroup.com
Table of Contents
Introduction...................................................................................................................................................................................... 1 Identity Management and FIM 2010 ........................................................................................................................................... 1 Identity Management Some Background .......................................................................................................................... 1 Identity User ...................................................................................................................................................................... 1 Management Data Synchronization .............................................................................................................................. 2 Not all Responsibility is Defined ....................................................................................................................................... 2 Identity Management Interfaces with Business Processes .......................................................................................... 3 Context = Everything .......................................................................................................................................................... 3 Summary.................................................................................................................................................................................. 4 An Illustrative Scenario.................................................................................................................................................................. 5 Phase 1: Classic Synchronization............................................................................................................................................ 5 Phase 1 Summary .................................................................................................................................................................. 6 Phase 2: Introducing the FIM Portal ...................................................................................................................................... 6 The FIM Service..................................................................................................................................................................... 7 FIM Delivers Pre-Configured Functionality Out-of-the-Box ..................................................................................... 7 FIM has a flexible schema.................................................................................................................................................... 7 FIM provides configurable UI components .................................................................................................................... 7 FIM controls access to its data via policies .................................................................................................................... 8 Phase 2: Summary ................................................................................................................................................................. 8 Phase 3: Integrating with the Sync Engine............................................................................................................................ 9 The FIM Management Agent .............................................................................................................................................. 9 Phase 3 Summary ................................................................................................................................................................ 10 Phase 4: Process Integration ................................................................................................................................................. 10 Connecting Active Directory .......................................................................................................................................... 10 Synchronization Rules........................................................................................................................................................ 11 The FIM Service in Detail.................................................................................................................................................. 11 New components for this Phase..................................................................................................................................... 12 Phase 4 Summary ................................................................................................................................................................ 13 Phase 5: Password Management........................................................................................................................................... 13 Forgotten Password Reset ............................................................................................................................................... 13 Password Reset System Components ........................................................................................................................... 14 Password Synchronization Components ...................................................................................................................... 14 Phase 5 Summary ................................................................................................................................................................ 14 Phase 6: Certificate Management......................................................................................................................................... 15 CS Components .................................................................................................................................................................. 15 Phase 6 Summary ................................................................................................................................................................ 16
Microsoft Forefront Identity Manager 2010 A Whitepaper from OCG Can it really be this easy?....................................................................................................................................................... 16 Careful Change Management is required ..................................................................................................................... 16 Extensions will often be required ................................................................................................................................... 16 Areas where custom solutions are typically required............................................................................................... 17 System Management: Room for Improvement............................................................................................................ 17 Compatibility with/Upgrade from ILM 2007 ..................................................................................................................... 18 Conclusion ................................................................................................................................................................................. 18 For Further Information......................................................................................................................................................... 19 Appendices...................................................................................................................................................................................... 20 Appendix 1: Detailed function of the Request Processor ............................................................................................. 20 Appendix 2: Pre-Configured Functionality ........................................................................................................................ 21
Introduction
This white paper discusses Forefront Identity Manager 2010 (FIM 2010), the newest star in Microsofts identity management firmament. It examines the functionality which is to be expected from a modern Identity Management platform, and asks whether the product fulfils these promises. For Microsoft, FIM 2010 represents a major step forward. ILM 2007, and its predecessor MIIS 2003, have for several years offered very powerful data synchronization solutions which, with significant customization, have been extended into very powerful identity management solutions. FIM provides us with many more out-of-thebox identity management functions, and therefore enables the straightforward configuration of the platform without the need for such extensive customization. Some functions, such as the ability for an end-user to reset their forgotten password, are available for the first time. While code-based customization is available in FIM as it was in ILM, the majority of an implementation is expressed in the form of policy objects which are made visible in the new FIM Portal. This makes them more transparent and accessible, which is a major improvement over the rather opaque configuration definitions in ILM 2007. The purpose of this paper is to describe the features of FIM 2010, and set them in context using an example scenario. For more background information about features offered in ILM 2007, as well as the identity management concepts common to both FIM and ILM, you might like to see the whitepapers Microsoft Identity Lifecycle Manager 2007 and Provisioning with Microsoft Identity Lifecycle Manager 2007 available under http://www.oxfordcomputergroup.com/resources.aspx.
Identity User
The sales presentations used throughout the industry focus almost exclusively on the management of user accounts. However, the Identity in Identity Management does not relate exclusively to Users. While there is a logic to this, in as much as the majority of implementations involve employees, Identity Management can deal with many types of Entity (such that the word identity is sometimes written as (id)entity to make this point) including Groups, Roles, Organizational Units, Cost Centres, Customers, Suppliers, Buildings, SharePoint Sites and many others (though it is rare that all of these are present in a single system). So, broadly, we are in the business of managing the data concerning many different objects of interest to the enterprise as a whole. By extension, therefore, our identity management system has to have technical interfaces with a wide variety of systems, not limited to HR systems and NOSs, but including almost any system which is used to store business data. Requirement #1: Identity Management systems must be able to handle a variety of types of Identity, and interface with the appropriate systems for this purpose.
Page 1
There is responsibility to manage requests for contractors, responsibility to manage contracts for contractors what is missing is responsibility to manage the contractors as identities in themselves. If this gap is to be filled, there are two components the establishment of responsibility (which is generally out of the scope of the identity management project) and the establishment of a system in which the contractors are to be managed. In the absence of another system, the identity management system can offer such a platform, including a user-interface, and usually without taking on the organizational responsibility for the management of contractors. This example concerning Contractors is only one of many. Identity management depends on a variety of data for validation and normalization purposes (such as the standard name for a department, or the street address of a location) which do not necessarily have a readily identifiable or accessible source.
Page 2
Requirement #3: Identity Management systems should to be able to act as primary sources for certain Identity types, providing an appropriate user interface.
It can also deliver interconnections between existing processes: for example, the process which manages the arrival of a new employee is often connected to the process which creates their email account via a paperbased process which causes delays and can introduce data errors and inconsistencies due to multiple data entry. In contrast a simple automated solution might be as follows: The IDM system detects data in the HR system which indicates that the user has completed the HROnboarding process The IDM system creates a ticket in the helpdesk system for the creation of an email account
This solution may be slightly unambitious in reality we might want to implement automation of the email account creation as well but also realistic. Neither the HR nor the Helpdesk processes have been modified (except perhaps to remove a paper-based form-filling exercise), but the identity management system has added value by making the connection between them smoother. Requirement #4: Identity Management systems must be able to deliver process integration.
Context = Everything
The issue of context follows on from the previous point about process. Managers make decisions about whether to sign the form in front of them based on context based, in fact, on the data on the form in front of them, coupled with their understanding of the purpose of the process in which they are involved. So a request for an account in the ERP system for an individual employed on a short term contract who was previously a contractor who worked extensively for a direct competitor may be viewed differently from a request for an employee who has been in the organization for 10 years. It is the ability to evaluate context which makes the business process reliable. Of course, the situation is similar in identity management: if we are to automate business rules, we need to be able to represent context (This individual is transferring from the Chinese subsidiary into London) as well as policies based on context (Individuals transferring from overseas subsidiaries require higher-level approval than those transferring internally). Oxford Computer Group Worldwide Ltd. 2010 Page 3
Requirement #5: Identity Management systems must be able to represent business context.
Summary
We have established the following Requirements: 1. 2. 3. 4. 5. Identity Management systems must be able to handle a variety of types of Identity, and interface with the appropriate systems for this purpose Identity Management systems must offer more than simple data synchronization they must offer a central point of policy implementation Identity Management systems should to be able to act as primary sources for certain Identity types, providing an appropriate user interface Identity Management systems must be able to deliver process integration Identity Management systems must be able to represent business context
Page 4
An Illustrative Scenario
We will now consider a FIM 2010 implementation scenario in which an identity management system is constructed step by step. This provides the opportunity to examine each of the components of the FIM 2010 platform in turn.
Native Clients
Sync Manager
Server Components
FIM Sync
Sync DB
MAs
Identity Stores
HR
Telephone System
ADLDS
The synchronization engine, making use of its SQL Server-based storage (the SyncDB) transfers data between the three connected systems. Its Management Agents (MAs) are configured appropriately (and we wont go into detail here) so that the records in the telephone system become correctly joined with the records imported from the HR system to create the aggregation of data that is then exported to ADLDS. This type of configuration is known as Classic configuration because the synchronization rules are defined in components of the synchronization engine itself: Management Agents contain rules for the creation, joining and removal of objects, as well as the flow of attributes between the system and the SyncDB
Page 5
At least one code extension is present, to perform the provisioning into ADLDS; it is likely that each Management Agent has its own code extension to implement data transformation and validation policies
This configuration is entirely familiar to those people who have worked with Microsoft Identity Lifecycle Manager 2007 (ILM 2007): the FIM Sync engine is an enhanced version of ILM 2007, and can make use of exactly the same rule configurations. The Synchronization Service Manager (Sync Manager in the illustration above) is equally familiar to ILM 2007 users: it has been minimally updated to be compatible with the new features in FIM 2010.
Phase 1 Summary
In phase 1, we have a data synchronization system built around the FIM Synchronization Service. The rules for data handling are implemented as Management Agent configurations and in code modules. This phase demonstrates how FIM fulfils our Requirement 1: Requirement #1: Identity Management systems must be able to handle a variety of types of Identity, and interface with the appropriate systems for this purpose.
Native Clients
FIM Portal
Server Components
FIM Service
App DB
The FIM Portal application runs within a Windows SharePoint Services environment, communicating primarily with the FIM Service. The FIM Service provides the major functionality at the heart of FIM, and it is important to understand its purpose.
Page 6
Page 7
This example highlights the fact that we need to make certain that our new attributes are included in the appropriate policies, so that our HR staff can manage them.
Phase 2: Summary
Now that we have installed the portal and configured its schema, some display configuration and some policies, our HR Staff have a platform to manage external employee objects using the FIM Portal. The rules controlling access to the information concerning the external employees is controlled via policies which are also visible in the portal. Thus we fulfil the requirements of Requirement 3: Requirement #3: Identity Management systems should to be able to act as primary sources for certain Identity types, providing an appropriate user interface. Oxford Computer Group Worldwide Ltd. 2010 Page 8
Native Clients
FIM Portal
Sync Manager
Server Components
FIM Service
FIM Sync
App DB
Sync DB
MAs
Identity Stores
HR
Telephone System
ADLDS
As a result of this integration, the data in the AppDB is synchronized with the SyncDB, in both directions. This means that all the external employees are imported into the SyncDB, and also that all the internal employees are exported into the AppDB. No code or additional configuration is required to achieve this the FIM MA simply makes sure that the data in the SyncDB is the same as that in the AppDB. Now that the AppDB contains the internal employees (from the HR system) our HR staff can begin to make the connections between internal and external employees using the InternalSponsor reference attribute.
Page 9
Phase 3 Summary
We have integrated the external employees data into the identity management system, and it is being published alongside the internal employees data in our ADLDS, mixed (where appropriate) with telephone data. The AppDB now contains all internal and external employees, and the external employees are assigned an InternalSponsor.
Page 10
Microsoft Forefront Identity Manager 2010 A Whitepaper from OCG Now the system looks like this:
Native Clients
FIM Portal
Sync Manager
Server Components
FIM Service
FIM Sync
App DB
Sync DB
MAs
Identity Stores
AD/Exchange
HR
Telephone System
ADLDS
Synchronization Rules
Our Policy Statement simply says external employees will get an AD/Exchange account it contains no specifics about the technical implementation where the mailbox will be stored, what user name should be used, how passwords should be generated, which attributes in Active Directory should be imported from or exported to, and so on. These rules must, of course, be defined: this is accomplished using Synchronization Rules. It is beyond the scope of this paper to describe Sync Rules in detail: we will simply state that they are necessary definitions of our specific technical implementation. Synchronization Rules which make changes in connected systems (Outbound Sync Rules), as opposed to those which just import information from connected systems (Inbound Sync Rules), are assigned specifically to individual objects. This explicit connection between (in our case) the external employee and the Sync Rule for Exchange is made by a Workflow, and this workflow is in turn triggered by a policy. It is beginning to get complicated! To understand how the various Portal objects work together to define the business rules governing the Exchange functionality, we need to delve a little deeper into the FIM Service.
Microsoft Forefront Identity Manager 2010 A Whitepaper from OCG The functions provided by the FIM Service are best illustrated as follows:
FIM Service
App DB
Request Processor Permissions AuthN Workflow AuthZ Workflow Action Workflow
The Request Processor receives requests via Web Services, and evaluates the other components as appropriate. (A more detailed look at how this occurs can be found in Appendix 1.) For now, we simply need to identify the types of behaviour which can be configured. Permissions: define whether the request is to be accepted. If permissions are not available, the user sees Access Denied.
If the request is only to Read data, rather than to modify it, the data is simply returned (provided the permissions for this are available). No further action is undertaken by the Request Processor. The steps below therefore apply to Modify requests. In our example, the request contains the data to Add a new External Employee. Authentication (AuthN) Workflows require the user to provide some information which confirms their identity. This is used in cases where, for example, no other authentication is possible (e.g. Forgotten Password scenarios) or where the activity is sensitive enough to require additional checks. Authorization (AuthZ) Workflows are used to implement a variety of checks to ensure that the request is allowable: the easiest to understand is an approval step where another user is invited to answer Accept or Decline to a prompt (either in the portal or in Outlook). Action Workflows are used where further modifications to data are required, based on the change which has just taken place.
Having added these components, our system looks something like this:
Page 12
Native Clients
FIM Portal
Outlook
Sync Manager
Server Components
FIM Service
FIM Sync
App DB
Request Processor Permissions AuthZ Workflow Action Workflow
Sync DB
MAs
Identity Stores
AD/Exchange
HR
Telephone System
ADLDS
Phase 4 Summary
The activities in this phase show how we can define policies to recognise business context, and to provide process integration. When the system recognises that a new External Employee is to be created, it triggers appropriate workflows, requests some human decision-making and then implements the required technical steps. We fulfil therefore Requirement #4: Identity Management systems must be able to deliver process integration. and Requirement #5: Identity Management systems must be able to represent business context.
Microsoft Forefront Identity Manager 2010 A Whitepaper from OCG Using the web-based password reset portal (for example, on a locked-down kiosk machine in the office, making use of Internet Explorer and ActiveX components) When the user attempts to reset their password, they are prompted to answer a sub-set of the questions to which they have registered answers. Provided the answers match the registered answers, the user is then deemed to have authenticated themselves, and they can then set a new password for themselves Repeated incorrect attempts to answer the questions result in temporary or permanent lockout from the password reset system. Administrators can lift this lockout in the FIM Portal. Unlimited numbers of question sets can be defined, allowing configurations for different languages and different levels of assurance o
This password reset system is implemented using the same FIM policies and workflows which we have been considering above it is not a separate system. The implementation involves enabling the policies in FIM which control this process (they are pre-configured) and entering the questions to which our users will register answers. For those client machines where we want the users to be able to reset their password from the login screen, we deploy client software in the form of a .MSI package.
Phase 5 Summary
We have implemented password reset and synchronization within FIM. Now our system contains these components:
Page 14
Native Clients
FIM Portal
Windows
Outlook
Sync Manager
Server Components
FIM Service
FIM Sync
App DB
Request Processor Permissions AuthN Workflow AuthZ Workflow Action Workflow
Sync DB
MAs
Identity Stores
AD/Exchange
HR
Telephone System
ADLDS
CS Components
The Certificate Services make use of their own separate database, and this is managed using a dedicated portal. Users will access the portal to participate in the various workflows which can be used for the issue, renewal, blocking and unblocking of certificates and smartcards. Permissions governing the workflows in the CS are set directly in Active Directory So that the details of the certificates which are issued are correctly captured by the CS database, we implement an Exit Module on the Certificate Authority (CA). Process integration is realised using a Management Agent in the Synchronization Service. This allows the creation of new workflows in the CS DB, based on events in other connected systems.
Page 15
Phase 6 Summary
We have completed our implementation. The FIM solution is deployed and we have well-managed systems!
Password-handling code for systems which do not offer standardised password-handling functionality themselves, and which are therefore not supported out-of-the-box (many are). Custom Management Agents for systems not supported out-of-the-box Custom CA Exit Modules for CAs not supported out-of-the-box
All of these extensions are built in well-documented .NET assemblies, and are nothing to be afraid of: but coding expertise and experience with the FIM extensibility model will be required for successful implementation of these.
There are enhanced tools which extend the functionality offered out-of-the-box: for example, OCGs Configuration Manager does not just extract and import system configurations, it packages the configurations and provides version control so that the deployments can be integrated into a change management process with the least difficulty. There are system management issues which will need to be solved depending on policies in place at the particular client: for example, the period of time for which audit data will be retained, coupled with the amount of base data and the frequency of changes, will affect the extent to which it is necessary to provide archival services. These would move old audit data to a secondary database, so that the audit data is available, but is not present in the production database, so that performance is optimized. The building blocks for archival are present, but the solution will look different for different implementations.
Page 17
Conclusion
The innovative policy engine, coupled with the scalability and flexibility of the implementation, mean that FIM is a system which is done right. We expect that future enhancements will build on this solid foundation, continuing the integration and further development of features into the portal. Microsoft has made a bold move forward with FIM, and Oxford Computer Group is proud to be at the leading edge with this new and exciting product. Forefront Identity Manager fulfils most of the requirements for an Identity Management system. There are gaps the lack of out-of-the-box reporting is the most obvious but the product forms a very sound foundation on which to build and because FIM is built using widely-used Microsoft components, there is a wide variety of solutions to fill these gaps from companies like Oxford Computer Group, and the development of custom solutions is reasonably straightforward.
Page 18
Email: info@oxfordcomputergroup.com Web: www.oxfordcomputergroup.com UK: Bignell Park Barns, Chesterton, Oxfordshire, OX26 1TD, UK Tel: +44 (0)8456 584425 Fax: +44 (0)8456 584426 US: One Microsoft Way, Building 25, Room 1482, Redmond WA 98052, USA Tel: + 1 877 862 1617 DE: Winterlestr.10b D-85435 Erding, Deutschland Tel: +49 8122 892089-0 Fax: +49 8122 892089-99 BeNeLux: Sweelinckplein 9, (Unit 11), 2517 GK Den Haag, The Netherlands Tel: +31 (0)70 36 21 045 Fax: +31 (0)70 36 21 677
Oxford Computer Group (OCG) is a Microsoft Gold Partner specializing in Identity and Access (IAM) management consulting and training. With operations in the USA, UK and mainland Europe, OCG has an enviable repository of expertise, solution components and training courses. OCG has deployed over 500 IAM solutions and trained over 5000 people on Microsoft IAM technologies. We understand IAM benefit from our expertise and capability.
Copyright Oxford Computer Group 2010
Page 19
Appendices
Appendix 1: Detailed function of the Request Processor
The Request Processor receives requests via Web Services, and evaluates the other components as appropriate: The request processor first establishes which policies apply to the request being processed. This set of policies define the downstream tasks to be executed. This set of policies is the Applied Policies. Permissions are gathered from all Applied Policies. If each of the changes in the request is covered by at least one permission-granting policy, the request continues to be processed; if not, the request processor returns Access Denied. If the request is only to Read data, rather than to modify it, no further action is undertaken by the Request Processor. The steps below therefore apply to Modify requests. In our example, the request contains the data to Add a new External Employee. Authentication (AuthN) Workflows are triggered. Each Applied Policy can require additional authentication steps before allowing the request through. This is most commonly applied in the Password Reset workflow, where a user cannot authenticate to Windows, but rather has to answer the pre-registered questions in exactly such an Authentication Workflow. If they answer the questions correctly, they are deemed to have authenticated themselves successfully, and the password reset request continues. Authorization (AuthZ) Workflows which have been defined in the Applied Policies are triggered once all Authentication Workflows have successfully completed. These workflows are used to implement a variety of checks to ensure that the request is allowable: the easiest to understand is an approval step where another user is invited to answer Accept or Decline to a prompt (either in the portal or in Outlook). AuthZ workflows are also used to validate the submitted data, for example against an external source to check for uniqueness or other validity. We will be using an Authorization Workflow to send an email to the InternalSponsor so that they can respond Accept or Decline to the request to add the new external employee. Once the Authorization Workflows have completed successfully the request is carried out the changes are made in the AppDB. Action Workflows are then triggered. These are used where further modifications to data are required, based on the change which has just taken place. Changes can be made to: o o o o The Request which is being processed The object representing the user making the request The object which is the target of the request Additional objects used to support the synchronization and workflow system
Page 20
These changes are made in the form of a new request, which in turn might trigger additional workflows. It is common, however, that these changes are committed without the need for further authorization, since they are initiated by the system itself. We will using be an Action workflow to perform two tasks: o o to generate a random password for the new AD Account and to send this password to the InternalSponsor in an email. to add the Synchronization Rule for AD/Exchange to the external employees who have been successfully approved by an Authorization Workflow
Self-Service management of groups via My Groups Users can add themselves to groups, and modify memberships of groups where permissions are Approval workflow for changes to memberships in groups which have an Owner Automatic group memberships based on filters Forgotten Password reset portal Time-based groups
Windows-based pre-login or web kiosk-based E.g. Users who will leave the company in the next 4 weeks
It is worth pointing out that in keeping with Microsofts policy that a system must be secure in its post-installation state, most of the policies which govern this functionality are disabled, and must therefore be selectively enabled to make the functionality available.
Page 21