Change role owner from Manage privilege to View only access in RSA Identity Governance & Lifecycle

[#1]

Article Number

000036747

Applies To

RSA Product Set: Identity Governance & Lifecycle
RSA Version/Condition: 7.x

Issue

• Due to an organizational Segregation of Duty (SoD) requirement, the Role Owner cannot be allowed to update roles.
• Need to override what is defined in the SecurityContext.csv Aveksa privilege file.
• Uploading the following through the UI (Admin > User Interface > Files > Security Files), does not work as expected.
• Trying to override any existing Aveksa application privileges results in duplicate entries in the underlying database table giving inconsistent privileges when the user logs in.

The following is a bad example of a SecurityContext.csv to upload, since the SECURE_OBJECT_TYPE,NAME of Role, Owner already exists in the main SecurityContext.csv provided with the application:

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER
Role,Owner,View,scope,,,t_av_roles,owner_id=${id}

Modifying the main SecurityContext.csv in the aveksa.ear is not recommended due to supportability issues and modifications provided with patches and upgrades.

Defect ACM-72713 has been created to change this feature to generate an error if an existing builtin entitlement is uploaded through the user interface.

Resolution

It is recommended to not override existing Aveksa application privileges but instead create new ones. 
 

Never upload a full SecurityContext.csv or one changing any existing entitlement(s) through the UI.

The preferred method is to create a new Aveksa entitlement based on a custom role user attribute.  In the example of a Role Owner that you want to have read only access, you could create a new entitlement based on a custom role user attribute.  In the following example, we are creating a new role Aveksa entitlement called Monitor using the unique SECURE_OBJECT_TYPE,NAME of Role, Monitor:

1. Create a new unique role custom user attribute using a name other than owner to avoid confusion.  In this example we will use Monitor and add it from the UI b navigating to Admin > Attributes > Role > Edit. Note the name of the custom user attribute selected. In this example it is CAU1.
2. Modify the roles through a collector or manually in the UI to remove the original owner assignment and to propagate the new Role Monitor attribute.
3. Create a new SecurityContext.csv file with only the header and following entry (and any other new attributes needed for other purposes):

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER
Role,Monitor,View,scope,,,t_av_roles,CAU1=${id}

4. Upload this new SecurityContext.csv file through the UI (Admin > User Interface > Files > Security Files).
5. Next time the user designated in the Role Monitor attribute logs in, they will have access to view their Roles but will not be able to edit the members or entitlements.
6. Modify workflows if you need the new Role Monitor to do any change request approvals.