Using pseudo operations

In some organizations the creation of accounts, additions to groups, or role changes are known to users only at an abstract level. Showing what modifications are going to be done is:

Potentially excessive
Potentially time-consuming to have the authorizer sift through the information to determine what is “really” being requested
Confusing for end users who “just want to do what sales people do”

Bravura Security Fabric allows you to display pseudo operations that describe what is being done at an abstract level as part of a request. The operations can be searched on and audited, but nothing is actually done by any connector. Pseudo operations simply allow end users to understand what is being requested even if they do not understand the details.

They can be standard operations that contain pseudo data; for example to add a user to a group that doesn’t actually exist on a target system. They can also be completely customized operations; for example, users can request to “update a user” to make them the new “floor fire marshal”.

The request rewrite plugin must be used to generate output for a pseudo operation. That information can then be used to display details of the request to users, and as input for the workflow view modification plugin . The Abstract modifications use case in Modifying how operations are viewed illustrates how pseudo operations are used.

How plugins handle pseudo operations

Input

Plugins receive information about pseudo operations in three key-value pairs within the main "request" KVGroup:

"request" "" = {
     ...
  "resource" "<resource identifier>" = {
    "authorizationsReceived" = "<number of authorizations received>"
    "authorizationsRequired" = "<number of authorizations required>"
    "authorizer" = "<authorizers for this resource>" ⋆
         
    "notes" = ""  # empty - only filled in upon provisioning
    "operation" = "<operation code>"
    "pseudoData" = "<Data for replacement in pseudoTag>"
    "pseudoOp" = "true|false" #Is this a pseudo Operation?
         # If true, this operation is NOT handled by idtm
    "pseudoTag" = "<m4 tag for display in the GUI>"
    "result" = "<status of the resource>"
    "itemType" = "<item type>"
    ...
    }
 }

See Request data for a listing of the full request KVGroup.

Data about pseudo operations is included in the reqacct table along with other operations data. Any normally requested operation, such as create and update, can be passed in as a pseudo operation. For example:

    "operation" = "GRUA" #add the user to a group
    "pseudoData" = ""
    "pseudoOp" = "true" #The group does not exist on a target system.
    "pseudoTag" = ""

Custom operations

You can also use custom operation tags CUST1, CUST2, CUST3 for requests that are not standard to Bravura Security Fabric . For example:

    "operation" = "CUST1" #Update the user
    "pseudoData" = "Fire marshal"
    "pseudoOp" = "true" #
    "pseudoTag" = ""

You can customize the description for these operations in M4 files, so that they can be displayed and searched on as request types in the Bravura Security Fabric user interface.

Note

These operations differ from the OPC1, OPC2, OPC3, and OPC4 operations, which can be used to trigger events resulting from input to custom fields in the user interface.

To use pseudo data with standard operations, customize:

!!!JOB_SEARCH in batchmod.m4 to allow it to be specified
The _BATCHMOD_PSEUDO_DATA_ tag in en-us-language.kvg
The BATCHMOD_PSEUDO_DATA tag in en-us-errmsg.kvg

To use custom operations, customize:

!!!JOB_SEARCH_OPERATION_OPTIONS in batchmod.m4
One or more of the following in en-us-language.kvg :
_BATCHMOD_SELECT_CUST1_
_BATCHMOD_SELECT_CUST2_
_BATCHMOD_SELECT_CUST3_
One or more of the following in en-us-language.kvg:
_BATCHMOD_REQ_CUSTOM1_ACCT_
_BATCHMOD_REQ_CUSTOM2_ACCT_
_BATCHMOD_REQ_CUSTOM3_ACCT_
One or more of the following in batchmod.kvg :
!!!BATCH_LONG_CUSTOM1_ACCT_ROW
!!!BATCH_LONG_CUSTOM2_ACCT_ROW
!!!BATCH_LONG_CUSTOM3_ACCT_ROW
Customize messages in en-us-errmsg.kvg for:
REQACCT_OPERATION_CUST1
REQACCT_OPERATION_CUST2
REQACCT_OPERATION_CUST3
Customize messages in en-us-errmsg.kvg for:
REQOPERTYPE_CUST1
REQOPERTYPE_CUST2
REQOPERTYPE_CUST3
Customize messages in en-us-errmsg.kvg for:
WF_REQACCT_DESC_CUSTOM1
WF_REQACCT_DESC_CUSTOM2
WF_REQACCT_DESC_CUSTOM3

Below is an example of customized batchmod.m4:

