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

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 his 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 these 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. In FIM, each of these management policies are called Request Management Policy Rules, since in each case there is an event in which a particular requestor is trying to make changes to one or more resources. For more information, see ManagementPolicyRuleType Property.

The previous table showed described the company's policy in terms of the event definition and the workflows associated with that event. The next sections show each row of the table represented as a ManagementPolicyRule resource.

An Administrator or organization owner tries to update a Person attribute

The following table defines one policy in terms of the event definition and the workflows associated with that event.

Event Description	EVENT DEFINITION: Requestor	EVENT DEFINITION: Request Type	EVENT DEFINITION: Target of Request	RIGHT: Granting a Right?	WORKFLOWS: Additional requirements for request to succeed	WORKFLOWS: Additional consequences if the request succeeds
An Administrator or organization owner tries to update a Person attribute	Administrator or "Company Owner"	Update	Any Person attribute	Yes	Requestor enters their SmartCard when prompted (this is an example of an Authentication workflow).	(none)

The management policy shown in the preceding table would be represented by the following ManagementPolicyRule:

Xml

Copy Code

<ManagementPolicyRule> <ManagementPolicyRuleType>Request</ManagementPolicyRuleType> <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.

A manager tries to update the job title of one of their employees

Event Description	EVENT DEFINITION: Requestor	EVENT DEFINITION: Request Type	EVENT DEFINITION: Target of Request	RIGHT: Granting a Right?	WORKFLOWS: Additional requirements for request to succeed	WORKFLOWS: Additional consequences if the request succeeds
A manager tries to update the job title of one of their employees	Manager	Update	"jobTitle" attribute of a Person managed by this Person	Yes	(none)	(none)

The management policy shown in the preceding table would be represented by the following ManagementPolicyRule:

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.

Copy Code

<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.

A Person tries to update his own job title

Event Description	EVENT DEFINITION: Requestor	EVENT DEFINITION: Request Type	EVENT DEFINITION: Target of Request	RIGHT: Granting a Right?	WORKFLOWS: Additional requirements for request to succeed	WORKFLOWS: Additional consequences if the request succeeds
A Person tries to update his own job title	Person	Update	This Person's "jobTitle" attribute	Yes	Approval from the manager's manager is received (this is an example of an Authorization workflow).	An e-mail is sent to the person's manager confirming the change (this is an example of an Action workflow).

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 resource that models that management policy is shown below:

Xml

Copy Code

<ManagementPolicyRule> <ManagementPolicyRuleType>Request</ManagementPolicyRuleType> <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.

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:

The new management policy does not grant any rights, but defines an action workflow that is run every time that an update to an attribute of a Person object occurs. An example of a ManagementPolicyRule object that models that management policy is shown below:

Copy Code

<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.

However, assume that the organization decides to add an additional policy that does not grant rights:

• All Groups must have an owner. If a group does not have an owner, then the Administrator will be assigned as the owner.
  
  

This policy does not grant rights, so in that way it is similar to the previous management policy. However, in the case of this management policy, there are many different ways that a group could not have an owner. A new group could be created without an owner. A Group could be modified so that the owner is removed. The event that causes the Group not to have an owner may not even be the direct result of a change to the Group: the owner of a Group could leave the company. What matters is that one way or another the Group has entered a state in which it does not have an owner, and the policy indicates that the Administrator should be assigned as the owner of the group. You could create several different management policies to try to make sure that there was a management policy associated with every case in which a Group could not have an owner, but there is a much easier way to do this in FIM using a Set Transition Management Policy Rule (see ManagementPolicyRuleType Property). In general terms, the management policy could be described as shown in the following table:

To implement this policy, you would need to create Sets that include "All Groups" and "All People," and an Action workflow that changed the owner of a group. An example of a ManagementPolicyRule object that models that management policy is shown below:

Copy Code

<ManagementPolicyRule> <ManagementPolicyRuleType>SetTransition</ManagementPolicyRuleType> <PrincipalSet>Reference to “All Groups" Set</Principal> <ActionType>TransitionOut</ActionType> <ActionParameter>Owner</ActionParameter> <ResourceCurrentSet>Reference to “All People" Set</ResourceCurrentSet> <GrantRight>false</GrantRight> <Disabled>false</Disabled> <ActionWorkflowDefinition>Reference to a custom “Assign FIM Administrator as New Group Owner" action WorkflowDefinition</ActionWorkflowDefinition> </ManagementPolicyRule>

In the above example, we are defining a transition in which the Owner attribute of a group is no longer in the list of valid "Person" resources. In other words, the owner of the Group transitions out of the set of valid "Person" resources.

For more information about Set Transition ManagementPolicyRule resources, see ManagementPolicyRule.