Management Policy Example

Defining management policy in a general sense involves defining both business events and system conditions, and then specifying the procedures that should be followed when those events or conditions occur. More simply stated; when this occurs, that process is performed.

Here are some examples that illustrate this relationship:

• "When a new employee is hired, we follow this process . . ."

• When an employee moves to Shanghai, we…"

• "When an authenticated user asks to join a group, we . . ."

• "When someone requests to add a new object type to the database, we…"

• "When a user requests to read confidential data, we . . ."

• "When an employee changes jobs within the company, we . . ."

• "When a contractor leaves the company, we…"

• "When an employee changes personal information, we…"

Consider the general event about an employee changing personal information such as their telephone number or address. The business policy might need to broken down into more specific sub-events, if different procedures have to be followed depending on the employee making the request, which personal information is being changed, or whose information is being changed. In each situation, the policy must clearly define who has the rights to perform what actions on which resources. The overall management policy for a system can be considered to be the total collection of all these events and policies, with some way to resolve cases in which more than one policy applies to what is occurring to the system.

The next section gives an example of defining a small set of management policies in general terms that are easy to compare with the way that Forefront Identity Manager (FIM) implements management policy. FIM implementation is described in detail in later sections.

Management Policy Example

General Management Policy Solution

This example shows how an enterprise might begin defining and planning an implementation of a simple management policy in terms of events.

An organization has a management policy regarding which people may modify personnel data. Specifically, one part of the management policy defines which people are allowed to change the "jobTitle" attribute of a person in the database as follows:

• People who are FIM administrators or organization owners can change any attribute of any person if they enter their registered SmartCard when prompted.

• People that are managers can change the job title of any person who they directly manage.

• A person can change their own job title with approval from a manager. Once the change is made, an e-mail is sent to the manager confirming the change.

• All other requests to change the "jobTitle" attribute are not allowed.

In this example, each of these four cases can be considered different events or management policies. The procedure that is followed when a person requests to change a "jobTitle" in the database depends on the role of the requestor (administrator, manager, or person) and the relationship to the person whose data is being changed. Consider that the requestor could be trying to change their own data, the data of an employee the requestor manages, or the data of another employee whom the requestor does not manage. In this example, any specific events that are not defined in the following table are not allowed by the system. Furthermore, all of the different requestor types are also Person objects in the system. Each of the previous management policies are concerned with granting rights. Therefore, there is another column to indicate this. Management policies that do not grant rights are discussed later in this section. A simple representation of the events in which updates to "jobTitle" attribute are allowed is shown in the following table:

Each row of the table represents a different event. In this table, the combination of Requestor, Request Type, and Target of Request columns define the event, which is summarized in the "Event Description" column. The last two columns indicate additional processes (FIM refers to these as "workflows") that are associated with the event. The type of each workflow in the table as defined in FIM (Authentication, Action, and Authentication) is noted. The column headings indicate whether the data in that column forms part of the event definition, rights, or workflows of the management policy. Each of the events defined in the table grant rights to a specific set of requestors to perform specific actions on specific resources.

However, assume that the organization decides to add an additional policy:

• Any changes to Person attribute values are logged to a file.

To implement this policy, you would need to create an Action workflow to log the change to a file. However, you have another decision to make – which management policies should include this workflow? One option is to add the workflow to each row of the table and any rows that are later created that have to do with modifying Person attributes. Another option is to create another row that represents the new management policy but has a "false" in the "RIGHTS" column. Each event in the table created earlier was granting a right to a specific set of requestors to perform specific actions on specific resources. This new event is not being used to do that; it is important because it triggers an additional workflow (logging data to a file).

In the management policies defined in the above table, if an administrator modifies their own "jobTitle", two different management policies apply: the management policy that applies to administrators modifying any Person object (in this case the Person object represents themselves), and the management policy that applies to an employee modifying their own job title. In FIM, all of the workflows associated with every management policy that is relevant to a request will be run when the request is processed. If a workflow is included in more than one of those management policies it will be run once for each management policy that includes it (see Request Processing). If you add the new Action workflow to each row of the table, every time an Administrator modifies their own "jobTitle," the change will be logged twice. Instead of adding our workflow to multiple rows of the table, you will create a new management policy rule that does not grant any rights to users to change Person attributes but causes the Action workflow to be run each time Person attributes are changed. The new management policy would look like the following:

This example showed how a small set of management policies could be defined in general terms that are easy to compare to FIM management policy. The rest of this document shows how to implement the previous examples in FIM.

Implementing Example Management Policy in FIM

This section shows how the previous management policy would be implemented in FIM.

In FIM, a ManagementPolicyRule is used to define an event and the rights and workflows that apply to that event. Each event listed in the example management policy in the previous section could be represented by a different ManagementPolicyRule. That object would define the event, including the sets the requestor belongs to (the "PrincipalSet…" attributes), the type of request, for example Update or Delete, and the target of the request (through the combination of various "Resource…" attributes). The "GrantRights" Boolean is used as described in the example to indicate which ManagementPolicyRule objects are granting rights and which are not. If the "GrantRight" attribute is set to true, the attributes that are part of the event definition ("Principal…", "Action…", and "Resource…" attributes) grant rights to a specific set of principals to perform a specific action or actions on a specific set of resources (and the type of change to the resource may be further limited by the "ResourceFinalSet…" attributes). If "GrantRight" = false, that ManagementPolicyRule does not grant rights (nor deny them). Instead of granting rights, that ManagementPolicyRule might be used to assign workflows to the event. An example of this type of ManagementPolicyRule is shown an example in this section and in some of the examples in Working with ManagementPolicyRule Objects.

