With FIM, managing groups, users, resetting passwords, policy management, and extensibility is easy.
You can use FIM to manage distribution groups and security groups (whether mail-enabled or not), regardless of scope: Universal, Global, or Domain local.
Groups can be configured with more than one owner.
The ability to create groups can be delegated to any set of users within the FIM Portal.
Membership in the groups is managed in one of three ways:
-
Manual
-
Manager
-
Criteria-based
Manually managed membership
Members are placed into manually managed groups by the owners of the group as shown in the figure below. Alternatively, users can request to join a group. The request is either granted automatically or is subject to owner approval. The owners are sent an e-mail message asking them to approve or reject the request.
.gif)
This depends on the join restriction (see the figure below) set on the group. One of the owners can approve or reject the request by performing a simple click of the Approve or Reject buttons inside the message in Office Outlook 2007. While there can be more than one owner, only one owner need respond to the request. Additionally, the request could be approved in the FIM Portal itself.
.gif)
Users can also request to join groups as shown in the figure below. Such requests are automatically rejected if made for manager-based or criteria-based groups.
.gif)
Manager-based membership
A group can also be created that automatically maintains the membership based on who reports to a particular manager. This automatically adds all of the manager’s direct reports. If a subsequent import from HR (or another authoritative data source) modifies someone’s manager, they are removed from this group and possibly placed in another group. The figure below illustrates that the principal step is to select the manager upon which to base the group. The manager is included in the group as well as their direct reports.
.gif)
Criteria-based membership
Groups based on more advanced criteria can also be created. The criterion is based on attributes and is compared with literal values provided by the group owner. So a group could be based on the following rule, Department is ‘Sales.’
Additional rules can also be included such as Department is ‘Sales’ and Manager is not ‘Terry Adams.’ The figure below shows how the filter builder can be used to set up these conditions.
.gif)
Criteria-based groups are one possible approach to role based access control with FIM.
With FIM, the end user has a whole new experience—the ability to edit their own profile, request membership in groups, approve and reject requests, and reset passwords.
When end users log into the FIM Portal, they see something similar to the figure below.
.gif)
Self-service user profile management
Users can also be delegated the permission to update some of their own data as shown in the figure below. Users can either be granted permission to update some attributes of their own data outright, or policies can be configured so that changes to some attributes may require approval by a manager or by HR.
.gif)
Requesting membership in groups
Users can request membership in groups through the FIM Portal as shown in the figure below, or through the Office Outlook 2007 client as displayed in the second figure below.
.gif)
With the FIM Add-in for Outlook installed, users do not need to access the FIM Portal to join and leave distribution lists.
.gif)
Managing requests
End users can view the status of their own requests to see the current state.
.gif)
End users can also approve or reject requests that are sent to them for approval. Requests are sent to them through e-mail messages and, if using Office Outlook 2010 or Office Outlook 2007 and Exchange 2010 or Exchange 2007, requests can be approved or rejected right from within the e-mail. Additionally, requests for approval can be addressed through the FIM Portal as shown in the figure below.
.gif)
After long weekends and vacations, users have a tendency to forget their passwords. FIM provides the capability for users to register for self-service password reset. This allows users to reset their passwords by answering some or all of the questions answered during registration.
The FIM password reset add-in is integrated with the Windows logon screen. The figure below shows an example logon screen from Windows Server 2008.
.gif)
After clicking the Reset Password link, the user answers questions like those shown in the figure below.
.gif)
You can test the password reset behavior by modifying the password reset AuthN workflow. There are three activities in the workflow shown in the figure below; password authentication challenge, lockout gate, and QA gate. The password authentication challenge is only used during the registration process to ensure that someone does not use a temporarily unoccupied but logged-on computer and register to be able to change that logged-on user’s password in the future.
.gif)
The lockout gate as shown in the figure below prevents denial of service attacks by limiting how many times a user can attempt to answer the password reset questions incorrectly.
.gif)
As shown in the figure below you can permit the user to reset their password through QA gate activity by determining a list of questions and how many questions are:
-
Presented during the registration process
-
Presented during the reset process
-
Required to be answered correctly
.gif)
Careful thought and consideration should go into developing questions that balance security and ease of use. These questions should have definitive answers, do not change, cannot be researched easily, and are relevant to your users.
Using questions with definitive answers, for instance, “What is the last name of your first grade teacher,” is important. With definitive answers in the self-service password reset process, the user does not wonder whether they registered with last name, first name, or full name of their first grade teacher.
For security, it is crucial to select questions that cannot be researched easily by searching for the information (like your home address) or questions that are easy to guess based on statistics such as common dog names. If the name of the user’s first dog is a common dog name such as Rex or Fido, the password may be easily guessed.
Irrelevant or culturally based questions force your users to make up answers. For example, users in other countries may not know what a prom is, much less have attended one, and will be unable to answer a question like “What is the first name of your prom date.” To avoid forcing users to answer irrelevant questions, you should have a large set of questions that users are prompted to answer during registration, but have a lower number that they are required to answer, allowing them to skip irrelevant questions.
You must also strive for a careful balance between security and ease of use. Will your users complain if required to answer 15 questions? Will the Chief of Information Security complain if users only have to answer two questions?
If you want to have users answer at least one question each from different banks of questions, you can set up multiple QA gate activities with each one containing the bank of questions.
After the user answers the questions required to reset their password, FIM password reset makes a real-time Windows Management Instrumentation (WMI) request to the FIM Synchronization Service to complete the password reset.
FIM builds upon a solid metadirectory synchronization platform to provide a rich policy-based request framework. The request framework provides the foundation for the application of workflow, the application of policy, and the ability to provide self-service capabilities to end users. The following section introduces the concepts for metadirectory synchronization.
Building upon MIIS and ILM 2007, the FIM Synchronization Service provides the next platform for connecting to data sources, synchronizing data between data sources, as well as the provisioning and deprovisioning of identities. With the release of FIM, the Synchronization Service now operates solely as a 64-bit application offering increased performance on very large datasets. The following sections detail aspects of the FIM Synchronization Service. The application of policy will be discussed in the Customizing and Extending FIM section.
Management agent
While the code modules that are used to communicate with a connected data source are called management agents (MAs), these agents are not installed on the connected data source systems. Instead, they are installed on the computer running the FIM Synchronization Service. The FIM architecture is generally agentless, despite having components that are called management agents (the Password Change Notification Service used for password synchronization does install and require agents).
The MA provides the agentless ability to converse by using remote system protocols instead of relying on the deployment of specialized agents. This means decreased risk and deployment times, especially when dealing with critical applications and systems.
In the figure below, the MA is synonymous with the connector space but encompasses all communication with the external system (the solid double-arrow lines).
The MA is responsible for all import and export functionality to the system and frees developers from needing to understand how to connect to each system natively when using rules extensions to customize data transformations. Imports and exports only occur when scheduled, allowing for further insulation from changes occurring within the system, since changes do not automatically propagate to the connected data source. In addition, developers may also create their own MAs, called extensible management agents (XMAs), for connecting to virtually any data source.
Attribute flow
The metaverse is the consolidated view of all joined identities from neighboring connector spaces.
In the figure below, attribute flow is depicted by using dotted lines for both inbound and outbound flow.
Attribute flow is the process of copying or transforming data from one system to another and all attribute flows (inbound or outbound) are defined as part of the MA definition. Attribute flow occurs between the connector space and the metaverse bi-directionally when synchronization (full or delta) operations are scheduled to run. Attribute flow only occurs when these synchronizations are run.
Connector space
In the figure below, the connector space is depicted as the outer ring of the diagram. Each connected data source is represented as a filtered subset of the objects and attributes in the connector space. This allows the synchronization service to operate locally without the need to contact the remote system when synchronizing the objects and restricts interaction to imports and exports only. When the data source and the MA have the ability to provide a list of changes (a delta import), then the operational efficiency increases dramatically as only changes since the last polling cycle are exchanged. The connector space insulates the connected data source from changes propagating automatically by requiring that the MA schedule imports and exports. This added insurance grants you peace of mind while testing, previewing, or confirming the next update.
The FIM Synchronization Service also contains a very valuable ability to preview changes and perform simple “what if” scenarios. By using the preview ability in conjunction with Visual Studio, developers can debug their custom extensions line-by-line and object-by-object to isolate and identify issues without impacting any remote systems due to the insulation that the connector space provides. Additionally, the statistical results of an import or a synchronization can be interrogated programmatically, giving you the ability to examine how many imports have been deleted or are about to be exported and to decide if manual intervention should be employed.
Metaverse
The metaverse, represented by the center portion of the donut in Figure 27, FIM Synchronization Service, is the consolidated view of all joined identities from neighboring connector spaces. As identities are joined together and authority is assigned for various attributes through import flow mappings, the central metaverse object begins to aggregate information from multiple systems. From this object attribute flow, mappings carry information to outbound systems.
Objects are created when an authoritative system projects them into the metaverse. As soon as all connections are removed, the metaverse object is deleted. Unlike some products, objects in the metaverse cannot be edited directly. All data in the object must be contributed through attribute flow.
The metaverse maintains persistent connectors with each connector space. These connectors do not require reevaluation for each synchronization run. This means that FIM does not have to locate the matching remote object each time. This avoids the need for costly agents to prevent changes to attributes that would normally be responsible for correlating the objects.
When discovering new data sources that may have preexisting objects that need to be managed, FIM uses a process called a join rule to evaluate potential candidates with which to establish a connector. Once the join is established, this evaluation does not reoccur and normal attribute flow can occur between the remote connected data source and the metaverse.
Provisioning
When an authoritative source projects a new object into the metaverse and either through a provisioning rules extension or a synchronization rule, a new connector space object can be created in another MA representing a downstream connected data source. This inherently establishes a connector, and attribute flow can proceed bi-directionally. Whenever a rule determines that a new connector space object needs to be created, it is called provisioning. However, because this operation only takes place within the connector space, it does not carry over into the connected data source until an export is performed.
The FIM Synchronization Service continues to be the backbone of the identity management system and serves as the fulfillment mechanism for the application policy. As policies are applied, the FIM Synchronization Service is responsible for maintaining the objects in the respective systems. The following section details how the application of policy and workflow integrate with the metadirectory framework.
In this section, you will learn about how the FIM Service handles policy management and how that policy management, in turn, drives the FIM Synchronization Service.
.gif)
As shown in the figure above, the FIM Service is connected to the FIM Synchronization Service through the FIM Web service request pipeline. This connection is provided through the FIM MA which is responsible for translating the object updates into Web service requests.
While it is possible for the FIM Synchronization Service to apply policy through the classic ILM 2007 method of custom .NET rules extensions, FIM adds additional power and flexibility through the application of its policy engine to allow for the application of policy through workflow activities. The following section discusses key concepts to understanding the application of policy and the transformation of objects in the FIM Service database.
Schema
The FIM Service database contains its own extensible schema so that it can describe object types and model the relationship between attributes and objects through bindings. New object types can be created or existing object types may be extended and customized to include company or process specific attributes. Furthermore, validation (through the application of regular expressions) rules may be applied at both the attribute and binding levels to ensure data integrity during request processing. The primary object types discussed here are requests, groups, users, sets, management policy rules, workflow processes, workflow activities, synchronization rules, functions, and search scopes.
Expiration time
All objects in the FIM Service database, including the requests themselves, can be expired by setting an expiration time on the object. It is this core functionality, in conjunction with the request management system and policy engine, that allows for built-in reconciliation of any object type and not just identities.
Filter
The filter attribute is available on several object types, but most notably on groups, sets, and search scopes. Filters allow for data-driven queries to be saved and reevaluated at run time so that when a filter is built to return all person objects that have an inactive employee status, the result set is automatically updated whenever a new object meets the search criteria. All filters in FIM use the W3C open standard XML Path (XPath) language syntax to define the query and all object references use the XPath syntax (//Target/EmployeeStatus). The XPath filter dialect is a subset of the XPath 2.0 specification.
Requests
When a user performs a task in the FIM Portal or the FIM Add-in for Outlook, or exports data through the FIM MA, it is represented in the form of a request object, which is used to indicate the request to perform that task. Each request object has common components that include the following:
-
Requester – Resource that requests to perform an operation.
-
Operation – Operation the requester wants to perform.
-
Target – Resource that is the target of the requested operation.
Logically, a request object is an implementation of the statement, "The requestor attempts to perform the following operation on this target."
The following figure shows the general architecture of a request object.
.gif)
Each request object has a status property to indicate the processing state.
Processing requests may require manual interaction to complete a request. For example, the owner of a group might be required to manually approve the request to join a group made by another user. In addition to a manual interaction, you can also configure FIM to automatically process a specific request without the need of human interaction.
Groups
The group object type is also provided as a default object type that allows FIM Portal users to participate in group self-service operations like the request and management of Active Directory distribution lists or security groups. Users can request any of the following or be restricted by the application of the policy.
FIM group types
|
Group type
|
Description
|
|
Named (static)
|
Groups where the membership is controlled by an owner or automatic approval
|
|
Manager
|
Derived groups that are built from direct reports of a manager
|
|
Calculated (dynamic)
|
Groups where the membership can be determined through the use of a filter
|
Users
By default, the FIM Service database includes a Person/User object type that provides the basis for user interaction with the application. (Person is the name of the object type. User is the object type’s display name.) Once someone has a user resource in the FIM Portal, they can then take advantage of the self-service capabilities such as password reset and group or account management.
Setting expiration times on group objects provides the foundation for the reconciliation of group membership. When combined with the built-in approval mechanisms, owners can automatically extend or expire groups that they own.
Sets
Sets provide the foundation for the policy engine to evaluate simple collections of objects or model complex transitions between states.
The membership in a set is manually managed or criteria-based. This means that you can manually add resources to a set and that you can define criterion that automatically adds resources to a set, based on a filter statement. When a resource fulfills the filter criteria, it is automatically added to the related set.
In the simplest case, a filter can be based on an attribute of a resource such as the employee type. For example, when your filter statement enables all users with an employee-type attribute value of “Contractor” to become members of a set, FIM automatically adds a user to this set when the employee type has been set to “Contractor.” The following screenshot shows an example for the related filter statement.
.gif)
The criteria-based membership in a set can be based on static values of resource attributes or it can be based on dates. For example, you can define a filter statement that automatically transitions resources into a set on a specific date. Examples for date-based attributes are the Employee Start Date or the Expiration Time. The set membership is flexible enough to allow you to define filter conditions that are relative to the date values. For example, you can define a filter that is based on “x days from today.”
Sets that are based on relative dates are also known as temporal sets. Each filter statement can be based on a collection of individual statements where either all filter conditions must be met or only one of them must be met to qualify a resource for transitioning into and out of a set.
Temporal sets provide a mechanism that can fully automate the process of transitioning into or out of a set based on the passage of time. An example temporal set is defined for all groups that expire one week from today. The system evaluates the objects automatically and adds them to this set on a daily basis.
At the heart of management policies is a series of sets that defines who the requester is, what types of objects the policy covers, and whether or not the object is transitioning between states to trigger the policy.
Through the combination of filters and static membership, sets provide the building blocks necessary on which MPRs are built. Sets can be combined together to create the intersection of the result sets allowing for greater flexibility should the definition of a such concepts as user and contractor evolve over time.
Management policy rules
In the FIM architecture, MPRs represent the core component to implement your policy statements. MPRs define the proper response to a condition. FIM defines two basic types of MPRs:
-
Request-based MPR
-
Set transition–based MPR
The following sections provide more details about both types of MPRs.
Requester MPRs
As indicated by the name, a requester management policy rule (RMPR) is evaluated and applied against incoming requests to perform operations. RMPRs consist of a condition and a response.
When you configure an RMPR, the requester is in the set that needs to perform an operation.
The FIM architecture defines six different operations for which an RMPR can be defined:
-
Create resource
-
Delete resource
-
Read resource
-
Add a value to a multivalued attribute
-
Remove a value from a multivalued attribute
-
Modify a single-valued attribute
When you define an RMPR, you must select at least one of these operations. The operations are always defined in the context of the requester. Each condition requires the definition of a target. An operation that is applied to a target can result in a state transition of the target resource. To effectively characterize the target of your condition, FIM allows the configuration of two states for the policy:
-
State that the object satisfies before the operation
-
State after the operation
You can also express the related resources relative to the requester (such as the requester’s own user object, a target user's manager, or a target group's owner).
The simplest form of a response to a condition is to grant permissions to perform the requested operation. In addition to granting permissions, you can also define other operations as a response to a condition in an RMPR. In the FIM architecture, these operations are defined in the form of workflows. At the time when a given RMPR is processed, the system might not have enough information to grant permission. In this case, you can define in your RMPR additional authentication steps and authorization steps that should apply to the person performing a given request. For example, to grant permission to perform the requested operation, you might require manual interaction of a user to approve it.
The following figure shows the complete architecture of an RMPR.
.gif)
When a new request object is created in FIM, the system queries the configured RMPRs for matching objects by comparing the request conditions with the configured conditions in your management RMPRs.
If matching RMPRs are located, they are applied to the queued request object.
The following figure shows this process.
.gif)
In FIM, permissions for operations must be explicitly granted. In other words, unless granted by an RMPR, all operations on resources are denied. Each request object requires at least one RMPR that grants permission to perform the requested operation on a target.
RMPRs provide a very flexible mechanism to address your policy requirements. For example, you will likely have a different process when an end user creates a group from when a group administrator performs the same operation. The process can be different in terms of the type of permissions that are available and which attributes and approvals need to be obtained as part of that process. You can implement all of these various requirements with related RMPRs.
Set Transition-based management policy rules
Set Transition management policy rules (TMPRs) represent the second class of MPRs.
The objective of TMPRs is to invoke the operations that are required in case of state transition to enable the resource to function efficiently. For example, you may want to express the following business requirement:
“When a new full-time employee is hired, enable access for them to the corporate network.”
In this case, the appropriate response to this Set Transition is to provision a new account to AD DS, which enables the new hire to access the corporate network.
As indicated by the name, Set Transition management policy rules are tied to a specific set. In FIM, this set is called the transition set.
There are two relevant types of Set Transitions:
-
Transition in – when a resource becomes a member of the transition set
-
Transition out – when a resource leaves the transition set
The main logical difference between a RMPR and a TMPR is the actual state of the condition. An RMPR is invoked before a requested operation has been performed. The objective of the related MPR is to define the access policy for the right response to the request, which is an answer to “how the request is handled.”
For TMPRs, the response is a reaction to an applied state change. When the related MPR is invoked, the condition has already been applied. This means that the affected resources have already transitioned into or out of a transition set. In this scenario, the objective of the response is not to define the reaction to a requested operation, but to define the response to an applied operation. In other words, for a TMPR, it is irrelevant how a state was reached. What matters are the consequences of a state change.
When you configure a TMPR in FIM, you have to specify the following three settings:
-
Transition set
-
Transition type
-
Policy workflows
The policy workflows are definitions of the processes that need to be invoked in response to the state change. The most common use cases for state-based MPRs are granting or revoking of entitlements and provisioning and deprovisioning in external data sources.
The following figure shows the complete architecture of a TMPR.
.gif)
TMPRs are activated by requests. When a request is processed and approved by an RMPR, the FIM service also determines whether an approved request results in a state transition and whether a state transition-based MPR that handles the state change exists.
The following figure shows the relationship between an RMPR and a TMPR.
.gif)
Workflow processes
FIM allows for the assembling of various workflow tasks or building block activities into a workflow process, which can be assigned collectively to an MPR to run. By grouping WF into the three phases, AuthN, AuthZ, and Action, frequently used processes can be reused by many policies.
Workflow activities
The underlying component of the workflow process is an assemblage of WF activities, either from the underlying WF workflow foundation, default FIM activities, or through custom activity development. These activities provide the building blocks necessary to operate on requests.
FIM exposes its own workflow process designer in Windows SharePoint Services, which allows FIM Portal administrators to link together prebuilt activities into sequential workflow processes without the need for Visual Studio or any development experience.
Synchronization rules
.gif)
Synchronization rules provide the foundation for declarative provisioning of objects into other connected data sources without the need for legacy rules extensions. Synchronization rules also provide the ability to map and apply basic data transformation functions much like attribute flow mappings do in the MAs. However, unlike MA attribute flows, most flow definitions in synchronization rules do not require rules extensions in Visual Studio. When custom transformations are required, they can be written either as WF activities that manipulate attributes on the target objects and then flow over as-is by using a flow definition, or you can add a custom function.
In the earlier figure, Adding the FIM Service database to the metadirectory solution, the synchronization rules are represented by the large yellow arrows and the absence of the orange arrows, which previously depicted attribute flow. With synchronization rules, attribute flow mappings are no longer added statically in the MA—they are dynamically defined.
Functions
.gif)
Functions provide the ability to declaratively manipulate and transform data during synchronization. Flow definitions can call upon existing functions to manipulate data as it is mapped from attribute to attribute.
Resource control display configuration
When interacting directly with the FIM Portal request processes, the user is taken through a wizard-like process to make the request. The experience is controlled by a series of XML definitions called resource control display configurations (RCDC) which allow customization of the user experience for each object type and each operation as defined in the following table.
FIM object visualization configuration verbs
|
Verb
|
Description
|
|
Create
|
Controls the user experience for Create operations requested through the FIM Portal. Allows for a subset of attributes to be defined at creation time while hiding others that may be seen through the application of policy.
|
|
Edit
|
Controls the user experience for Edit operations requested through the FIM Portal. They are similar to Create operations but may reveal additional controls not present during the initial creation of the object.
|
|
View
|
Controls the user experience for View operations requested through the FIM Portal. These operations appear in dialog boxes and provide a read-only view of the object.
|
RCDC definitions render controls that allow the user to complete the request by using familiar mechanisms like option buttons, drop-down lists, and object pickers. Controls are defined by binding them to attributes and then grouping them onto tabs.
Search scopes
.gif)
Search scopes provide a convenient union between sets and saved queries by allowing FIM Portal administrators to define prebuilt search criteria and bind them to RCDC controls. Search scopes can be used anywhere a search control is exposed by defining usage keywords that link the scope and control together. As shown in the figure above, search scopes can be used to save useful queries for frequent usage.
FIM provides the Web service request framework for which the application of policy through workflow becomes possible. This framework makes the self-service capabilities for object management available. The following section discusses the request management architecture.