Notifications
Clear all
Topic starter
12/06/2026 12:29 am
TL;DR: Hard-coded role and claims checks become brittle as .NET Core applications need ownership, context, and dynamic policy decisions, according to Cerbos. Moving authorization into external policies reduces code-level sprawl and makes access control easier to change without rewriting controllers.
NHIMG editorial — based on content published by Cerbos: integrating Cerbos with .NET Core Identity for policy-driven authorization
Questions worth separating out
Q: How should security teams handle contextual authorization in .NET Core applications?
A: Use authentication for identity verification and externalize authorization into a governed policy layer that can evaluate resource attributes such as ownership, status, or tenant context.
Q: When does role-based access control become a poor fit for application security?
A: RBAC becomes a poor fit when access depends on more than a stable job role, such as document ownership, publication state, or time-bound business rules.
Q: What should teams do to keep authorization changes from becoming code debt?
A: Move changing access rules into version-controlled policy files, then test those policies independently of the application release cycle.
Practitioner guidance
- Separate authentication from authorization decisions Keep .NET Core Identity for sign-in and identity proofing, but route authorization through a dedicated policy service so access rules do not accumulate inside controllers.
- Pass resource attributes explicitly to the decision point Include ownership, publication state, and other resource attributes in every authorization request so rules can be evaluated consistently outside application code.
- Version and test policy files like application code Store policy YAML in source control, run compile checks in CI, and review changes through the same change-control process used for code releases.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step .NET Core implementation details for custom authorization providers and handlers.
- Full Cerbos policy examples for document ownership, publication state, and admin override logic.
- Local Docker setup and compile validation steps for testing policy changes during development.
- End-to-end request flow showing how the authorization service evaluates principals and resource attributes.
👉 Read Cerbos' guide to policy-driven authorization with .NET Core Identity →
Cerbos and .NET Core Identity: where RBAC starts to break?
Explore further
25/06/2026 5:28 pm
RBAC becomes a maintenance trap the moment authorization depends on context. The article shows the classic failure mode: roles are too blunt for ownership, publication state, and other business conditions. Once teams respond by adding more granular roles or conditional code paths, the authorization model becomes harder to reason about than the application it protects. The practical conclusion is that role sprawl is a governance symptom, not a solution.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How do policy-driven authorization and application code differ in access control?
A: Application code enforces access by embedding logic inside controllers or handlers, while policy-driven authorization evaluates rules outside the codebase and returns an allow or deny decision. The policy model is easier to govern because it separates decision logic from execution logic and reduces hidden exceptions.
👉 Read our full editorial: Policy-driven authorization for .NET Core Identity scales beyond RBAC
