Skip navigation

Majority, if not all customers of RSA IGL use Active Directory (AD) as a way of managing who can access certain applications and what actions they can perform within the application.


Early phases of an RSA IGL project focus on visibility, and this typically includes the collection of all accounts, groups and group memberships from a primary AD domain. Although this data provides great insight in to the AD environment, it doesn’t quickly and clearly identify which AD managed applications users have access to.


This normally results in customers requesting a solution for on-boardng AD managed applications in to RSA IGL that must be:

  • Easy to implement
  • Uses out of the box functionality
  • Easy and repeatable to on-board applications
  • Does not duplicate data
  • Works with all areas of IGL
    • Visibility of access
    • Reviews
    • Access request
    • AFX


The following document, created by RSA Professional Services, provides details on the out of the box components used to separate the AD managed applications so that they are displayed as individual applications, instead of AD groups within a directory. Once separated, these applications are clearly displayed against the user, within User Access Reviews and also Access Request where changes can be automatically fulfilled re-using existing connectors.


Active Directory (AD) Managed Applications  


Although this solution covers the use of Access Request and AFX, it can be still be used without these to enhance visibility around the users access and during user access reviews.


This blog post is intended to highlight considerations and recommended practices regarding extending avuser schema to utilise custom attributes within RSA Identity Governance & Lifecycle. There are numerous legitimate reasons why additional attributes are required and this post will ensure you use these in a manner that meets your requirements without causing unexpected issues. 

DISCLAIMER: You should always make configuration changes in a non-production environment before promoting through to production. This is particularly important when extending the avuser schema as once extended it cannot be deleted and important data relating to the attribute cannot be changed.

What do you mean by AVUSER Schema?

Within the avuser schema there are the following objects: 


  • Account
  • Account Mapping
  • Business Source
  • Application Role
  • Business Unit
  • Change Request
  • Change Request Item
  • Entitlement
  • Group
  • Report
  • Form
  • Resource
  • Role
  • User
  • User Entitlement
  • Custom Values


These objects have predefined attributes that can be viewed and extended by navigating to Admin > Attributes within the UI. 



Why would I want to extend the AVUSER schema?

The following excerpt is taken from the RSA Identity Governance & Lifecycle 7.2 online help on custom attributes:


RSA Identity Governance and Lifecycle lets you create attributes for collected, created, and managed objects. Pre-defined attributes may provide only some of the attributes you need for your objects. Creating attributes lets you collect more comprehensive and important data. They also let you more accurately represent business sources for which you are managing compliance.


Essentially it allows you to better represent your organisation’s data within RSA Identity Governance & Lifecycle. That could be enriching your user objects with more data from your HR/Identity Sources; allowing more information to be collected or added relating to accounts and permissions within your applications or other use cases. Some of which will be covered at a high level within this post.


Considerations before extending the AVUSER Schema


When extending objects it is highly recommended that this is done when there is minimal activity in the RSA Identity Governance & Lifecycle application. This includes but is not limited to user and system at activity such as workflow processing, review generations, rule processing and collections. This is particularly true when extending the User object schema as this makes a change to the internal database table structure. 

This is covered in more detail here:


Before extending an object with a new attribute consider the following questions:


  • Why do I need to add this attribute?
  • What business process/use case requires this attribute?
  • Is there another attribute I could use already?
  • Is the information available through collection?


With the exception of the User schema, it is worth noting that there are a limited number of attributes object schemas can be extended by so it is important to only extend where necessary as once extended an attribute cannot then be deleted.


Additionally, every time you add a new custom attribute you are increasing the size of your application’s database. To avoid filling your database with unneeded data make sure that what you intend to collect or manage within RSA Identity Governance & Lifecycle adds value by enabling a business process to function or resolving a use case.


An example of unnecessary data may be the collection of identity related information at an Account level. Collecting a user’s name associated with an Account can assist with Orphan Account Management to identify who is associated with an Account if account mapping has failed. However, information such as Team, Department, Location, etc. should probably not be collected an Account level unless it specifically restricts or controls access within the specified application.


It is easy to consider adding a new attribute each time a new requirement is gathered. However, you should always check if there is an available attribute that could be used or modified to meet this new requirement.


