Designing Business Policy Rules

Applies To: Forefront Identity Manager 2010

To compete in this economy, organizations need to provide efficient and secure access to their internal applications and data for full-time employees as well as external entities such as contractors, business partners, customers, and mobile employees. This requires an Identity and Access Management solution that provides seamless and secure access to corporate information and applications from virtually any location and device.

Identity and access management is primarily defined as a set of policies required to control entitlements of people, applications, or other services to critical resources. Entitlements range from traditional access control to data and operations to more complex provisioning of access to applications and management of that access throughout a lifecycle. As a consequence, implementing identity and access management in your environment is about modeling the right policies. Technologies such as Microsoft® Forefront® Identity Manager (FIM) 2010 help to facilitate the implementation of these policies.

This document shows you how to turn your written policy statements into a technical implementation based on FIM 2010.

For an overview of FIM 2010 documentation and guidance for using it, see the Documentation Roadmap.

Collecting Policy Statements

The first step in modeling your business policy rules with FIM 2010 R2 is to create a collection of your actual requirements. You may already have a related list created for your environment.

This list should include:

• Your resources and who is required to have access to them.

• The functional roles in your environment and what they require in terms of access to resources, including your directories and databases, to function effectively.

• Policies that affect your environment and are mandated by governmental and industry regulations.

Common examples for these policy statements are:

• All full-time employees with Active Directory® accounts

• Only full-time employees in the Human Resources (HR) department with access to the HR application.

• Employees leaving the HR department that need to have their access to the HR application revoked.

You should use a nontechnical language to ensure that all the stakeholders fully understand your policy statements. In addition, you should be as detailed as possible when gathering these requirements and track them in a related document.

Defining Logical Policy Statements

In many cases, the collection of policy statements does not follow a specific format. This can make it hard for reviewers to provide meaningful feedback and is also a general source for possible misinterpretation of the meaning of a policy. To avoid ambiguity and to improve the specificity, you should apply a specific format to these freestyle policy statements. For a policy to be meaningful, tie them to conditions that can occur in your environment and provide the appropriate response to them:

"When <condition> happens, do <response>"

This document refers to policy statements that follow this structure as logical policy statements.

The following illustration outlines the general format of a logical policy statement:

Some examples for typical business policy rules are:

• “When a person has become an employee, perform the following steps…”

• “When a person moves to a different department, follow this process…”

• “When someone is fired, the Sarbanes–Oxley Act (SOX) requires the following…”

• “When someone wants to join this group, do…”

• “When someone tries to read sensitive data, do…”

• “When someone becomes a contractor, do…”

• “When a person is no longer a contractor, do…

• "When an administrator tries to create a new user, do…”

• "When a user tries to create a new distribution group, do…"

One aspect of your logical policy statements is to define access rules for the resources in your environment. In a corporate environment, the term resource is not isolated to people; it encompasses all of your assets including people, computers, printers, and others.

You are probably already familiar with the access control model in Microsoft Windows®. In this model, you can protect securable objects such as printers, files, and shared resources by assigning access control lists (ACL) to them. An access control list consists of access control entries (ACE) that define the access rights of an entity to a resource. In FIM 2010 R2, you can see some similarities between access policies and the Windows access control model. However, FIM 2010 R2 access policies provide a higher level of detail and a broader reach because they are not tied to the security model of a specific, managed data source. In FIM 2010 R2, you define your access policies across all managed resources regardless of the actual protection technology they are tied to.

You can define FIM 2010 R2 access policies on an attribute level. After the installation, access to all resources is, with the expectation of some access policies that are required for administrative tasks, prohibited. For your resources to access resources in your environment, you need to grant permission to perform operations on them. In your logical policy statements, you define these access policies in the form of request-based policy statements.

Granting permissions is only one aspect of a request-based policy statement. You can also, for example, require in your access policy that an operation requires manual approval by an authorized entity. In essence, FIM 2010 R2 access policies are flexible and customizable and the scope is not isolated to just granting permissions. You can find more information about this issue later in this document.

In a request-based policy statement, the condition consists of three components:

1. Requester

2. Operation

3. Target

In an enterprise environment, the requester is typically not a single entity. When you define logical business policy statements, you typically define them on the basis of a set of resources that share some common characteristics. For example, the requester of an operation could be "All full-time employees in the HR department."

