Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog
1 2 3 Previous Next

RSA Identity Governance & Lifecycle

127 posts

Hey all,

We have been working on a new dashboard to help show the value driven from RSA Lifecycle (AFX) module, as per the example below.

We are looking for a customer who uses AFX and would like to spend an hour (or so) on an online meeting, to test this out on their environment. You will get to use dashboard pack yourself, once we have finished. 

If you are interested, please email jamie.pryer@rsa.com 

The dashboard uses the new v7.2x "dashboard facts" and some charts. 

  • The dashboard facts show summary information for "all time"
  • the dashboard charts show you information for the previous 10 weeks, to help understand recent benefit and current trending

This dashboard has 6 key elements, all driven from 2 key values.

 

Dashboard benefits:

  • Show the value the solution is providing your company
  • show how much time and $ your work is saving the company
  • Understand weekly trending
  • Simple dashboard to provide stakeholders key metrics.

 

Key values:

  1. Average time in minutes a request takes within your organisation to complete manually (eg. 15 minutes)
  2. Average $ in cost, that this request would cost (eg. $9 or £5)

 

Dashboard items: 

  1. Dashboard Fact: The total number of AFX requests completed, for all recorded time
  2. Dashboard Fact: The total Hours saved, because of all the AFX requests completed, for all recorded time
  3. Dashboard Fact: the total $ (or whatever currency you like) saved, because of all the AFX requests completed, for all recorded time.
  4. Chart: AFX Total Requests Completed each week (trending over the previous 10 weeks)
    • Eg. What is the total number of AFX requests that were completed, week over week
  5. Chart: AFX Total $ saved each week (trending over the previous 10 weeks)
    • Looking at the total number of completed requests, how much $ has this saved you, week over week
  6. Chart: AFX total hours saved each week (trending over the previous 10 weeks)
    • Looking at the total number of completed requests, how many hours has this saved you, week over week

 

 

Please drop me an email if you want to test this out on your environment too.

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.

DONT FORGET - please register for the March RSA IGL Webinar - RSA Identity Governance & Lifecycle Webinar - March 25th 2020 

 

Our goal of this newsletter, is to help share more information about what's happening and key things for you to be aware of, specifically for RSA Identity Governance and Lifecycle.

This is a monthly release, so you can expect a new Newsletter at the start of each month.

Please feel free to leave comments/suggestions (positive or negative!) below and don't forget to hit that "like" button too 

Current Edition:

  • Issue #11, March 2020: See attachment below 
    • Note:you should be able to view this in a browser, or download/preview the document too. Any issues/questions, just reply to this!

Previous Newsletter Editions:

 

Previous Webinar Recordings: (Note: you must login to view these)

One of the strengths of the RSA Identity Governance and Lifecycle offering is the ability to model groupings of user access using our local role management solution. This provides the capability of combining different types of entitlements (access) that are collected from various end points.  These local roles, whether they are defined as business, technical or global roles, allow you to customize the necessary access that is required for different jobs in an organization.  These become the building blocks of access by allowing you to combine various local roles that will fully define the access needed for your user population.

 

A local role is different from a collected role.  A collected role, like other collected information, is access obtained from an endpoint which maintains that information externally from our system.  Like any collected items, a collected global role is suitable to use as an entitlement in a local role.  A potential problem can occur when a user attempts to add a local role as an entitlement to a collected role.  The endpoint that maintains the collected role definition doesn’t know anything about our internal (local) roles – which contain entitlements from a number of other types and sources, including other local roles and local entitlements.  This would make provisioning of the information difficult, if not impossible, and extremely confusing.

 

At this time, there are areas of the product which inadvertently allow the addition of local to collected roles.  This is not intentional, and we plan to remove that capability in future releases.

In earlier releases of RSA Identity Governance and Lifecycle, a feature to limit the expiration date chosen during rule remediation was made available under the Rules->Configuration menu.  Similar functionality has been introduced in the RSA Identity Governance and Lifecycle 7.2 release for reviews so review administrators can set the maximum number of days access can be maintained with an expiration date.  The settings can be changed under the Reviews->Configuration and Rules->Configuration menus.  The same setting is exposed in both places allowing administrators to specify the default number of days for exception access and also the maximum number of days.

 

 

