Skip navigation

RSA IGL Version: , v7.2x

Modules: Governance and Lifecycle

Product Area: Workflows

Time to apply: ~2 hours

 

Most organizations struggle to accurately manage and understand all their Application/Directory Accounts and which ones are actively being used. There is a huge risk associated to all accounts which are no longer in use but are still active and could be susceptible for attacks if compromised. Additionally, there could be unnecessary cost associated with licenses assigned to accounts that are no longer in use.

 

We see organizations introduce manual dormancy processes, but these can be inaccurate and require significant ongoing effort to be effective.

 

Typically, organizations want to introduce an automated and phased approach to managing dormant accounts. This process would first notify account owners and administration teams of any dormant accounts, enabling the user/team to take action if the account is still required. If no action is taken, the solution should then perform automated Account Disablement and possibly Account Deletion after a specified number of days of inactivity.

 

 

The following document, created by RSA Professional Services, provides steps on how to configure this solution within your environment.

 

NOTE:

Always first add configuration to a non-production environment and test thoroughly against real life data before promoting to further environments.

 

Always take a backup of the environment/s before making any significant changes.

 

RSA IGL Version: 7.1.x & 7.2.x

Modules: Governance/Lifecycle

Product Area: Workflows/Emails

Time to apply: <10 minutes (dependent on number of emails and SQL complexity)

 

Summary:

This guide uses the SQL Nodes within RSA IGL workflows to create HTML tables that can be used within the body of emails to improve how data is displayed.

 

Example of HTML Table within email:

This is a very simple solution that helps to improve end user experience.

 

For this solution to work, 'Sanitized HTML' must be allowed for Email body Templates, Review Emails and Workflow Emails. 

 

This is configured under Admin > System > Security

 

By default, all settings are set to 'No markup allowed' to prevent cross-site scripting attacks. Allowing Sanitized HTML is done so at your own risk and must be in line with your companies security standards. Further details on this can be found in the online help under 'Managing System Security'.

 

 

Background

Within RSA IGL email notifications are sent to specific end users containing details of items that require action, for example Approvals or Manual Fulfillment.

 

Although the out of the box email templates contain all the required details, it’s not displayed in the most user friendly format.

 

This solution will present the details in a user-friendly table format.

 

 

Challenge

Out of the box emails can sometimes contain a large number of items which can become confusing for the recipient. This can result in processing mistakes occurring or items being missed entirely.

 

Additionally, there’s no option to apply default sorting/ordering to the list in line with customer requirements. For example, order the items by the user name.

 

Solution 

As mentioned above, for this solution to work 'Sanitized HTML' must be allowed for email bodies.

 

Using SQL XMLELEMENT within SQL Select nodes, HTML tables can be created to display the data in a more user-friendly way and also allow for results to be ordered/sorted.

 

The HTML table is created as a Variable which is then referenced in the body of the email.

 

Implementation

Make sure you thoroughly test any changes in lower environments before promoting to Production.

The SQL Query used to extract the details required should be written using a database query tool such as SQL Developer or SQuirrel SQL and referencing the RSA IGL Public Database Schema Reference document found under the Documentation menu of the Community.

 

Once happy with the query, this can be used to create the HTML table.

If you’re adding this solution to an out of the box workflow, always create a copy and add to that. Do not update the original workflow as the changes may be overwritten when patching/upgrading.

The table is created using the following query which is added to a SQL Select node:

SELECT
    XMLELEMENT(
        "table",
        XMLATTRIBUTES(
            '1' AS "border" --, 'border-collapse: collapse;' AS "style"
        ), XMLELEMENT(
            "thead", XMLELEMENT(
                "tr", XMLFOREST(/* Add your column headers in format: '<ColumnHeader>' as "th" */ 'Column 1' AS "th", 'Column 2' AS "th", 'Column 3' AS "th", 'Column 4' AS "th")
            )
        ), XMLELEMENT(
            "tbody", XMLAGG(XMLELEMENT(
                "tr", XMLFOREST(/* Add your selected columns here in format: '<ColumnName>' as "td" */ COLUMN1 AS "td", COLUMN2 AS "td", COLUMN3 AS "td", COLUMN4 AS "td")
            ))
        )
    ) act_table
FROM
    (
         -- Insert SQL statement here

    )

 

As highlighted by the comments in the above, it’s then simply a case of adding the query needed to return the required results under the ‘Insert SQL statement here’ section.

 

The ‘Add your selected columns here’ section is used to determine which columns from the query you wish to display within the table.

 

The ‘Add your column headers’ section is then used to display a friendly name as the column header of the table. For example, ‘Column 1’ instead of ‘COLUMN1’.

 

The table is created with the variable act_table as highlighted in Yellow. Set the Variable Type on the SQL Select Node to ‘Job’ and Save the workflow.

 

Add a Send Email node to the workflow and join the nodes together with a transition. Within the body of the email, add the ‘act_table’ variable:

Depending on the configuration of the workflow, you may also need to disable emails being sent from the approval/activity node otherwise this could result in duplication.

Save the workflow.

 

That’s it!

 

Example

The below image shows how the data is currently displayed using the out of the box 'Task Assigned' email notification.

Using the below query will return the data in a table format making it much more user friendly. Additionally, results are sorted/ordered as part of the SQL. For example, this table shows the users full name in ascending order (ORDER BY pUSR.FIRST_NAME||' '||pUSR.LAST_NAME ASC)

SELECT
    XMLELEMENT(
        "table",
        XMLATTRIBUTES(
            '1' AS "border" --, 'border-collapse: collapse;' AS "style"
        ), XMLELEMENT(
            "thead", XMLELEMENT(
                "tr", XMLFOREST(/* Add your column headers in format: '<ColumnHeader>' as "th" */ 'Action' AS "th", 'User Full' AS "th", 'Application' AS "th", 'App-Role Name' AS "th")
            )
        ), XMLELEMENT(
            "tbody", XMLAGG(XMLELEMENT(
                "tr", XMLFOREST(/* Add your selected columns here in format: '<ColumnName>' as "td" */ ACTION AS "td", USRNAME AS "td", APPNME AS "td", APRNAME AS "td")
            ))
        )
    ) act_table
FROM
    (
         -- Insert SQL statement here
SELECT
pCRD.TYPE AS ACTION,
pUSR.FIRST_NAME||' '||pUSR.LAST_NAME as USRNAME,
pBSC.NAME as APPNME,
pCRD.VALUE_NAME as APRNAME
FROM PV_CHANGE_REQUEST_DETAIL pCRD
LEFT JOIN PV_USERS pUSR
ON pCRD.AFFECTED_USER_ID = pUSR.ID
LEFT JOIN PV_BUSINESS_SOURCE pBSC
ON pCRD.VALUE_BUSINESS_SOURCE_ID = pBSC.ID
WHERE pCRD.CHANGE_REQUEST_ID = '${access_request_requestID}'
AND TYPE = 'AddUserToAppRole'
ORDER BY pUSR.FIRST_NAME||' '||pUSR.LAST_NAME ASC
    )

RSA IGL Version: V7.1x & V7.2x

Modules: Governance

Product Area: Charts, Single Series

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~20 minutes

 

Please share your results and ideas below!

 

Summary:

This recipe shows you how to create a very simple chart, displaying the total number of leavers you have had each week, over the previous 10 weeks.

