Add Identity and Access Management dimension

[jdsmithit]

Adds a new "Identity and Access Management" dimension to the Implementation stage, covering both governance controls (central SSO/IdP for human access, account inventory, segregation of duties, automated joiner-mover-leaver provisioning, periodic access recertification, just-in-time privileged access) and controls owned directly by developers (server-side authorization enforcement, automated authorization test coverage, correct OAuth2/OIDC flows, least-privilege scoping for service accounts and CI permissions).

Non-human identities (service accounts, workload identities, CI/CD pipelines) are called out explicitly since they're an increasingly common source of access-related incidents.

[jdsmithit]

This one's been a bit of a tough one, since you have to frame the dev team's responsibilities from an IT ops standpoint. Feedback would be appreciated. I could see this growing bigger in the future, but I think it's a good starting point, given broken access control is still #1 in the OWASP Top 10.

[wurstbrot]

Do we need to cleanup, e.g. moving https://dsomm.owasp.org/activity-description?uuid=598e9f13-1ac8-4a01-b85e-8fab93ee81de to this subdimension?

Can we delete or move https://dsomm.owasp.org/activity-description?uuid=070bb14b-e04a-4f3d-896a-a08eba7a35f9 ?

[jdsmithit]

i would move RBAC and MFA https://dsomm.owasp.org/#598e9f13-1ac8-4a01-b85e-8fab93ee81de, but leave MFA for admins where it is thoughts?

[wurstbrot]

Why would that not be in the new dimension? They are both very much connected

I will one day change RBAC to Attribute Based Access Control.

[jdsmithit]

Yes, you're absolutely correct. I got confused, as I was thinking it was specifically related to infrastructure. There is also a simple access controls category for systems: https://dsomm.owasp.org/#82e499d1-f463-4a4b-be90-68812a874af6. I'll move that as well.

I think RBAC might be better positioned as "Fine-Grained Access Controls", encompassing approaches such as ABAC, RBAC, and PBAC. That would align better with the Simple Access Controls category as well.

[jdsmithit]

Drafted the change for RBAC

[wurstbrot]

It feels to me that there are too many activities at level 2

[jdsmithit]

Level 1 — foundations

Simple access control for systems — all internal systems use basic authentication; a documented baseline gate
MFA for admins — two+ factor authentication on all privileged accounts
Account inventory — a current, owned list of every account, human and non-human
Enforce server-side authorization on every request — deny-by-default authz checked on the server, stopping IDOR / broken access control

Level 2 — consolidate and structure

Central identity provider for human access — all human access federated through one IdP/SSO instead of per-system logins
MFA — extend two+ factor to all accounts on important systems
Use correct OAuth2/OIDC authorization flows — Auth Code + PKCE for apps, Client Credentials for services; no Implicit/ROPC
Least-privilege access baseline — default-deny roles, no shared accounts, capped admins, scoped service accounts
Role-based access control (RBAC) baseline — access driven by defined, documented roles rather than per-user grants

Level 3 — automate and assure

Segregation of duties for critical actions — conflicting duties (author vs approver, deploy vs approve) split and technically enforced
Automated authorization test coverage — CI tests asserting each role/permission boundary, including negative "should be denied" cases
Automated joiner-mover-leaver provisioning — access granted/changed/revoked automatically from an authoritative source, with a leaver SLA
Workload and machine identity — short-lived, verifiable identities (OIDC federation/SPIFFE) for non-human access, retiring static keys

Level 4 — eliminate standing privilege / policy-driven access

Just-in-time privileged access — time-boxed, approved, auto-revoked elevation; zero standing admin
Attribute/policy-based access control (ABAC/PBAC) — attributes or centrally evaluated policies (e.g. OPA) where roles are too coarse
Periodic access recertification — scheduled re-attestation of access with enforced revocation, covering service accounts too

Level 5 — continuous verification

Continuous and risk-adaptive access — decisions re-evaluated on device/context/risk, with automatic segregation-of-duties conflict detection

[wurstbrot]

Hi, Level 1 should be a no brainer, so at least "Account inventory — a current, owned list of every account, human and non-human" needs to move to 2.
Level 2 also has to many activities, half needs to move to 3. RBAC is 4 already and needs to stay I think or go level 3.
"Use correct OAuth2/OIDC authorization flows" feels like level 3 because it is not easy to implement.

[jdsmithit]

