000035482 - Pending accounts which resolve to no known user attribute are expected to be orphaned once collections occur but instead are left in a partially completed state in RSA Identity Governance and Lifecycle

Document created by RSA Customer Support Employee on Sep 19, 2017
Version 1Show Document
  • View in full screen mode

Article Content

Article Number000035482
Applies ToRSA Product Set: Identity Governance and Lifecycle
RSA Version/Condition: 7.0.2 GA HF02, 7.0.2 P02
 
IssueIn RSA Identity Governance and Lifecycle 7.0.2 GA HF02, when requesting an app-role entitlement to an application for which a user does not have an account, the account is created via an account template and then via a form in the manual fulfillment step of a workflow. This works fine as long as the account name resolves to the collected user attribute defined under the Account Data Collector's IADC) User Resolution Rules. However, when performing the manual fulfillment, if the account name is changed by the person fulfilling the request to an attribute that does not resolve, the expected behavior is for the account to be orphaned. Instead, the account is left in a partial state which requires the account to be unmapped and remapped. Further, there is no way to easily identify accounts in this state.
For example, you have an application called 'Animal-Care' with several associated entitlements. If an AD user requests an entitlement in this application, you require an account to also be created in this application using an account template. Let's say you want the account name to be a name not yet known or collected into the Access Certification Manager (ACM). The end-point application also does not know of any attributes collected into ACM. Therefore, there is no known attribute which can be used to resolve this new account upon collection. As such, the desired behavior is, once the ADC and EDC (Entitlement Data Collector) for this application have run, for the entitlements to be associated with this account and for the account to be orphaned so that it may later be identified and mapped to the appropriate user. Instead the following occurs after collection:
In this case the account name is changed to 'Professor' which is not a known collected user attribute so it is not able to resolve to the defined user resolution attribute in the collector definition.
  1. The account shows under the user's access, but not as an orphan.
  2. The app-roles associated with the account do not show under the user's access tab, which is not expected unless the account is orphaned.
User-added image

  1. The account shows the associated app-roles under the application's Accounts tab, as expected.
  2. The account does not show as orphaned under the application's 'Accounts' tab, which is not expected.
User-added image

User-added image

  1. The user does not show under the application's Who Has Access tab, which is not expected unless the account is orphaned.
  2. The request is completed 
AFTER collections are run, the expected behavior for an account unable to resolve to a user is:
  1. The account shows under the user's access tab as an orphan.
  2. The app-roles associated with the account do not show under the user's access tab.
User-added image

  1. The account shows the associated app-roles under the application's Accounts tab.
  2. The account shows as orphaned under the application's Accounts tab.
User-added image

User-added image

 
  1. The user does not show under the application's 'Who Has Access tab' which is correct since the account is orphaned.
  2. The request is completed. 
 
CauseThis is a defect.
ResolutionUpgrade to 7.0.2 P02.
WorkaroundResolve to a known user collected attribute in the Account Collector definition. This assumes that this user attribute is known to the data source and can be collected from the data source. In the case where there is no known user attribute to resolve to, you will need to apply the patch in order to get the collected account to become properly orphaned.

Attachments

    Outcomes