You can use this data to understand trending within your organisation and potentially look into how automation of the leavers process, could save you time/money

 

Blog Contents:

 

Prerequisites:

  • RSA IGL v7.1x or v7.2x
  • Identity data collections running, with some leavers in the environment 
Make sure you thoroughly test any changes in lower environments first before promoting them to Production.

 

Optional Changes to the Chart

If you want to change this chart to display more/less than 10 weeks, you need to update 2 key values in the SQL. 

  1. "CONNECT BY LEVEL <= 10" - the 10 here, is the number of weeks you want to display, so you could change this to be 8 or 15
  2. "where deletion_date > sysdate - 70 " - the 70 here, is the number of total days, depending on how many weeks you have selected.
    • So if you have 8 weeks, you would have 8weeks * 7 days = 56
    • So if you have 12 weeks, you would have 12weeks * 7 = 84

I would strongly recommended you do not have too many weeks, otherwise it will not display very well in the UI. 

 

The SQL to use:

Please test this works first, within your environment

(select * from 
(select
     T1.tmpWeek as "Week",
     CASE WHEN T2.TotalPerWeek IS NULL THEN CAST(('0') AS NUMBER(20)) ELSE CAST(T2.TotalPerWeek AS NUMBER(20)) END AS "# Leavers"
from
     (
     SELECT
          to_char(sysdate - (7 * level) +7,'YYYYMMDD') as FullDate,
          to_char(sysdate - (7 * level) +7,'WW') as tmpWeek
     FROM dual
     CONNECT BY LEVEL <= 10
     ) t1
left join
     (
     select
          'Leavers' as AppAction,
          tmpWeek,
          count(deletion_date) as TotalPerWeek
     from
          (
          select distinct
               ID,
               deletion_date,
               to_char(deletion_date,'WW') as tmpWeek
          from avuser.pv_users
          where deletion_date > sysdate - 70
          )
          group by tmpWeek
     ) t2
ON t2.tmpWeek = t1.tmpWeek
order by FullDate asc)
)

 

The output looks like this in my environment. Showing that there were 41 leavers in week 27

 

Steps to create within the RSA IGL UI

  1. Log into RSA IGL as a user who can create charts. In my example, im using AveksaAdmin
  2. Go to "Reports" / "Charts"
  3. Select "+ Create Chart" button
  4. Under the "General Tab" add the following details:
    • Name
    • Description
    • Type = Single Series Chart
  5. Under the "Query" Tab, copy the SQL from above and hit "Preview", you should see some results.

    If you get an error at this stage, please test your SQL in a Query tool, like "SQL Developer" or "SQL Squirrel" to ensure it works first. 
    If it still doesn't work, please share your SQL and a screen shot of the issue below.
  6. Under the "Columns" Tab, please use the configuration shown in the image below
  7. Under the "Display Attributes" tab, you should select "Style = Line". Please also apply these settings:
    • Under "Title and Axis Names"
      • Caption: "Total Leavers Per Week"
      • Sub Caption: "For the Previous 10 Weeks"
      • X Axis Name: "Week #"
      • Y Axis Name: Total Leavers
    • Under "Functional attributes"
      • Select "Animation" checkbox (ticked)
      • Select "Show Labels" (Ticked)
      • Select "Show Values" (Ticked)

There are MANY other "display attributes" you can play with on this screen, so please update and make changes as you see fit. 

Final Result

 

 

Next Steps

Add this chart to a dashboard, so you can easily see the data.

RSA IGL Version: V7.1x & V7.2x

Modules: Governance

Product Area: Charts, Multi Series

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~20 minutes

 

Please share your results and ideas below!

 

Summary:

This recipe shows you how to create a very simple multi-series chart, displaying the total number of joiners AND leavers you have had each week, over the previous 8 weeks.

You can use this data to understand trending within your organisation and potentially look into how automation of the joiners and leavers process, could save you time/money

 

Blog Contents:

 

Prerequisites:

Make sure you thoroughly test any changes in lower environments first before promoting them to Production.

 

Optional Changes to the Chart

If you want to change this chart to display more/less than 8 weeks, you need to update 3 key values in the SQL. 

  1. "CONNECT BY LEVEL <= 8" - the 8 here, is the number of weeks you want to display, so you could change this to be 5 or 15
  2. "where creation_date > sysdate - 56" - the 56 here, is the number of total days, depending on how many weeks you have selected.
    • So if you have 10 weeks, you would have 10weeks * 7 days = 70
    • So if you have 12 weeks, you would have 12weeks * 7 = 84
  3. "where deletion_date > sysdate - 56" - same as the point above

I would strongly recommended you do not have too many weeks, otherwise it will not display very well in the UI. 

 

The SQL to use:

Please test this works first, within your environment.

(select * from 
(select
     T1.tmpWeek as "Week",
     CASE WHEN T2.TotalPerWeek IS NULL THEN CAST(('0') AS NUMBER(20)) ELSE CAST(T2.TotalPerWeek AS NUMBER(20)) END AS "# Leavers",
     CASE WHEN T3.TotalPerWeek IS NULL THEN CAST(('0') AS NUMBER(20)) ELSE CAST(T3.TotalPerWeek AS NUMBER(20)) END AS "# Joiners"
from
     (
     SELECT
          to_char(sysdate - (7 * level) +7,'YYYYMMDD') as FullDate,
          to_char(sysdate - (7 * level) +7,'WW') as tmpWeek
     FROM dual
     CONNECT BY LEVEL <= 8
     ) t1
left join
     (
     select
          'Leavers' as AppAction,
          tmpWeek,
          count(deletion_date) as TotalPerWeek
     from
          (
          select distinct
               ID,
               deletion_date,
               to_char(deletion_date,'WW') as tmpWeek
          from avuser.pv_users
          where deletion_date > sysdate - 56
          )
          group by tmpWeek
     ) t2
ON t2.tmpWeek = t1.tmpWeek
left join
     (
     select  -- this will tell you how many accounts have been created per week
          'Joiners' as AppAction,
          tmpWeek,
          count(creation_date) as TotalPerWeek
     from
          (
          select distinct
               ID,
               creation_date,
               to_char(creation_date,'WW') as tmpWeek
          from avuser.pv_users
          where creation_date > sysdate - 56 --change this to be the same number of days, as per the total weeks selected
          )
          group by tmpWeek
     ) t3
ON t3.tmpWeek = t1.tmpWeek
order by FullDate asc)
)

 

The output looks like this in my environment. Showing that there were 1651 new joiners in week 23 of this year and 41 leavers in week 27 of the year

 

 

Steps to create within the RSA IGL UI

  1. Log into RSA IGL as a user who can create charts. In my example, im using AveksaAdmin
  2. Go to "Reports" / "Charts"
  3. Select "+ Create Chart" button
  4. Under the "General Tab" add the following details:
    • Name
    • Description
    • Type = Multiple Series Chart
  5. Under the "Query" Tab, copy the SQL from above and hit "Preview", you should see some results.

    If you get an error at this stage, please test your SQL in a Query tool, like "SQL Developer" or "SQL Squirrel" to ensure it works first. 
    If it still doesn't work, please share your SQL and a screen shot of the issue below.
  6. Under the "Columns" Tab, please use the configuration shown in the image below, however you can change this to be whatever you like. I think that using red for leavers and green for joiners, looks good.
  7. Under the "Display Attributes" tab, you should select "Style = MS Line". Please also apply these settings
    • Under "Title and Axis Names"
      • Caption: "Weekly Joiners and Leavers"
      • Sub Caption: "For the Previous 8 Weeks"
      • X Axis Name: "Week #"
      • Y Axis Name: Total
    • Under "Functional attributes"
      • Select "Animation" checkbox (ticked)
      • Select "Show Labels" (Ticked)
      • Select "Show Values" (Ticked)

