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.
Within the avuser schema there are the following objects:
These objects have predefined attributes that can be viewed and extended by navigating to Admin > Attributes within the UI.
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.
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: https://community.rsa.com/docs/DOC-111131
Before extending an object with a new attribute consider the following questions:
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:
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.
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.
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:
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.
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:
How, when and where the attribute will be visible in the UI is controlled by the following settings:
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.
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.