Filter requests
Bravura Security Fabric can hide certain requests from recipients and authorizers. For example, you may want to prevent recipients from viewing requests for the termination of their accounts, or you may want to prevent workflow managers in Houston from working on requests submitted for users in Calgary.
Bravura Security Fabric can run a request filter plugin when a request is made, to determine whether a request should be hidden from users.
This plugin is set by the Modules > Options > FILTER REQUEST PLUGIN field.
There are no shipped plugins in use with this plugin point.
Requirements
See Writing plugins for general requirements.
Execution points
This plugin is run by the Requests app and Workflow Manager Service.
Filter plugins operate differently from most plugins, which are synchronous. All filter plugins support asynchronous calling. There are two forms of asynchronous calling:
Standard input/output mode that processes standard filter plugin input/output.
Callback mode that uses two functions to process the input/output.
This mode can be used to reduce processing time in environments with large numbers of users.
In standard input/output (stdio) mode, filter plugins work in the following way:
An event triggers a CGI program to call the plugin program or script and sends it standard user data.
The calling program continues to stream input from stdin, one item at a time until there are no more items.
For each item, the plugin returns the filter result to stdout.
The calling program receives the final standard output and continues.
Input
Input is similar for all resource filter plugins. The plugin first receives standard data in the format:
"" "" = {
"sessionid" = "<session ID>" # The session ID of the request.
"module" = "<idr|ids|idp|idwfm>"
"accountID" = "<account ID>" # The account ID of the recipient.
"template = "<template ID>" # The selected template ID.
"targetid" = "<target ID>" # The target ID for the recipient.
"navigation" "" = { ... } # User navigation data
"recipient" "<user|empty>" = {
# The "recipient" group contains standard information about the
# subject of the request.
}
"viewer" "user" = {
# The "viewer" group contains standard information about the
# person using the CGI.
}
"request" "" = {
# The "request" group contains standard information about the
# the request.
}
} Some of the values above may be empty, due to the stage and type of the request.
The plugin then receives a series of KVGroups; one for each item.
For example:
"request" "" = {
"entryDate" = "1218736546"
"macroStatus" = "G"
"notes" = ""
"reason" = ""
"recipient" = "steven.benes"
"recipientEmail" = "steven.benes@norse.bravurasecurity.com"
"requestID" = "2048"
"requester" = "steven.benes"
"requesterEmail" = "steven.benes@norse.bravurasecurity.com"
"requesterName" = "Steven Benes"
"reservationid" = "00000000-0000-0000-0000-000000000000"
"segment" = "0"
"attribute" "EMAIL" = {
"value" "" = {
}
}
"attribute" "END_TIME" = {
"value" "" = {
"value" = "2008-08-14 13:55:00"
}
}
"attribute" "FIRST_NAME" = {
"value" "" = {
}
}
"attribute" "LASTLOGON" = {
"value" "" = {
}
}
"attribute" "LAST_NAME" = {
"value" "" = {
}
}
"attribute" "OTHER_NAME" = {
"value" "" = {
}
}
"attribute" "START_TIME" = {
"value" "" = {
"value" = "2008-08-14 12:55:00"
}
}
"attribute" "TELEPHONE" = {
"value" "" = {
}
}
"attribute" "VIEWABLE_BY_RECIPIENT" = {
"value" "" = {
}
}
"authorizer" "steven.benes" = {
"actualAuthorizer" = ""
"reason" = ""
"remindersSent" = "0"
"resource" = "4F12FA11531BCBC574BC4C4295D4872E"
"status" = "I"
}
"resource" "4F12FA11531BCBC574BC4C4295D4872E" = {
"authorizationsReceived" = "0"
"authorizationsRequired" = "1"
authorizer" = "steven.benes"
"itemType" = "accountID"
"notes" = ""
"operation" = "ARCHREQPWD"
"pseudoData" = ""
"pseudoOp" = "false"
"pseudoTag" = ""
"result" = "K"
"accountID" = "backdoor"
"targetid" = "NORSE"
}
}See Request data for a description of the request KVGroup.
Output
For each item, one output KVGroup is expected on stdout, with an optional "filter" = "true" pair to indicate that the item should not be displayed:
"" "" = {
"filter" = "true|false"
# If false, the user is displayed
# If true, the user is not displayed
"retval" = "<#>"
# Optional, if non-zero returned, abort the plugin
"sendactions" = "1|0"
# If 1, the detailed "resource" kvgroup is included in the input of
# the next request. By default, it is set to 1.
# If 0, the detailed "resource" kvgroup is not included in the input
# of the next request.
"sendattrs" = "1|0"
# If 1, the "attribute" KVGroups are included in the input of the
# next request.
# If 0, the "attribute" KVGroups are not included in the input of the
# next request. By default, it is set to 0.
} The sendactions and sendattrs items can only be used in call back mode if you express $detail as a KVGroup. See Callback mode below for details.
A plugin that encounters errors in its processing can add standard output pairs for individual items, which should cause the plugin execution to be aborted.
In callback mode the request filter plugin uses two functions:
OnFilterInit(const $inkvg, output $detail) This function is called once to initialize the environment based on the request.
$inkvg– the viewer$detailif 0, only "resource" detail is provided on input kvg for each request
if 1, both "resource" and "attribute" details are provided on input kvg for each request
can also be expressed as a KVGroup, see the example below
OnItemFilter(const $inkvg, output $msg, output $allow) This function is called once per item to determine what requests the user can view or manage.
$inkvg– the request to filter$msg– error message$allowif 1, this request is displayed and available
if 0, this request is not displayed and is unavailable
Examples
Using integer for $detail:
function OnFilterInit( const $inkvg, output $detail ) { $detail = 0; }Using KVGroup for $detail:
function OnFilterInit( const $inkvg, output $detail ) { $detail = kvgCreate( "", "" ); kvgAddValue( $detail, "sendactions", "1" ); kvgAddValue( $detail, "sendattrs", "1" ); }