For example, a common extension of the Group object would be to add the distinguishedName for collection from Active Directory. This is required for AFX to provision group membership changes and can provide useful information on the location of the group within your domain structure. However, naming this attribute distinguishedName within the avuser schema is very AD-centric. Consider calling this Technical Name so that other Applications or Directories you need to collect Groups from can make use of the same attribute without confusing matters or creating an unnecessary additional attribute.


What kind of attribute do I need?

You will have already identified why this attribute is needed and as a result you should know what type of attribute you need to create too. An attribute can be a:


  • Date
  • Integer
  • String


Obvious use cases for Date attributes are Join, Move or Leave date for Users and Last Logged On for Accounts.


Integer attributes are not frequently used but are useful for use cases involving counts such as license management for example.


You will find most attributes you create will be Strings as these allow a combination of alphanumeric and special characters.


Attributes can either be Collected or Managed and this is dependent on whether they are available from a data source or require to be managed within the UI.


For example, the distinguishedName use case earlier would be a Collected attribute as it is available in Active Directory but you may want to create a Managed attribute to classify or categorise the Group to be used in Review, Rule or Report definitions from data that is not available in the target source.


Where possible the preference should always be to collect the data from source rather than manage it within RSA Identity Governance & Lifecycle.


How do I extend the AVUSER schema?

If you wanted to extend the user object within the avuser schema with a new attribute you would navigate to Admin > Attributes > User > Edit then define the name and type of attribute you wish you create. For other objects you would navigate to the appropriate tab on the Attributes page.




We have already discussed making the Attribute Name as generic as possible so it can meet multiple use cases but it is worth highlighting that Attributes can also be shared. For example, if you created an attribute called Classification for Groups, App Roles and Entitlements it is far easier to manage and configure Reviews, Rules and Reports based on this shared attribute than it would be on separate attributes called Group Classification, App Role Classification and Entitlement Classification.


This excerpt from the online help section explains the difference between the Attribute Name and Reference Name: 

Attribute Name — Enter a name for the attribute. You would typically provide a name that denotes the type of information the attribute represents. Avoid attribute names that contain special characters other than $ and _. Attribute names with other special characters are not allowed in AFX mappings.


Reference Name - A name for custom attributes that is unique across all attributes of the same data type. For a new custom attribute, the reference name field is automatically populated with the Attribute Name with spaces replaced with underscores. For example, an attribute with the Attribute Name of Account Expires would, by default, have a Reference Name of Account_Expires.


Database ID

The Database ID is important and you should ensure you synchronize these across your environments as you will encounter problems Importing and Exporting configuration if the IDs do not match up. For all objects except User this is selected under Database ID.


For example, if you create an attribute called Type for Group objects assigned to CAS3 in your non-production environment, ensure it is also created and assigned CAS3 in all other environments.



User object schema increments the database ID per data type so it is important when adding multiple attributes that you do these in the same order through your environments to avoid the same issue.


Notice the length is specified in brackets for other object types but you can specify this for User attributes, be pragmatic when setting this as the larger it is the more space it takes up but you also do not want it to be insufficient.



It is important to note the Data Type, Database ID, Data Type, Length and Data Source cannot be changed once the attribute is created.


To avoid issues when importing and exporting configuration between environments:


  • For User attributes ensure they are created in the same order in each environment to ensure the same Database ID is assigned.
  • For all other attribute types ensure you choose the same Database ID for your attribute in each environment.

Managed or Collected

When creating an attribute you will collect from a data source select Collected under Data Source. This newly created attribute will then be available to populate in the associated collector. For example, a new User Attribute will appear as an available attribute under Identity Collectors; Account and Group Attributes under Account Collectors and App Role, Entitlement and Resource Attributes under Entitlement Collectors.


If you are creating a Managed Attribute you will notice an Editable tick box appears:




Select this option if you want this attribute to be updated within the UI.


For example, if you extended the App Role object to include a Managed, Editable String attribute called Access Classification you would be able to update this by editing the App Role in the UI:




Where you want to control the values that can be selected for a Managed attribute you can set up a Custom Values attribute with predefined values that can be selected from a drop-down. Otherwise this will be a free text box for end users – leaving input prone to human error which would cause issues if the attribute is to be used in Rule or Review Definitions.


