Skip to main content

Modifying general behavior

The following sections describe behaviors you can set globally for consoles and modules. Navigate to Manage the system > Modules > Options to access the Module options page.

Automatic storage/retrieval of field values

After initial login, users may find it useful if some fields are automatically filled in on subsequent logins. Bravura Security Fabric can recognize users and automatically populate certain fields, such as the number of records to display on search pages, using cookies or its database.

Note

The database method will not work if proxy servers are being used. Bravura Security Fabric uses IP to recognize users and retrieve information.

Enable the following options:

AUTO SET COOKIE

to store previously entered values on cookies on a user’s workstation.

AUTO FILL SET COOKIE MODULE EXACT

to store previously entered module-specific values.

AUTO FILL SET COOKIE USER EXACT

to store previously entered user-specific values.

AUTO FILL COOKIE

to retrieve values from cookies.

AUTO FILL COOKIE MODULE EXACT

to retrieve only module-specific values only from cookies.

AUTO FILL COOKIE USER EXACT

to retrieve only user-specific values from cookies.

AUTO SET DB

to store previously entered values in the Bravura Security Fabric database.

AUTO FILL SET DB MODULE EXACT

to store module-specific database values.

AUTO FILL SET DB USER EXACT

to store user-specific database values.

AUTO FILL DB

to retrieve values from Bravura Security Fabric ’s database.

AUTO FILL DB MODULE EXACT

to retrieve only module-specific values from Bravura Security Fabric ’s database.

AUTO FILL DB USER EXACT

to retrieve only user-specific values from Bravura Security Fabric ’s database.

When either method is used Bravura Security Fabric automatically populates profile ID and email address fields. Other fields can be set up for automatic setting or filling by editing Bravura Security Fabric m4 files. For example, you may want to populate the request notes field with some boilerplate text.

Set the API session inactivity timeout period

By default, Bravura Security Fabric shuts a user out after 600 seconds of inactivity during an API session. To change the default inactivity timeout for an API session, type the number of seconds required in the DEFAULT API SESS EXPIRY SECONDS field. It accepts a value between 60 and 999999.

Set the inactivity timeout period

By default, Bravura Security Fabric shuts a user out after 600 seconds of inactivity. To change the default inactivity timeout for a session, type the number of seconds required in the DEFAULT EXPIRY SECONDS field. It accepts a value between 60 and 999999.

Set the maximum size of stored sessions

By default, when Bravura Security Fabric stores user session data in the sessdata directory, it will terminate any sessions whose data file exceeds 5242880 Bytes in size. To change the maximum size of stored sessions, set a new value for maximum size in bytes in the SESSION MAX BIN SIZE field. It accepts a value between 0 and 2147483647.

Set the default time for schedule tasks

By default, Bravura Security Fabric sets time to run at 01:00 (1AM) when you add a scheduled job. To change the default time, type the time in 24-hour format (HH:MM) in the DEFAULT SCHEDULE TIME field. You can change the time for individual jobs in the Time to run field. This field affects scheduled tasks added for:

  • Manage the system > Maintenance > Scheduled jobs

  • Manage the system > Policies > User notifications > Batch notifications

  • Manage reports > Reports > Reports

Digitally sign files

You can use a plugin to digitally sign files created by the Bravura Security Fabric server. Use this to sign MSI files for installing on local service mode resources.

To use a digital signature plugin, ensure that the plugin is located in the plugin directory, then type the plugin name in the Modules > Options > DIGITAL SIGN PLUGIN field.

There are no shipped plugins for this plugin point.

Write a custom digital sign plugin

Requirements

See Writing pluginsfor general requirements.

Execution points

This plugin runs when Bravura Privilege creates local-service-mode installation keys, whether manually created in the Manage the system (PSA) module or by a replicating server generating the installation files.

Input

The plugin accepts the following input:

 "" "" = {
      "FILES" "" = {
          "name" = "<file name>"
          "name" = "<file name>"
          .
          .
          .
      }
    }

Output

