Identity

The Identity object is the centre of the IdentityIQ object model. It represents a single person (or service principal) and consolidates everything known about them: their accounts on every system, their entitlements and roles, and a set of governed identity attributes. In the UI and documentation it is often called the Identity Cube.

• Links (accounts): one per correlated account on each application.
• Identity attributes: name, department, title, manager, employee type, status, plus any extended attributes you define.
• Assigned and detected roles: roles granted deliberately versus those inferred from held entitlements.
• Policy state: any violations the identity currently has.

Identities are created by identity aggregation from the authoritative source and kept current by identity refresh, which re-applies attribute mappings, re-evaluates role assignment, runs policy and fires lifecycle events. Clean attribute mapping and a reliable refresh cadence are what keep cubes accurate.

The Identity is referenced by almost everything: certifications review an identity’s access, provisioning changes an identity’s accounts, policies evaluate an identity’s combined entitlements, and roles attach to identities. This centrality is why data quality on the identity propagates, good or bad, to every governance outcome.

Because governance decisions are made per person, the identity is the unit of certification, request and policy. Non-human identities (service accounts, bots) should be modelled as identities too, with an appropriate type, so they are owned and reviewed rather than left ungoverned.

• Weak correlation leaving accounts unattached to any identity.
• Attributes mapped from non-authoritative sources, producing conflicts.
• Skipping refresh after aggregation, so cubes look updated but roles and policy are stale.