There are MANY other "display attributes" you can play with on this screen, so please update and make changes as you see fit. 

Final Result

 

Next Steps

Add this chart to a dashboard, so you can easily see the data.

RSA IGL Version: V7.1x & V7.2x

Modules: Governance

Product Area: Charts, Single Series

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~20 minutes

Please share your results and ideas below!

 

Summary:

This recipe shows you how to create a very simple chart, displaying the total number of joiners you have had each week, over the previous 10 weeks.

You can use this data to understand trending within your organisation and potentially look into how automation of the joiners process, could save you time/money

 

Blog Contents:

 

Prerequisites:

  • RSA IGL v7.1x or v7.2x
  • Identity data collections running, with some new joiners in the environment 

 

Make sure you thoroughly test any changes in lower environments first before promoting them to Production.

 

 

Optional Changes to the Chart

If you want to change this chart to display more/less than 10 weeks, you need to update 2 key values in the SQL. 

  1. "CONNECT BY LEVEL <= 10" - the 10 here, is the number of weeks you want to display, so you could change this to be 8 or 15
  2. "where creation_date > sysdate - 70 " - the 70 here, is the number of total days, depending on how many weeks you have selected.
    • So if you have 8 weeks, you would have 8weeks * 7 days = 56
    • So if you have 12 weeks, you would have 12weeks * 7 = 84

I would strongly recommended you do not have too many weeks, otherwise it will not display very well in the UI. 

 

The SQL to use:

Please test this works first, within your environment. 

(select * from 
(select
     T1.tmpWeek as "Week",
     CASE WHEN T2.TotalPerWeek IS NULL THEN CAST(('0') AS NUMBER(20)) ELSE CAST(T2.TotalPerWeek AS NUMBER(20)) END AS "# Joiners"
from
     (
     SELECT
          to_char(sysdate - (7 * level) +7,'YYYYMMDD') as FullDate,
          to_char(sysdate - (7 * level) +7,'WW') as tmpWeek
     FROM dual
     CONNECT BY LEVEL <= 10
     ) t1
left join
     (
     select
          'Joiners' as AppAction,
          tmpWeek,
          count(creation_date) as TotalPerWeek
     from
          (
          select distinct
               ID,
               creation_date,
               to_char(creation_date,'WW') as tmpWeek
          from avuser.pv_users
          where creation_date > sysdate - 70
          )
          group by tmpWeek
     ) t2
ON t2.tmpWeek = t1.tmpWeek
order by FullDate asc)
)

 

The output looks like this in my environment. Showing that there were 1651 new joiners in week 23 of this year and 13 new joiners in week 27 of this year. 

 

 

Steps to create within the RSA IGL UI

  1. Log into RSA IGL as a user who can create charts. In my example, im using AveksaAdmin
  2. Go to "Reports" / "Charts"
  3. Select "+ Create Chart" button
  4. Under the "General Tab" add the following details:
    • Name
    • Description
    • Type = Single Series Chart
  5. Under the "Query" Tab, copy the SQL from above and hit "Preview", you should see some results.

    If you get an error at this stage, please test your SQL in a Query tool, like "SQL Developer" or "SQL Squirrel" to ensure it works first.
    If it still doesn't work, please share your SQL and a screen shot of the issue below.
  6. Under the "Columns" Tab, please use the configuration shown in the image below
  7. Under the "Display Attributes" tab, you should select "Style = Line". Please also apply these settings
    • Under "Title and Axis Names"
      • Caption: "Total New Joiners Per Week"
      • Sub Caption: "For the Previous 10 Weeks"
      • X Axis Name: "Week #"
      • Y Axis Name: Total New Joiners
    • Under "Functional attributes"
      • Select "Animation" checkbox (ticked)
      • Select "Show Labels" (Ticked)
      • Select "Show Values" (Ticked)

There are MANY other "display attributes" you can play with on this screen, so please update and make changes as you see fit. 

Final Result

 

 

Next Steps

Add this chart to a dashboard, so you can easily see the data.

RSA IGL Version: V7.1x & V7.2x

Modules: Governance

Product Area: Reviews, Reports

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~30 minutes

 

Summary:

This recipe uses the Reporting module within RSA IGL to create create Coverage Files in the correct format which can be then be uploaded directly to Review Definitions/Results.

 

The benefit of this approach is that it removes the manual effort normally associated with Coverage Files and the likelihood of user error.

 

 

Background

Within RSA IGL you can specify reviewers using the review definition wizard, for example ‘Supervisors review their subordinates’ or ‘Asset Owners review their assets’.

 

In scenarios where these options do not meet your requirements, you can, as an alternative use a Coverage File to specify who reviews what. Coverage Files provide greater flexibility and allow for granular filtering to be applied, for example, User A is responsible for reviewing application roles with the name ‘Admin’ for all users within the Department ‘Finance’.

 

Challenge

The immediate concern around the use of Coverage Files is the manual effort to create these and the ongoing maintenance required to ensure they contain the correct details.

 

Additionally, there’s also the added risk of user error associated with manual creation and management.

 

Suggested Solution 

The Reports module within RSA IGL can be used to generate coverage files in the correct format, ready for uploading directly to the Review Definition. Using Reports allows for the internal RSA IGL database views to be queried each time, meaning the coverage file will include the correct details - assuming the environment has been kept up to date!

 

As an example, the following covers the scenario of Application Roles classified as ‘Privileged’ being assigned to the associated Application Business Owner within a User Access Review.

 

The classification against the Application Role is set using a Managed/Editable Custom Attribute (CAS6) and a Custom Value List.

 

 

The Application Business Owner is set using the out of the box attribute.

 

 

Using a database query tool such as SQL Developer or SQuirrel SQL to create the query, the following returns the name of the Application Role marked as ‘Privileged’, the User ID of the associated Application Business Owner and the ID of the Application.

 

The required entries and pipe separators are added so that the results are in the required Coverage File format ready for upload to RSA IGL.

 

SELECT -- APPROLE PRIVILEGED TO BUSINESS OWNER
  'user_id='||''''||pUSR.USER_ID||'''|user'||'|'||'1=1'||''||'|'||'app-role|name='||''''||vAUE.NAME||''''||' AND APPLICATION_ID ='||''''||pAPP.ID||'''' AS COVERAGE_REVIEWER
FROM avuser.V_ALL_UNIFIED_ENTITLEMENTS vAUE
JOIN avuser.PV_APPLICATION pAPP
ON vAUE.APPLICATION_ID = pAPP.ID
JOIN avuser.PV_USERS pUSR
ON pAPP.BUSINESS_OWNER = pUSR.ID
WHERE vAUE.ENT_TYPES = 'app-role'
AND LOWER(APPROLE_CAS6) = 'privileged'

 

Result:

 

