Microsoft Forefront Identity Manager 2010 R2 Handbook
上QQ阅读APP看书,第一时间看更新

FIM Service

If FIM Synchronization Service is the heart pumping information, FIM Service is the brain (sorry FIM CM, but your brain is not as impressive; I'll give you credit later).

FIM Service plays many roles in FIM, and during the design phase the capabilities of FIM Service is often on focus. FIM Service allows you to enforce the Identity Management policy within your organization and also make sure you are compliant at all times.

FIM Service has its own database, where it stores the information about the identities it manages.

Request pipeline

In order to make any changes to objects in the FIM Service database, you need to work your way through the FIM Service request pipeline. So, let's look at the following diagram and walk through the request pipeline:

Request pipeline

Every request is made to the web service interface, and follows the ensuing flow:

  1. The Request Processor workflow receives the request and evaluates the token (who?) and the request type (what?).
  2. Permission is checked to see if the request is allowed. Management Policy Rules are evaluated.
  3. If Authenticate workflow is required, serialize and run interactive workflow.
  4. If Authorize workflow is required, parallelize and run asynchronous workflow.
  5. Modify the object in FIM Service Database according to the request.
  6. If Action workflow is required, run follow-up workflows.

As you can see, a request to FIM Service may trigger three types of workflows. With the installation of FIM 2001 R2, you will get a few workflows that will cover many basic requirements, but this is one of the situations where custom coding or third-party workflows might be required in order to fulfill the identity management policy within the organization.

Authentication workflow (AuthN) is used when the request requires additional authentication. An example of this is when a user tries to reset his password—the AuthN workflow will ask the anonymous user to authenticate using the QA gateway.

Authorization workflow (AuthZ) is used when the request requires authorization from someone else. An example of this is when a user is added to a group, but the policy states that the owner of the group needs to approve the request.

Action workflow is used for many types of follow-up actions—it could be sending a notification email or modifying attributes, among many other things.

FIM Service Management Agent

FIM Service Management Agent , as we discussed earlier, is responsible for synchronizing data between FIM Service and FIM Synchronization Service. I said then that this MA is a bit special, and even from the FIM Service perspective it works a little differently.

A couple of examples of the special relationship between the FIM Service MA and FIM Service are as follows:

  • Any request made by the FIM Service MA will bypass any AuthN and AuthZ workflows
  • As a performance enhancer, the FIM Service MA is allowed to make changes directly to the FIM Service DB in FIM 2010 R2, without using the request pipeline described earlier

Management Policy Rules (MPRs)

The way we control what can be done, or what should happen, is by defining Management Policy Rules (MPRs) within FIM Service.

MPR is our tool to enforce the Identity Management policies within our organization.

There are two types of MPRs—Request and Set Transition.

A Request MPR is used to define how the request pipeline should behave on a particular request. If a request comes in and there is no Request MPR matching the request, it will fail.

A Set Transition MPR is used to detect changes in objects and react upon that change. For example, if my EmployeeStatus is changed to Fired, my Active Directory (AD) account should be disabled.

A Set is used within FIM Service to group objects. We define rules that govern the criteria for an object to be part of a Set. For example, we can create a Set, which contains all users with Fired as EmployeeStatus. As objects satisfy this criteria and transition in to the Set, we can define a Set Transition MPR to make things such as disabling the AD account happen. We can also define an MPR that applies to the transition out from a Set.

The Sets are also used to configure permissions within FIM Service. Using Sets allows us to configure very granular permissions in scenarios where FIM Service is used for user self service.