Account Mapping feature design and usage

  • 7011003
  • 17-Feb-2012
  • 01-Nov-2012

Environment

Access Governance

Resolution


The "account mapping" feature allows Access Governance Suite to define attributes/values on application accounts (aka links) beyond actual settings coming from the applications.  Admin users manage the definitions thru UI ("System Settings"->"Account Mappings").  The cfg options cover the account mapping's name, display name (optional), value options (modifiable, type, searchable, cardinality), and list of sources.  IIQ keeps this cfg info in the "ObjectConfig" object named "Link".  The "debug" UI page offers a "Link Configuration" button to display the XML object.

Once defined, then aggregation or refresh operations call "Identitizer" methods to check and to assign values on account mappings.  The aggregation task always runs logic making the assignments (auto-enabling the hidden "promoteAttributes" option).  The refresh task checks link attrs on logical/composite applications via the "Refresh logical application links" option.  Otherwise the (5.x) identity refresh task requires enabling a "hidden" setting (forceLinkAttributePromotion) to run the logic.

Once assigned, the attributes/values appear on all qualified application accounts.  Any role, rule, or workflow sees account mappings like "ordinary" link attributes.  While all rules,workflows access them just like "ordinary" link attributes, yet certain situations show the differences.

For example, consider an env with the same name for both account mappings and application schema attributes.  An aggregation first pulls the "actual" account setting from the application and updates the account attr value.

Later on, the aggregation detects that the account attr has an Access Governance Suite-cfged account mapping.  The aggregation checks and applies the "Link" ObjectConfig definition to (re)update the same account attribute.  As a side-effect, if "Link" ObjectConfig's sourcing list omits the target application, then the aggregration drops the update and restores the original attr value.  Avoid this behavior by either specifying a global rule for the account mapping, adding all applications to the account mapping list of sources, or never use the same name on both account mapping, application schema attributes.