As mentioned previously, using Reports means that the Coverage File can be generated ahead of a Review cycle and will provide consistent results in sync with the details contained within RSA IGL. For example, if the Standard User Application Role was marked as Privileged, this would then also be captured in the Coverage File once the report has been run and exported to CSV:

 

 

 

Note: Ahead of the Review Cycle, the Report must be re-run, exported (without headers), saved and manually re-uploaded to the Review Definition/Result. 

Implementation

Coverage Files are covered in detail within the online product help under the section ‘Coverage Files Overview’. Here you will find details around the require structure of Coverage Files for different review types and actors (reviewer, monitor) and also a number of examples.

 

 

The online product help should first be read and understood before trying to create Coverage Files using Reports.

Note: As always, apply configuration to the non-production environments first and only promote to Production once the solution has been fully test. Always take a backup of the environment before making changes.

 

The SQL Query used to extract the details required within the Coverage File should be written using a database query tool such as SQL Developer or SQuirrel SQL and referencing the RSA IGL Public Database Schema Reference document found under the Documentation menu of the Community.

 

Once happy with the query, this can be created as a Tabular Report within RSA IGL.

 

Other than a meaningful name and description, no further changes are required on the General tab.

 

 

Add the query under the Query tab.

Note: As with all reports created within RSA IGL, the query must be surrounded by parenthesis. 

Save the report.

 

Run the Report and select Export and select .csv data only.

 

Note: The file will fail on upload if the headers are also included.

 

If you were to try and upload this file, it will fail with the following error:

 

 

The reason for this can be seen when opening the file in Notepad++, you’ll notice that the results are surrounded by double quotes (“):

 

 

Instead, open the file in Excel and and select Save As.

 

 

Ensure the file is saved as CSV (Comma delimited) and not CSV UTF-8

 

 

Navigate to the required Review Definition or Review Result and upload the Coverage File:

 

 

Once uploaded, you can click View to validate the contents are correct:

 

 

Run the review to validate that the correct reviewers have been assigned to the correct items:

 

 

Note: Always thoroughly check and validate the results before setting the state to Active.

 

Examples

The below covers reviewer requirements that have previously requested via the Community.

 

Example 1

Requirement: Entire application to be reviewed by an Application Administrator (not Business or Technical Owner)

 

Pre-Requisites: Requires a Custom User Attribute to be created at a Business Source level. This attribute must be Managed and Editable. Attribute used in this example is CAU3.

 

 

 

Query used:

(SELECT -- APP ADMINSTRATOR TO APP
'user_id='||''''||pUSR.USER_ID||'''|user'||'|'||'1=1'||''||'|'||'application|name='||''''||pAPP.NAME||'''' AS COVERAGE_REVIEWER
FROM avuser.PV_APPLICATION pAPP
JOIN avuser.PV_USERS pUSR
ON pAPP.CAU3 = pUSR.ID
WHERE pAPP.CAU3 IS NOT NULL);

 

 

Example 2

Requirement: Application Roles must be reviewed by specific Owner.

 

Pre-Requisites: Requires a Custom User Attribute to be created at an Application Role level. This attribute must be Managed and Editable. Attribute used in this example is CAU1.

 

 

Query Used:

(SELECT -- APPROLE TO OWNER
  'user_id='||''''||pUSR.USER_ID||'''|user'||'|'||'1=1'||''||'|'||'app-role|name='||''''||vAUE.NAME||''''||' AND APPLICATION_ID ='||''''||pAPP.ID||'''' AS COVERAGE_REVIEWER
FROM avuser.V_ALL_UNIFIED_ENTITLEMENTS vAUE
JOIN avuser.PV_APPLICATION pAPP
ON vAUE.APPLICATION_ID = pAPP.ID
JOIN avuser.PV_USERS pUSR
ON vAUE.APPROLE_CAU1 = pUSR.ID
WHERE vAUE.ENT_TYPES = 'app-role'
AND vAUE.APPROLE_CAU1 IS NOT NULL);


 

 

 

Majority, if not all customers of RSA IGL use Active Directory (AD) as a way of managing who can access certain applications and what actions they can perform within the application.

 

Early phases of an RSA IGL project focus on visibility, and this typically includes the collection of all accounts, groups and group memberships from a primary AD domain. Although this data provides great insight in to the AD environment, it doesn’t quickly and clearly identify which AD managed applications users have access to.

 

This normally results in customers requesting a solution for on-boardng AD managed applications in to RSA IGL that must be:

  • Easy to implement
  • Uses out of the box functionality
  • Easy and repeatable to on-board applications
  • Does not duplicate data
  • Works with all areas of IGL
    • Visibility of access
    • Reviews
    • Access request
    • AFX

 

The following document, created by RSA Professional Services, provides details on the out of the box components used to separate the AD managed applications so that they are displayed as individual applications, instead of AD groups within a directory. Once separated, these applications are clearly displayed against the user, within User Access Reviews and also Access Request where changes can be automatically fulfilled re-using existing connectors.

 

Active Directory (AD) Managed Applications  

 

Although this solution covers the use of Access Request and AFX, it can be still be used without these to enhance visibility around the users access and during user access reviews.

 

This blog post is intended to highlight considerations and recommended practices regarding extending avuser schema to utilise custom attributes within RSA Identity Governance & Lifecycle. There are numerous legitimate reasons why additional attributes are required and this post will ensure you use these in a manner that meets your requirements without causing unexpected issues. 

DISCLAIMER: You should always make configuration changes in a non-production environment before promoting through to production. This is particularly important when extending the avuser schema as once extended it cannot be deleted and important data relating to the attribute cannot be changed.

What do you mean by AVUSER Schema?

Within the avuser schema there are the following objects: 

 

  • Account
  • Account Mapping
  • Business Source
  • Application Role
  • Business Unit
  • Change Request
  • Change Request Item
  • Entitlement
  • Group
  • Report
  • Form
  • Resource
  • Role
  • User
  • User Entitlement
  • Custom Values

 

These objects have predefined attributes that can be viewed and extended by navigating to Admin > Attributes within the UI. 

 

 

Why would I want to extend the AVUSER schema?

The following excerpt is taken from the RSA Identity Governance & Lifecycle 7.2 online help on custom attributes:

 

RSA Identity Governance and Lifecycle lets you create attributes for collected, created, and managed objects. Pre-defined attributes may provide only some of the attributes you need for your objects. Creating attributes lets you collect more comprehensive and important data. They also let you more accurately represent business sources for which you are managing compliance.

 

Essentially it allows you to better represent your organisation’s data within RSA Identity Governance & Lifecycle. That could be enriching your user objects with more data from your HR/Identity Sources; allowing more information to be collected or added relating to accounts and permissions within your applications or other use cases. Some of which will be covered at a high level within this post.

 

Considerations before extending the AVUSER Schema

When?

When extending objects it is highly recommended that this is done when there is minimal activity in the RSA Identity Governance & Lifecycle application. This includes but is not limited to user and system at activity such as workflow processing, review generations, rule processing and collections. This is particularly true when extending the User object schema as this makes a change to the internal database table structure. 

This is covered in more detail here: https://community.rsa.com/docs/DOC-111131

Why?

Before extending an object with a new attribute consider the following questions:

 

  • Why do I need to add this attribute?
  • What business process/use case requires this attribute?
  • Is there another attribute I could use already?
  • Is the information available through collection?

 