The operation requester attempts to perform is either one or a collection of the following basic operations:

• Create

• Read

• Update

• Delete

The third component of the condition is the target of the operation. The target can be either a complete object or just parts of it that are defined as attributes.

The objective of a request-based policy statement is to define how the system responds when a requester attempts to perform an operation on a target. The simplest form of a response is to grant permissions to perform the requested operation. However, just granting permissions might not always be sufficient. This is why a response can also be another action the system is expected to perform in response to the condition.

The following illustration summarizes the general architecture of a request-based policy statement:

Defining access policies is just one category of logical policy statements. The second class is related to the states of the resources in your environment. In a business environment, people are typically categorized into functional roles. For example, you typically have functional roles such as:

• Full-time employees

• Contractors

• All people who are part of Cost Center 456790

• Administrators in North America

In FIM 2010 R2 , these functional roles are also known as FIM 2010 R2 roles. A FIM 2010 R2 role is defined by a group of users who share some common characteristics. To operate effectively in your environment, you need to define what the right response of your system is to a FIM 2010 R2 role transition. There are two options for a FIM 2010 R2 role transition when someone transitions:

1. Into a role

2. Out of a role

FIM 2010 R2 roles are just one example of transitions in your environment. Transitions can also occur for other resource types such as, for example, computers or groups. A transition changes the state of a resource.

Defining the proper response to a FIM 2010 R2 role or state transition is the subject of this second class of logical policy statements that is known as state-based policy statements. Common requirements for these state-based policy statements are to define account requirements for FIM 2010 R2 roles. For example, one requirement might be that all full-time employees be granted access to the corporate network or a specific line-of-business application. Access to a network of a specific application translates usually into the availability of a related account that the resource uses to log on.

In a state-based policy statement, you express the policy condition in the form of a state change. For example:

• "When a user enters the FIM 2010 R2 role of a contractor, do…"

• "When a user leaves the FIM 2010 R2 role of a full-time employee, do…"

For instance, in the request-based policy statements, the condition is followed by a definition of the right response to the condition. The following illustration shows the general architecture of a state-based policy statement:

When you compare request-based policy statements and state-based policy statements, you notice one major difference between both types. In a request-based policy, you define the appropriate response to an attempt to perform an operation. At the time when the policy is applied, the requested operation has not yet taken place.

State-based policy statements define a response to a change that has already been applied. For state-based policy statements, it does not matter how a state is reached. The policy defines the proper reaction to an applied change.

Transforming your freeform policy statements into logical policy statements has various benefits. At the beginning of this section, you have already seen that this process can help you to remove ambiguities and improve the specificity of your statements. In addition, the translation also helps you to identify possible gaps. While you can define access policies and state transition-based policies independent from each other, you should perform another review pass when you have completed the initial transformation. In this cycle, you analyze whether a given:

• Access policy causes a state transition that needs to be handled as a state transition-based policy

• State transition-based policy has a related request-based policy that causes the state transition

As mentioned earlier in this section, for state transition-based policies, how a state was reached is irrelevant. This is because you can assume that each state change is a result of an underlying request-based policy that has handled the state change. For example, to enter the FIM 2010 R2 role of a contractor, an update of the Employee Type attribute of a user must have been applied. Your request-based policies ensure that an update to the Employee Type attribute of a user is only possible for entities with the right authority to perform this operation. As you can see in this simple example, while they are defined independently from each other, there are dependencies between a request-based policy statements and state transition-based policy statement.

Lastly, using a common schema for logical policy statements helps your reviewers to provide better feedback to you because all your statements follow an easy-to-understand template that makes it easy to spot potential gaps.

Technical Components of a Business Policy

One common challenge for business environments has always been the translation of logical business policy statements into technical implementations. FIM 2010 R2 introduces a significant improvement to the process of modeling business policies in a corporate environment by requiring fewer logical translations from the logical policy definition into a technical implementation.

In FIM 2010 R2 , the related architecture for the technical implementation of a logical policy statement consists of four main components:

1. Resources and Sets

2. Requests

3. Management Policy Rules (MPRs)

4. Workflows

Introduction to Resources and Sets

