Approximately eight years ago, I began asking SailPoint why IdentityIQ didn’t track attribute change history. Meanwhile, I created Instrumental Identity’s History Plugin to fill the gap, starting with IIQ 7.2. SailPoint finally introduced their Access History feature in IIQ’s 8.4 release.
The History Plugin (HP) and Access History (AH) have a lot in common. They both record changes to Identity and Account attributes. They both offer a user interface to display history for a selected identity. They both track changes in the form of snapshots and deltas.
The differences lie in the details. This blog post aims to analyze the similarities and differences between the two tools, arguing that:
- The History Plugin, particularly in combination with our other plugins, remains the state-of-the-art for IIQ Identity History.
- The two tools don’t compete, but rather complement one another. There’s no reason an organization can’t simply use both.
Fundamental interest
The two tools have a fundamentally different (but complementary) focus.
Access History is, as the name suggests, fundamentally interested in changes to access. It does keep track of attribute-level updates to Identities and Accounts, but these are largely incidental to its detection of Role, Entitlement, and Capability changes.
The History Plugin’s scanner focuses on attribute changes. This captures role, entitlement, and capability changes (as those are simply attributes), but those are not the primary focus.
The History Plugin’s viewer user interface merges history data into a single view. It pulls data not only from its own Identity and Account “delta” records, but also from IIQ’s Access Request, Certification, Provisioning Transaction, Lifecycle Event, and Audit Event histories. These disparate data sources, which already exist in IIQ, are merged into a single searchable timeline.
Customers can also “bring their own” audit event data, showing audit events generated by your own workflows or plugins.
In the near future, data from Access History will also contribute to the History Plugin’s timeline. (In particular, its role assignment events are captured nowhere else in the system.)
Maintenance and updates
The Access History product is baked in to IdentityIQ 8.4+. It is not available prior to 8.4. As an on-premises “monolithic” software tool, you will need to wait for an IIQ patch or major version upgrade to see large improvements to Access History. (There are rumors of some good stuff coming in 8.5!)
The History Plugin is published by Instrumental Identity. We routinely publish new updates for the History Plugin, often in response to customer requests. The plugin supports every version of IIQ from 7.2 to the present.
Triggering a history scan
Both HP and AH periodically scan the system for Identities and Accounts modified since the most recent check. These objects are then processed to detect and record changes.
The Access History scanner detects updates to Identities, Accounts, Roles, Capabilities, and several other objects. This expansive change detection is very useful. Detected changes are then written to an external message queue service, from which a listener in IIQ consumes events. (This use of a message queue has proven deeply unpopular, to the extent that SailPoint will offer other options in 8.5.)
For Identity and Account data, the HP’s implementation is, in my opinion, the better of the two.
- The HP can scan for changes in either a Scheduled Task or a background Service. The underlying implementation is identical, but the Service can run more frequently.
- Since both scanners detect a change some time after it happens, they must decide which date to put onto the “change” itself. HP makes an effort to derive the actual change date from various places. AH uses the start date of the collector job for all changes.
-
The History Plugin’s scanner also has an expanded view of “sameness“. We don’t record a change if values only differ in order, or if the value changes from Boolean true to String “true”.
Storage and reporting
The History Plugin stores its “delta” events, the changes to both Identities and Accounts, as regular IIQ Audit Events. Like all Audit Events, these can be queried in Advanced Analytics. More technical analysts can create Filter or HQL reports to export relevant data.
Access History stores its data in a dedicated database schema, the new identityiqah repository.
While it’s possible to write a report against the data stored by Access History, SailPoint would prefer that analysts use their own UI and export tools to do so. Much of the data is also stored in a JSON format, making it difficult to query for particular attribute or account updates.
The History Plugin makes an effort to keep the most commonly-used data in separate Audit Event database columns. You can query the history using regular SQL.
If you need more power, the History Plugin can also store changes in its own custom database tables, allowing easy export to a data warehouse, SIEM or BI tool, or custom report.
User interfaces
Both AH and HP offer user interfaces allowing analysts or developers to select an identity, then view its history. Unfortunately, that is where their similarities end.
The Access History UI was designed to mimic the similar user interface in Identity Security Cloud. It displays historical events in a blocky, spacious timeline, requiring a large amount of scrolling. (If your monitor isn’t large, the screen has no fewer than three separate scrollable areas.) The text content of events cannot be searched.
The History Plugin UI – History Viewer – was written to display as much information as possible in as little space as possible. It arranges historical events of all types in a paged table timeline, offering text filters at the top of each column. Details are extracted from the actual event objects (e.g., Access Requests), rather than the truncated snapshots stored by Access History.
A timeline bar at the top of the page allows users to narrow their focus onto a single timeframe.
You can also show your own custom audit events in the timeline. This has been extremely powerful for our customers whose IIQ configuration includes numerous custom workflows or APIs.
In the latest version, you may also configure History Viewer with per-attribute security, hiding sensitive attributes from lower-privilege analysts.
As mentioned above, if you’d rather not use our plugin’s UI, or if you have very specific requirements, you can also display change events using Advanced Analytics or a custom report. This is a key advantage of using OOTB Audit Events.
