Problems with Aveksa Application Roles and Entitlements managed in the RSA Identity Governance & Lifecycle Aveksa Application using the SecurityRole.csv file
RSA Product Set: RSA Identity Governance and Lifecycle RSA Product/Service Type: User Interface, Account Data Collector (ADC), Entitlement Data Collector (EDC), Business Role Manager (BRM) RSA Version/Condition: 7.0.0, 7.0.1, 7.0.2, 7.1.0
When managing the RSA Identity Governance & Lifecycle Aveksa Application Roles using the SecurityRole.csv file, the following artifacts are observed.
1. Users may be assigned Aveksa Application Roles without an Aveksa Application account. The Access tab may show app-role and Entitlements assigned to an Entitlement Path that references an Account that does not exist.
2. Additionally, when viewing the Accounts under the Aveksa Application Accounts tab the account previously associated with the user shows as deleted.
3. Users may be assigned Aveksa Application Roles and Entitlements for Roles that do not exist in the Aveksa Application.
4. If using the Privilege tab to manage Aveksa Security users Aveksa Application it is not possible to Add or Remove Aveksa Application Privileges from the user. When an attempt is made to Add or Remove a Privilege after clicking on the "Apply Changes" button the changes are not accepted.
The stated purpose of the SecurityRole.csv file is to allow customers to add additional Roles to the Aveksa Application Role model. Roles are added by adding them to the SecurityRole.csv file and importing the file under the Files tab on the Admin User Interface menu.
Roles imported in this manner are added directly to the Role model and any changes to this file causes the Aveksa Application ADC (Account Data Collector) and Aveksa Application EDC (Entitlement Data Collector) to be run. If a Role was previously added to an imported SecurityRole.csv file, and a new SecurityRole.csv file is imported that is missing that Role, then that Role will effectively be removed from the Security model. Roles are removed directly without checking to see if that Role is in use. If a Role is removed, and that Role is already assigned to users then the Role assignments for those users becomes orphaned. This may cause Users to show with Roles and Entitlements and Privileges that do not exist in the system.
In addition, when an Aveksa User is associated with an Aveksa Account, and the all Roles for that user are Removed, to ensure that the user is not able to log on as an Aveksa Administrator, the Aveksa Account for that user is Deleted. When the Aveksa Application Account is deleted, it is not possible to manage the users Aveksa Account Privileges from the User Privileges tab. Normally when adding Privileges back to a User the Aveksa Application will automatically create an Aveksa Application Account but this does not occur in this use case.
At this time there is no restriction in place to prevent customers from removing Aveksa Application Roles from the imported SecurityRole.csv file. This is a defect and is targeted for remediation in a future release of the product.
Customers should ensure that an Aveksa Application Role or Aveksa Application Privilege is removed from all Users before removing the corresponding Role from the SecurityRoles.csv file.
Deleting an existing SecurityRole.csv file by selecting the Delete icon and submitting the change, is equivalent to importing an empty SecurityRoles.csv file. This action will immediately delete all previously customer defined Aveksa Application Roles! Users should take care never to use the Delete function of the SecurityRoles.csv file.
Importing an empty SecurityRoles.csv file may cause many different issues. The issues may be different depending on if the RSA Identity Governance & Lifecycle Role and Business Role Manager packages are enabled or if Aveksa Application security is being manged using the "User Privileges" tab. Consult RSA Customer Support for guidance regarding your specific challenges.
Here are some techniques for working around the specific issues outlined in this article.
These techniques assume you have enabled the RSA Identity Governance & Lifecycle Role and Business Role Manager packages. This package will allow you to directly manage the Aveksa Application Roles and will allow you to create Role Rules to repair the data. There is limited ability to work around this issue if these packages are disabled. The techniques to recover from the issues outlines above are as follows.
Enable the Aveksa Application Accounts that are disabled. This will occur automatically when any new Roles are assigned to the user.
If an Aveksa users Privilege cannot be managed using the Privileges tab because the Aveksa Application Account has been deleted, the following Workaround may be used to create a new Account.
Enable the Aveksa Access Request Manager feature (if this is not enabled). If you temporarily assign any Aveksa Application Role to the account using the Access Request Manger, it will automatically create a new Aveksa Application Account for the user. Once the Aveksa Application Account has been created the user may be managed normally using the Privileges tab. The Role you added may be removed if not required.
Restore the missing Roles to the Aveksa Application Accounts.
Users who are missing the Application Roles may still be able to function because they may still have the Entitlements associated with those Roles. The Roles should however be repaired so that the user management features reflect the correct Role mappings. This is best accomplished by creating and running a Role Review for the Aveksa Application. Consult the documentation on how to create a Role Review.