In a logical business policy statement, the source and the target are core elements of a condition, which represent the resources in your environment. You have already learned that the term resource encompasses all your assets from people to computers, files and others – depending on your requirements. FIM 2010 R2 tracks all managed resources of your environment in the FIM 2010 R2 Service database. To add resources to the FIM 2010 R2 Service database, you can either add them directly by using the FIM 2010 R2 Portal user interface, implement an external method that uses the Web services API, or you can also import resources from external systems such as an HR database or Active Directory Domain Services (AD DS) by taking advantage of the FIM 2010 R2 Synchronization Service.

Each resource has an underlying basic object type such as user or group. The FIM 2010 R2 schema is customizable. You can use it to define your own basic object types according to your requirements.

Resources are an elementary part of the condition in your policy statements. Policy statements are typically not defined based on basic object types only. For example, in most cases, you do not define a policy for all users or all groups. Instead, you typically define your policies based on a group of resources that share some common characteristics. In the FIM 2010 R2 terminology, a group of resources that share some common characteristics is known as Set.

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 a criterion that automatically adds resources to a Set based on a property statement. When a resource fulfills the filter criterion, 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 allows all users with an Employee Type attribute value of Contractor to become members of a set, FIM 2010 R2 automatically adds a user to this Set when Employee Type has been set to Contractor. The following screenshot shows an example for the related filter statement:

The criteria-based membership in a set can be based on static values of resource attributes or it can be based on dates. For example, you can define a filter statement that automatically transitions resources into a Set on a specific date. Examples for date-based attributes are the Employee Start Date or the Expiration Time. The Set membership is flexible enough that you can 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 one or all filter conditions must be met to qualify a resource for transitioning into and out of a Set.

Temporal Sets in particular 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 in the system automatically and adds them to this set on a daily basis.

In your policy statements, Sets are used to define requesters, targets, and transition targets.

Understanding set limitations

This section covers unsupported filter definitions and set transition limitations for system resources.

Unsupported filter definitions

