Enterprise Identity & Access Management Platform  ·  View 09 of 27  ·  Data

Identity & Entitlement Data Model

The state an access decision reads, and how a person joins to a permission.

Editable source SVG draw.io All views
tenant
tenant_id PK
kind ENUM(CORP,CIAM,PARTNER)
home_domain
isolation_tier
data_residency
tenant...
identity
object_id PK
tenant_id FK -> tenant
upn
kind ENUM(EMP,CTR,GUEST,CUST,BG)
hr_worker_id
account_enabled
last_sign_in_at
identity...
group
group_id PK
tenant_id FK -> tenant
name (app-env scoped)
source ENUM(DYNAMIC,ASSIGNED,PIM)
owner_id FK -> identity
group...
application
app_id PK
tenant_id FK -> tenant
display_name
sign_in_audience
owner_group_id FK -> group
application...
workload_identity
principal_id PK
tenant_id FK -> tenant
kind ENUM(SYS_MI,USER_MI,SP)
app_id FK -> application
credential ENUM(MI,FIC,SECRET)
owner_group_id
workload_identity...
group_membership
group_id FK -> group
member_id FK -> identity
source ENUM(HR,PACKAGE,PIM)
granted_at
expires_at NULL = permanent
group_membership...
access_package
package_id PK
catalog_id
name
approver_group_id FK -> group
duration_days
review_cadence_days
access_package...
app_role
role_id PK
app_id FK -> application
value (roles claim)
allowed_member_types
requires_admin_consent
app_role...
federated_credential
fic_id PK
principal_id FK -> workload_identity
issuer (OIDC)
subject (repo:env / ns:sa)
audience
created_by
federated_credential...
rbac_role_assignment
assignment_id PK
principal_id (group preferred)
role_definition_id
scope (MG/sub/RG/resource)
condition ABAC NULL
is_pim_eligible
rbac_role_assignment...
entitlement_assignment
assignment_id PK
package_id FK -> access_package
identity_id FK -> identity
state ENUM(PENDING,ACTIVE,EXPIRED)
justification
expires_at
entitlement_assignment...
pim_activation
activation_id PK
assignment_id FK -> rbac_role_assignment
ticket_ref
approver_id FK -> identity
activated_at
expires_at (max 8 h)
auth_strength_met
pim_activation...
access_review_decision
review_id PK
assignment_id FK -> entitlement_assignment
reviewer_id FK -> identity
decision ENUM(APPROVE,DENY,NO_RESP)
decided_at
evidence_uri
access_review_decision...
1 : N
1 : N
1 : N
1 : N
1 : N
1 : N
1 : N
1 : N
grants N : M
grants N : M
grants N : M
grants N : M
1 : N
1 : N
1 : N
1 : N
1 : N
1 : N
principal N : 1
principal N : 1
1 : N
1 : N
1 : N
1 : N
Identity & Entitlement Data Model
Identity & Entitlement Data Model
Sign-in and audit events are deliberately absent: they are append-only telemetry with a different owner and retention, and view 11 places them. Everything drawn here is state that access decisions read.
Sign-in and audit events are deliberately absent: they are append-only telemetry with a different owner and retention, and view 11 places them. Everything drawn here is state that access decisions read.
v 1.0 · owner Data & AI Global Practice · date 2026-08
v 1.0 · owner Data & AI Global Practice · date 2026-08
Text is not SVG - cannot display

Modelling decisions

  • tenant_id appears on every top-level entity. Isolation is a schema property here, so an accidental cross-tenant join is a query that fails rather than a leak that succeeds.
  • group_membership carries expires_at and a source. Access with no expiry and no provenance is the mechanism by which entitlement creep happens; making both mandatory columns makes the creep visible.
  • rbac_role_assignment records is_pim_eligible separately from an active grant, so 'who could become privileged' and 'who is privileged right now' are two different queries with two different answers.

The join that matters

  • employee_id from Workday is the only correlation key between HR and the directory. Everything downstream depends on it being present and stable across a rehire.
  • access_package is the grant unit for humans and group membership is its effect, which is why reviews target packages rather than groups: reviewing a group asks the wrong question.
  • federated_credential stores issuer, subject and audience. Those three fields are the whole security boundary of a CI/CD federation, so they are modelled explicitly rather than left inside an opaque configuration blob.

Deliberate omissions

  • Sign-in and audit events are absent. They are append-only telemetry with a different owner, a different retention and a different store — view 11 places them.
  • Consent grants and OAuth permission grants are not modelled here; they are governed operationally through the admin consent workflow (view 27, row 3).
  • Device and its compliance state belong to Intune's model. This platform reads the signal and does not restate the schema.