SecurID® Governance & Lifecycle Recipes

SecurID Governance & Lifecycle recipes is a collection of items, to help you get the most out of your product deployment. For example, a useful report with the SQL to implement or a way to achieve some advanced rule processing.

RSA IGL Services 101: Explaining Workflow Nodes - "Create Admin Error"

Services 101 blogs, help to explain various areas of RSA Identity Governance and Lifecycle, to ensure you are getting the most out of the product and following recommended practices. We hope to show you lots of great features, tips and tricks that you may not have been aware of!

Please reply below with any questions or hit like if this is helpful!

We are starting by looking at workflow nodes and in this blog, specifically the "Create Admin Error" node. 

Click the images to enlarge if you need!

Product Area: Workflow's

Note: A summary of all workflows is found here: https://community.rsa.com/community/products/governance-and-lifecycle/blog/2019/12/11/rsa-igl-services-101-explaning-workflow-nodes-summary

Workflow Node: Create Admin Error

Time to apply: <10 minutes

Impact: High positive impact for administrative users and support, Low risk to workflow process and performance as this node has a very low data footprint.

Summary: "Create Admin Error" nodes provide a great way to help log success or failures from within workflows. These results can be captured in a clear and meaningful format and are then available within the RSA IGL UI (Admin > Admin Errors > Summary) and via reports/charts.

 

Capturing Admin Errors helps to highlight processing issues that require attention to administrative users without them having to drill down in to workflows. 

RSA Field Example: To put this in to a real-life scenario, it’s a common requirement that Active Directory accounts have the password reset and are moved to a different OU when the associated user is flagged as a leaver.

 

This would be achieved using Provisioning Command nodes (1) within the fulfillment workflow. These Provisioning Command nodes then call the relevant AFX capability on the Business Source to perform the action and provide a status of 0 if successful or -1 if unsuccessful (2). Further details on the values and how they can be referenced as variables can be found here - https://community.rsa.com/docs/DOC-64651

 

A Decision node (3) then separates the successful from the unsuccessful allowing the Create Admin Error nodes (4) to return different errors depending on the result.

 

pastedImage_7.png

The Create Admin Error is then configured to capture the relevant details in a clear format that is easily understood by administrators.

 

Below is a format we typically use when configuring Admin Errors for the following reasons:

  • Highlighting the status (WARNING) at the start of the message helps focus attention

  • Including the associated process (LEAVER) helps sorting/filtering/reporting and can form part of daily checks

  • Including dynamic variables from the workflow makes the message more meaningful and easier to track

  • Inclusion of the Change Request ID enables easily linking to other tables/views for extended reporting options

  • Pipe separator simplifies report query

 

pastedImage_8.png

 

The Admin Errors are then visible within the UI from the Admin > Admin Errors screen

pastedImage_10.png

And can be easily extracted in to a report format which can be emailed on a scheduled basis or added to a dashboard to form part of the daily checks.

pastedImage_11.png

As mentioned, the inclusion of the CR ID in the Admin Errors provides a logical join to the CR views which provide useful additional detail such as user details, dates, times, days late, etc.

 

Within the above report, the join was achieved using the following query:

 

FROM avuser.PV_CHANGE_REQUEST_DETAIL pCRD
LEFT JOIN avuser.V_AVR_ADMIN_EXCEPTIONS vAAE
ON PCRD.CHANGE_REQUEST_ID = TRIM(REGEXP_SUBSTR(VAAE.Description, '[^|]+', 1, 5))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

 

The REGEXP_SUBSTR function uses the pipe separator (|) as a way of determining the string to return. Once joined to the PV_CHANGE_REQUEST_DETAIL view, this can be easily extended, for example:

 

LEFT JOIN avuser.PV_CHANGE_REQUEST pCR
ON pCRD.CHANGE_REQUEST_ID = pCR.ID‍‍‍‍‍‍‍‍‍‍

 

LEFT JOIN avuser.PV_USERS pUSR
ON pCRD.Affected_User_ID = pUSR.ID‍‍‍‍‍‍‍‍‍‍

 

Usage: All workflows that contain provisioning activities and provide status response (Provisioning Command node, Web Service) should include error handling, where possible.

 

General Notes/Benefits:

  • Reduce troubleshooting effort (no need to dig around in workflow)

  • Help create audit trail

  • Quickly and clearly highlight issues that require attention

  • Easy to configure

  • Very low data footprint so won’t impact performance

  • Ability to include variables in error messages provides huge flexibility

  • Populated to V_AVR_ADMIN_EXCEPTIONS view

  • Ease of reporting/dashboards

  • Admin Errors are not included in data purging although can be manually deleted from the UI if required

     

     

 

Configuration:

  • We are using v7.1 P04 in the example below, however most versions of the older product also have milestones available. 
  • Create Admin Error nodes are found under the "Modeler Toolbox", about halfway down, as shown in the image below. To add a new node to your workflow, just single left-click the required node icon from the left-side panel then double left-click anywhere in the middle area to add that node.

    pastedImage_34.png

Create Admin Error nodes are made up of 3 sections:

Type

Available to select from a drop-down list and can be used as grouping/sorting criteria on the Admin Errors page.

pastedImage_37.png

 

Priority

Drop-down select of either Low, Medium or High

 

Error Description

Free text box

 

As mentioned above, within the Error Description box you can also use variables from within the workflow. The use of dynamic variables makes the message more meaningful and also provides greater flexibility when it comes to reporting.

 

RSA PS Recommendation

Unless absolutely necessary, RSA recommends to only create Admin Errors for the failed/un-successful changes. This helps keep the Admin Error page lean and focus attention on only those items that require action/remediation.

Labels (1)
No ratings
Version history
Last update:
‎2020-01-10 12:29 PM
Updated by:
Contributors
Article Dashboard