The plugin expects the following output:

  "" "" = {
      "retval" = "0"
      /* optional
      "errmsg"  = "<message>"
      "warnmsg" = "<message>"
      "infomsg" = "<message>"
   }

For retval, 0 indicates success and non-zero indicates failure.

Display simplified login IDs

By default, when users view account information Bravura Security Fabric displays the context-sensitive login ID (long ID). You can configure Bravura Security Fabric to present users with a simplified login ID (short ID) by enabling the DISPLAY ALIAS SIMPLIFIED option.

For example, if DISPLAY ALIAS SIMPLIFIED is enabled, the LDAP login ID is reduced to just the UID value.

This option does not apply to any of the certification pages.

Display group IDs

In the user interface, Bravura Security Fabric generally lists groups by their IDs and descriptions.

Sometimes it is preferable to display the short ID rather than long ID or vice versa. For example, a company could have a group with the short ID of DEV and the description Development in Calgary , with the long ID something like:

cn=DEV,ou=CalgaryOffice,dc=company,dc=com

You can change the way group IDs are displayed by enabling the DISPLAY GROUPID PLUGIN option in the Modules > Options menu. The default is to display the short ID.

You can also configure when to display the group IDs one way or another depending on which page it is being displayed.

Bravura Security Fabric has two built-in plugin programs:

  • longid.pss always displays groups’ long ID

  • shortid.pss always displays groups’ short ID

Write a custom plugin to display group IDs

Requirements

The plugin must be placed in the \<instance>\plugin\ directory and runs on the Bravura Security Fabric server. See Writing plugins for general requirements.

Execution points

This plugin is executed whenever Group IDs are displayed.

Input

Input to this plugin must include the hostid, platform, groupshortid, grouplongid, and groupdesc fields from the nosgroups table. It will also include which module called the plugin and the navigation it took.

 "" "" = {
   "GROUPDESC" = "CN=sales1,CN=Users,DC=example,DC=com"
   "GROUPLONGID" = "CN=sales1,CN=Users,DC=example,DC=com"
   "GROUPSHORTID" = "sales1"
   "HOSTID" = "AD"
   "PLATFORM" = "WIN2K"
   "module" = "idr"
   "navigation" "" = {
      "wfpage" = "useracct"
                   }
   "sessionid" = "Sa29ad806-4e15-4119-b02f-4b79ec90b05a"
 }

Output

Output includes GROUPID value. For example:

 "" "" = {
   "GROUPID" = "AD - sales1"
 }

Filter users

You can restrict access to certain user profiles by using the appropriate user filter or list generation plugin.

For example, the FILTER USER PLUGIN and KEEP USER PLUGIN controls who can view and manage which users. By default, regular users and help desk users can make access change requests for any user with a profile ID in the database. You may want to set up a filter, for example, to allow users to manage only their subordinates or members of their own group. The GENERATE USER PLUGIN generates a white list of accepted users to manage; whereas the filter plugin excludes users.

FILTER USER PLUGIN, KEEP USER PLUGIN, and GENERATE USER PLUGIN can also utilize user classes as filter criteria. You can do this instead of using a plugin, or in conjunction with a plugin. You may want to set up a relational user class to allow users to manage only their subordinates or members of their own group. See more information on using user classes with these plugin points .

FILTER USER PLUGIN and KEEP USER PLUGIN take precedence over GENERATE USER PLUGIN if they are both in use. For example, if GENERATE USER PLUGIN is set to list User01 and User02, but FILTER USER PLUGIN is set to filter out all users, then no users are listed.

Configure these plugins via the Manage the system > Modules > Options menu:

  • FILTER USER PLUGIN

  • KEEP USER PLUGIN

  • GENERATE USER PLUGIN

There are no shipped plugins for use with these plugin points. Advanced sample plugin scripts, filter-user.psl and filter-user-callback.psl are located in the samples\plugin directory.

See also

Filter resources show you how to write and configure plugins to filter resources such as template accounts and groups.

Write a custom user filter plugin

Requirements

See Writing plugins for general requirements.

Execution points

The plugin is called by the View and update profile (IDR) module and Help users (IDA) modules before the user list is displayed. It is called multiple times if there are more users than the value of the RECORDS PER PAGE setting. The plugin runs with the number of users determined by the RECORDS PER PAGE at a time.

Filter plugins operate differently from most plugins, which are synchronous. All filter plugins support asynchronous calling. There are two forms of asynchronous calling:

FILTER USER PLUGIN Standard input/output mode

In standard input/output (stdio) mode, filter plugins work in the following way:

  1. An event triggers a CGI program to call the plugin program or script and sends it standard user data.

  2. The calling program continues to stream input from stdin, one item at a time until there are no more items.

  3. For each item, the plugin returns the filter result to stdout.

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

"user" "" = {
    "id" = "Dave-Appla"
    "name" = "Dave Appla"
    "filter" = "<true|false>"
    # true, if the user has been excluded by this plugin
    # false, otherwise
}

See User data for a description of the user 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
    "needitemdetail" = "1|0"
           # If 1, all details are displayed in the input of the next user.
           # If 0, only ID is displayed in the input of the next user. By
           # default, it is set to 1.
}

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.

FILTER USER PLUGIN Callback mode

This mode can reduce processing time in environments with large numbers of users.

In callback mode the user filter plugin uses two functions:

OnFilterInit(const $inkvg, output $detail) This function is called once to initialize the environment based on the cgi user.

  • $inkvg – the viewer

  • $detail – if 0, no detail provided on input kvg for each user

    – if 1, detail is provided on input kvg for each user

    – 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 who the user can view or manage.

  • $inkvg – the user to filter

  • $msg – error message

  • $allow – if 1, this user is displayed and available

    – if 0, this user is not displayed and is unavailable

Examples

  1. Using integer for $detail:

     function OnFilterInit( const $inkvg, output $detail ) 
 { 
    $detail = 0; // 0 means no need for detail info, if 1, detail info will be in inkvg for OnItemFilter 
 } 
                           
 function OnItemFilter( const $inkvg, output $msg, output $allow ) 
 { 
     $allow = 0; 
     var $id; 
     kvgGetValue( $inkvg, "id", $id ); 
     if( $id[0] == "w" ) 
     { 
         $allow = 1; 
     } 
     return 0; 
 }

  2. Using KVGroup for $detail:

    function OnFilterInit( const $inkvg, output $detail ) 
{ 
                           
    $detail = kvgCreate( "", "" ); 
    kvgAddValue( $detail, "needitemdetail", "1" ); 
} 
                           
function OnItemFilter( const $inkvg, output $msg, output $allow ) 
{ 
    $allow = 0; 
    var $id; 
    kvgGetValue( $inkvg, "id", $id ); 
    if( $id[0] == "w" ) 
    { 
        $allow = 1; 
    } 
    return 0; 
}

Write a custom keep user filter plugin

Requirements

See Writing plugins for general requirements.

Execution points

The plugin is called by the View and update profile (IDR) module and Help users (IDA) module before the user list is displayed. It is called multiple times if there are more users than the value of the RECORDS PER PAGE setting. The plugin runs with the number of users determined by the RECORDS PER PAGE at a time.

Filter plugins operate differently from most plugins, which are synchronous. All filter plugins support asynchronous calling. There are two forms of asynchronous calling:

KEEP USER FILTER Standard input/output mode

In standard input/output (stdio) mode, filter plugins work in the following way:

  1. An event triggers a CGI program to call the plugin program or script and sends it standard user data.

  2. The calling program continues to stream input from stdin, one item at a time until there are no more items.

  3. For each item, the plugin returns the filter result to stdout.

  4. 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 requester.
                     
  "module" = "<idr|ids|idp|idwfm>"
                     
  "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:

"user" "" = {
    "id" = "Dave-Appla"
    "name" = "Dave Appla"
    "filter" = "<true|false>"
    # true, if the user has been excluded by this plugin
    # false, otherwise
}

See User data for a description of the user KVGroup.

Output

For each item, one output KVGroup is expected on stdout, with an optional "keep" = "true" pair to indicate that the item should be displayed:

"" "" = {
    "keep" = "true|false"
           # If false, the user is displayed
           # If true, the user is not displayed
    "retval" = "<#>"
           # Optional, if non-zero returned, abort the plugin
    "needitemdetail" = "1|0"
           # If 1, all details are displayed in the input of the next user.
           # If 0, only ID is displayed in the input of the next user. By
           # default, it is set to 1.
}

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.

KEEP USER FILTER Callback mode

In callback mode the keep user plugin uses two functions:

OnKeepInit(const $inkvg, output $detail) This function is called once to initialize the environment based on the cgi user.

  • $inkvg – the viewer

  • $detail – if 0, no detail provided on input kvg for each user

    – if 1, detail is provided on input kvg for each user

    – can also be expressed as a KVGroup, see the example below

OnItemKeep(const $inkvg, output $msg, output $allow) This function is called once per item to determine who the user can view or manage.

  • $inkvg – the user

  • $msg – error message

  • $allow – if 1, this user is displayed and available

    – if 0, this user is not displayed and is unavailable

Examples

  1. Using integer for $detail:

    function OnKeepInit( const $inkvg, output $detail ) 
 { 
    $detail = 0; // 0 means no need for detail info, if 1, detail info will be in inkvg for OnItemKeep 
 } 
                           
 function OnItemKeep( const $inkvg, output $msg, output $allow ) 
 { 
     $allow = 0; 
     var $id; 
     kvgGetValue( $inkvg, "id", $id ); 
     if( $id[0] == "w" ) 
     { 
         $allow = 1; 
     } 
     return 0; 
 }

  2. Using KVGroup for $detail:

    function OnKeepInit( const $inkvg, output $detail ) 
{ 
    $detail = kvgCreate( "", "" ); 
    kvgAddValue( $detail, "needitemdetail", "1" ); 
} 
                           
function OnItemKeep( const $inkvg, output $msg, output $allow ) 
{ 
    $allow = 0; 
    var $id; 
    kvgGetValue( $inkvg, "id", $id ); 
    if( $id[0] == "w" ) 
    { 
        $allow = 1; 
    } 
    return 0; 
}

Write a custom user list generator plugin

Requirements

See Writing plugins for general requirements.

Execution points

The plugin is called by the View and update profile (IDR) module and Help users (IDA) module before the user list is displayed. It is called once when a user select page is first rendered. Users that are returned by the plugin are only available for selection. If the set of users is empty, the end user is not able to submit a request for anyone.

User list generation is similar to the filter plugins. This plugin supports support synchronous calling. There are two forms of synchronous calling:

GENERATE USER PLUGIN Standard input/output mode

In standard input/output (stdio) mode, a synchronous list generation plugin works in the following way:

  1. An event triggers a CGI program to call the plugin program or script and sends it standard use data.

  2. When the CGI program is ready to receive an object, it sends an empty KVGroup ( "" "" = { }) to the plugin program.

  3. The plugin program sends a KVGroup that includes an object ID, or is empty to indicate end of list.

  4. Steps 2 and 3 continue until the plugin sends an empty KVGroup to indicate end of list, or the objects generated reaches the limit required by the calling program.

Input

Input sent to the plugin is as follows:

"" "" = {
  "module" = "<idr|psw|ida>"
                     
  "navigation" "" = { ... } # User navigation data.
                     
  "recipient" "<user|empty>" = {
                     
     # The "recipient" group contains standard information about the
                     
     # subject of the request.
   }
  "viewer" "<user|admin>" = {
     # The "viewer" group contains standard information about the
     # person using the CGI.
   }
 }

Output

The list of users is passed from the plugin on stdout. A KVGroup is sent for each user.

The output KVGroup sent from the plugin must be as follows:

"" "" = {
  "userid" = "<profile ID>"
                     
      # Optional; This indicates the next user to add to the list of users
      # If omitted, this indicates there are no more users to add.
  "abort"  = "<true|false>" #If true, bypass the list generation plugin
  "errmsg" = "<text message>" # A message sent on an error
  "retval" = "0" # Mandatory; non-zero indicates failure
}

GENERATE USER PLUGIN Callback mode

In call back mode, the user generator uses two functions:

OnGeneratorInit(input $inkvg) This function is called once to initialize the environment based on the cgi user.

  • $inkvg – the viewer and module

GetGenList( output $list ) This function returns users that the user is able to view or manage.

  • $list – the array of user profile IDs

Example

  function OnGeneratorInit( input $inkvg )
  {
      log( "inkvg: " + kvgToString($inkvg ));
  }
  function GetGenList( output $list )
  {
      var $include_user[]
      $include_user[ size( $include_user ) ] = "AUSER1";
      $include_user[ size( $include_user ) ] = "AUSER2";
      $include_user[ size( $include_user ) ] = "AUSER3";
      $list = $include_user;
  }

Filter pre-defined requests

Bravura Security Fabric can filter pre-defined requests so that requesters only see requests that are relevant to them. Bravura Security Fabric can run a request filter plugin when users select options to request new resources or update their or another user’s profile.

This plugin is set by the Modules > Options > FILTER PREQUEST PLUGIN field.

It also affects the pre-defined requests that product administrators are allowed to manage if the PSA FILTERING option is enabled in the Modules > Manage the system (PSA) module menu.

There are no shipped plugins in use with this plugin point.

Write a custom pre-defined request filter plugin

Requirements

See Writing plugins for general requirements.

Execution points

This plugin is run by the View and update profile (IDR) module.

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.

FILTER PREQUEST PLUGIN Standard input/output mode

In standard input/output (stdio) mode, filter plugins work in the following way:

  1. An event triggers a CGI program to call the plugin program or script and sends it standard user data.

  2. The calling program continues to stream input from stdin, one item at a time until there are no more items.

  3. For each item, the plugin returns the filter result to stdout.

  4. The calling program receives the final standard output and continues.

Input

Input is similar to resource filter plugins. The plugin first receives standard data in the format:

"" "" = {
       "recipient" "user" = {
                     
           # The "recipient" group contains standard information about the
                     
           # subject of the request.
       }
       "module" = "idr"
                     
       "viewer" "user" = {
           # The "viewer" group contains standard information about the
           # person using the CGI.
       }
   }

The plugin then receives a series of KVGroups; one for each item.

For example:

# KVGROUP-V1.0
          "prequest" "" = {
            "description" = "PREQ1"
            "itemID" = "PREQ1"
          }
# KVGROUP-V1.0
          "prequest" "" = {
            "description" = "PREQ2"
            "itemID" = "PREQ2"
          }
# KVGROUP-V1.0
          "prequest" "" = {
            "description" = "PREQ3"
            "itemID" = "PREQ3"
          }
# KVGROUP-V1.0
          "prequest" "" = {
            "description" = "!!!_CUSTOM_REQUEST_"
            "itemID" = "_CUSTOM_"
          }

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
}

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.

FILTER PREQUEST PLUGIN Callback mode

In callback mode the pre-defined request filter plugin uses two functions:

OnFilterInit(const $inkvg, output $detail) This function is called once to initialize the environment based on the cgi user.

  • $inkvg – the viewer

  • $detail

    • if 0, no detail provided on input kvg for each user

    • if 1, detail is provided on input kvg for each user

    • can also be expressed as a KVGroup

OnItemFilter(const $inkvg, output $msg, output $allow) This function is called once per item to determine what pre-defined requests the user can use.

  • $inkvg – the pre-defined request to filter

  • $msg – error message

  • $allow

    • if 1, this user is displayed and available

    • if 0, this user is not displayed and is unavailable

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.

Write a custom request filter plugin

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.

FILTER REQUEST PLUGIN Standard input/output mode

In standard input/output (stdio) mode, filter plugins work in the following way:

  1. An event triggers a CGI program to call the plugin program or script and sends it standard user data.

  2. The calling program continues to stream input from stdin, one item at a time until there are no more items.

  3. For each item, the plugin returns the filter result to stdout.

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

FILTER REQUEST PLUGIN Callback mode

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

  • $detail

    • if 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

  • $allow

    • if 1, this request is displayed and available

    • if 0, this request is not displayed and is unavailable

Examples

  1. Using integer for $detail:

    function OnFilterInit( const $inkvg, output $detail ) 
       { 
       $detail = 0; 
       }

  2. Using KVGroup for $detail:

    function OnFilterInit( const $inkvg, output $detail ) 
       { 
           $detail = kvgCreate( "", "" ); 
        kvgAddValue( $detail, "sendactions", "1" ); 
     kvgAddValue( $detail, "sendattrs", "1" ); 
       }

Modify the number of records per page

Bravura Security Fabric displays lists of objects with a default 20 items per page. Users can scroll through the pages to find the item they want, and change the number of items if required. You can change the default number of items per page by modifying RECORDS PER PAGE. There is a minimum of 2 and a maximum of 500 records per page.

RECORDS PER PAGE must be one of the values in RECORDS PER PAGELIST. For example; the default RECORDS PER PAGE LIST is 10, 20, 50, 100 and the default RECORDS PER PAGE is 20. This provides 20 records per page and the option to show 10, 20, 50 or 100 search result records per page.

Identify users in a session

You can use a session identifier plugin to add identifying information to session event reports. By default, the reports carry information about the IP address from which an event originated. Alternatively, you can write a plugin that will return an IDENT=<info> key-value pair.

You can use the Session Log Identifier field on the Operations report page to search for the identifying IP address or other information. The information is displayed in the report under the "Ident" heading.

This plugin is enabled by the SESSION IDENT PLUGIN option.

There is no shipped plugin in use with this plugin point.

Write a custom session identification plugin

Requirements

See Writing plugins for general requirements.

Execution points

When configured, this plugin is run by all modules when a user logs into Bravura Security Fabric .

Input

The plugin will receive the following input corresponding to fields in the sesslog table:

"" "" = {
  "ENVIRONMENT" "" = {
    "ALLUSERSPROFILE" = "C:\\Documents and Settings\\All Users"
    "CommonProgramFiles" = "C:\\Program Files\\Common Files"
    "COMPUTERNAME" = "MYCOMPUTER"
    "ComSpec" = "C:\\WINNT\\system32\\cmd.exe"
    "CONTENT_LENGTH" = "145"
    "CONTENT_TYPE" = "application/x-www-form-urlencoded"
    "EXCHICONS" = "C:\\Program Files\\Exchsrvr\\bin\\maildsmx.dll"
    "GATEWAY_INTERFACE" = "CGI/1.1"
    "HTTP_ACCEPT" = "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, ⋆/⋆"
    "HTTP_ACCEPT_ENCODING" = "gzip, deflate"
    "HTTP_ACCEPT_LANGUAGE" = "en-us"
    "HTTP_CACHE_CONTROL" = "no-cache"
    "HTTP_CONNECTION" = "Keep-Alive"
    "HTTP_CONTENT_LENGTH" = "145"
    "HTTP_CONTENT_TYPE" = "application/x-www-form-urlencoded"
    "HTTP_COOKIE" = "HITACHI-ID-DEFAULT-VALUES=43d7c817-00"
    "HTTP_HOST" = "localhost"
    "HTTP_REFERER" = "https://localhost/default/"
    "HTTP_USER_AGENT" = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
    "HTTPS" = "off"
    "INSTANCE_ID" = "1"
    "LOCAL_ADDR" = "127.0.0.1"
    "NUMBER_OF_PROCESSORS" = "1"
    "OS" = "Windows_NT"
    "Os2LibPath" = "C:\\WINNT\\system32\\os2\\dll;"
    "Path" = "C:\\WINNT\\system32;C:\\WINNT;C:\\WINNT\\System32\\Wbem;C:\\PROGRA~1\\ULTRAE~1"
    "PATH_TRANSLATED" = "c:\\inetpub\\wwwroot"
    "PATHEXT" = ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH"
    "PROCESSOR_ARCHITECTURE" = "x86"
    "PROCESSOR_IDENTIFIER" = "x86 Family 15 Model 4 Stepping 8, GenuineIntel"
    "PROCESSOR_LEVEL" = "15"
    "PROCESSOR_REVISION" = "0408"
    "ProgramFiles" = "C:\\Program Files"
    "REMOTE_ADDR" = "127.0.0.1"
    "REMOTE_HOST" = "127.0.0.1"
    "REQUEST_METHOD" = "POST"
    "SCRIPT_NAME" = "/default/"
    "SERVER_NAME" = "localhost"
    "SERVER_PORT" = "80"
    "SERVER_PORT_SECURE" = "0"
    "SERVER_PROTOCOL" = "HTTP/1.1"
    "SERVER_SOFTWARE" = "Microsoft-IIS/5.0"
    "SystemDrive" = "C:"
    "SystemRoot" = "C:\\WINNT"
    "TEMP" = "C:\\WINNT\\TEMP"
    "TMP" = "C:\\WINNT\\TEMP"
    "USERPROFILE" = "C:\\Documents and Settings\\psadmin"
     
    "windir" = "C:\\WINNT"
  }
  "SESSION" "" = {
    "HOST" = ""
    "HOSTID" = ""
    "ID" = "S382005-153PMY~h/2Z@"
    "LONGID" = "SMITHBO"
    "OPER" = "USUP"
    "REQBY" = "SMITHBO"
    "RESULT" = ""
    "RESULTCODE" = "0"
    "TEND" = "422e10d1"
    "TSTART" = "422e10d1"
    "USERID" = "SMITHBO"
  }
  "requester" "user" = {
         
    "ID" = "SMITHBO"
    "NAME" = "Bob Jon Smith"
  }
}

Output

The plugin returns:

"" "" = {
  "IDENT" = "<ip address>"
  "retval" = "0"
}

Where:

  • IDENT is the string to be saved in the sesslog.ident field

  • retval indicates success if the value is 0.

If the plugin fails (value is not 0), the user’s IP address will be stored. The optional key-value pair errmsg can be used to provide a reason for the failure.

Limit session file size

You can limit the session file size by configuring SESSION MAX BIN SIZE. This prevents large numbers of concurrent access requests to Bravura Security Fabric from identical users. When the configured size is reached, the offending user’s session is invalidated and the user is required to re-login.

By default, SESSION MAX BIN SIZE is set to 5,242,880 bytes (5MB).

Enable remotely administered target systems

A target system is "administered remotely" if its credentials are stored on an external source rather than local to the target system. Before Bravura Privilege can remotely administer target systems, you must enable the TARGET CREDENTIAL ASSOCIATION system variable in the Manage the system > Modules> Options menu.

See Remotely administered target systems for details.

Control the Phone Password Manager source of IVR IDs

You can change the profile and request attribute that is used as a source of users’ IVR IDs (the digits users enter to identify themselves to the IVR phone system). By default, the telephone keypad translations of users’ profile IDs are used as their IVR IDs. Phone Password Manager finds a users’ profile ID by searching on their “numid” and “altnumid”.

The TPM ID ATTR option allows you to change the source of IVR IDs by specifying a new profile and request attribute. When TPM IDATTR is in use, Phone Password Manager finds users’ profile IDs by searching on the specified attribute.

For example:

Using the default setup of profile ID

Find user “test123” by entering 8378123 on the keypad. This is the telephone keypad translation of the user’s profile ID.

Using TPM ID ATTR

If user “test123” has their “Telephone number” attribute specified as “4035550740”, then set TPM ID ATTR to “Telephone number”, and enter 4035550740 on the telephone keypad to find the user.

For the TPM ID ATTR option to work as defined above, you must associate the “Telephone” profile/request attribute with the account attribute “telephoneNumber”

TPM ID ATTR requires the specified attribute to only contain numeric characters; it cannot contain alphabetic or special characters.

Enable the translation interface (transcgi)

To enable and control access to the translation interface (transcgi), use the TRANSCGI ALLOWED IP option. Enter a comma-delimited list of IP addresses (with CIDR bitmask ) that are allowed to use the translation interface (transcgi).

Display time zone information

By default, Bravura Security Fabric displays date and time to users as follows:

  • On request-detail pages and in emails, the date and time are displayed based on the (Windows) regional settings for the psadmin user on the Bravura Security Fabric server.

  • In HTML date/time widgets, the date and time are displayed by default in the format: YYYY-MM-DD HH:mm

Enable the DISPLAY TIMEZONE option to add time zone information, so that date and time are displayed as: YYYY-MM-DD HH:mm (UTC+/-HH:mm)

In this section: