Rewriting target system operations
You can use a plugin to rewrite requested operations on target systems. The plugin accepts information about requested actions, and maps them to 0 or more sub-actions on specified target systems; for example, a single update operation can be translated into an update and rename operation on a target system. This plugin works in a similar way to the request rewrite plugin , which rewrites requests before they have been approved.
The operation rewrite plugin suits situations where authorizers do not need to know the details of the rewrite.
A common use case best describes the need for operation rewrites. Upon employee termination, many organizations do not delete users’ system accounts. Instead, accounts are disabled for a certain amount of time before they are deleted, and the user may be removed from security groups. On some systems, the user is moved into a special group or organizational unit.
Implementation of such business rules requires a plugin that can translate one operation into other type of operation or operations. In the example provided above, Bravura Identity needs to translate the delete (DELU) operation in two separate operations; for example, disable (DNAU) and group user delete (GRUD). See Operation codes.
The operation rewrite plugin point is used by the Transaction Monitor Service (idtm) since it is responsible for executing operations by using Bravura Identity connectors.
The plugin used by the operation rewrite plugin point is responsible for investigating the request submitted by the end user and determining if the operation requires re-writing. If the operation does not require re-writing, it is then executed by the Transaction Monitor Service. If the operation requires re-writing, the plugin instructs the idtm to execute additional or alternative operations.
Some of the common operation rewrites include:
Delete > disable
Delete > group membership change
Delete > OU context move
Attribute update > group membership change
Implementation of the operation rewrite plugin point should be considered carefully and properly tested because the plugin point is used for every operation executed by the Transaction Monitor Service.
To use this plugin, type the name of the plugin in the IDTM BATCH OPREP PLUGIN field on the Transaction Monitor Service configuration page.
There are no shipped plugins in use with this plugin point.
Requirements
See Writing plugins for general requirements. See Operation codes for a list of operation codes and their meaning.
Execution points
When configured, an operation rewrite plugin is run by the Transaction Monitor Service after a request has been approved, and just before the actual operation would usually be executed (that is, by running the connector).
Input
In the following examples, user Auth4 is to be deleted from target system ADCANADA, and the result is that the user’s account is disabled and removed from the manager group.
Following is the input expected by the plugin:
"" "" = {
"batch" "20070503-113234-00" = { # Used in idtm and idwfm. Do not change.
"action" "20070503-113234-00_0" = { # Used by idwfm. Do not change for
# the primary action
"accountid" = "Auth4" # Account name
"fname" = "" # Full name used for create user operation
"groupid" = "" # Group ID on the target
"groupname" = "" # Used for group operations
"homeDir" = ""
"hostid" = "ADCANADA" # Target Id
"interactive" = "false" # Determines priority. The idtm service runs interactive jobs before non-interactive jobs.
"modelHomeDir" = ""
"modelid" = "" # The template ID (as entered in Workflow -> Template accounts)
"modelShare" = ""
"newpw" = "" # Password (encrypted). Required for Password Admin Reset and Password Admin Reset expire operations.
"operation" = "DELU" # Operation code
"replyid" = "eca0000000000000ff" # Tells idwfm the status of the operation
"share" = ""
"userid" = "AUTH4" # User name on the target
"depends" "" = { # Dependency for an added action. This KVGroup should
# be empty for the primary operation.
}
}
}
"recipient" "user" = { #The profile of the recipient
"ID" = "AUTH4"
"NAME" = "Auth 4"
}
"request" "" = {
"certround" = ""
"entryDate" = "456c5e5c"
"finalID" = "AUTH4"
"IDApprover" = ""
"initialID" = "AUTH4"
"macroStatus" = "Approved, performing requested operations"
"notes" = ""
"reason" = ""
"recipientEmail" = "Auth4@yan.local"
"requester" = "AUTH2"
"requesterEmail" = "auth2@yan.local"
"requesterName" = "Auth2"
"requestID" = "20061128-110548-00"
"reservationid" = "" # Output by attribute validation and idsynch id plugins
"authorizer" "AUTH1" = {
"actualAuthorizer" = "AUTH1"
"reason" = ""
"remindersSent" = "1"
"resource" = "4F12FA11531BCBC574BC4C4295D4872E"
"status" = "A"
}
"resource" "4F12FA11531BCBC574BC4C4295D4872E" = {
"authorizationsReceived" = "1"
"authorizationsRequired" = "1"
"authorizer" = "AUTH1"
"itemType" = "accountID"
"notes" = ""
"operation" = "DELU"
"result" = "I"
"accountID" = "doe.john"
"targetid" = "AD"
}
}
} Some operations – for example update template – require a main attribute KVGroup:
"attributes" "" = {
"<attribute name>" = "<value>"
"<attribute name>" = "<value>"
...
} replyid
The replyid is a unique ID the Transaction Monitor Service service uses to tell the Workflow Manager Service service when a particular action related to a request is completed. If a replyid is not specified, then idwfm is not informed. This generally occurs when an operation is "fanned out". For example operation rewrite can turn one action into many. A disable action can become a disable plus adding a user to a group. The disable action would keep its replyid but the add user action would be orphaned since a replyid can only be used once. See Rewriting custom requests for a solution to this if required.
Output
Following is an example of the plugin output:
"" "" = {
"changed" = "true" # Must be true if anything has changed. If not, the change is not committed.
"retval" = "0" # 0=success. If an error occurs, the value is automatically set according to error type.
"batch" "20061128-110548-00" = { # Must be kept untouched from input
"action" "20061128-110548-00_0" = { # Do not change for the primary action
"accountid" = "Auth4"
"fname" = ""
"groupid" = ""
"groupname" = ""
"homeDir" = ""
"hostid" = "ADCANADA"
"interactive" = "false"
"modelHomeDir" = ""
"modelid" = ""
"modelShare" = ""
"newpw" = ""
"operation" = "DNAU"
"replyid" = "eca0000000000000ff"
"share" = ""
"userid" = "AUTH4"
"depends" "" = {# This should be empty for the primary action
}
}
"action" "20061128-110548-00_2" = { # Action ID for fanned action
"accountid" = "Auth4"
"fname" = ""
"groupid" = "CN=manager,OU=CANADA,DC=yan,DC=local"
"groupname" = ""
"homeDir" = ""
"hostid" = "ADCANADA"
"interactive" = "false"
"modelHomeDir" = ""
"modelid" = ""
"modelShare" = ""
"newpw" = ""
"operation" = "GRUD"
"replyid" = "" # Empty for the fanned action
"share" = ""
"userid" = "AUTH4"
"depends" "" = {# For the fanned action, this is required if
# the new action is processed only when the primary action
# returns success.
"local" "" = {
"action" = "20061128-110548-00_0"
"batch" = "20061128-110548-00"
}
}
}
}
} If there is any syntax error, idtm will ignore the whole operation rewrite script and processes the primary action. An error message is written to the log.
If one key is missing – for example "accountid" – and the action must have this value, an error message is displayed on the web interface to indicate what is missing in which action.