Skip to main content

Requests overview for Bravura Identity

This topic provides an overview of the life cycle of a request using Bravura Identity , and the various features and programs involved in the lifecycle.

A pre-defined request is a common element of the request lifecycle. A PDR is a definition / template from which a request is generated and defines the following.

  • Actions / operations a generated request can or must execute.

  • Request attribute groups that can be provided as input to the request.

  • Users that are allowed to submit or receive requests from this PDR.

  • In what context should the request be visible in the user interface (for example, creating a user, modifying an existing user,).

  • The order of display in which the request attributes must be populated when the wizard is used to submit the request manually.

Request creation and submission methods

There are numerous ways that a request can be generated.

Automated request generation via auto-discovery

When auto discovery runs, Bravura Identity identifies changes (adds/deletes/changes) are identified. Components that provide idtrack functionality can process those changes then submit the appropriate workflow requests. For example, when a new record in a Source of Records (SoR) target is identified, idtrack implementing component logic will execute, automatically populate and send a request to onboard a user.

You can identify components that implement idtrack functionality by searching for the string <provides>IDTRACK</provides> in the manifest.xml files in the components directory.

Some configurations for idtrack can be found in the hid_global_configuration policy extdb table. These entries will be identifiable as they will contain namespace=AUTOMATION.

Automated request generation via automatic assignment

The automatic assignment process utilizes user class membership to automatically assign/unassign roles or groups to a profile.

Automated request generation via role enforcement

The role enforcement process utilizes role membership to submit requests to automatically assign/unassign roles or groups to a role.

Automated request generation via Attribute Propagation

When a user's profile attribute is updated, Bravura Identity can be configured to automatically propagate the updated profile attribute value to its mapped account attributes.

Manual request via wizard in Bravura Identity user interface

From the user interface, when a user clicks a request link such as My Profile > View and update profile > Request a group membership it opens the pre-defined request wizard. Each page of the wizard is a form that facilitates the input of the necessary request attributes. When the user clicks the Submit button, the request is generated and populated with the specified request attributes.

Custom Scripts

Requests can also be created from custom scripts. Some API calls that can be used to submit requests are:

  • WFPDRSubmit API call

    • A simpler API for submitting requests. Less granular than WFRequest*.

    • May be called remotely via SOAP to create/submit a request from a specified PDR.

    • May also be called locally via custom script directly from the Identity application node.

  • WFRequest* API calls

    • WFRequestCreate / WFRequestAttrsSet / WFRequestSubmit / etc.

    • May also be called via SOAP or locally on application node.

    • Can provide more control over the process of creating and submitting a request in comparison to WFPDRSubmit.

Request structure

A request consists of base metadata, actions, authorizers and/or implementers and request attributes. Through the lifetime of the request this data is stored/modified in Bravura Identity 's backend SQL tables. The below sections detail these SQL tables along with some of their more important columns.

Base metadata

Base metadata refers to information about the request itself. Some notable items are:

  • Request ID: This is a unique guid assigned to each request.

    In the Requests UI, when choosing a request, this guid can be seen in the URL bar.

    This unique identifier is useful for troubleshooting exercises as:

    • It can be used to trace request execution in the idmsuite logging.

    • It can be used to pull information on the request from the backend SQL tables.

  • Request Name: This is a unique readable name assigned to the request.

    In the Requests UI, when choosing a request, this will show in right pane under Details and will be formatted YYYYMMDD-X.

  • Request Status: This is current operational status of the request.

    The status will clearly state if the request is "Processing", "Calculating Authorizers", "Approved, performing requested operations", "Processed".

    In the Requests UI, when choosing a request, this will show in the right pane under Details.

  • Requester: Who initiated the request.

  • Recipient: Who the request is for.

  • PDR ID: From which PDR the request was generated.

The base metadata for a request is stored in the reqbatch table.

Request attributes

Attributes can be added to a request at submission time and can be modified further via custom request rewrite scripts or component-utilized policy tables. These attributes can be used by custom or default component logic to execute their designated tasks.

In reqinfo the attribute's name and value can be found in addition to the request those request attribute's belong to.

The attributes for a request are stored in the reqinfo table.

Request actions

A "Request Action" comprises of a resource and an operation.

The resource is the object / entitlement that will be modified by the Operation. Examples of resources are profiles, accounts and groups.

An operation is executed against a resource. Examples of operations are account additions/deletions, group additions / deletions, role additions / deletions. As the operation executes its "status" (for example approved/canceled) and "result" (for example failed/successful) will be recorded.

Request ACTIONS for a request are stored in the reqacct table.

Authorizer and Implementers (stored in authreq table)

An authorizer is a user who is assigned to approve/deny a request action. An Implementer is a user who is assigned to a request action which requires manual execution of tasks in target systems.

For each request, Bravura Identity records / modifies the status of implementer and authorizer activities. It also records / modifies the assignment of authorizers and implementers to a request action.

Authorizer and Implementer activity is stored in the authreq table.

Request execution

When a request executes:

  1. Authorizers and implementers are calculated.

  2. Authorizers approve and implementers can fulfill requests.

  3. Component logic can be executed to modify the request,calculate attributes, and more.

  4. Operations are executed and request is completed.

The following outlines the processes involved in request execution and what responsibilities they carry.

Workflow Manager (idwfm)

  1. Calculates authorizers / Implementers via:

    • Functional.im_policy_authorization component .

      Policy rules utilized by this component to calculate authorizers are in the im_policy_authorization extdb table.

      These policy rules can override authorization configurations set in the Bravura Identity UI.

    • Custom components can calculate authorizers / implementers. These components will implement plugin IDSYNCH_AUTH_CRITERIA_MOD_PLUGIN .

    • While custom standalone script can also calculate authorizers / implementers via plugin IDSYNCH_AUTH_CRITERIA_MOD_PLUGIN this was more common in older versions of Identity. Custom components should be used instead wherever possible.

  2. Calculates request attributes and modifies requests via:

    • Attribute calculation via:

      • Policy rules in the hid_policy_attrval_calculation extdb table.

      • Request rewrite logic from custom components.

    • Request modification via:

      Custom components that implement request rewrite logic via plugin WF_WIZARD_PLUGIN to dynamically detach or attach actions to a request.

  3. Executes logic from enabled components.

  4. Manages request status. To view request status:

    • Bravura Identity UI

      As an end user, click Requests then click on the request of interest. In the right pane, click blue text with the batch name formatted yyyymmdd-n to see request details.

    • SQL tables can be viewed for a lower level view into request status

      • reqinfo for the request's attributes.

      • authreq for the request's authorizers / implementers.

      • reqacct for the request's operations.

      • reqbatch for the request's status .

  5. Calls Transaction Monitor (idtm) to execute request operations.

    The order in which operations will execute can be enforced via Operation dependencies .

See more information about the Workflow Manager Service .

Transaction Manager (idtm)

  1. Executes request operations directed for a Target system (for example create account / modify group membership). It does this by:

    • Calling the appropriate agent for the target system.

    • Provides the agent with input values based on what was received from idwfm .

    • Receives response from target system (success / failure).

    • Reports results back to idwfm .

    The pstee utility can be used for debugging purposes to expose the agent inputs and target outputs as .kvg files in the logs directory.

  2. On success the Bravura Identity database is updated.

    For example on successful target account creation, the account will also be added into the Bravura Identity database.

  3. On failure Bravura Identity retrIes the operation as per the intervals defined in Maintenance -> Services -> Transaction Monitor Service . The operation fails after all retries are spent.

See more information about the Transaction Monitor Service.

In this section: