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

RSA Identity Governance & Lifecycle

80 posts

Im very excited and happy to share our first edition of the RSA IGL newseltter!


Our goal is to help share more informatoin about whats happening and key things for you to be aware of. 

This is a monthly release, so you can expect the next newseltter at the start of April.


It's official - time to get your creative juices flowing as the RSA Charge 2019 'Call for Speakers' (C4S) is now open and awaiting your submissions!


As you are aware, the RSA Charge events represent all RSA products and an increasing number of customers across solutions attend this one-of-a-kind event each year. The RSA 2019 Charge promises to be the biggest event in our history of RSA Charge and RSA Summit conferences. 


The RSA Charge event is successful in no small part because of the stellar customer submissions we receive each year. We invite you to submit your presentation brief(s) for consideration. (That's right, you may submit more than one submission brief!)


This year for the first time the '8' Tracks for RSA Charge 2019 are identical across all products and represent all RSA solutions. We are pleased to present them to you:


Transforming Your Cyber Risk Strategy - Cyber-attacks are at the top of the list of risks for many companies today.  Tell us how you are approaching reducing this risk utilizing RSA products.


Beyond the Checkbox: Modernizing Your Compliance Program - The regulatory landscape is always shifting.  How are you keeping up and what steps are you taking towards a sustainable, agile compliance program?


Aligning Third Party Risk for the Digital Transformation - Inherited risk from your business partners is a top of mind issue.  Third party risk must be attacked from multiple angles.  Share your strategy.


Managing Operational Risk for Impact - Enterprise risk, operational risk, all things risk management.  Share your experience and strategy on how you identify, assess and treat risk across your business operations.


View from Above: Securing the Cloud - From security visibility to managing organizational mandates, what is your risk and security strategy to answer the "go to cloud" call.


Under the RSA Hood: Managing Risk in the Dynamic Workforce - The workforce has become a dynamic variable for many organizations - from remote users to BYOD to contractors and seasonal workers.  How are you addressing this shift?


Business Resiliency for the 'Always On' Enterprise - The world expects connectivity.  When the lights are off, the business suffers.  Tell us how you are ensuring your business is 'always on' - business continuity, recovery, crisis management and the resilient infrastructure.


Performance Optimization: RSA Product Learning Lab - Share your technical insights of how you use RSA products to meet your business objectives.  Extra points for cool 'insider' tips and tricks.


We know you have great stories to share with your peers, best practices, teachings, and how-to's. We hope you consider submitting a brief and thank you in advance for your consideration. More information can be found on the RSA Charge 2019 website (scroll to bottom of page) including the RSA Charge 2019 Call for Speakers Submission Form. Submission should be sent to:


Call for Speakers 'closes' April 19. 


For larger enterprises, creating a clustered environment for RSA Identity Governance and Lifecycle helps to scale the product. The RSA Identity Governance and Lifecycle 7.1 Configuring WildFly Clustering document (RSA Identity Governance and Lifecycle 7.1: Configuring Wildfly Clustering ) describes how to configure a cluster using multicast/UDP for communication between the nodes of the cluster. 


RSA Identity Governance and Lifecycle 7.1 now allows communication between the nodes in a cluster to use TCP, rather than multicast/UDP, because TCP is highly reliable and key to a more stable cluster. The new document,


Configure WildFly Cluster to Use TCP (RSA Identity Governance and Lifecycle 7.1 Configure WildFly Cluster to Use TCP ), describes how to change current UDP/multicast clusters to use TCP-based communication.

RSA recommends that clusters use TCP rather than multicast/UDP because of some of the key differences between UDP and TCP:


1. TCP is connection-oriented, unlike UDP, which is a connectionless protocol.
2. TCP is highly reliable for transferring data because it uses the acknowledgment of sent information and automatically resends any lost packets. UDP does not request retransmission if the packet is lost.
3. While TCP is slower compared to UDP, this is because TCP establishes the connection before transmitting data, and ensures the proper delivery of packets. 
4. The header size of UDP is 8 bytes, while the header size of TCP is more than 16 bytes.  Releases higher than 7.1 deprecate the UDP/Multicast setup in favor of TCP protocol.

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