!!!JOB_SEARCH_OPERATION_OPTIONS
<!-- JOB_SEARCH_OPERATION_OPTIONS -->
<SELECT name="SEARCH_OPERATION">
   <OPTION value="" %NONE_SELECTED%>_BATCHMOD_SELECT_NONE_
   <OPTION value="RLUA" %RLUA_SELECTED%>_BATCHMOD_SELECT_RLUA_
   <OPTION value="ACUA" %ACUA_SELECTED%>_BATCHMOD_SELECT_ACUA_
   <OPTION value="UPDT" %UPDT_SELECTED%>_BATCHMOD_SELECT_UPDT_
   <OPTION value="DELU" %DELU_SELECTED%>_BATCHMOD_SELECT_DELU_
   <OPTION value="TERM" %TERM_SELECTED%>_BATCHMOD_SELECT_TERM_
   <OPTION value="RENU" %RENU_SELECTED%>_BATCHMOD_SELECT_RENU_
   <OPTION value="MVCU" %MVCU_SELECTED%>_BATCHMOD_SELECT_MVCU_
   <OPTION value="ENAU" %ENAU_SELECTED%>_BATCHMOD_SELECT_ENAU_
   <OPTION value="DNAU" %DNAU_SELECTED%>_BATCHMOD_SELECT_DNAU_
   <OPTION value="GRUA" %GRUA_SELECTED%>_BATCHMOD_SELECT_GRUA_
   <OPTION value="GRUD" %GRUD_SELECTED%>_BATCHMOD_SELECT_GRUD_
   <OPTION value="GROA" %GROA_SELECTED%>_BATCHMOD_SELECT_GROA_
   <OPTION value="GROD" %GROD_SELECTED%>_BATCHMOD_SELECT_GROD_
   <OPTION value="CRTG" %CRTG_SELECTED%>_BATCHMOD_SELECT_CRTG_
   <OPTION value="DELG" %DELG_SELECTED%>_BATCHMOD_SELECT_DELG_
   <OPTION value="CUST1" %CUST1_SELECTED%>_BATCHMOD_SELECT_CUST1_
<!--   <OPTION value="CUST2" %CUST2_SELECTED%>_BATCHMOD_SELECT_CUST2_ -->
<!--   <OPTION value="CUST3" %CUST3_SELECTED%>_BATCHMOD_SELECT_CUST3_ -->
</SELECT>
!!!BATCH_LONG_CUSTOM1_ACCT_ROW
<!-- BATCH_LONG_CUSTOM1_ACCT_ROW -->
  <TR>
    TABLE_TDBD
     Available for replacement are:
     HostId(%HOST_ID%) (target ID) ACCT_ID(%ACCT_ID%) (long ID) ACCT_NAME(%ACCT_NAME%) (user fullname)
     SRC_ID(%SRC_ID%) TFR_ID(%TFR_ID%) GROUP_ID(%GROUP_ID%)
     REQ_OPERATIONS(%REQ_OPERATIONS%) PSEUDO_DATA(%PSEUDO_DATA%) PSEUDO_TAG(%PSEUDO_TAG%) %DETAILS_BUTTON%
      &nbsp;
    TABLE_TDE
  </TR>

Below is an example of customized en-us-errmsg.kvg:

"language" "EN_US" = {
  "codepage" = "28591"
  "encoding" = "iso-8859-1"
  "version" = "fox 1234"
  "REQACCT_OPERATION_CUST1" "" = {
    "text" = "Cust1 is in the dropdown"
  }
  "REQOPERTYPE_CUST1" "" = {
    "text" = "Cust1 description"
  }
  "WF_REQACCT_DESC_CUSTOM1" "" = {
    "text" = "reqacct custom1 description"
  }
  "CUSTOM_PSEUDO_TAG" "" = {
    "text" = "contents of the tag that is the pseudo data"
  }
  "CUSTOM_TAG_OKAY" "" = {
    "text" = "contents of the OKAY tag that is the pseudo data"
  }
}

Below is an example of customized en-us-language.kvg:

"language" "EN_US" = {
  "codepage" = "28591"
  "encoding" = "iso-8859-1"
  "version" = "fox 1234"
  "_BATCHMOD_REQ_CUSTOM1_ACCT_" "" = {
    "text" = "This introduces custom1 requests (customized)"
  }
  "_BATCHMOD_SELECT_CUST1_" "" = {
    "text" = "Search for cust1 (I'm in the dropdown)"
  }
  "_BATCHMOD_PSEUDO_DATA_" "" = {
    "text" = "Here is the intro to the pseudo data:"
  }
}

Output

The output for the plugin is:

"" "" = {
  "errmsg" = ""
  "retval" = "<N>" # 0 is success, non-0 is failure.
  "resource" "" = {
    ...
   }
}

There may be 0 or more resource KVGroups. The resources returned will replace the ones in the request. If you do not want to modify the request, all resources passed into the plugin must be returned as output.

The format and contents of the resource KVGroup should be the same as the input would be if the resource was part of a normal request. It is recommended that you issue a request for the resource requested to gather the input format for that specific operation.

In this section:

Using pseudo operations

How plugins handle pseudo operations

Note

Search results