Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog > Author: Sean Miller

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.

Sean Miller

New Feature: Web Services

Posted by Sean Miller Employee Mar 19, 2019

In the recent RSA Identity Governance and Lifecycle 7.1.1 Service Pack Release we have added some new web services.  In previous releases you could use the findApprovals, getApprovalDetails, and performApproval web services to interact with approvals.  In this release the following web services have been introduced to interact with any type of work item including approvals:


  • getWorkItemsForUser
  • getWorkItemDetails
  • performWorkItem


The getWorkItemsForUser web service returns high level details for the work items including the work item IDs.  The getWorkItemDetails takes a work item ID and returns more details including what actions can be taken.  The actions that are returned are based on the transitions modeled in the workflow.  The performWorkItem web service is used to complete the work item using the provided action and comment.

The approval-specific web services will be deprecated in a future release.  Any implementations based on this should be updated to use the more generic work item web services.



Lastly, the new web service findReviews has be introduced in this release.  This allows you to search for reviews by name or other search criteria.  The web service returns details about the reviews based on the requested columns.  In particular, the review ID is returned which is needed for other calls like getReviewStatus, refreshReview, setReviewState, and updateUnreviewedItems.

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

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 

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 

With a focus on helping organizations achieve business agility – we are proud to announce an improvement to request forms and workflows in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release 


Prior to this release, all request forms were processed using the request workflow that is configured on the Requests->Workflows->Overview screen for the explicit request source.  This has led to many customer workflows where business decision logic is needed to route the request differently based on the source.  This can help separate the business logic for a request form into it's own specific workflow.  Although many request forms should continue to go through the normal request workflow, this feature can help isolate your business logic for a specific form from all other workflows.


To configure this feature, edit a request workflow and select the appropriate request workflow using the picker shown beside the Request Workflow label:


Any requests that are generated using this request form are then processed using the configured request workflow.

With a focus on helping organizations achieve business agility – we are proud to announce the release improvements to account templates in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release With this new release, an account template can leverage the power of naming policies directly.  In earlier releases, you could only use naming policies through a request form.  This meant that any request created from a source other than a request form would need special logic to create accounts.


With 7.0.2, whenever an account needs to be created the naming policy can be used to generate a unique name.  This is done by associating a naming policy right on the account template object:


Once associated, you can refer to the value of the naming policy like any other variable.  In this example, the calculated value is mapped directly to the name of the account with no additions:


Consider using this feature and remove the custom business logic from the workflow to calculate the name of the account to create.

Ever wondered what the workflow engine is doing?  While you can see at a high level the phase your request is in, there are times where it is useful to ensure the workflow engine is running and how busy it is.


We are proud to announce the release of the workflow monitoring feature in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release .  


This feature is located on the Monitoring screen found under the Admin->Workflow menu.  This screen has a few purposes:

  • List the name and state of all the configured queues associated with the workflow engine
  • Show how hard the workflow engine is work (Number of Items Serviced)
  • Show how much work there is to do still (Queue Size)


While I can's tell exactly where my change request might be in a long line of work to do, this screen will help us understand that things are still moving and how much volume there is.  This screen will update the metrics every minute shows a real time glimpse into the workflow engine with scrolling graphs. 


NOTE: This information is not written to any database tables for historical review.  The screen is purely meant for real time inspections of the system.

Have you ever gone to add a user to a role and been overwelmed by all the indirect entitlements the user receives because of the role?  Many approvers are as well.


With a focus on helping organizations achieve business agility – we are proud to announce the release of the simplified approval improvement in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release .  


Most approvers are not spending all day in the RSA Identity Governance and Lifecycle product and they are being involved in the process for business reasons.  In this scenario, 99% of the time we probably are asking an approver the question: Should this user be a <role name>?  For example, if someone joins my team, I am likely being asked if they should be a developer and my job is to approve or reject that.  What it means to be a developer is an entirely different problem likely maintained by a very different process.  For this reason, we have added a new setting to approval workflows and changed the default for the out of the box approval workflows and any new approval workflows that are created to not include indirect entitlements by default.  Existing customer approval workflows are not touched. 


You may want to reevaluate your approval process though and decide if you really want your approvers worrying about indirects either.  Do you want them focused on the simple question: Should this user be a developer or do you want them really approving the one hundred other entitlements the user will receive because they are a developer?

In earlier releases all attributes were visible to users.  This made sense in some use cases but this quickly became a general security concern where only privileged users should be able to see the majority of the attributes.  In the first iteration of this feature, RSA chose the attributes that were shown for user objects.  While this solved the security concern, there were several customer use cases that were not met by this functionality. 