• Double negation in set filters is unsupported. If a filter contains any condition of the form not(Attribute != Value) (for example, /Person[not(DisplayName != ‘value’)], an exception is returned notifying the client that the server cannot process the filter as requested, and that the use of double negation is unsupported.

• Multiple conditions nested inside a not() statement in set filters is unsupported. If a filter contains multiple conditions inside a not() statement, the filter will be rejected. For example: /Person[not(JobTitle = ‘Developer’ or JobTitle = ‘Tester’)]

• The creation of filters that reference the membership of a temporal set is not supported. If a set/group filter is created with a filter that dynamically nests a temporal set, the request is rejected with the following error message:  “A temporal set cannot be dynamically nested in other sets.”

• The creation of filters in temporal sets that reference the membership of other sets is not supported. If a set/group filter is created with a Datetime-based filter condition,  the set’s filter is not permitted to reference the membership of other sets.

• The creation of filters that include relational conditions based on multivalued Datetime or multivalued Integer attributes is not supported. If a set/group filter is created with a filter that contains a relational condition on a multivalued Datetime or integer, the request is rejected with the following error message:  “Relational conditions cannot be defined on multivalued DateTime and multivalued Integer attributes in a set filter.” The unsupported operators consist of: >, >=, <, <=

• The creation of filters that include the != operator with a multivalued attributes is not supported. Such a condition is not supported by the FIM 2010 xpath filter dialect.

• The contains() xpath function is not supported in set filters.

• Multiple location steps are not supported, except when referencing the membership of a set. The following filter is unsupported in sets:  /Person/Manager.

  The following filter is supported, because the multiple levels of dereferencing is to reference the membership of a set:  /Person[Manager = /Set[ObjectID = ‘7CF6B5A3-01B2-45d3-8337-5EB521DDA08D’]/ComputedMember]

• Sets cannot reference the membership of Group resources. The following filter is not supported: /Person[Manager = /Group[ObjectID = ‘7CF6B5A3-01B2-45d3-8337-5EB521DDA08D’]/ComputedMember].

Set transition limitations for system resources

The following resource types are referred to as “System Resources” in this specification:

• Request

• Workflow Instance

• Expected Rule Entry

When a new instance of one of the above resource types is created, the resource will transition only into sets with one of the following filter definitions:

1. /* - this represents the “all resources” set.

2. /ResourceType  - for example, /Approval.

   This implies that the system resources identified in this specification will only enter sets that have no membership conditions other than one based on object type.

When a Request is created to modify or delete a system resource, the target of the Request will transition in/out of all sets as appropriate based on the filter definition of the set:

• If a set has the filter /WorkflowInstance, when a WorkflowInstance object is deleted, it will transition out of the set.

• If a set has the filter /Request[RequestControl = ‘CancelPostProcessing’], if a Request object is modified, through the submission of a Request, such that it now satisfies the criteria of the set, the Request object will transition into the set.

Introduction to Request Objects

When a user performs a task in the FIM 2010 R2 Portal or the FIM 2010 R2 Add-in for Outlook®, the task is represented as a request object, which is used to indicate the request to perform that task.

Requests represent not only objects in FIM 2010 R2, they also represent a convenient reporting mechanism for activities in your system.

Each request object has common components that include:

• Requester –A resource that asks to perform an operation

• Operation – The action that the requester wants to perform

• Target –The resource that is the target of the requested operation

You have already been introduced to these three components in the section about logical policy statements. These components can also be thought of as the condition of the request object.

Logically, a request object is an implementation of the following statement:

"The requester attempts to perform the following operation on this target…"

The following illustration outlines the general architecture of a request object:

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

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

Introduction to Management Policy Rules

In the FIM 2010 R2 architecture, management policy rules (MPRs) represent the core component to implement your logical policy statements. MPRs define the proper response to a condition. For instance, in logical business policy statements, FIM 2010 R2 defines two basic types of MPRs:

1. Request-based MPRs

2. Set transition-based MPRs

The following sections provide more information about both MPR types.

Request-based MPRs

As suggested by the name, a request-based management policy rule (RMPR) is evaluated and applied against incoming requests to perform operations. For instance, in a request-based policy statement, RMPRs consist of a condition and a response.

When you configure an RMPR, the requester is in the Set designed to perform an operation.

The FIM 2010 R2 architecture defines six different operations that an RMPR can be defined for:

1. Create resource

2. Delete resource

3. Read resource

4. Add a value to a multivalued attribute

5. Remove a value from a multivalued attribute

6. Modify a single-valued attribute

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

1. Target Resource Definition Before Request – the state of the target before the request is applied.

2. Target Resource Definition After Request – the state of the target after the request is applied.

Whether you need to define both states depends on the operations your RMPR is defined to do. In a Create operation, the requested resource has no initial state. This is why you only need to configure Target Resource Definition After Request" for a Create operation.

A Read or Delete operation does not cause a state transition. For these two types of operations, you are only required to specify Target Resource Definition Before Request.

For a Modify operation or all other combinations of operations, you need to configure both states, which may have the same values if no state transition takes place.

You can 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 2010 R2 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 additional authentication and authorization steps in your RMPR that 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 the operation.

The following illustration outlines the complete architecture of an RMPR:

When a new request object is created in FIM 2010 R2, 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 illustration outlines this process:

In FIM 2010 R2, 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 all your policy requirements. For example, you will likely have a different process for an end-user creating a group and for a group administrator performing the same operation. The process can be different in the type of permissions that are available and in what attributes and what approvals need to be obtained as part of that process. You can implement all these various requirements with related RMPRs.

Set transition-based management policy rules

Set transition-based management policy rules represent the second class of MPRs.

The objective of set transition-based MPRs is to invoke the operations that are required in state transitions so that the resource can function efficiently. For example, your logical policy statement could mandate the following:

"When a new FTE is hired, create access to the corporate network for them."

In this case, the appropriate response to this Set transition is to provision a new account to AD DS that the new hire can use to access the corporate's network.

As indicated by the name, Set transition-based MPRs are tied to a specific Set. In the FIM 2010 R2 terminology, this Set is called a transition Set.

In Set transitions, you have two important types that are relevant:

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

2. Transition Out - a resource leaves the transition set.

The main logical difference between an RMPR and a state transition-based management policy rule is the actual state of the condition. An RMPR 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 MPR, 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 set transition-based MPR, it is irrelevant how a state was reached. What is relevant are the consequences of a state change.

When you configure a set transition-based MPR in FIM 2010 R2, you need to specify the following three settings:

1. Transition Set

2. Transition Type

3. Policy Workflows

The policy workflows are definitions of the processes that need to be invoked in response to the state change. The most common use cases for state-based MPRs are the 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 MPR:

Set transition-based MPRs are activated by requests. When a request is processed and approved by an RMPR, the FIM 2010 R2 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 illustration outlines the relationship between a request and a set transition-based MPR.

Introduction to workflows

The objective of an MPR is to define a proper response to a condition. The simplest form of a response is granting permissions to perform requested operations. However, if a response requires more complex processing steps, these steps are encapsulated in a workflow object. While they are optional components, workflows are closely tied to MPRs. In FIM 2010 R2, workflows define an activity or activities that must occur during the processing of an MPR. FIM 2010 R2 installs several default workflows that can be used as is or as a basis for a custom workflow.

Examples for workflow activities are:

• Sending an automated e-mail message to request approval

• Restricting the attributes that a user can see during a custom search

• Validating a new group against AD DS or FIM 2010 R2 guidelines

• Adding or removing the object from the scope of a synchronization rule

To address all processing requirements in your environment, the FIM 2010 R2 architecture defines three types of workflows:

1. Authentication –used to perform additional user identity validation before continuing with the request.

2. Authorization –used to validate a request through a sequence of activities such as obtaining necessary outside approval before processing a request.

3. Action –used to process any further activities after the original request has been completed successfully.

Understanding the Request Processing Model

In the previous section, you have been introduced to the components of a technical business policy. Request objects and RMPRs play an important role in this architecture. The objective of this section is to provide a more detailed description of how requests are processed in FIM 2010 R2.

The request processing model in FIM 2010 R2 is composed of three main phases:

1. Authentication

2. Authorization

3. Action

Workflows, each of which contains one or more activities, can be attached to each of these phases and run in the context of executing a single request. A request can initiate from a single user call to one of the Web Service endpoints or through a user creating a request in the FIM 2010 R2 Portal.

The following illustration shows the relationship of the request processing components:

Processing requests

Requests are processed in the following order:

1. Request Object Creation- FIM 2010 creates a Request object in response to a call to one of the Web Service endpoints or because of a request initiated through the FIM 2010 R2 Portal.

2. MPR Evaluation - The requester’s rights to request the action are validated and the computation of the applicable workflows is performed. The request is checked against mappings to any MPR objects. To map to an MPR, all the applicable fields of the MPR for the requested operation need to match. This includes the requester, operation, target resource, and attributes. If all of these conditions including the attributes being affected are true for an incoming request, then the appropriate MPR is matched to the request. A request must map to at least one MPR that grants the permission as part of its definition. If this is true, the request passes through the permissions check stage of request processing. If this is not true, the request fails. The system also determines the set transitions that are part of the request and locates all related set transition-based MPRs.

3. Authentication - FIM 2010 runs authentication workflows one at a time in a nondeterministic order to confirm the requester’s identity.

4. Authorization - FIM 2010 confirms the requester’s permission to perform the requested operation on the resource specified in the request. All dependent authorization workflows are run in parallel, but a request is not committed to the FIM 2010 R2 Object Store unless all of the workflows have been completed and all have succeeded.

5. Processing - FIM 2010 performs the requested operation on the FIM 2010 R2 Application Store.

6. Action - FIM 2010 executes any processes that are to occur because of the requested operation. All action workflows are run in parallel. Read operations do not have any workflows applied to their processing. This includes the configured workflows in the RMPR as well as the workflows in the set transition-based MPRs.

Using Management Policy Rules

MPRs play an important role in the FIM 2010 R2 architecture. Earlier in this document, you already have been introduced to the basic MPR types. The objective of this section is to summarize how you can use MPRs in your deployment.

The main design objects for MPRs are:

• Modeling permissions

• Modeling workflows mappings

• Modeling transitions

• Modeling reflexive definitions

• Modeling unauthenticated user access

• Modeling temporal policies

• Modeling filter permissions

Modeling permissions

Granting permissions to perform the requested operations on a target is the simplest implementation of a response to a condition. Permissions, in its simplest form define, who can request to do what. An example of using an MPR to grant permissions is giving all full-time employees the ability to request the creation of groups in the FIM 2010 R2.

In the FIM 2010 R2 processing model, the access condition to a resource is first validated. If the user has the required permission, the next steps in the processing model are evaluated, namely any workflows that need to be executed.

This implies that if an MPR is defined that does not grant any permissions but does define associated workflows, those workflows can only be executed if another MPR exists in the system that grants the permission. For example, if an MPR exists that defines a notification workflow to the Manager any time the user’s title is updated but does not select that the rule grants the permission, then a different MPR needs to exist that grants permission for anyone to be able to request an update to the user’s title before any notifications can be generated in the system.

Otherwise, the operation to update the user’s title would result in an Access Denied error. As a result, modeling permission should be the first translation sequence from a logical policy statement to technical MPR.

You can only use RMPRs to grant permissions on resources in your environment.

To grant permissions as a response to the defined MPR condition, the Grants Permission option must be checked in the MPR configuration. MPRs use the sets concept to define rules in terms of collection of users. You can only apply rights to sets.

The existence of only a single MPR object matching the criteria is sufficient for the requester to be granted the rights to perform an operation under the criteria defined in an MPR.

Modeling workflow mappings

Workflow mappings define what needs to happen when a request is processed in the FIM 2010 R2 system. For example, you may define an MPR that states that all full-time employees can create groups. By creating this MPR, you are granting the necessary permissions to the full-time employees set to create groups. Your corporate security policy may further state that in order for groups to be created, you need to have approval by one or more members of the administration set. By using FIM 2010 R2, you can create a workflow that defines that members of the administration set must approve any request to create a group. After creating this workflow, you can do one of two things: attach it to the MPR granting full-time employees the rights to create a group or create a stand-alone MPR that defines that whenever anyone submits a request to the FIM 2010 R2 system to create a group, this workflow is triggered.

Policy workflows are of three types:

1. Authentication - performs additional validations on a user's identity.

2. Authorization - obtains necessary outside approvals before executing a request or performs additional validation of an incoming request.

3. Action - executes any further activities after a request has been stored in the FIM 2010 R2 store.

While you define action workflows for RMPRs and set transition-based policy rules, authentication and authorization workflows can only be defined in the context of RMPRs.

Modeling resource transitions

Many business processes need to model transitions between resource states. Transitions occur when a resource moves from one state to another, which is expressed through set membership changes in FIM 2010 R2. As mentioned earlier in this document, for state transitions, it is typically irrelevant how a resource has transitioned into a state or out of a state since the activity that caused the state change must have already been handled by an RMPR.The objective of modeling resource transitions is to define a proper response to a state change. State transitions are mainly handled by set transition-based MPRs.

Policies for provisioning of resources are the most common examples for transition-based MPRs. This is commonly modeled by applying provisioning action workflows to MPRs based on the set transitions.

Reflexive definition of MPRs

When you define RMPRs, you need to configure a requester. While the typical requester is a Set, there are cases where the required FIM 2010 R2 role is a generic role that a requester has dynamically inherited from a relationship to a resource.

Examples for these generic roles are a user's manager or a group's owner.

With reflexive definitions of MPRs, you can define generic roles dynamically from relationship inherited roles as requesters. You can also implement statements such as "When the owner of a group attempts to update the display name of the group, grant permission to perform this operation."

When configuring an MPR of this type, you use a reference attribute that is unique to the defined resource to identify valid requesters for the operations.

Reflexive definitions are only available for RMPRs.

Modeling unauthenticated user access

Modeling unauthenticated user access applies only to RMPRs. For instance, for reflexive definitions, unauthenticated users represent another generic type of requesters for RMPRs. These users are resources that have not been authenticated to the FIM 2010 R2 system.

An example usage within FIM 2010 R2 is during the password reset process, which requires nonauthenticated user access to the FIM 2010 R2 system before a user’s identity can be validated. Since the user is not authenticated to the domain, to perform this task, an MPR is defined granting members of the unauthenticated users set the rights to modify the necessary attributes to request a password reset operation.

Modeling temporal policies

Temporal policies are implemented by using set transition-based MPRs.

With temporal policies, you can tie the triggering event for a policy to a specific date and time.

For example, you can configure an MPR to send out a notification when a resource is within a specified number of days of expiring.

Another example is the deletion of resources that have expired after a specified number of days.

Temporal policies are related to the concept of temporal sets—set definitions that are based on dateTime attributes. Temporal sets need to be used in the resource definition of temporal policy MPRs. In addition to a standard request processing evaluation, temporal set memberships are evaluated by a Microsoft SQL Server® Agent job. You can configure the frequency of this evaluation through the configuration of the SQL Server Agent job for FIM_TemporalEventsJob and setting the appropriate frequency. By default, the frequency is set to a daily interval.

The general process of defining temporal policies follows the same pattern as other policy definitions. You need to first define the condition for the policy and then the workflows that need to occur when the condition is met. Time-based policy definitions focus on defining only workflows through its policy and do not include permission granting.

To define the condition for the MPR, you must first create the required sets and workflows as with any other policy. Temporal policy conditions should set the requester to the set of All objects and the operations to Modify and Add. Depending on whether you are configuring this for a single-value or multivalued attribute, the attributes should include Resource Time and the attribute whose value has a time-based dependency.

This can be Expiration Time or any other custom attribute. For the target resource definition after the request, you must use a temporal set that defines the resource objects of your policy. Policy workflows can include any action workflows you want to invoke when the condition is met.

Modeling filter permissions

Filters are used in FIM 2010 to manage memberships of dynamic groups and sets. When you create a dynamic set or group, you define your criteria that is used to match the objects into the collection. The criteria may be based on attributes such as an object type or any other attribute or function. For example, you want to create a group where Employee Type equals Full-Time Employee. It is this criteria that matches all resources that are of the type Person and that have the value of the attribute Employee Type set to Full-Time Employee.

Another example consists of the following three distribution lists:

• IT

• HR

• Marketing

You create a distribution list called All Departments that uses the member of function to include members of the other three distribution groups.

FIM 2010 gives you the capability to allow nonadministrative users the ability to create dynamic groups. But you may want to control specifically what kind of dynamic groups the users can create. You can use the filter permissions feature to configure the type of criteria that can be used by users creating dynamic groups and provide a:

• Server-enforced mechanism for customers to restrict the types of attributes used by users creating dynamic groups and sets.

• Server-enforced mechanism for customers to allow only specific groups and sets to be referenced in user-defined dynamic groups and sets.

• Mechanism for providing different restrictions to different users. For examples, you can have your administrator create dynamic groups without any restrictions, while your end-users only use a limited set of attributes.

• Administrators can use the default FIM 2010 R2 configuration to create unconstrained dynamic groups and sets. Nonadministrative users can only create dynamic groups based on a subset of attributes available in the system. You can modify these default configurations to match the security policies of your organization.

The functionality to define and enforce permissions on the types of filters that are available to the users of V is provided through the following components:

• FilterScope objects - identifies a list of attributes and membership references that a filter may contain. The attributes contained within these FilterScope objects represent attributes that a given set of users have permission to use in filter definitions.

• A Filter Validation activity- validates the filter of an object against a FilterScope object to verify that all the attributes used in the filter are permitted.

• Management Policy Rules - defines which filter validation activity is applied for the specific request.

The FilterScope object is a FIM 2010 R2 Resource. It contains the following two important properties:

1. AllowedAttributes - a multivalued reference attribute that identifies the attributes that a target filter may contain.

2. AllowedMembershipReference - references to a set referencing other set or group objects that users are allowed to reference in their dynamic criteria such as ExplicitMember, ComputedMember, or Membersof.

The Filter Validation activity is a default, configurable authorization activity that validates an object’s filter against one or more FilterScope objects. It is through this activity that the FilterScope objects are applied as permissions in the system. The Filter Validation activity applies the filter permissions to the target objects for which the request is being performed. If the request is not authorized, a Permission denied error appears.

Considerations when designing management policy rules and workflows

When you design management policy rules or workflow for your environment, you should follow the following best practice recommendations:

• Keep the number of management policy rules in your environment to a minimum:

  • If two management policy rules use the same criteria (i.e. Initiator, Target, Operation, Attributes, etc.) consider combining them into a single MPR.

• Designing Action Workflows to act in the manner desired:

  • If a specific order of operation is required, include all activities in a single workflow definition.

  • Multiple action workflows called from a single MPR will be called in non-deterministic order by the workflow host.

Summary

In FIM 2010, MPRs are the main component of a flexible and customizable framework to deploy and manage your access policies in your environment. By using a policy-driven approach in combination with workflows for secondary authentication, authorization, and validation, you can take the classic access control implementation to a next level that is independent from the underlying protection mechanism and encompass the various states of your managed resources throughout the entire lifecycle.

For deploying access policies, you should allocate sufficient time to model your requirements. A key part of your FIM 2010 R2 system design is to correctly express your intended system behavior through MPRs, the intended object grouping through roles and state transition-related actions through set transition policies. As part of this process, the transformation of your requirements into logical policy statements helps you to simplify the transition of written statements into a technical implementation.