Input Transformation
Input Transformation Policies handle the conversion of data formats provided by the application shim to those expected by DirXML engine. The conversions include attribute value format and XML vocabulary, and status messages and documents are handled as with the Output Transformation policies, but with the flow reversed.
Name |
Driver |
Channel |
Description |
|
Push Back On Email |
Any |
Publisher |
Reset email value to source value when add or modify is not from authoritative source. |
Output Transformation
Output Transformation Policies handle the conversion of the data formats provided by the DirXML engine to those expected by the application shim. This includes attribute value format conversion and XML vocabulary conversion. There is custom handling of status messages returned from the DirXML engine to the application shim. All documents supplied to the application shim by the DirXML engine pass through the Output Transformation Policies.
Name |
Driver |
Channel |
Description |
|
No policies currently available |
Event Transformation
Event Transformation Policies alter DirXML's view of what happened. The most common task to perform in an Event Transformation Policy is custom filtering. You can use custom filtering to remove unwanted event types or remove events for objects that are out of scope, based on location or attribute. Event Transformation Policies can also alter events in other ways. Remember that altering an event changes DirXML's view of what happened, which only indirectly changes what DirXML is going to do about it.
Command Transformation
Command Transformation Policies alter the commands that DirXML sends to the destination datastore. Commands can be substituted, such as changing the delete command to modify or move, or disabling it. Commands can also be added to perform additional actions as the result of an attribute change. Most things that don't fit neatly into the descriptions of any of the the other policies belong here. Often, the things you would tend to put in Event Transformation or Input Transformation Policies really belong in the Command Transformation Policies.
Name |
Driver |
Channel |
Description |
|
Set Email By Given Name And Surname |
Any |
Any |
Set email address based on the employee's given name and last name. |
|
Uppercase Names |
Any |
Any |
This policy is used to conver a user's first and last name to uppercase. |
|
Add Create Groups |
Any |
Publisher |
Policy which adds a user to the appropriate group with the appropriate rights based on met criteria. |
|
Group Change On Title Change |
Any |
Publisher |
This policy changes a user's group membership when defined criteria for that group is no longer met (i.e. a manager changing to an employee). |
|
Disable Move On Termination |
Any |
Publisher |
Disable and move user object when user's account is disabled. |
Create
Creation Policies control when and how a new object is created in the destination datastore, based on an unassociated object in the source datastore. This can be used to veto creation of objects that don't qualify as meeting the policy conditions. The absence of a policy implies consent. The Creation Policy may provide default attribute values and may provide a default password. You can specify template objects for use in the creation process. Creation Policies are always supported for creating objects in the Identity Vault, and they can be supported by any application shim.
Name |
Driver |
Channel |
Description |
|
Required Attributes |
Any |
Any |
This policy defines required attributes for user object creation. |
|
Synthesize Full Name |
Any |
Any |
This policy formats full name as surname, given name (i.e. smith, john). |
|
Assign Template By Title |
Any |
Publisher |
This policy assigns the appropriate template to a user when certain criteria is met. |
Matching
Matching Policies look for an object in the destination datastore that corresponds to an unassociated object in the source datastore. This is not always needed or desired. An initial migration occurs when there are pre-existing, corresponding objects in both datastores, and objects may originate in either datastore. A Matching Policy must be carefully crafted to ensure that the Matching Policy doesn't find false matches.
Name |
Driver |
Channel |
Description |
|
By Given Name And Surname |
Any |
Any |
This policy defines a matching policy based on given name and surname. |
Placement
Placement Policies control where a new object should be created in the destination datastore and what the new object should be named. Placement Policies may not be needed, depending on the nature of the destination datastore. However, they are always needed on the publisher channel.
Name |
Driver |
Channel |
Description |
|
By Surname |
Any |
Publisher |
This policy defines the user object placement based on the first character of the user's last name. the policy also generates nsure audit events. |
Solutions
A solution is a collection of policies and tools that work together to achieve specific functionality. When you customize a policy, make sure that the customization is compatible with the other components in the solution. The information provided in each solution explains where you should install the components.
Name |
Description |
|
Challenge Set Driver |
Implementation of the Loopback driver to define challenge set questions and responses. Contains the driver configuration, supporting classes and documentation. |