Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog
Jamie Pryer

Reporting on Reports....

Posted by Jamie Pryer Employee Dec 6, 2018

A common question we get asked... "How many reports are there within RSA IGL"

The answer: LOADS!


Within RSA IGL we have a LOAD of out the box (OTB) reports included and shipped as standard.

All these reports can be found in the UI, by going to “Reports/Tabular” then “Create Report” button at the top.

From here you can find a lot of OTB reports by using the “type” and “Template” dropdowns.

For example, if you wanted a report on all your orphan accounts, you would select “Account” and then “Orphaned Accounts” - thats it! really simple


If you want a simple way to see all the reports you have in the system overall, you can execute the following query, either within something like SQL Developer or create a new a report within the UI itself


Main Query:

Select * from V_LIST_REPORTS;

This table tells you all the reports you have in your enviroment, both OTB and any you have also created as well.


Steps to create this in the UI are as follows

Note: this takes <5minutes to complete

  1. Log in as an admin user or as a user who can create reports
  2. Go to “Reports/Tabular”
  3. Click “Create Report” button
  4. Give you report a title and some details so you know what its for in future.

  5. Click the “Query” tab at the top
  6. Add the following SQL query:
    (select *  from avuser.V_LIST_REPORTS)
    Note: makes sure you wrap you the SQL in parenthesis “(“ and “)”
  7. Click the “Columns” tab
  8. Select only the following columns in the right-hand pane called “Displayed Columns” – everything else should be moved to the right.
    • Name
    • Report Description
    • Report Title
    • Last Modified Date
  9.    Click on “preview” button at the bottom to check its worked.

    These are more nice to have changes, that might make the report look a bit better, in my opinion
  10. Go to the “Grouping and Sorting” tab
  11. Select “Report Type” under Grouping, so that we can see the groups of reports we have created

  12. Click the “style” button at the bottom of the row

  13. Select “slate”

  14. Click "OK" to save and exit your report


Thats it, all done!

Sean Miller

Security Context

Posted by Sean Miller Employee Nov 21, 2018

This is for advanced users.  While security contexts can help control who can do what in the product, it can adversely affect performance if you have a lot of rules or the scope filters are very heavy to evaluate.  These rules must be evaluated on every user login.

Custom security context files can be used to define your own security rules and/or overload security rules provided in the shipping product.  The key to identifying if you are adding new privileges or modifying existing ones is based on matching the secure object type, name, and action.  If those match an existing entry, then you are overloading an existing privilege.


Custom Security Context

To customize the security context, you should:

  1. Do NOT modify the default file inside the aveksa.ear
    Modifying the security context file inside the aveksa.ear is not supported and you will lose your changes on upgrades, moving to other systems, or within a cluster.  By following the steps below you will keep your changes, they will be included in upgrades, and all nodes involved will see the changes.
  2. Take a copy of it to your PC (to use for reference later) so you have the header format and you can see existing entries.
  3. Create a new SecurityContext.csv file with the Header and a line for each privilege you want to add or modify or delete.
  4. Save and upload the custom security file to the UI under Admin > User Interface > Files > Security.

New Privilege

A new privilege is defined when it has a unique secure object type, name, and action.  The product has an internal fixed list of security object types and actions it supports so adding your own won't have an effect (only introduce unique names).


If the following privilege is defined, then I might introduce a similar privilege with a different name.  This has the effect of adding to the existing security privileges for the secure object and action:



Application,Business Owner,Manage,,scope,,t_applications,business_owner=${id} and resource_type='A' and is_deleted='FALSE'

Application,Custom Business Owner,Manage,,scope,,t_applications,cas1=${id} and resource_type='A' and is_deleted='FALSE'


In the example above, we defined a new privilege that is going to look in the custom attribute CAS1 to determine if the logged in user should have the Application:Manage privilege.  I named this new privilege 'Custom Business Owner'.


To use the new privilege, upload the custom security context file using the 'Custom Security Context' section above.


Modifying Default Privilege

To modify an existing privilege, following the steps in the 'Custom Security Context' section above. Find the line of the existing privilege. In this example:


Change Request,Affected,View,scope,,,t_av_change_requests, in (selectchange_requests_id from t_av_change_request_details where affected_user_id=${id})


Modify the scope filter for the privilege and upload the custom security context file on the UI under Admin > User Interface > Files > Security.


Disabling Default Privileges

Should you want to disable an existing privilege, then you should follow the exact same steps as in the modifying default privilege, but provide a scope filter that is never true (For example: 1=0).



Change Request,Affected,View,scope,,,t_av_change_requests,1=0


Many people have incorrectly tried to modify the default security context file instead removing the physical entry all together.

This posting is based on functionality as of 7.1.0 P04 and 7.0.2 P10

Please see the attached case study for how RSA IGL has helped a leading automotive company to reduce data retention and acces risk

Please find attached details of how RSA IGL has heped Dell technologies to reduce audit effforts by 50%, enhance their compliance posture and improve overall user experience!

Please see the attached for a great case study around how RSA IGL has helped a leading food manufacture to cut excessive privilages and reduce business risk.

A lot of quesitons are asked around how to calculate users within RSA IGL and different totals for each user "type". for people who have left the organisation. 


A user "type" could be one of the following, when it comes to their status

  • Active
    • They are an active employee, who is part of the organisation still (eg. they are still on the payroll and working for the company)
  • Leaver
    • They are no longer an active employee and part of the organisation (eg. they are not being paid for working at the company any longer.
    • These can be collected and broken down into 2 different classifications:
      • Terminated (is_terminated)
      • Deleted (is_deleted)


Taking a step back and looking at identity collection...

RSA IGL works by collecting identities (individual users) into the system but we NEVER remove them out again. So once an identity is "in" RSA IGL, that’s it, they are there forever.

Even if we remove an identity from the source feed of HR (so an identity is no longer included within an identity collection), that identity will still be seen in RSA IGL.


RSA IGL Flags used for leaver types

 All companies do things differently, some companies keep their historic employees that have gone in their HR feeds =  these would be covered with an "is_terminated" flag. 

Some just keep a HR feed of only active users, so these would be covered with an "is_deleted" flag AND the "is_terminated" flag.


There are 2 different flags that we use to classify tan identity who is a "leaver", due to the way different companies manage their leaver data. These flags are set at the individual idenitty level and can be seen from the main "user" display view, or within any selected identity itself.

  • Is_terminated = this shows a identity who we are still collected into RSA IGL but HR states they have left the organsiation (maybe with a flag). This is like a positive confirmation someone has gone from the organisation and is a great piece of information to gather if possible.
  • Is_deleted = this shows a identity who we no longer collected by the RSA IGL identity collection process and so RSA IGL will assume that that they have left the organsiation (as they are no longer in the HR source data). This method is not a positive confirmation someone has left however, as it could just be that there was a mistake and the identity was not included in the HR source data for some reason. In general however, if someone is removed from the HR source, we treat this as confirmed they have left that company.

When an identity is set to "is_deleted = true", we also assume they have left the company. So the "is_terminated = true" flag is ALSO set. 



Working examples
  • Active Identity 
    • The identity for "Joe Blogs" is found in the HR source with the ID "JBLOGS". This identity is active within the company and a current employee.  This identity is collected into RSA IGL as an "active" user and so
      • Is_terminated = flase (no)
      • Is_deleted = flase (no)
  • "Is_Deleted" 
    • The identity for "Joe Blogs" is NO LONGER found in the HR Source anymore. So the ID for "JBLOGS" which was in the HR data previous has seen been totally removed from this data source. The identity is NOT collected into RSA IGL, as its not in the HR data. 
      • Is_terminated = true (yes)
      • Is_deleted = true (yes)
  • "Is_Terminated"
    • The identity for "Joe Blogs" is STILL found in the HR, however HR has set a flag against the "JBLOGS" for "Leaver" to be "true" - So the HR team is telling RSA IGL that JBLOGS has left the company. The identity for JBLOGS is collected into RSA IGL, but we also have this extra info with the flag being set.
      • Is_Terminated = true (yes)
      • Is_Deleted = flase (no)


How can you calculate these different types of identities in RSA IGL?

Option 1 = In the RSA IGL UI itself. (see image below)

  1. Log in to RSA IGL as someone within Admin privilages (who can see all identities in the system)
  2. Click on the "Users" then "Users" menu
  3. Using the "Grouping" drop down, select either "Is_Deleted" or "Is Terminated"
  4. This will then give you the total number of identies for each status.

SO in this example below, we can see there are 85005 identies who are "is_deleted"

NOTE: this method will have some cross-over, as there are some identites in a system who could be set to BOTH "is_deleted = yes" and "is_terminated = yes". See examples above for more info on this

UI Calculation Example

Option 2 = A SQL query against the DB

  1. Run the folllowing SQL query against your DB, to produce a list of the different types of identies. 


count(1) as TotalUsers,

sum(is_terminated) as TerminatedCount,

sum(is_deleted) as DeletedCount

from avuser.t_master_enterprise_users


Note: The SUM total of "is_deleted" and "is_terminated" might not always add up to the "total_users" value. This is due to the fact that some identites could be set to both "is_deleted = true" and "is_Terminated = true". Please see the example above for more infomation.



Thanks for reading - if you have any quesitons, please ask below.


Jamie Pryer

RSA Global Services Product Lead - Identity

Please see the attached for a case study around how RSA IGL has helped a leading healthcare company lower their risk and slash their provisioning times!

Currently we document some minimum database server resource requirements which can be found here:


These are minimum requirements and do not mean that your system will always perform optimally as there are several factors that can contribute to the performance of your system. These factors range from the amount of Applications you are going to monitor, to the Change Requests you create & process, and the number of Certification cycles you go through. These are just an example of some of the factors that determine the resource requirements of the system. We can give you a more accurate sizing guideline with a detailed analysis of the data you will maintain/collect and the features used in the system. For more information contact your local Professional Services group to go through a sizing exercise or Edwin Mullie.

We do not recommend running the database on a virtual machine. If you plan to run the application on a virtual machine make sure you understand the basics of virtualization. Virtual machines share the resources with all the other virtual machines running on the same host server. Depending on your virtual infrastructure a virtual machine may not actually be able to allocate all the resources that it was created with. This overcommitting of resources such as memory will cause severe performance problems with the virtual machine and all the applications that are running on it. The allocation of resources and monitoring of a virtual server requires in depth knowledge so that all virtual machines on that server can service the applications they are hosting efficiently. The requirements for a VM running our application server can be found here:

The RSA® Identity Governance Service Team recently published a new Implementation Blueprint for integrating RSA Identity Governance and Lifecycle with Varonis DataPrivilege®.  Together RSA Identity Governance and Lifecycle and Varonis deliver a data access governance solution that allows centralized management and control of unstructured data to quickly detect and mitigate access risks ensuring continuous compliance.


This Implementation Blueprint will help the business to quickly detect security and compliance access risks and amend access entitlements issues associated with unstructured data


This Implementation Blueprint provides the following benefits:

  • Enhanced visibility and control of unstructured data directly within RSA Identity Governance and Lifecycle.
  • Ensures users are granted appropriate access permissions in accordance with the organization’s access policies.
  • Reduces the attack surface and enhances regulatory compliance by limiting access privileges and deactivating stale/orphaned accounts.
  • Automate provisioning and de-provisioning of access permissions


Key Use Cases:

  • Unstructured data access certifications
  • Self-service access request for unstructured data
  • Data owner approval of access requests
  • Automate access requests and revocations to Varonis


For more information on RSA Identity Governance and Lifecycle Implementation Blueprints, please visit or contact an RSA representative.

The RSA Identity Governance and Lifecycle Shopping Cart has been certified on Jakarta and Kingston versions of ServiceNow.


RSA is making identity governance and administration (IGA) easier with the release of RSA Identity Governance and Lifecycle version 7.1 to simplify day-to-day governance while reducing overall identity risks.


Whether you are on an older version of RSA Identity Governance and Lifecycle or just recently updated to version 7.0.x, upgrading to version 7.1 provides many benefits.

Better User Experience and More Effective User Access Reviews

The new user experience for reviews provides a much simpler experience for your end users, a great advantage, but it’s more than that. The newly enhanced experience leverages underlying risk analytics to determine risky access and/or violations and prioritizes that access for the end users. By taking a risk-based approach, reviews are more effective, as the highest priority (riskiest access) is addressed first by the end users. This ultimately helps reduce rubber stamping by business users and improves your overall security posture.

More Secure Password Management for Privileged Users

Organizations that are using the current integration with CyberArk Application Identity ManagerTM (AIM)in the 7.0 platform can enable the collectors with version 7.1 for CyberArk in addition to the existing connectors. This enables passwords to be managed and rotated through CyberArk instead of being stored inside RSA Identity Governance and Lifecycle.

Improved Product Performance and Scalability

We continue to focus on advancing overall performance and scalability of the platform to ensure it meets the growing needs of our customers. Additional enhancements, including data archiving and workflow priority queuing and dashboards, help to streamline and make day-to-day administration easier and faster within the platform. The archiving feature helps organizations that have lengthy retention policies and/or compliance requirements. By archiving, you are able to meet the requirement, but move data off of production in order to improve overall performance and not bog down the system.

Broader System Support

The newly released platform supports updated versions of the operating system (SUSE 12), application services (WildFly 10, WebLogic 12.2, WebSphere 9) and Java 8. These updated version supports may be required by some environments and are available now with version 7.1.



Workflow Priority Queues & Enhanced Dashboard

Improved workflow priority visibility lets users proactively understand factors that may be blocking higher-priority requests and be able to remediate.

Multiple workflow queues have been added to manage various types of requests to process the most important items first, such as termination/password reset requests, which are placed in a high-priority queue. New dashboard surfaces details on workflow performance and alerts administrators with issues that may be blocking higher-priority requests from being addressed.


Virtual Application for VMware

RSA has made it easier for customers to deploy a virtual image of the RSA Identity Governance and Lifecycle application in their virtual environment for VMware. This reduces the time and effort required to get RSA Identity Governance and Lifecycle up and running in a virtual environment through traditional installation processes.




For more information visit RSA Announces the Availability of the RSA Identity Governance and Lifecycle 7.1 Release . To schedule a demo of version RSA Identity Governance and Lifecycle 7.1, contact your RSA representative.

We have all been driving our car and at some point a light comes on the dashboard.  Sometimes it is a simple orange light like the windshield fluid.  We should top that up but I can keep driving without harm likely (unless I can no longer see the road).  The dashboard might similarly show me an orange check engine light.  This usually means you need to get your car into the shop but it isn't an immediate concern.  Alternatively, the same light might show red telling you a serious problem has occurred in your engine.  You need to stop driving now.  In the recent  RSA Identity Governance and Lifecycle 7.1 release, we have introduced a similar concept focusing on workflow system status.

The Admin->Workflow→Monitoring page will show you a real time view of the workflow system status.  This includes graphs for how hard it is working (Number of Items Serviced), if anything is backing up (Queue Size), and system status indicators.  The status indicators only show if there is an issue. Not only do the status indicators surface that there is a problem, they generally have a means to resolve the problem or at least get more details.  A status indicator will show a hand cursor if you can click it for more information to resolve the issue.  In addition to the visual indicators,  the system will send out admin errors with the appropriate status and information.  The administrators can configure Notification rules to email these events to the appropriate administrator.   


The system is configured to monitor the following conditions and surface workflow status indicators.

Verification (Count)

This status indicator determines how many changes are pending verification that are older than one month and less than 12 months.


  1. Warning - 100 changes
  2. Error - 500 changes
  3. Critical - 1000 changes


This status indicator allows you to click through to a screen that shows the changes that we are trying to verify.  The verifications will be dealt with by future collections or an administrator can choose to cancel a change here to remove the verification.

Verification (Age)

This status indicator determines if there are any changes pending verification that are older than n months


  1. Warning - no warning by default
  2. Error - There are changes older than 6 months that havent been verified
  3. Critical - There are changes older than 12 months that havent been verified


This status indicator allows you to click through to a screen that shows the changes that we are trying to verify.  The verifications will be dealt with by future collections or an administrator can choose to cancel a change here to remove the verification.

Queue Backup

This is a series of status indicator (one for each priority queue type) that will show if work 


  1. Warning - 1000 ms by default
  2. Error -      2*60*1000 ms by default
  3. Critical -  4*60*1000 ms by default

Stalled Workflows

This status indicator determines if there are any workflows marked as stalled.


  1. Warning - 0
  2. Error - 50
  3. Critical - 100

Workflows should not ever be marked as stalled.  So even one is being considered a warning.


This status indicator allows you to click through to see the stalled workflow jobs.   In general, a stalled workflow needs to be examined more closely to see if there is some flaw in the business logic.  A stalled workflow indicates something took longer than expected.  From this screen you can also evaluate the workflow(s) to see if they can proceed. 

Database Connections



  1. Critical - Any exception thrown by the workflow engine that it can no longer communicate with the database


Clicking this status indicator icon opens up dialog where an administrator can check if the workflow engine can communicate with the database. If the connection is successful, the status indicator is cleared and an admin error is logged for change of status.

For more information on this feature – please check out Workflow Priority Queues 

In the recent RSA Identity Governance and Lifecycle 7.1 release, the user interface can customized to better brand the product for the customer's environment.  One new key customization available is the background image displayed when user's are on the login screen.  The file must be a JPEG file that is called login-background.jpg.  The file should be uploaded to the Admin→User Interface→Files page under the images section.  When new users login, they will be shown a customized login screen like the following:

Things to consider when customizing this:

  • The image should be a decent resolution so it renders on various client screen resolutions
  • The file size should not exceed 10MB so it doesnt impact the speed to load the screen the first time too much
  • The uploaded image is audited as part of the events found under Admin->System→Audit


Included in this blog is a set of background images (see attachments) to try out.  Rename the image to login-background.jpg and upload.  The image will be shown the next time you login to the product.

In the RSA Identity Governance and Lifecycle 7.1 release we have added a data archiving feature to allow for the removal of old data from the active system.  The feature will enabled administrations to reduce the size of the database, improve system efficiency and more effectively adhere to their data retention policies.   Once archived, the data will be removed in the next scheduled data purge session. 


Check out this post for an overview of the previously released data purge feature - New Feature:  Database Purge . 


For more information on this feature – please review this additional content


Introduction to Data Archiving 

Data Archive Planning 

Creating a Data Archive 

Troubleshooting Data Archive Failures 

How to Stop a Data Archive 

How to Resume a Suspended Data Archive Run 

Data Archiving: Administrator Experience 

In the recent RSA Identity Governance and Lifecycle 7.1 release we are very excited to announce the release of a new User Access Review experience. 


We have been engaged with many of our customers and partners to understand their key challenges with access reviews. From this engagement we set out to re-imagine our end-user review experience with a focus on three goals:


  • Incorporate risk concepts into the governance process.   Things like open violations, exceptional access, application criticality and privileged should all be incorporated into the decision to maintain or revoke access. 
  • Arm reviewers with more context.   Reviewers should have a wide range of context at their fingertips to understand the mountain of data they are often asked to review.
  • Make reviews easier.  We want reviewers to complete their reviews faster, provide a more meaningful experience and allow them to get back to their day jobs sooner.   


Some notable highlights for the new design experience:


Review Instructions – No longer will review instructions cover the table when open by default.


Progress Monitor – In the upper right side of the table we include in review progress indicator that also will highlight when the review is due.  The progress indicator provides real time feedback as the reviewer takes action on items within the review.


Analysis and Guidance Panel -   Prioritize your attention during a review by organizing your review items into useful categories.  Also see this separate post on the Analysis and Guidance Panel.


Column Level Filtering - Narrow down your review items by using one or more column filters.


Centralized Take Action Menu – Select many items and take action in 1 click.


Centralized Review Data – Expand the row to view more information about the user, entitlement and business source.


For more information on this feature – please check out this additional content. 


New User Access Review Experience - Review Components 

New User Access Review Experience - Table and Review Items 

New User Access Review Experience - Analysis and Guidance Panel 

New User Access Review Experience - Review Item Delegation 

New User Access Review Experience - Take Action Menu 

New User Access Review Experience - Expanded View 

New User Access Review Experience - View and Column Filters 

New User Access Review Experience - Table Options 


Achieve Business Agility with RSA Identity Governance and Lifecycle.