Summary 

An identity cube is the basic and most prevalent data component withinAccess Governance Suite. The design of this element impacts usability and ultimately performance of the tool. Care needs to be taken that the identity cube relates to actual people records and isn't encumbered with unnecessary data.

To keep overall system performance in line with other similar implementations of Access Governance Suite, this document outlines strategies for dealing with service or system accounts Specific details of these steps are listed later in this document, but the key recommendations include:

1. Streamline usage of attributes

2. Allow creation of orphan accounts

3. Eliminate pseudo relationships with people identities

Conceptual Data Structure

The basis of any Access Governance Suite implementation is the identity cube. Inefficiencies incorporated into this basic data element will be reflected across the board in performance data loads, certification, role management and reporting. When considering the use cases for Access Governance Suite the best practice is to only load necessary data, and to structure that data according to the identity-data relationships that Access Governance Suite is designed around.

 An Identity cube consists of many data elements that are stored in the database. The most common component called an application link is retained as an XML object stored in a CLOB in the database. This design decision allows an extensible framework to define attributes without needing to re-design the database when attributes change.

The key attributes thatAccess Governance Suite uses are:

 Name

Firstname

Lastname

Email

Isinactive

Manager

When extending these attributes, the best practice is to only add attributes that are needed for driving certification creation or to triggers rules or workflows. When analyzing the customer choices for identity attributes it's likely that efficiencies can be gained by removing anything not actually relevant toAccess Governance Suite.

Other applications will typically provide entitlement data. This information is stored as links on the identity cube. The more links (and size of links) a cube has, the larger that cube becomes with resultant impacts on processing the cube.

Identity Cube Analysis

Starting the cube analysis, we can see that for the results of certification the minimum components needed are:

Name: - The name of the account

Application: - The application the account belongs to

Entitlements: This can be several attributes, which are approved/revoked by certifiers

 That identity cube information must be transmitted in its entirety when it's being evaluated. When evaluating an individual identity for certification, aggregation, reporting and analysis the size and linkage complexity of this data is highly relevant for performance profiling.

 Given a typical cube (most implementations) we would see sizes around:

ID attributes ~ 300 Bytes

Number of Links ~ 10

Size of links ~ 300 Bytes

Scorecard data ~ 20 Bytes

Total raw cube size 630 Bytes

 When dealing with very-large identity cubes the assumptions regarding system sizing start to not only breakdown from an infrastructure perspective but also from a software best practices viewpoint. The above example fits inline from a database table storage perspective. When we exceed limits for the storage of LOB data (typically 4-8K depending on the DB platform), we need to accommodate this through special schema design to handle large CLOB values.

 The performance implications of this cannot be underemphasized. When larger cubes are evaluated for aggregation the entire cube needs to be evaluated when manipulating the system. Since most of the data is XML represented it must be retrieved in its entirety, which ultimately taxes the database, application server and the network. 

Recommendation: Streamline usage of attributes

Streamlining would entail eliminating those attributes that aren't needed for the certification process. Ultimately only the customer can determine what data meets the criteria for removal. Every piece of data removed from the construction of the cube will have positive impacts across the entire system.

 The goal for the data is to identify the account information, the entitlements, when the account is certified and what application it belongs to. ForAccess Governance Suite purposes, anything additional is simply not needed.

Recommendation: Avoid assignment of functional accounts to identities

 This recommendation is intended to address the issue of an account having many links that realistically do not belong to that identity. Given the tendency to artificially assign the accounts to de-facto owners, the cubes can grow to enormous sizes. 

An identity cube contains account links; these links are copies of the account data from the application. The design intent forAccess Governance Suite is that account links are accounts that are used by the identity cube. The result of this design intent is that cubes typically have less than 100 account links and usually average 10 for most users. A number of customers have attempted to exceed this trend by an order of magnitude. The result is performance degradation when evaluating these links.

 An alternative to identity linkage would be to aggregate this information as orphans intoAccess Governance Suite. Access Governance Suite could then be leveraged to perform advanced certifications based on business rules. This would allow individual system owners and application owners the ability to track down the orphans and ultimately improve compliance. As users are terminated, transferred etc clear ownership patterns of the elevated accounts would likewise improve.

 Instead of forcing these accounts into the model aboveAccess Governance Suite would treat these as orphans. This does not preclude them from certification, and if needed these accounts could be sent to individual certifiers based on business logic in an assignment rule. 

Recommendation: Eliminate Pseudo Identity Assignment

 The end result is an explosion in complexity. An end-user can end up with thousands of subordinate links which can complicate certification efforts, from a visibility standpointAccess Governance Suite believes these to all be individual people but in fact are simply attributes that belong to other cubes.