Custom Values

The Custom Values attributes behave differently to other attributes in that they can be deleted. They are meant for for populating Attributes that are both Manageable and Editable.


To create a new list navigate to Admin > Attributes > Custom Values > New Value List…




As with extending the schema of other objects carefully consider the values you want contained in your list. Once created they can be changed but if you have already been populating object’s attributes with values from the list they do not dynamically change.


Another interesting use case for Custom Value Lists is utilising the Object type for the list. Rather than a string or an integer you can restrict the value to be populated into the Managed Attribute to be selected from an object picker:




Display Options

How, when and where the attribute will be visible in the UI is controlled by the following settings:




  • Public — Select this option if you want this attribute to appear in detail views and information popups for users who do not have explicit permissions for the object. By default, all user attributes and custom attributes on other objects are set to private, which means the attribute will not be displayed for users who do not have explicit permissions. For more information, see Specify How Attributes Are Displayed in the User Interface.
  • In Detail — Select this option if you want this attribute to appear in the details view for the object.
  • In Popup — Select this option if you want this attribute to appear in information pop-ups in the user interface.
  • In Tables — Select this option if you want this attribute to be included in a table and available as a column in a table (from Table Options).
  • Detail URL — Provide a URL that you want displayed in a popup dialog when the information icon for the value of the attribute is clicked to show further details.
  • Hide if Empty — Select this option if you do not want this attribute to appear in details views or information pop-ups in the user interface if it does not hold a value; otherwise, deselect.


In addition to this, the order in which attributes are shown under each object can be set by moving the attributes into the order you want and Separators can be added to group things logically. This can be particularly useful for User objects where you want to split attributes by HR Data, Contact Information and Technical Detail for example:




These are easily created by selecting the Add Separator button on the same screen where you can edit/create Attributes. Unlike Attributes, Separators can be deleted at any time.


That's it...

I hope this blog post has highlighted how useful the creation of custom attributes can be as well as the importance of doing so for the right reasons in a controlled manner.


Please comment with any feedback, ideas or use cases of your own and thank you for reading.

RSA IGL Version: V7.1x & V7.2x

Modules: Governance

Product Area: Reviews

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~30 minutes



This recipe combines web services and workflows to automate and control the review change request generation tasks. The recipe combines the benefits of both out of the box Automatic and Explicit review change request generation options with minimal configuration.




The RSA IGL Reviews module provides 2 methods for generating change requests, as explained below:


1. Automatically

Since change requests are automatically created as soon as reviewers saves their decisions, you get the following:


  • No additional administration overhead for the review owner or administrators to periodically generate change requests.


  • There is no control over the timing of the generated change requests.
  • There is no control over the grouping of change items.
  • Reviewers have no margin for error since a change request is generated the moment they save their changes.


2. Explicitly by Owner

Since change requests are not generated until the review owner or administrator manually triggers the change request generation, you get the following:


  • More control over the change request generation grouping (By Reviewer, By Component ... etc).
  • More control over the time when change requests are generated (Daily, Weekly ... etc).
  • Reviewers have the ability to review and change their decisions until the next change request generation task is run.


  • Additional overhead of the review owner or administrators to manually start the change request generation process.
  • Potential of missing a few changes if the review owner or administrator does not manually generate the change requests. 




One of the most common requests we've seen is a solution that combines the benefits of both Automatic and Explicit change request generation. The requirements are mostly:

  1. Having the ability to control the timing and grouping of generated change requests without requiring manual intervention from the review owner or administrators.
  2. Giving reviewers a grace period - for example: until the end of the business day or end of the week - to change any decisions they took before any change requests are generated without requiring the review owner or administrators to perform manual actions outside business hours.


Suggested Solution 


We can leverage the createRequestsByOwner web service command which is used to generate change requests for a review. This is equivalent to the 'Create Change Requests' button found on the Change Preview tab of reviews that are configured to generate requests explicitly by owner.


Web Service Usage

Note: The below is only the relevant subset of the full web service description. For full usage details, you can go to Admin > Web Services > Requests > Click 'Click for details' beside the createRequestsByOwner web service.