(Changes since the earlier comment: RBAC baseline and ABAC/PBAC merged into one "Fine-Grained Access Controls" activity at L3 and aligned with old RBAC; the advanced policy-engine piece split out as "Externalized policy-as-code authorization" at L5; Segregation of duties for critical actions moved from L3 to L4, fixed merge conflicts.

Sort out signing issues.

Sorry for the delay.

Level 1 — foundations

• Simple access control for systems — all internal systems use basic authentication; a documented baseline gate
• MFA for admins — two+ factor authentication on all privileged accounts
• Enforce server-side authorization on every request — deny-by-default authz checked on the server, stopping IDOR / broken access control

Level 2 — consolidate and structure

• Account inventory — a current, owned list of every account, human and non-human
• Central identity provider for human access — all human access federated through one IdP/SSO instead of per-system logins
• MFA — extend two+ factor to all accounts on important systems
• Least-privilege access baseline — default-deny roles, no shared accounts, capped admins, scoped service accounts

Level 3 — model, automate and assure

• Use correct OAuth2/OIDC authorization flows — Auth Code + PKCE for apps, Client Credentials for services; no Implicit/ROPC
• Fine-Grained Access Controls for authentication and authorization — roles (RBAC) as the baseline, refined with attributes (ABAC) or policy rules (PBAC) where roles are too coarse
• Automated authorization test coverage — CI tests asserting each role/permission boundary, including negative "should be denied" cases
• Automated joiner-mover-leaver provisioning — access granted/changed/revoked automatically from an authoritative source, with a leaver SLA

Level 4 — eliminate standing privilege

• Segregation of duties for critical actions — conflicting duties (author vs approver, deploy vs approve) split and technically enforced
• Workload and machine identity — short-lived, verifiable identities (OIDC federation/SPIFFE) for non-human access, retiring static keys
• Just-in-time privileged access — time-boxed, approved, auto-revoked elevation; zero standing admin
• Periodic access recertification — scheduled re-attestation of access with enforced revocation, covering service accounts too

Level 5 — continuous verification & policy as code

• Externalized policy-as-code authorization — a central policy engine (e.g. OPA/Rego) serving multiple services, with policies version-controlled and tested and decisions logged
• Continuous and risk-adaptive access — decisions re-evaluated on device/context/risk, with automatic segregation-of-duties conflict detection

[wurstbrot]

Reviewed the framework references against the source standards (OWASP SAMM v2, ISO/IEC 27001:2013/2022 Annex A, MITRE D3FEND). The reference scheme is right and consistent with the repo, but there are a few factual errors and mislabels worth fixing, plus one YAML indentation bug. Concrete suggestions inline.

One broader (non-blocking) note: nearly every activity maps to SAMM O-EM-A-x (Operations → Environment Management → Configuration Hardening). That's a fine fallback, but Config Hardening isn't really about identity. The app-level items you already mapped well (D-SR-A-* for authz/OAuth, V-RT-A-1 for authz test coverage) show the better pattern — consider D-SA (Security Architecture) for the IdP / policy-as-code / fine-grained items rather than O-EM-A.

[wurstbrot]

please check the suggestions from claude code. I checked them and they sound correct.

[wurstbrot]

I will wipe "iso27001-2017" soon. I do not think it has a use.

[wurstbrot]

thank you, will go live with version 5.0.0 of the main app soon

[jdsmithit]

Went through the feedback, agree with all the points — fixed everything you flagged plus a couple more I found along the way.

Fixed the MFA refs (dropped the unrelated SoD/secure-dev-policy entries, fixed the typo, added secure log-on/secure authentication instead), the 9.1.1→9.4.1 mislabel on least-privilege baseline, the LocalAccountMonitoring→AccessModeling swap, the indentation bug on Fine-Grained Access Controls, and the two wrong "9.2.1" comments.

Also caught a real bug: the merge from main had brought back the old "MFA for admins"/"MFA" blocks in InfrastructureHardening.yaml with the same UUIDs as their new home here. Deleted the duplicates.

On the O-EM-A-x point — moved the actual architecture/tech decisions (central IdP, fine-grained access controls, policy-as-code, MFA, workload identity) over to D-SA, checked against the SAMM v2 site. Left JIT and risk-adaptive access on O-EM-A since those are genuinely runtime controls.

Found one more mismatch myself: account inventory had 9.2.1 paired with 8.2, which actually comes from 9.2.3 and isn't about inventory anyway. Removed it.

Added d3f where a real technique applies — password auth, token-based auth, access modeling, certificate-based auth, user behavior analysis. Skipped account inventory even though D3-AI exists, since its scope is explicitly software/hardware, not accounts.

[wurstbrot]

will you push here again or create a new PR?

[jdsmithit]

ill push and new branch, due to the bug