With the exception of the User schema, it is worth noting that there are a limited number of attributes object schemas can be extended by so it is important to only extend where necessary as once extended an attribute cannot then be deleted.

 

Additionally, every time you add a new custom attribute you are increasing the size of your application’s database. To avoid filling your database with unneeded data make sure that what you intend to collect or manage within RSA Identity Governance & Lifecycle adds value by enabling a business process to function or resolving a use case.

 

An example of unnecessary data may be the collection of identity related information at an Account level. Collecting a user’s name associated with an Account can assist with Orphan Account Management to identify who is associated with an Account if account mapping has failed. However, information such as Team, Department, Location, etc. should probably not be collected an Account level unless it specifically restricts or controls access within the specified application.

 

It is easy to consider adding a new attribute each time a new requirement is gathered. However, you should always check if there is an available attribute that could be used or modified to meet this new requirement.

 

For example, a common extension of the Group object would be to add the distinguishedName for collection from Active Directory. This is required for AFX to provision group membership changes and can provide useful information on the location of the group within your domain structure. However, naming this attribute distinguishedName within the avuser schema is very AD-centric. Consider calling this Technical Name so that other Applications or Directories you need to collect Groups from can make use of the same attribute without confusing matters or creating an unnecessary additional attribute.

 

What kind of attribute do I need?

You will have already identified why this attribute is needed and as a result you should know what type of attribute you need to create too. An attribute can be a:

 

  • Date
  • Integer
  • String

 

Obvious use cases for Date attributes are Join, Move or Leave date for Users and Last Logged On for Accounts.

 

Integer attributes are not frequently used but are useful for use cases involving counts such as license management for example.

 

You will find most attributes you create will be Strings as these allow a combination of alphanumeric and special characters.

 

Attributes can either be Collected or Managed and this is dependent on whether they are available from a data source or require to be managed within the UI.

 

For example, the distinguishedName use case earlier would be a Collected attribute as it is available in Active Directory but you may want to create a Managed attribute to classify or categorise the Group to be used in Review, Rule or Report definitions from data that is not available in the target source.

 

Where possible the preference should always be to collect the data from source rather than manage it within RSA Identity Governance & Lifecycle.

 

How do I extend the AVUSER schema?

If you wanted to extend the user object within the avuser schema with a new attribute you would navigate to Admin > Attributes > User > Edit then define the name and type of attribute you wish you create. For other objects you would navigate to the appropriate tab on the Attributes page.

 

 

Naming

We have already discussed making the Attribute Name as generic as possible so it can meet multiple use cases but it is worth highlighting that Attributes can also be shared. For example, if you created an attribute called Classification for Groups, App Roles and Entitlements it is far easier to manage and configure Reviews, Rules and Reports based on this shared attribute than it would be on separate attributes called Group Classification, App Role Classification and Entitlement Classification.

 

This excerpt from the online help section explains the difference between the Attribute Name and Reference Name: 

Attribute Name — Enter a name for the attribute. You would typically provide a name that denotes the type of information the attribute represents. Avoid attribute names that contain special characters other than $ and _. Attribute names with other special characters are not allowed in AFX mappings.

 

Reference Name - A name for custom attributes that is unique across all attributes of the same data type. For a new custom attribute, the reference name field is automatically populated with the Attribute Name with spaces replaced with underscores. For example, an attribute with the Attribute Name of Account Expires would, by default, have a Reference Name of Account_Expires.

 

Database ID

The Database ID is important and you should ensure you synchronize these across your environments as you will encounter problems Importing and Exporting configuration if the IDs do not match up. For all objects except User this is selected under Database ID.

 

For example, if you create an attribute called Type for Group objects assigned to CAS3 in your non-production environment, ensure it is also created and assigned CAS3 in all other environments.

 

 

User object schema increments the database ID per data type so it is important when adding multiple attributes that you do these in the same order through your environments to avoid the same issue.

 

Notice the length is specified in brackets for other object types but you can specify this for User attributes, be pragmatic when setting this as the larger it is the more space it takes up but you also do not want it to be insufficient.

 

          

It is important to note the Data Type, Database ID, Data Type, Length and Data Source cannot be changed once the attribute is created.

 

To avoid issues when importing and exporting configuration between environments:

 

  • For User attributes ensure they are created in the same order in each environment to ensure the same Database ID is assigned.
  • For all other attribute types ensure you choose the same Database ID for your attribute in each environment.

Managed or Collected

When creating an attribute you will collect from a data source select Collected under Data Source. This newly created attribute will then be available to populate in the associated collector. For example, a new User Attribute will appear as an available attribute under Identity Collectors; Account and Group Attributes under Account Collectors and App Role, Entitlement and Resource Attributes under Entitlement Collectors.

 

If you are creating a Managed Attribute you will notice an Editable tick box appears:

 

         

 

Select this option if you want this attribute to be updated within the UI.

 

For example, if you extended the App Role object to include a Managed, Editable String attribute called Access Classification you would be able to update this by editing the App Role in the UI:

 

                                 

 

Where you want to control the values that can be selected for a Managed attribute you can set up a Custom Values attribute with predefined values that can be selected from a drop-down. Otherwise this will be a free text box for end users – leaving input prone to human error which would cause issues if the attribute is to be used in Rule or Review Definitions.

 

Custom Values

The Custom Values attributes behave differently to other attributes in that they can be deleted. They are meant for for populating Attributes that are both Manageable and Editable.

 

To create a new list navigate to Admin > Attributes > Custom Values > New Value List…

 

                          

 

As with extending the schema of other objects carefully consider the values you want contained in your list. Once created they can be changed but if you have already been populating object’s attributes with values from the list they do not dynamically change.

 

Another interesting use case for Custom Value Lists is utilising the Object type for the list. Rather than a string or an integer you can restrict the value to be populated into the Managed Attribute to be selected from an object picker:

 

                                    

 

Display Options

How, when and where the attribute will be visible in the UI is controlled by the following settings:

 

                                 

 

  • Public — Select this option if you want this attribute to appear in detail views and information popups for users who do not have explicit permissions for the object. By default, all user attributes and custom attributes on other objects are set to private, which means the attribute will not be displayed for users who do not have explicit permissions. For more information, see Specify How Attributes Are Displayed in the User Interface.
  • In Detail — Select this option if you want this attribute to appear in the details view for the object.
  • In Popup — Select this option if you want this attribute to appear in information pop-ups in the user interface.
  • In Tables — Select this option if you want this attribute to be included in a table and available as a column in a table (from Table Options).
  • Detail URL — Provide a URL that you want displayed in a popup dialog when the information icon for the value of the attribute is clicked to show further details.
  • Hide if Empty — Select this option if you do not want this attribute to appear in details views or information pop-ups in the user interface if it does not hold a value; otherwise, deselect.

 

In addition to this, the order in which attributes are shown under each object can be set by moving the attributes into the order you want and Separators can be added to group things logically. This can be particularly useful for User objects where you want to split attributes by HR Data, Contact Information and Technical Detail for example:

 

               

 

These are easily created by selecting the Add Separator button on the same screen where you can edit/create Attributes. Unlike Attributes, Separators can be deleted at any time.

 

That's it...

I hope this blog post has highlighted how useful the creation of custom attributes can be as well as the importance of doing so for the right reasons in a controlled manner.

 

Please comment with any feedback, ideas or use cases of your own and thank you for reading.

