Governance Access Model

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

Hi Sailors,

I am currently working on onboarding an API-based application into IdentityIQ.

During account aggregation, I identified four break-glass accounts. Each account is assigned one of the following privilege levels:

  • Admin
  • Power
  • Basic
  • Custom

The Admin, Power, and Basic privilege levels are standard roles with predefined sets of permissions. However, the Custom privilege level allows administrators to individually select and customize permissions from a larger set of more than 100 underlying privileges.

From an IIQ access governance perspective, I see a potential challenge:

  • IIQ currently aggregates only the high-level privilege (Admin, Power, Basic, Custom).
  • The underlying permissions associated with the Custom privilege are not being aggregated or represented as entitlements in IIQ.
  • As a result, two users assigned the Custom privilege could have completely different permission sets, while appearing identical during access reviews and certifications.
  • This could make certifications inaccurate, as certifiers would only see “Custom” without visibility into the actual permissions granted.

My concern is that this creates a governance and audit gap, since the effective access is not fully represented in IIQ.

What would be the recommended approach to address this from an Identity Governance perspective?

2

Hello Reynold. I would fix this at the aggregation layer. IIQ can only govern the access it receives. For Custom, aggregate the effective permissions as a Multi-Valued + Entitlement account attribute, for example:

permissions = [PermissionA, PermissionB, PermissionC]

This allows IIQ to track and include each permission in certifications. Mark it Managed as well if you need Entitlement Catalog metadata such as owner, description, display name, or requestability. (Application Schemas)

If the account API only returns Custom, use a child aggregation endpoint or other connector logic to retrieve the underlying permissions. If those permissions cannot be returned or derived from the target, IIQ cannot accurately certify the effective access, so another governance control is required.

Since these are break-glass accounts, also define how intentionally uncorrelated accounts will be reviewed.