The IAM Architecture Bible

IAM Design Philosophy

Identity is the first control point. Access grows progressively, follows least privilege and remains explainable throughout its lifecycle.

• Separate authentication, authorization, ownership and administration.
• Use groups for functional access wherever practical.
• Keep every decision traceable to a governance boundary.

A successful login does not prove the user should have every downstream permission.

Identity Architecture

Central identity establishes the person or workload. Applications and resources consume it through governed trust relationships.

• Use central identity for immediate leaver containment.
• Model people, service identities, groups, apps and resources separately.
• Treat identity proof, sessions and entitlement as separate controls.

Joiner / Mover / Leaver

Joiners receive staged access, movers replace obsolete access, and leavers are contained immediately before downstream cleanup.

• Join: birthright → time gate → training → approval → functional access.
• Move: calculate the target state and remove obsolete roles.
• Leave: disable identity, revoke sessions, transfer ownership and preserve history.

Mover access is replacement, not accumulation.

Birthright & Department Visibility

Birthright is limited onboarding access. Operational visibility supports work without exposing credentials or administrative control.

• Keep birthright small and essential.
• A time gate reduces exposure; it does not establish trust.
• READ covers ordinary operational data, never secret or bypass material.

VIEW DATA ≠ VIEW SECRETS ≠ MODIFY ≠ ADMINISTER

Functional & Privileged Access

Tool owners define useful functions; IAM gives those functions a governed identity representation and lifecycle.

• Prefer additive groups with one clear purpose.
• Increase approval rigor with criticality and blast radius.
• Keep global administration rare, explicit and separately reviewed.

Tool Classification

Classify each boundary as Core/Infrastructure (INF), Project/Time-bound (PRJ), or Custom/Internal (CUS).

• INF covers durable organization-wide platforms.
• PRJ covers workloads, often below a parent platform.
• CUS covers internal tools with a named individual owner.

Governance ID Standard

Every governed object receives a permanent identifier such as INF-000021, PRJ-001042 or CUS-000014.

• Never encode mutable department, owner or tool names.
• Trace groups, apps, resources, reviews and audits to the ID.
• The registry is authoritative; names remain human-friendly labels.

Example group: PRJ-001042-DEV

Group Architecture

Groups describe why access exists, its boundary and the authority that approves membership.

• INF and PRJ start with OWNER, READ and GLOBAL-ADMIN design records.
• Add functional groups only when the owner defines their purpose.
• Map every controlled group to an approver before activation.

Core Infrastructure Model

Long-lived platforms use durable group ownership, technical administration, tiered approval and explicit global access.

• Keep governance ownership separate from platform administration.
• Allow owner-defined support levels such as L1–L4.
• Place shared resources in an explicit core boundary.

Project Access Model

A project has its own Governance ID, owner group, lifecycle, functions and resources even on a shared platform.

• Record the parent platform relationship.
• Route access to the project approver group by default.
• Require expiry for time-bound projects.

Custom Tool Model

Internal tools and automations require an active named owner and only the identity functions they need.

• Do not force enterprise group scaffolding onto every tool.
• Record dependency and handover information.
• Block activation if the named owner is inactive.

Ownership Model

Ownership expresses accountability; technical administration expresses the ability to operate a system.

• Use durable owner groups for infrastructure and projects.
• Require an individual owner for custom tools.
• Close assignments with effective dates and preserve history.

Approval Architecture

Authority belongs to configured groups or owners, while each event records the individual who acted.

• Scale rigor with scope, criticality and blast radius.
• Avoid named approvers for durable platform policy.
• Prevent administrators from self-approving privileged access.

Authentication Applications

SAML, OIDC, API service and other identity apps are registry records associated with a Governance ID.

• Record purpose, type and external identifier.
• Keep secrets out of general metadata.
• Separate authentication configuration from resource authorization.

Resource Governance

Each resource has one formal ownership boundary; consumer relationships document cross-project use.

• Associate resources with a Governance ID.
• Use core boundaries for shared infrastructure.
• Map group intent without pretending IAM owns platform-native policy.

Recertification

Reviews confirm continued need, ownership, memberships, approval mappings and lifecycle state.

• Use configurable review frequency.
• Escalate overdue reviews and apply defined fail-closed policy.
• Retire with retained history rather than destructive deletion.

No response is never certification.

Audit & Traceability

Important changes create append-oriented events with actor, time, target, Governance ID and meaningful before/after values.

• Use immutable audit identifiers.
• Record ownership, access, apps, resources, reviews and lifecycle changes.
• Never log credentials, tokens, private keys or recovery material.

Automation

Automation applies approved decisions consistently; it does not invent ownership or access meaning.

• Prefer authoritative HR events for lifecycle triggers.
• Design extension points for provisioning platforms.
• Validate imports and authorize every automated mutation.

Dashboard & Reporting

Dashboards surface active objects, expiry, reviews, ownership gaps and traceability exceptions.

• Make exceptions actionable.
• Search by ID, person, group, department, resource and app.
• Keep secret material out of reporting views.

Reference Architectures

Reference patterns connect classification, ownership, groups, approvals and resources without becoming vendor rules.

• Start with the boundary and purpose.
• Show who owns, approves and administers.
• Trace each access path to its resource.

Jamf Example

Jamf is an INF object with OWNER, READ and GLOBAL-ADMIN plus owner-defined L1–L4 functions.

• IAM governs groups; Jamf administrators map privileges.
• READ excludes recovery keys and bypass codes.
• Approval rigor increases toward global administration.

AWS Example

AWS is an INF platform. Each governed workload can be a PRJ child with separate ownership and resources.

• Associate resources with the project Governance ID.
• Use AWS-native policy for exact actions.
• Allow multi-project access only for legitimate responsibility.

Custom Application Example

A CUS application has a named owner, requested identity functions and a leaver handover dependency.

• The owner defines access meaning and eligibility.
• IAM creates only the required identity representation.
• The business chooses a successor, not IAM.

IAM Architect Checklists

Check classification, identity design, access intent, approval, resource ownership, lifecycle, review and audit.

• Can every permission answer WHO, WHAT, WHY and WHERE?
• Can each approval identify its authority and actor?
• Can ownership, expiry and review state be found without decoding group names?