RSA IGL Version: V7.1x & V7.2x

Modules: Governance

Product Area: Reviews

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~30 minutes

 

Summary:

This recipe combines web services and workflows to automate and control the review change request generation tasks. The recipe combines the benefits of both out of the box Automatic and Explicit review change request generation options with minimal configuration.

 

 

Background

The RSA IGL Reviews module provides 2 methods for generating change requests, as explained below:

 

1. Automatically

Since change requests are automatically created as soon as reviewers saves their decisions, you get the following:

Pros

  • No additional administration overhead for the review owner or administrators to periodically generate change requests.

Cons

  • There is no control over the timing of the generated change requests.
  • There is no control over the grouping of change items.
  • Reviewers have no margin for error since a change request is generated the moment they save their changes.

 

2. Explicitly by Owner

Since change requests are not generated until the review owner or administrator manually triggers the change request generation, you get the following:

Pros

  • More control over the change request generation grouping (By Reviewer, By Component ... etc).
  • More control over the time when change requests are generated (Daily, Weekly ... etc).
  • Reviewers have the ability to review and change their decisions until the next change request generation task is run.

Cons

  • Additional overhead of the review owner or administrators to manually start the change request generation process.
  • Potential of missing a few changes if the review owner or administrator does not manually generate the change requests. 

 

Challenge

 

One of the most common requests we've seen is a solution that combines the benefits of both Automatic and Explicit change request generation. The requirements are mostly:

  1. Having the ability to control the timing and grouping of generated change requests without requiring manual intervention from the review owner or administrators.
  2. Giving reviewers a grace period - for example: until the end of the business day or end of the week - to change any decisions they took before any change requests are generated without requiring the review owner or administrators to perform manual actions outside business hours.

 

Suggested Solution 

 

We can leverage the createRequestsByOwner web service command which is used to generate change requests for a review. This is equivalent to the 'Create Change Requests' button found on the Change Preview tab of reviews that are configured to generate requests explicitly by owner.

 

Web Service Usage

Note: The below is only the relevant subset of the full web service description. For full usage details, you can go to Admin > Web Services > Requests > Click 'Click for details' beside the createRequestsByOwner web service.

  

Input Parameters

The command expects the following parameters where a * denotes a required parameter:

  • id* - The id of the review result to create change requests for.
  • group - Specifies how changes should be grouped together.
    • Reviewer, PerComponent, PerAsset valid for user reviews.
    • Reviewer, PerComponentResource, PerComponent, PerAsset valid for account reviews.
    • PerComponent valid for group and role reviews.
  • format: The format to return the data in (default = properties)

 

Output Parameters

The command returns the following properties as output:

  • name - name of the review.
  • status - success or failure.
  • message- Optional message to return along with the status.

A precondition failed (412) return code is returned if the review is not configured to generate requests explicitly by owner.

 

Example

An example url used to invoke this command is shown below:

https://<Hostname>:<Port>/aveksa/command.submit?cmd=createRequestsByOwner&id=1&group=Reviewer&format=properties

 

Calling the Web Service

 

There are two suggestions on how to call and schedule this web service:

 

Option 1 - Review Escalation Workflows

Using a Review Escalation workflow which calls createRequestsByOwner for the specific in scope.
Pros:

  • Simple to implement and has better visibility on runs per review.
  • Also easier to have different options/frequency per review.

Cons:

  • Review Escalation workflows cannot be triggered in a recurring way (every day). So an escalation must be added per exection. Depending on the duration of the review, this could require a large number of escalation workflows.

 

Option 2 - Custom Task Workflows

Schedule a generic Custom Task workflow that calls the createRequestsByOwner for all open reviews.
Pros:

  • A single workflow should work for all active reviews.
  • Better scheduling frequency options.

Cons:

  • Less visibility on runs per review.
  • Extra complexity to control options/frequency per review type.

 

Implementation

 

Web Service Security Settings

Make sure you thoroughly test any changes in lower environments first before promoting them to Production.

Make sure you are on 7.1.1 P07 / 7.2.0 P01 or above to be able to call the web service from workflows without a token (Reference ACM-103573).

  

You need to make sure of two things:

  1. Enable Web Services and whitelist the IGL server(s)' internal IP addresses.


  2. Enable the "Request Forms and Workflows (no token)" checkbox for the createRequestsByOwner web service.

 

Workflow Configuration

 

Option 1 - Review Escalation Workflow

 

  1. Create a new "per Review" Review Escalation Workflow


  2. Configure a simple REST node that calls the createRequestsByOwner web service.

    REQUEST
    URL: https://<Internal-Hostname>:<Internal-HTTPS-Port>/aveksa/command.submit
    Method: GET
    Request Params:
    cmd: createRequestsByOwner

    format: properties
    group: <Grouping option of choice>
    id: ${jobUserData_acm.ReviewId}


    HEADER
    Content-Type: text/plain

    RESPONSE
    Proceed on failure: Checked
    Response Type: Properties
    Response Variables:
    status: Job, status

  3. Add the escalation workflow to the Escalations tab of the review definition as much as required.
    Example running this workflow on a weekly basis for 4 weeks (28 days):

 

Useful Tip for Scheduling Review Escalation Workflows

 

Since Review Escalation Workflows do not have the ability to specify the exact time (hours and minutes) the workflow will run on a specific day, you can use a Delay node with SQL Delay that returns the today's date at a specific time.

 

For example, if you want the change request generation to be triggered at 9:00 pm. Then it can be calculated as follows: 

  • trunc(sysdate) returns today's date at exactly 12:00 AM (00:00)
  • + (day fraction) to add the exact time offset required. For example, 9:00 PM is 21:00 which means 21 / 24.
SELECT
    trunc(sysdate) + 21 / 24 AS wait_date
FROM
    dual

 

Option 2 - Custom Task Workflow

 

  1. Create a Custom Task workflow.

  2. Add a SQL Select node that gets any non-completed Review ID that is configured to generate change requests explicitly by owner. Use the following SQL statement as an example:
    SELECT
        rv.id    AS review_ids,
        0        AS tmp_id
    FROM
             t_av_entreviewdefversions rdv
        JOIN pv_review rv ON rv.review_definition_id = rdv.id
                             AND rdv.generate_change_request = 'M'
                             AND rv.state IN (
            'InProcess',
            'InActionable'
        )

     

  3. Configure a Next Valye node to loop through the Review IDs


  4. Add a REST node with the same configuration as in Option 1 Step 2. The only difference is that the Review ID is now in the created Workflow Variable ${jobUserData_TMP_ID}



  5. Make sure the two transitions coming out of the Next Value node are set to Completion Code.
    • True: Continue looping.

    • False: Finish process.


  6. Schedule the Custom Task workflow as required.

RSA IGL Version: V7.1x & V7.2x

Modules: Governance 

Product Area: Account Reviews

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~2 hours

 

Summary:

Within Account Access and Ownership Reviews, the Maintain and Revoke buttons are mandatory and cannot be hidden or removed. When a reviewer selects Revoke against the account, this will result in a change request being generated to delete the account.

 

It is not always possible to delete accounts and it has been asked by multiple customers how the Revoke button behaviour can be changed to perform disablement of the account or even disablement and removal of access.

 