Input Parameters

The command expects the following parameters where a * denotes a required parameter:

  • id* - The id of the review result to create change requests for.
  • group - Specifies how changes should be grouped together.
    • Reviewer, PerComponent, PerAsset valid for user reviews.
    • Reviewer, PerComponentResource, PerComponent, PerAsset valid for account reviews.
    • PerComponent valid for group and role reviews.
  • format: The format to return the data in (default = properties)


Output Parameters

The command returns the following properties as output:

  • name - name of the review.
  • status - success or failure.
  • message- Optional message to return along with the status.

A precondition failed (412) return code is returned if the review is not configured to generate requests explicitly by owner.



An example url used to invoke this command is shown below:



Calling the Web Service


There are two suggestions on how to call and schedule this web service:


Option 1 - Review Escalation Workflows

Using a Review Escalation workflow which calls createRequestsByOwner for the specific in scope.

  • Simple to implement and has better visibility on runs per review.
  • Also easier to have different options/frequency per review.


  • Review Escalation workflows cannot be triggered in a recurring way (every day). So an escalation must be added per exection. Depending on the duration of the review, this could require a large number of escalation workflows.


Option 2 - Custom Task Workflows

Schedule a generic Custom Task workflow that calls the createRequestsByOwner for all open reviews.

  • A single workflow should work for all active reviews.
  • Better scheduling frequency options.


  • Less visibility on runs per review.
  • Extra complexity to control options/frequency per review type.




Web Service Security Settings

Make sure you thoroughly test any changes in lower environments first before promoting them to Production.

Make sure you are on 7.1.1 P07 / 7.2.0 P01 or above to be able to call the web service from workflows without a token (Reference ACM-103573).


You need to make sure of two things:

  1. Enable Web Services and whitelist the IGL server(s)' internal IP addresses.

  2. Enable the "Request Forms and Workflows (no token)" checkbox for the createRequestsByOwner web service.


Workflow Configuration


Option 1 - Review Escalation Workflow


  1. Create a new "per Review" Review Escalation Workflow

  2. Configure a simple REST node that calls the createRequestsByOwner web service.

    URL: https://<Internal-Hostname>:<Internal-HTTPS-Port>/aveksa/command.submit
    Method: GET
    Request Params:
    cmd: createRequestsByOwner

    format: properties
    group: <Grouping option of choice>
    id: ${jobUserData_acm.ReviewId}

    Content-Type: text/plain

    Proceed on failure: Checked
    Response Type: Properties
    Response Variables:
    status: Job, status

  3. Add the escalation workflow to the Escalations tab of the review definition as much as required.
    Example running this workflow on a weekly basis for 4 weeks (28 days):


Useful Tip for Scheduling Review Escalation Workflows


Since Review Escalation Workflows do not have the ability to specify the exact time (hours and minutes) the workflow will run on a specific day, you can use a Delay node with SQL Delay that returns the today's date at a specific time.


For example, if you want the change request generation to be triggered at 9:00 pm. Then it can be calculated as follows: 

  • trunc(sysdate) returns today's date at exactly 12:00 AM (00:00)
  • + (day fraction) to add the exact time offset required. For example, 9:00 PM is 21:00 which means 21 / 24.
    trunc(sysdate) + 21 / 24 AS wait_date


Option 2 - Custom Task Workflow


  1. Create a Custom Task workflow.

  2. Add a SQL Select node that gets any non-completed Review ID that is configured to generate change requests explicitly by owner. Use the following SQL statement as an example:
    SELECT    AS review_ids,
        0        AS tmp_id
             t_av_entreviewdefversions rdv
        JOIN pv_review rv ON rv.review_definition_id =
                             AND rdv.generate_change_request = 'M'
                             AND rv.state IN (


  3. Configure a Next Valye node to loop through the Review IDs

  4. Add a REST node with the same configuration as in Option 1 Step 2. The only difference is that the Review ID is now in the created Workflow Variable ${jobUserData_TMP_ID}

  5. Make sure the two transitions coming out of the Next Value node are set to Completion Code.
    • True: Continue looping.

    • False: Finish process.

  6. Schedule the Custom Task workflow as required.