Cost Allocation & Showback Platform  ·  View 22 of 22  ·  7 · Assurance

Identity and Access Flow

Who is allowed to see whose bill, and why an out-of-scope read is answered rather than refused.

Editable source SVG draw.io All views
Engineering lead Entra ID Query API Scope resolver Org tree Fact store Audit log 1. sign in, MFA 2. token + group claims 3. GET /statements?team=X 4. resolve scope for subject 5. teams owned as of date 6. team set (effective-dated) 7. predicate: team in set 8. inject predicate, reject override 9. scoped query 10. rows within scope 11. log subject, scope, grain 12. statement + drill-through 13. GET /statements?team=Y 14. aggregate only, no resources 15. log cross-team read Identity and Access — Who Is Allowed to See Whose Bill The scope predicate is injected server-side and cannot be overridden by a query parameter. Out-of-scope reads are answered at aggregate grain rather than refused, because a flat denial teaches nothing and drives people to spreadsheets. v 1.0 · owner Platform Architecture · date 2026-09

Decisions

  • The scope predicate is resolved server-side from the effective-dated org tree and injected into every query
  • A query parameter can never widen scope; an attempt is logged
  • Scope is resolved as of the statement's period, so a reorganisation does not retroactively open or close access

Why aggregate rather than deny

  • A flat denial teaches nothing and drives people to exported spreadsheets, which is the worse outcome
  • Aggregate grain answers 'is my team unusual' without disclosing another team's architecture

Stated assumptions

  • MFA is enforced for all human access; machine access uses short-lived workload identity with no static keys
  • Group claims from the identity provider name the person, not their scope — scope comes from the org tree
◀  Security Trust Zones All views
Solution Architecture v1.0 · Microsoft Azure · Cost & Efficiency Architecture · 2026-0922-identity-and-access