The attached document, created by RSA Professional Services, provides details on the out of the box components used and steps followed to create an Approval Workflow to:

  • Reject the automatically created Delete Account change request
  • Create a new change request to disable the account
  • Create a new change request to remove access (if required)

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: RSA IGL Services 101: Explaining 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.

 

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

 

 

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

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.

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.

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.

 

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.

RSA IGL 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!

 

This blog provides a high level index and summary of each workflow node available, taken from v7.1x of RSA IGL. As we dive into more detail of each node, we will provide a link below, to click and get more info. For example, please click "Milestone" in the table below.

If there is a specific node you would like to know more about, please let us know in the comments below

Workflow Node Summary

The workflow editor includes processing nodes common to and also specific to request, approval, fulfillment, and escalation workflows. Nodes are the building blocks you use to create and modify workflows. This following table lists nodes that you can use in request, approval, fulfillment, and escalation workflows.

 

Node

Description

Activity

Used to define a activity for a change request.

Approval

Used to define an approval for a change request.

Approvals Phase

Used to allow change request items to be approved as groups at the same level.

Cancel Change Request

Used to generate a milestone to cancel the entire change request processed by the workflow and revert all changes completed in the change request, reject the entire change request processed by the workflow, or put the change request in an error state.

Complete Assigned

Used in an escalation workflow to mark work assigned to a user (through an approval or activity) as completed.

Create Admin Error

Specifies the type of admin error to create for an administrator.

Decision

Evaluates a condition(s) based on a true or false result for outgoing transitions to an action or stop delimiter based on whether or not the condition exists.

Delay

Suspends a workflow temporarily based on date criteria. The date could be a specific date, the change request fulfillment date, a system calculated date relative to current time, the result of a java method that returns a date, or the result of a SQL query resulting in a date.

Form Approval

Used to define an approval for a change request generated from a form.

Form Fulfillment

Used to define a fulfillment for a change request generated from a form.

Fulfillment Handler

Invokes a Java class to fulfill changes in a request.

Fulfillment Phase

Used to allow change request items to be fulfilled as groups at the same level.

Get Remaining SecondsUsed to store how much time remains for a calculated due date, performs some escalation outside of the assigned user’s control, and then updates the due date for the assigned user based on the earlier recorded remaining time.

Java *

Provides an interface to a Java method passing any parameters and returning a true/false result you can incorporate into a workflow.

The Java node, can evaluate conditions and perform actions in a workflow required for an approval and to initiate completion of an activity.

Note that if you use the Java node in a workflow or use the Java tag in workflow forms, you should place custom classes or jars in one of the following directories:

  • aveksa.ear/aveksa.war/WEB-INF/plugins/JavaNode/lib
  • aveksa.ear/aveksa.war/WEB-INF/plugins/JavaNode/classes

The sample Java Node workflow is deployed and references classes in these plugin directories. The source files for the samples are also included in the plugin directory under the src directory.

Job State

Specifies a job state the pauses a workflow: Canceled, Error, or Suspension

Manual Fulfillment

Used to handle a fulfillment manually and not automatically by the system.

Mark Verified

Used to indicate that changes marked as pending verification should be marked as verified.

Milestone

Provides high-level status information about a workflow milestone you want displayed in a change request.

Next Value

Returns the next value for a given job level workflow variable. If no value is returned (the last value was previously retrieved), the node returns false, which can be tested on an outgoing transition. If a valid value is returned, a true return code is provided. This node is typically used to iterate through an array of values to get the next value in the array..

Provisioning Command

Used to complete a provisioning command in a data source for a particular business source.

Reassign

Used to assign an approval or activity to another user.

Reset Password

Used to generate an email notification prompting a user to retrieve a password that has been reset for the user.

REST Web Service *

Invokes a REST call to an endpoint. The responses and results from the calls are stored in the workflow variables based on the configuration in the node. This information can be used in a workflow’s decision logic.

The node supports:

  • GET and POST methods
  • Basic authentication
  • Header parameters.
  • XML and Properties response types
  • Parsing of the response using XPath and RegEx expressions.

Run Report

Generates a report configured for the node in the workflow.

Run Review

Used to generate a user access review associated with the node.

Send Email

Generates email you want from the workflow. It supports the use of workflow variables or runtime workflow information to specify the To/From portions of the email.

Set Value

Creates or updates a job level workflow variable(s) using the value(s) provided. The value can be a literal or use other workflow variables that are evaluated at the time the node is executed

SOAP Web Service *

Invokes a SOAP call to an endpoint. The responses and results from the calls are stored in the workflow variables based on the configuration in the node. This information can be used in a workflow’s decision logic.

The node supports:

  • POST method
  • Basic authentication
  • WS-Security
  • Generic MIME Header
  • SOAP based XML response type
  • Parsing of the response using XPath and RegEx expressions

SQL Execute *

Runs an Insert/Update/Delete SQL command or a stored procedure where no result set is needed. It runs against the system database (AVDB). This node supports variables from the workflow with the SQL.

If you want to use an output parameter from your stored procedure (say, ‘success’ or “failure’ status) as a workflow variable for subsequent processing, you must define the stored procedure as a function and use the following syntax:

select sp_update_db (‘JOE’, ‘SMITH’, status) status from dual.

SQL Select *

To be updated.

Start

Used as the start delimiter for a workflow.

Stop

Used as the stop delimiter for a workflow.

Subprocess

Calls/interjects another workflow as a subprocess of the current workflow. This node is useful in compartmentalizing work items or to improve maintenance or re-use of workflows.

Text Node

Used to enter text into a workflow.

Transition

Used to connect two workflow nodes (processes) unidirectionally with a straight line. Transitions can be conditional or unconditional. A conditional transition occurs only if a particular condition is true. An unconditional transition can occur regardless of whether a condition is true. A transition is visually represented as an arrow.

Undo Changes

Used to generates changes to reverse the requested changes that have been fulfilled.

Wait for Verification

Used to create a database watch for evidence of a change request fulfillment.

 

Note: Not all controls and types are available for every workflow type. Also, nodes with an asterisk symbol ( * ) are designed for advanced application. These nodes should be implemented carefully because poorly defined nodes can negatively impact workflow performance.

RSA IGL 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!

 

Product Area: Reports/Charts/Table's

Data: App-Roles

Summary: Application roles collected within "directories" are not located in the PV_APPLICATION_ROLE view but are instead found under PV_DIRECTORY_ROLE view. If you use directories and collect in APP-ROLES, you must take this into account for all your reports/charts that you create, so that you dont miss out any information. 

RSA Field Example: If creating a report/chart to display all app_roles within RSA IGL which have a "privileged" flag set to "yes", you will need to take into account both these tables in the SQL.

SQL Example:

select 
    application_id,
    name
from avuser.pv_application_role
where lower(privileged) = 'yes'
union all
select
    application_id,
    name
from avuser.PV_DIRECTORY_ROLE
where lower(privileged) = 'yes'

 

These images show where the data is found.

 

Within the Directory "Navision - SQL Database" we can see the "app role" called "db_access_admin"

When searching against PV_APPLICATION_ROLE table - the result is not found

When searching against PV_DIRECTORY_ROLE table - the result is found

 

Thought I'd share this to save others time if they weren't already aware.

 

Cheers,

Clive

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 "milestone" node. 

The RSA Services team love to use Milestone Nodes whenever possible and find they are a great addition to any workflow. However they are surprised to find they are not being used enough by our customers to help make things easier and clearer!

 

