Identity
The Identity object: the person-centric cube linking all of a user's accounts and access.
The Identity object (Identity Cube) is the central record for a person, linking their accounts, entitlements, roles and attributes.
- What the Identity object represents
- Key attributes and relationships
- How it is created and maintained
- Where it appears in governance
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.
What the object holds
- 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.
How it is created and maintained
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.
Relationships to other objects
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.
Governing identities
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.
Common pitfalls
- 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.