The following management policy was discussed in the previous section:

• People that are FIM administrators or organization owners can change any attribute of any person if they enter their registered SmartCard when prompted.

An example of a ManagementPolicyRule object that models this management policy in FIM is shown below:

<ManagementPolicyRule>
<PrincipalSet>Reference to a custom "All FIM Administrators and organization owners" Set</PrincipalSet>
<ActionType> Update</ActionType>
<ActionParameters>*</ActionParameters>
<ResourceCurrentSet>Reference to "All Users" Set</ResourceCurrentSet>
<ResourceFinalSet>Any</ResourceFinalSet>
<GrantRight>true<GrantRight/>
<AuthenticationWorkflowDefinition>Reference to a custom "SmartCard Authentication" WorkflowDefinition</AuthenticationWorkflowDefinition>
</ManagementPolicyRule>

Note that to create this object, the objects following must have already been created:

• A custom Set that represents all FIM Administrators and organization owners

• A Set that contains all Person objects (the default "All Users" set).

• A custom WorkflowDefinition that defines an authorization workflow that involves entering a SmartCard when prompted.

Since the "ResourceCurrentSet" attribute points to a set that contains all Person objects, an "ActionParameters" value of "*" indicates that this management policy applies to all attributes of a Person object.

The following management policy was discussed in the previous section:

• A person can change their own job title with approval from their manager. Once the change is made, an e-mail is sent to the manager confirming the change.

In this example the resource that the person wants to change is defined in terms of the person making the request. In this case, rather than using the "ResourceCurrentSet" and "ResourceFinalSet" optional attributes, the "ResourceCurrentSetRelativeToPrincipal" and "ResourceFinalSetRelativeToPrincipal" must be used instead (exactly one "ResourceCurrentSet…" attribute and one "ResourceFinalSet…" attribute can be defined in a ManagementPolicyRule object). An example of a ManagementPolicyRule object that models that management policy is shown below:

<ManagementPolicyRule>
<PrincipalSet>Reference to "All Users" Set</PrincipalSet>
<ActionType>Update</ActionType>
<ActionParameters>jobTitle</ActionParameters>
<ResourceCurrentSetRelativeToPrincipal>/Principal/ObjectId</ResourceCurrentSetRelativeToPrincipal>
<ResourceFinalSetRelativeToPrincipal>/Principal/ObjectId</ResourceFinalSetRelativeToPrincipal>
<GrantRight>true</GrantRight>
<AuthorizationWorkflowDefinition>Reference to a custom "Get Manager Authorization" WorkflowDefinition</AuthorizationWorkflowDefinition>
<ActionWorkflowDefinition>Reference to a custom "Notify Manager of Update to jobTitle" WorkflowDefinitionWorkflowDefinition</ActionWorkflowDefinition>
</ManagementPolicyRule>

Note that this object contains references to custom workflows that must be created, and that "jobTitle" is already a default attribute of a Person object.

The following management policy was discussed in the previous section:

• People that are managers can change the "jobTitle" of any Person that they directly manage.

This example is more difficult to implement using the default object schema. A Person object has a "manager" attribute, so it is possible to use the "ResourceCurrentSetRelativeToPrincipal" attribute to refer to a user's manager, as shown in an earlier example. However, the default Person does not have a link to all of the people that report directly to that person. In order to implement this management policy using the default schema, you would need to create a set for each manager that includes the people who report directly to that manager. Then you would create one ManagementPolicyRule for each manager that would use that manager as the "PrincipalSet" and the set containing people who report directly to them in the "ResourceCurrentSet" and "ResourceFinalSet" attributes.

<ManagementPolicyRule>
<PrincipalSet>Reference to a custom Set object that only contains the Person object associated with this manager</PrincipalSet>
<ActionType>Update</ActionType>
<ActionParameters>jobTitle</ActionParameters>
<ResourceCurrentSet>Reference to a custom Set object that contains this manager's direct reports.</ResourceCurrentSet>
<ResourceFinalSet>Reference to a custom Set object that contains this manager's direct reports.</ResourceFinalSet>
<GrantRight>true</GrantRight>
</ManagementPolicyRule>

If the Sets that contain the people that manager supervises are dynamic then as soon as an employee's "Manager" field is updated, the set will be updated. To fully implement the above example, either these sets and the ManagementPolicyRule objects that use them would need to be created and deleted manually (when a manager is created, deleted, or stops being a manager) or a workflow would need to be created that creates or deletes the appropriate Set and ManagementPolicyRule objects.

The following management policy was discussed in the previous section:

Any changes to Person attribute values are logged to a file.

<ManagementPolicyRule>
<PrincipalSet>Reference to All Users" Set</PrincipalSet>
<ActionType>Update</ActionType>
<ActionParameters>*</ActionParameters>
<ResourceCurrentSet>Reference to "All Users" Set</ResourceCurrentSet>
<ResourceFinalSet>Reference to "All Users" Set</ResourceFinalSet>
<GrantRight>false</GrantRight>
<ActionWorkflowDefinition>Reference to custom "Log User Attribute Changes" WorkflowDefinition</ActionWorkflowDefinition>
</ManagementPolicyRule>

Note that this object contains references a custom workflow that must be created.

The previous example is an example of a management policy that does not grant rights ("GrantRight"=false). Instead, the management policy associates an action workflow with the update event.

See Also

Concepts

ManagementPolicyRule
Working with ManagementPolicyRule Objects