Thanks to the PS rockstars: Clive Morrish, Ahmed Nofal and Mostafa Helmy for their help on this blog.

Click the images to enlarge if you need!

Product Area: Workflow's

Note: A summary of all workflows is found here: RSA IGL Services 101: Explaining Workflow Nodes - Summary

Workflow Node: Milestones

Time to apply: <10 minutes

Impact: High positive impact for end users, Low risk to workflow process as nothing is being changed to effect the flow.

Summary: Using "Milestone" nodes, provide a great way to help track the route a workflow has taken and give some business friendly information about what's happening, without having to drill into the processing itself. This helps business end users and admin's alike, as the Milestones are captured on the Request Tab to provide an easy to use reference point. 

RSA Field Example: To put it in generic terms, what we really use them for, is to help determine why the CR has ended up where it has, without having to look at the processing workflow. We typically use them after decision nodes or to provide success/failure response. 

As shown in this status image below, to meet a customer requirement we needed to identify requests created as a result of an account being Revoked within an account review and handle them differently. This is the first decision within the workflow and we use the Milestone to confirm this, without this Milestone you'd need to view the processing workflow to confirm the route the request has taken.

 

Then, because it’s a revoke from a review, there's a requirement to create a new CR from the workflow. This milestone not only confirms the new CR has been created but also provides the new CR id. This provides an audit-able trail and helps users with locating the new CR.

 

In its simplest form, the Supervisor Approval workflow could be updated to include Milestone to advise if a supervisor couldn’t be found! Without the milestone, you'd need to dig a little deeper to extract this useful information.

 

 

Usage: All workflows should include milestones where possible, especially ones which are seen by business users, to make their understanding clearer and the process more simple.

General Notes/Benefits

  • Positive business impact to provide added information and details
  • Reduced help desk calls, where business users don't understand whats happened and why
  • Aid with troubleshooting
  • Can be used to provide error handling
  • Can be used to assist with tracking/auditing
  • Can provide dynamic variables from the request
    • As an example, you could have a workflow create an additional CR, a milestone can be used to confirm the new CR has been created successfully and also provide the CR ID, as shown below:

 

Configuration:  

  • We are using v7.1x in the example below, however most versions of the older product also have milestones available. 
  • Milestone nodes are found under the "Modeler Toolbox", about halfway down, as shown in the image below. Just drag and drop them into your workflow.

  • Milestone nodes have a couple of basic properties:
    • General: Name
      • Keep the node name generic and configure the milestone message under the Status options, for the following reasons
      • Variables cannot be used within the Node Name but they can be when using the Status options
      • The status options can be used to control when the milestone is displayed
    • General: Description
      • A simple description of what the milestone is doing, for future reference.

 

  • Status options:
    • Planned (Possible)
    • Completed
      • Planned (Definite) - we recommend not to use this one and to stick with the Possible/Completed

 

To help try and explain these, we have created the following workflow that contains a Milestone for each option.

 

 

The Planned (Possible) message will be displayed even though at this point the workflow has not yet transitioned through the node. This is a way to provide some information about a potential next step in the process, which is upcoming. 

 

 

 

Completed will populate the message only after the workflow has successfully transitioned through/past the node:

  

 

RSA PS Recommendation

Leave both ‘Planned’ options empty and only populate the Completed option to show the business which items have actually happen in the process flow, so as to not cause any confusion.

Final note.

Milestone nodes, also make use of the helpful information "i" button, found at the end of the status details. The "i" button displays details directly from the request. The below image is the first decision in the License Review workflow which checks if the requested entitlement is licensed or not. By clicking on the "i" button it confirms which entitlement it’s referring to, this is really relevant if you have CR containing multiple items (which is a common use case)

Date formats in workflows, typically come in a very long and "un-useful" format, which is: "YYYY-MM-DD HH:MM:SS" eg: 2019-11-05 10:46:54.0

This format is not very useful for business users and so changing it to be something more "readable" is a good idea in general. 

 

Thanks to the help from our resident rock star...Mostafa Helmy, we have the following example that you can use today for your review esclation emails. The below could be applied to any dates in other areas of the product too, however review esclations is a widely used area and a good place to start.

 

The process is as follows, where we want to update the review "end date" value.You could apply this to the "start date" too, if you wanted.

 

  1. First, establish the format of how you want the date to look. e.g.. "29-01-2019" or "Feb-22-19" etc..
  2. To do this, open a query analyser (e.g. SQL Developer) and test with the following SQL to find the date you want to display.
    Note, this example has 2 different options to get you started. Also, see the table below to get more ideas of the date formats that you could use.

    select to_char(sysdate,'MM/DD/YYYY') as new_date from dual;

    select to_char(sysdate,'DAY DD-MON-YY') as new_date from dual;


    Image of the above SQL example

  3. Once you have the correct format that you want to use
    Always start in DEV, NOT prod
  4. Log into RSA IGL as a user who can edit/create workflows
  5. Find the workflow/escalation you want to edit and open it
  6. Add a new "SQL Select" object to the workflow, at the start
    It must be before the "email" or what ever you want this better date format to be
  7. Edit the "SQL Select" object to be the following SQL.
    Note: This SQL will create a new value called "new_end_date" which can then be added into your email.
    Format SQL
    MM-DD-YYYY
    (08/21/2019)

    select to_char(end_date,'MM/DD/YYYY') as new_end_date from pv_review where id='${jobUserData_acm.ReviewId}'

    DD-MM-YYYY
    (21/08/2019)

    select to_char(end_date,'DD/MM/YYYY') as new_end_date from pv_review where id='${jobUserData_acm.ReviewId}'

  8. Set the Variable Type to Job. This must be set so that it can be referenced as a variable within the workflow
  9. Make sure you now hit "SAVE"
    The new value wont show until you have done this!!
  10. Select your email node and "right-click" where you want to add the new value (new_end_date) to add it in. (See image below)
  11. Test this has worked by generating a new email and confirming the date format is correct and as expected.
  12. Migrate to production

 

 

 

 

Other formatting suggestions:

Note:

  • The format, MUST be in the correct CASE
  • See this link for Oracle datetime format models: Format Models 
YEARYear, spelled out
YYYY4-digit year
YYY
YY
Y
Last 3, 2, or 1 digit(s) of year.
IYY
IY
I
Last 3, 2, or 1 digit(s) of ISO year.
IYYY4-digit year based on the ISO standard
QQuarter of year (1, 2, 3, 4; JAN-MAR = 1).
MMMonth (01-12; JAN = 01).
MONAbbreviated name of month.
MONTHName of month, padded with blanks to length of 9 characters.
RMRoman numeral month (I-XII; JAN = I).
WWWeek of year (1-53) where week 1 starts on the first day of the year and continues to the seventh day of the year.
WWeek of month (1-5) where week 1 starts on the first day of the month and ends on the seventh.
IWWeek of year (1-52 or 1-53) based on the ISO standard.
DDay of week (1-7).
DAYName of day.
DDDay of month (1-31).
DDDDay of year (1-366).
DYAbbreviated name of day.
JJulian day; the number of days since January 1, 4712 BC.
HHHour of day (1-12).
HH12Hour of day (1-12).
HH24Hour of day (0-23).
MIMinute (0-59).
SSSecond (0-59).
SSSSSSeconds past midnight (0-86399).
FFFractional seconds.