/sota-identity-access

name: sota-identity-access
description: >-
  State-of-the-art identity and access management engineering (2026) for
  BUILDING/configuring identity infrastructure AND AUDITING it — federation,
  IdPs, authorization models, the joiner-mover-leaver lifecycle,
  privileged/break-glass access, workload identity, MFA/passkeys, and
  assurance levels; audits cover orphaned accounts, over-privileged roles,
  weak MFA, long-lived tokens, and SAML misconfig. Owns identity
  INFRASTRUCTURE and access-management DESIGN, not app-level login/session/JWT
  mechanics (sota-code-security owns those). Trigger keywords: IAM, IdP, OIDC,
  OAuth 2.1, PKCE, DPoP, PAR, RAR, JAR, FAPI, SAML,
  SCIM, provisioning, deprovisioning, RBAC, ABAC, ReBAC, Zanzibar, OpenFGA,
  SpiceDB, OPA, Cedar, Kanidm, Keycloak, Authentik, Zitadel, Entra, Okta, SSO,
  single logout, MFA, passkey, FIDO2, WebAuthn, step-up, conditional access,
  CAEP, PAM, break-glass, just-in-time, SPIFFE, access review, NIST 800-63,
  IAL, AAL, FAL, Active Directory, Kerberos, Kerberoasting, ADCS, RBCD,
  gMSA, dMSA, LAPS, krbtgt.

SOTA Identity & Access

Purpose

Own the identity **infrastructure** and access-management **design** of a system: the federation protocols themselves, the IdP that issues and validates tokens, the authorization model that decides who may do what, the lifecycle that creates and destroys access, privileged access, and machine identity. Two modes. In **BUILD** mode you stand up or configure this infrastructure correctly by default. In **AUDIT** mode you assess an existing identity estate against the same rules and report severity-rated findings. The rules files are the single source of truth for both.

Boundary discipline — this skill does **not** re-teach what siblings own:

• **App-level authn ceremony** (password storage/argon2id, session cookie flags,

WebAuthn ceremony, JWT *signature* validation mechanics at one RP): that is **[sota-code-security** rules/02](../sota-code-security/rules/02-authentication.md) (sessions and JWT: [rules/17](../sota-code-security/rules/17-sessions-and-tokens.md)). This skill owns the protocol and the IdP side.

• **App-level object/function authz** (IDOR/BOLA in one service's handlers): that is

**[sota-code-security** rules/03](../sota-code-security/rules/03-authorization.md). This skill owns the authorization *model* and the *policy engine* that the app calls.

• **Secret storage, OIDC-federation mechanics for workloads, JWT `kid` rotation as a

credential operation**: **[sota-secrets-management** rules/01](../sota-secrets-management/rules/01-lifecycle-and-workload-identity.md) and [rules/05](../sota-secrets-management/rules/05-credential-types.md).

Concurrent siblings to invoke alongside: **[sota-network-security](../sota-network-security/SKILL.md)** (mTLS, ZTNA, identity-aware proxy), **[sota-kubernetes](../sota-kubernetes/SKILL.md)** (K8s RBAC, OIDC to the API server, SA tokens), **[sota-detection-engineering](../sota-detection-engineering/SKILL.md)** (identity-based detections, impossible-travel, auth anomaly), **[sota-privacy-compliance](../sota-privacy-compliance/SKILL.md)** (consent, DSAR, audit evidence).

The hierarchy of preference, always: **(1)** no standing credential — short-lived, federated, sender-constrained tokens; **(2)** standing identity with strong phishing-resistant authentication and just-in-time elevation; **(3)** long-lived secret-authenticated client with rotation and audit; **(4)** anything static and broadly-scoped is a defect to be justified or removed.

BUILD mode

Use when standing up or configuring any identity component.

1. **Pick the protocol, not the vibe.** Interactive user login → OIDC Authorization Code + PKCE (the only sanctioned interactive flow). Service-to-service → client credentials with `private_key_jwt`/mTLS, or workload identity federation. High assurance → FAPI 2.0. Legacy SAML only where a relying party requires it. Read [`rules/01-federation-protocols.md`](rules/01-federation-protocols.md) before configuring any client. 2. **Treat the IdP as a tier-0 asset.** HA, backups of the identity store, restricted admin plane, signing-key rotation, break-glass design. [`rules/02-idp-operations.md`](rules/02-idp-operations.md). 3. **Design the authorization model deliberately.** RBAC vs ABAC vs ReBAC is an architecture decision; model roles/relationships and write policy as code with a test matrix. [`rules/03-authorization-models.md`](rules/03-authorization-models.md). 4. **Wire the lifecycle before launch.** Joiner-mover-leaver, SCIM provisioning AND deprovisioning, access reviews. Deprovisioning is the #1 IAM failure — design it first. [`rules/04-lifecycle-provisioning.md`](rules/04-lifecycle-provisioning.md). 5. **Separate and time-box privilege.** Admin-account separation, JIT elevation, logged-and-alerted break-glass, machine identity. [`rules/05-privileged-workload.md`](rules/05-privileged-workload.md). 6. **Make authentication phishing-resistant and adaptive.** Passkeys/FIDO2 at the IdP, step-up, CAEP/SSF for continuous evaluation. [`rules/06-mfa-federation-assurance.md`](rules/06-mfa-federation-assurance.md). 7. **Self-review against each file's Audit checklist** before declaring done.

AUDIT mode

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

Use when assessing an existing identity estate.

Sweep procedure

1. **Enumerate the IdP config**: clients/relying parties and their redirect URIs, client-auth methods, token lifetimes, grant types enabled, signing keys + rotation, session/SLO config, MFA policy, federation/brokering trusts — and, on any hybrid or on-prem estate, the AD domains, ADCS CAs and directory-sync servers (swept by 07). Pull from the IdP API or config export, not