Once configured, reviewers will be limited in the calendar control available to select expiration dates.  The default date will be selected based on the configuration and the user interface will not allow selections beyond the maximum number of days.

 

For additional information on this update – please check out this additional context:

In earlier release of RSA Identity Governance and LIfecycle, the Generic REST connector was introduced and is being used by many customers.  In the RSA Identity Governance and Lifecycle 7.2 release, we have introduced the matching connectors to allow you to collect entitlements, accounts, and identities from endpoints using REST API calls.  REST is becoming a standard way to interact with systems returning data in a well defined structure (JSON).  One of the key advantages is that if endpoints change implementations, you don't need an entirely new collector but instead simply adjust the REST API calls configured slightly.

 

To get started, create a new collector and select Generic REST as the data source type:

 

 

The following video dives deeper into what to consider when creating a collector and how to handle things like pagination, authentication, and how to debug the configuration.  A REST client like Postman is recommended to determine the right apis to call and how to parse the responses:

In the RSA Identity Governance and Lifecycle 7.2 release, we have introduced a new component that can be used on dashboards to display a single value "fact".  Dashboard Facts are a convenient way to provide high level information on a dashboard with click through support to dive into the details.  Combined with other dashboard components you can build very powerful dashboards targeted to specific users or roles.

 

To create a dashboard fact, you will need to decide on the fact you want to show.  For example, maybe I want to know how many applications have been onboarded into RSA Identity Governance and Lifecycle.  Dashboard facts can appear on any type of dashboard (Welcome, Object, or Topic level).  Along with the fact you will want some visualizations like a name, a colour for the fact, and some descriptive text to explain why anyone cares about the fact (or to give the context for the fact).  When creating a fact, the most important thing to keep in mind is what is the fact meant to convey.  For example, if I show a number of 100 is that a good thing or a bad thing someone may want to drill into more.  For this reason, keep your facts concise.  In addition to the fact itself, you can configure an url that allows the fact to be clicked on to get more details.  This is especially useful to provide a high level dashboard that links to a lot more content like a report or a detail screen within the product.

 

 

It is highly recommended you start with thinking about the fact you want to present and is there an efficient way to get the value to display.  Performance is the key as the query will be run everytime the dashboard is displayed.  RSA recommends using values that are not calculated at runtime.  For example, use counts for objects that are gathered daily and stored in the public view PV_TELEMETRY_DATA  rather than a query that does an actual count every time the query is executed.

 

To showcase this new feature and help system administrators, the 7.2 release includes a new dashboard available out of the box called 'System Admin' Dashboard.  Facts like the number of admin errors are shown on this dashboard with click through support to take the end user to the actual admin errors.

 

For additional information on this update – please check out this additional context:

Two new review analysis have been introduced in the RSA Identity Governance and Lifecycle 7.2 release:

 

 

 

 Never Reviewed

This new category finds any access that has not been reviewed by any reviewer in any review.  This helps reviewers to identify items that have never been reviewed in their list and take appropriate actions.  Other review items will likely have similar review actions to previous reviews unless a user's role or status has changed.

 

 Expiring Soon

Exceptional access given for access raised as a violation will be flagged by this category if the expiration date is within 30 days (default) from the time of the review generation.  The default value can be overridden by navigating to Admin->System->Settings.  This allows reviewers to review the access and make a decision before the access expires and goes through another round of remediation.

 

These new categories can be configured from the Analysis & Guidance page of the review definition along with the other existing categories:

 

For additional information on this update – please check out this additional context:

Sean Miller

New Feature: IMAP Support

Posted by Sean Miller Employee Feb 11, 2020

Email protocols have evolved and to remain modern and provide secure solutions theRSA Identity Governance and Lifecycle 7.2 release now includes IMAP/IMAPS as a supported protocol for receiving inbound emails.  This can be configured on the Admin->Email->Settings page.

 

 

IMAP is recommended to use for the inbound server protocol rather than POP3 and many organizations are now requiring the use of this protocol.

Filter Blog

By date: By tag: