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

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. 

In the recent  RSA Identity Governance and Lifecycle 7.1 release, you can now require a user to specify if a mitigating control is in place for when granting an exception to a Segregation of Duty (SOD) or User Access (UA) policy violation.

During a policy violation review, and when granting an exception, the remediator can specify if there is a mitigating control in place. They can choose if control is:

  • In-Place – there is a control that has been implemented
  • Pending – there is a control defined and is in the process of being implemented
  • None – there are no controls in place or defined at this time

This feature compliments New Feature: Customer Specific Business Justifications that can also be selected when granting a policy exception.   

The configuration for adding mitigating controls for granting exceptional access to policy violations can be found within the rule definition. 

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

Mitigating Controls for Violation Remediation 

We are excited to introduce a new virtual deployment option in the recent RSA Identity Governance and Lifecycle 7.1  release which makes it easier to deploy our solution in a VMWare virtualization environment!

Provided as an OVA file, all the neccessary componets are supplied to connect your RSA Identity Governance and Lifecycle application to an existing database instance.  Using the supplied configuration wizard, which prompts and ensures that all the necessary configurations are set, customers can quickly stand up the RSA Identity Governance and Lifecycle application. 

For more information and to view an example installation and setup, please refer to the following video tutorial:

Virtual Application Installation and Setup 

Sean Miller

Workflow Priority Queues

Posted by Sean Miller Employee Feb 19, 2018

In the recent  RSA Identity Governance and Lifecycle 7.1 release, we have introduced priority queues in the workflow engine.  These are not exposed to end users but are designed to provide more throughput in processing workflows.  In particular, if a larger request is being processed, some other types of requests can still get through if they are deemed important enough rather than waiting in line.  In the past, the workflow engine processed things in a first come first served model.

in addition to help improve throughput, the priority queues will also help with isolating longer running work and identify potential problems.  For example, a very large role change that is committed can generate a number of indirect entitlement changes for all the role members.  These are now processed using a different priority queue than normal changes flowing through the system from explicit requests end users are making.  Similarly, changes related to SQL Select, SQL Execute, and Java nodes are processed by a different priority queue.  This will help workflow developers and administrators identify if there are long running custom logic that needs closer inspection.


The following priority queues are defined now:

  • Normal (Default) - explicit changes flow through this queue
  • Urgent - Requests of that represent user terminations or password resets are handled by this queue
  • Role - Requests that are role related (usually containing indirect entitlement changes) are handled by this queue
  • Custom nodes - Logic run as part of SQL Select, SQL Execute, and Java nodes are handled by this queue


The Admin->Workflow→Monitoring screen provides a real time view of what is going on in the workflow engine.  The priority queues are shown in this interface so you can see how each queue is performing and where there may be bottlenecks that need closer inspection.

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

Workflow Priority Queues