With a focus on helping organizations achieve business agility by limiting who can see what attributes – we are proud to announce the release of the public versus private attributes feature in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release System administrators can use the public versus private attribute feature to configure what attributes are public.  Only public attributes are visible to non-privileged user.


For example, if I am a reviewer for an application, I may be able to see who has access to my application.  While it is important to have some details about the user to decide if the access should be maintained or revoked, it does not make sense for me to see all attributes about the user.  The user object may include some more sensitive attributes that administrators have decided to keep private.  By default, a very minimal set of user attributes are marked as public.

With a focus on helping organizations achieve business agility – we are proud to announce the release of web service features in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release With this new release, we have added some additional web services and also enhanced some existing web services.  Documentation on all the web services available can be found on the Admin->Web Services page of the RSA Identity Governance and Lifecycle console.


Single Sign On

The loginUser web service has been enhanced to accept an authentication source.  This can be used in conjuction with credentials or you can specify the authentication source by itself and the authentication source then relies on artifacts already present in the request for authentication.  For example, you might specify a configured SSO user header authentication source.  The web service would use the authentication source to validate the right artifacts are there before returning a token.  The token can then be used for subsequent web service calls.


Process Rule

A new web service to run a specific rule or all rules is now available.  The call requires appropriate security privileges as documented on the web service page.


Update Review Items

updateReviewItems is a new web service that can be used to update review items outside of RSA Identity Governance and Lifecycle's review user interface.  This may be used for use cases where a reviewer is reacting to an email received for example or some form of offline/out of band review where decisions are sent back to RSA Identity Governance and Lifecycle using the web service.


Create Change Request

The createChangeRequest web service has been enhanced to support additional operations:

* Terminate user

* Mapping users to accounts

* Unmap users from accounts

All of these operations are described and examples provided on the Admin->Web Services page.  A successful call will result in a change request that can then be approved and fulfilled through RSA Identity Governance and Lifecycle.

The mapping and unmapping from accounts operations are demonstrated here.

Sean Miller

New Feature: Reporting

Posted by Sean Miller Employee Sep 27, 2016

We have had reporting in the product for sometime now but we have improved the reporting engine in the recent RSA Identity Governance and Lifecycle 7.0.1 Service Pack release.  This includes bug fixes to the reporting engine but also removes our dependency on Adobe flash.  For many corporate environments, Adobe Flash is not allowed.


In addition to an upgraded reporting engine, we have improved how absolute and proportional layout work.  This is very useful for building dashboards for environments where end users are working with a variety of different monitor and screen resolutions.  With proportional layout, you select the number of components and the layout of each.  We will use the maximum space to properly render the components to fill the selected layout.


Sean Miller

New Feature: Auditing

Posted by Sean Miller Employee Sep 27, 2016

Prior to RSA Identity Governance and Lifecycle 7.0.1 Service Pack, some basic events were audited.  A number of new types of events are now audited including:

  • server startup
  • server shutdown
  • changes to configurations
  • changes to metadata objects
  • running/processing tasks


There is also a user interface now to configure what types of events should be audited found under Admin->System->Audit


Lastly, an out of the box report 'Audit Events for the Past 30 Days' is included to view the events for the last 30 days.  This can be modified to group/filter the types of events.

In the recent RSA Identity Governance and Lifecycle 7.0.1 Service Pack release we have added a feature to put the server in maintenance mode.  This allows you to keep the server running while preventing any logins. When in this mode, no users are allowed to login to the system other than administrators.  Other users are show a configurable login screen like the following:



In the meantime, administrators can login and do diagnosis or maintenance tasks.


Note: Active users are not kicked out of the system when you place the server into maintenance mode.

This document is aimed at users building request forms using the form controls and building block tools that are provided in the application. This content is meant to be used as a reference and complements the material included in the online help and product documentation.


Also included are the following examples (as exported XML configuration files) which demonstrate the use of the Javascript control to take specific actions:

  • Invoking custom code based on a change
  • Setting the default value for a Dropdown
  • Manipulating Dates


We hope that you will find these examples useful and can adapt/extend them for your specific needs in building Request Forms. More importantly, we encourage you to share some of your commonly-used such implementations as examples by responding to this post and attaching your exported configuration file. With your active participation we hope to develop/grow this example set for the benefit of all members in this RSA Via Lifecycle and Governance user community.