RSA Identity Governance and Lifecycle 7.2.1.x Release Notes
These release notes describe improvements and functional changes to RSA Identity Governance and Lifecycle 7.2.1 and all released patches, as well as links to fixed issues for each release or patch. This page is updated with each patch.
To receive notifications about changes to this page, sign in to RSA Link, click Actions, and select Follow.
To view this page as a PDF, sign in to RSA Link, click Actions, and select View as PDF.
7.2.1 P02 is available as a patch and full installer. Customers who installed 7.2.1 or 7.2.1 P01 can apply the 7.2.1 P02 patch. All other customers can install the 7.2.1 P02 full kit.
A new feature flag (FeatureFlag.PreventativeCheck) is introduced to allow customers to enable or disable the violation calculation.
By default, FeatureFlag.PreventativeCheck is set to true, and violations are calculated only when a member/entitlement is added/removed from a role or when the role itself is deleted).
When FeatureFlag.PreventativeCheck is set to false, violations are skipped for any change in Role.
A new parameter, ‘UpdateCommentsOnly”, has been added to the Webservice command ‘updateReviewItem’. When ‘UpdateCommentsOnly” is set to true, comments will be added without affecting the review state.
Role modification references in the T_AV_CHANGE_REQUEST_DETAILS now has references to the role RAW_NAME, and shows ALT_NAME in the UI.
A new filter has been added to RoleSet policies to use "Business Source Raw name". This provides an option when Business Source Names (Display Name) have identical names that span Applications.
That may cause technical roles as entitlements to be visible even when a roleset policy is set to Deny.
In the Generic REST collector, the following warning message is displayed in the authorization page and parent page if refresh token is null: "Refresh Token unavailable in the response : This configuration may fail later as access token once expired will not be refreshed without a refresh token."
Updated labels and messages for Swedish language. Vendor systems are also updated for Swedish translations
"TargetObjectID" and "CurrentUserID" can now be used in the query in dashboard facts.
CurrentUserID — The value of this parameter is automatically replaced by the ID of the currently logged in user.
TargetObjectID — The target ID of the selected object. This parameter can only be used in object dashboards and is replaced by the selected object on that dashboard.
Using CurrentUserID in a Query(to get accounts count for the logged in user): select count(*) from T_AV_USER_ACCOUNT_MAPPINGS where user_id = :CurrentUserID
Using TargetObjectID in a Query(to get change request items count for the selected user): select count(*) from t_av_change_request_details where affected_user_id = :TargetObjectID
The following table describes changes that affect the user interface or behavior ofRSA Identity Governance and Lifecycle7.2.1 as the result of fixed issues.
· Long business descriptions were not being cut off in review. Long descriptions for business source and entitlement will now display in a pop-up window when the user clicks on the 'Show Description' icon.
· IG&L had allowed end-users to create simultaneous role modifications on the same role that was in an applied state. The Role “Actions” menu allowed a role to be unlocked and allowed new change requests that included changes that were already included in other pending change requests. Roles>Actions or Role>Analysis were thereby able to create new change requests for a role already in an applied state. Roles in an applied state are no-longer allowed for actions that generate a change request. For example, on the Roles page, checkboxes are disabled for roles in the applied state, such as Roles>Actions>Add Entitlements, Roles>Actions>Remove Entitlements and Roles>Analysis>Suggest Options.
The option to export member and entitlement attributes while exporting roles was previously available, however these attributes were for informational use and not intended for import. Export of this information is now disabled by default. During export, a message displays to inform you that you can optionally continue the export process, but member and entitlement data cannot be imported.
Terminated/deleted users that are part of a pending role membership are displayed with a line through them when listed as role members in the display.
These users will not be part of the change request created for committing role changes and they are not added to the role after the change request is completed. Committed roles will contain only active users as members.
Submission variables starting with avform are ignored in the Request Details page. 'avform' is an internal key word used for variables/form names. The fix no longer allows the creation of variable/form names that start with avform. Any existing variable starting with 'avform' must be renamed if the user wants to use the variables to display information in the change request details.
You can no longer modify the raw name for a business source.
The order of the tabs under Rules>>Violations has been changed to the following:
The Data Access Governance module now supports data access data collection from Varonis DatAdvantage using a new out-of-the-box collector template. The collector configuration wizard allows you to configure a connection to the Varonis API easily through the user interface.
The Varonis data access collector collects permissions for both domain accounts and domain groups. Folder owners are collected as suggested owners, and added as resource owners.
Data Access Governance: StealthAudit Collector
RSA Identity Governance and Lifecycle 7.2.1 provides a new, out-of-the-box StealthAudit data access collector, which replaces the previous StealthAudit collector. The new StealthAudit collector encompasses the following changes:
Unlike the old StealthAudit collector, the new collector does not require the use of compatibility views delivered as an instance job within the StealthAudit product. The new version does support the use of compatibility views, but RSA recommends recreating views using the out-of-the-box views.
The new StealthAudit collector collects only the folders and shares to only those on which accounts or groups have direct permissions. The previous version of the collector collected all folders and shares that had been gathered by StealthAudit, and, as a result of the change, the first run with the new collector template may collect significantly fewer resources and entitlements than with the old.
The new StealthAudit collector calculates suggested owners based on users' activity for specific folders and shares. Previously, the calculation of suggested owners required a licensed product from Stealthbits that used a proprietary function to calculate suggested owners.
The deprecated StealthAudit collector template is no longer available when creating a new data access collector. However, existing implementations of the deprecated collector type continue to work and can be edited until migrated to the new template.
You can migrate an existing, active StealthAudit collector to the new template using the Migrate button next to the Data Source Type field on the collector's General page to open the collector configuration wizard. The wizard automatically changes the Data Source Type from Data Entitlement Aggregator to StealthAudit. To complete migration, follow the prompts to review the collector details, changing any configuration details if needed. For further details, see "Migrate to the New StealthAudit Collector" in the Online Help.
Email: OAuth 2.0 Support
RSA Identity Governance and Lifecycle now supports OAuth 2.0 authentication for both inbound and outbound email connections. OAuth allows RSA Identity Governance and Lifecycle to receive and send mail using a third-party account, such as Gmail or Office 365, without knowing or providing the credentials for that account.
You configure OAuth 2.0 support by registering the RSA Identity Governance and Lifecycle client with your email provider, and then configuring authentication using the System Email Settings page. For more information, see "Managing System Email Settings" in the Online Help.
Email: STARTTLS Support
You can now configure the outbound email server to use the STARTTLS email protocol command to request to secure an insecure connection between the email server and client. STARTTLS must be supported by your email provider to use this feature.
When STARTTLS is enabled, it is invoked after the email server and client have connected but before any credentials are exchanged. You enable this command on the System Email Settings Page. For more information, see "Managing System Email Settings" in the Online Help.
The way RSA Identity Governance and Lifecycle handles tasks when the system is in maintenance mode has been updated. The following table describes the way in which RSA Identity Governance and Lifecycle handles each type of task during maintenance mode.
Maintenance Mode Behavior
Aborted when triggered during maintenance mode. The Data Runs page displays the aborted tasks.
Scheduled rules-triggering reviews
Scheduled report generation, including ASR generation
Skipped when triggered during maintenance mode. The system indicates this in aveksaServer.log.
Not permitted. HTTP error 403 and the configured maintenance mode message appear in the response.
Manually triggered collections and other manual tasks
Scheduled Admin > System tasks such as backups
Oracle 19c Qualification
Oracle 19c has been qualified for use in RSA Identity Governance and Lifecycle deployments with customer-supplied databases.
Additional Features and Improvements
The new user and violation review user interface now allows users to display up to 20 columns.
The configuration of Account Data Collectors (ADC) now provide an option to allow the reuse of accounts that have been disabled and then deleted. Previously, if an account was disabled before deletion, the account could not be moved back into a pending state if system-wide setting "Enable Disabled Accounts for Entitlement Requests" is enabled. Now, when the new Allow Account Reuse option is selected for an ADC, when disabled accounts are deleted, the disabled flag is removed from the account, which allows the accounts to be reused.
Data Collection Processing and Management
When a data collection run fails due to the circuit breaker, the circuit breaker is ignored when a user re-processes the data collection run.
The method of selecting recipients for report emails has been improved. Previously, email recipients had to be directly selected. With this improvement, you can filter users based on user IDs, attributes, and relationships to roles and groups.
The way in which role metrics are calculated has been updated to improve performance for users.
The method of selecting roles for role membership change, role membership rule difference, role metric change, and role missing entitlements rules has been improved to allow the selection of roles using an advanced search filter.
The method of selecting groups for group membership change rules has been improved to allow the selection of groups using an advanced search filter.
The ordering of the tabs under Rules > Violations has changed so that By Violation appears before Violation Remediation.
The first time a system administrator logs on to the RSA Identity Governance and Lifecycle user interface, to agree to the license, he or she must enter the Customer ID, Customer Name, and System Type. The Customer ID value is provided by RSA and is provided to all customers through email. These values are logged in the diagnostics and system data.
A new runReport web service has been added, which allows reports to be run by name.
The following table describes changes that affect the user interface or behavior of RSA Identity Governance and Lifecycle 7.2.1 as the result of fixed issues.
When trying to create a change request for which a pending change request already existed, a warning message is now displayed and the Finish button is disabled. Previously, the system allowed the creation of a change request even when a pending submission existed.
Previously, pending accounts associated with a Create Account change item were deleted for a change request when any duplicate account was found. Pending accounts are now deleted only for rejected change items for which the duplicate account is found, and the account will be renamed successfully based on the account template configuration for Create Account change item.
ACM Security Model
The security context CSV file has been updated to remove deprecated entries. Now, the Role, Role Set, Rule, Rule Set, Data Resource Set, and Directory objects are no longer associated with Business Units.
Remote AFX and agents do not work after upgrading Java 1.8 JDK to u241 or higher. This patch updates the generation of the self-signed certificates for RSA Identity Governance and Lifecycle.
If you have applied this patch and upgraded to Java version JDK 8u241 or higher, you must download or regenerate the self-signed certificates for RSA Identity Governance and Lifecycle into your environment and restart the server.
Log in to RSA Identity Governance and Lifecycle, and go to Admin > System > Security. In a clustered environment, perform this step on the single system operations node (SON).
Click Change Certificate Store, and click OK to change the root certificate and CA.
Click Download and save the server.keystore file to a location on your computer.
Go to AFX > Servers, click Change Certificate Store, and click OK to change the client certificate.
Click Download and save the client.keystore file to a location on your computer.
Stop the ACM and AFX servers.
Copy the new server.keystore file to the location on the server where your web server reads the keystore. For example, $AVEKSA_HOME/keystore.
Copy the new client.keystore file to the AFX server under <AFX-server-root>/esb/conf.
Update the client.keystore files from the remote agents after you download the corresponding client.keystore from RSA Identity Governance and Lifecycle.
Restart the ACM and AFX servers and verify connectivity with the endpoints.
Change Requests and Workflows
The RSA Identity Governance and Lifecycle user interface now allows the cancellation of change request items in a pending verification state when the change request and workflows are completed.
Change Requests and Workflows
The Cancel button is no longer enabled when a change request is in the Undoing state.
Change Requests and Workflows
On an approval workflow node, users can now configure the approval due date to start either on the job start time or the node start time.
Change Requests and Workflows
Added a tooltip to clarify that the "Max items per change request" setting does not affect change requests adding or removing entitlements from roles. Changes generated from roles are always in a single request to ensure that dependencies are clear to approvers.
Change Requests and Workflows
Admin > Workflow > Settings has a new scheduled task to ensure that the workflow completes when a request has all watches closed.
The RESTful webservices connector now retrieves and stores id_token, if available, in addition to the access_token when using the OAuth2 flow for authorization. This can be used while making the API requests.
Data Collection Processing and Management
Previously, unification occurred even when mandatory collections failed. Scheduled unification and IDC post-processing now only occurs after successful collections.
Added additional workflow object auditing to include editing as well as create and delete. Also added auditing for edit, create, and delete workflow forms.
Change requests can now remove entitlements from deleted users, and users are prompted to enter a comment in the change request item.
RSA Identity Governance and Lifecycle no longer allows users to submit a new change request when a pending account in a pending submission already exists.
When removing a role through a role review that has both members and entitlements, the system now calculates the indirects for the revocation.
The schema no longer allows null values for the CanRequest field when editing groups.
The user interface now uses the terms trusted list and untrusted list instead of whitelist and blacklist.