sota-identity-access

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. 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. 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 and rules/05.

Concurrent siblings to invoke alongside: sota-network-security (mTLS, ZTNA, identity-aware proxy), sota-kubernetes (K8s RBAC, OIDC to the API server, SA tokens), sota-detection-engineering (identity-based detections, impossible-travel, auth anomaly), sota-privacy-compliance (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 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.
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.
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.
5. Separate and time-box privilege. Admin-account separation, JIT elevation, logged-and-alerted break-glass, machine identity. 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.
7. Self-review against each file's Audit checklist before declaring done.

AUDIT mode

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. Pull from the IdP API or config export, not screenshots.
2. Enumerate the population: every human and service account, its authentication strength, last-login, group/role assignments, and owner. Cross against the HR/source-of-truth roster to find orphans.
3. Sweep by rules file: 01 (protocol/token misconfig), 02 (IdP hardening), 03 (over-privilege/SoD), 04 (orphaned/dormant/no-reviews — usually the most findings), 05 (break-glass/standing admin/static workload creds), 06 (weak MFA).
4. Verify, don't assume: a wildcard redirect URI, an account that logged in 400 days ago, a role granting * — confirm each against the live config/logs before reporting. Never authenticate as a discovered account or trigger break-glass without explicit permission.

Severity conventions

Finding format

Report every finding as one line, ordered Critical → Info:

file:line | rule | severity | effort (trivial/small/medium/large) | fix

Where file:line anchors to the offending config (e.g. keycloak/realm.json:412, policies/rbac.rego:88, or idp://clients/web-app#redirect_uris for live config with no file). rule is the rules-file section (e.g. 01 §redirect-uri). Group repeated instances of one weakness into a single finding listing all locations. End the audit with: counts per severity, the orphaned/dormant account tally, and the top 3 systemic fixes (almost always: deprovisioning automation, MFA hardening, least-privilege roles).

Rules index

Top-10 non-negotiables

Violations are findings regardless of context; in BUILD mode they are never shortcuts.

1. Authorization Code + PKCE is the only sanctioned interactive flow. Implicit and ROPC/password grant are dead and disabled at the IdP. (rules/01)
2. Exact redirect-URI matching, no wildcards, no scheme/host/path looseness. A loose redirect_uri is a token-exfiltration primitive. (rules/01)
3. At the RP, pin algorithms and validate iss, aud, exp, and nonce; reject unsigned tokens and alg:none. SAML RPs reject unsigned assertions and validate the signature over the whole response with anti-XSW canonicalization. (rules/01)
4. The IdP is a tier-0 asset: HA, backed-up identity store, restricted admin plane, rotating signing keys with kid overlap, no standing super-admin without phishing-resistant MFA. (rules/02)
5. Refresh tokens rotate with reuse detection, or are sender-constrained (DPoP/mTLS); access tokens are short-lived. No non-expiring tokens. (rules/01, rules/02)
6. Authorization is least-privilege by an explicit model with policy-as-code and a tested allow/deny matrix. No role grants estate-wide *; segregation of duties enforced on sensitive pairs. (rules/03)
7. Group→role mapping is explicit and default-deny: a user with no matching mapping gets no access, never a silent default role. (rules/03)
8. Deprovisioning is automated and prompt — a leaver loses all access within the agreed SLA, source-of-truth driven via SCIM; access is recertified on a schedule. Deprovisioning is the #1 IAM failure. (rules/04)
9. Privileged access is separated, just-in-time, and time-boxed; break-glass is logged, alerted, and expires. No permanent quiet admin backdoor. (rules/05)
10. Phishing-resistant MFA (FIDO2/passkeys) at the IdP for all privileged and, ideally, all users; step-up for sensitive operations; SMS/voice OTP is not phishing-resistant. (rules/06)