Role-Based Access Control in Blazor with Authorization Policies

When you build line-of-business apps for Australian organisations, whether it's a claims portal for a private health fund in Sydney, a loan-origination system for a mutual bank in Melbourne, or an internal tool for a council in regional Queensland, you quickly hit the same wall: not every user should see every screen, and the rules around who-sees-what are often written into legislation like the Privacy Act or APRA's CPS 234. Role-based access control in Blazor, layered with ASP.NET Core's authorization policies, gives you a clean way to express those rules in code that is testable, auditable, and friendly to the kind of multi-tenant SaaS that many Aussie ISVs are shipping today.

The rest of this piece walks through the building blocks. We'll cover the difference between authentication and authorization, set up role seeding that survives a container restart, define policies beyond simple role checks, apply them in components, and finish with the production hardening that matters once auditors start asking questions — including how to keep access logs consistent across AEST, AEDT, and the various zones your international users might be sitting in.

Authentication, roles, and where policies fit

Authentication answers "who is this person?" and authorization answers "what are they allowed to do?". In Blazor Server and Blazor WebAssembly, both flow through the same ASP.NET Core ClaimsPrincipal, which carries the user's identity, role claims, and any custom claims you issue. Out of the box, you can stick [Authorize(Roles = "Admin")] on a page and the framework checks the role claim, but that approach quickly gets unwieldy. Once you have a dozen roles combining in different ways — for example, a "BranchManager" in Victoria who can also approve NSW loans up to a limit — inline role strings become a maintenance headache.

Policies solve this by letting you encapsulate a rule in one place and refer to it by name. A policy is a named bundle of one or more requirements, and each requirement is a small class that knows how to evaluate itself against the current user. This separation means your controller, page, or component never has to know the business logic of who is allowed to do what; it just asks for PolicyName, and the authorization handler figures out the rest. It's a pattern that lines up nicely with how compliance teams in Australian banks and government agencies prefer to see access rules documented — as discrete, testable units rather than strings sprinkled across a codebase.

Seeding roles in the identity store

Before any policy is useful, you need roles to exist. In a typical Blazor app backed by ASP.NET Core Identity, the RoleManager<IdentityRole> service seeds them at startup. A common pattern is a RoleSeeder hosted service that runs once on boot, creates the roles if they don't exist, and optionally assigns baseline permissions. The roles you pick should reflect your domain: for a health-tech product, you might have Practitioner, Receptionist, PracticeManager, and BillingOfficer; for a financial planning SaaS out of Brisbane, you might use Advisor, Paraplanner, ComplianceReviewer, and Admin.

A few details worth getting right for Australian deployments. Make the seeder idempotent so it's safe to run against a database that already has roles — Kubernetes pods in AKS often restart multiple times during a blue-green deploy, and you don't want a duplicate-key exception crashing the new pod. If you're using a SQL geo-replicated setup across Sydney and Melbourne regions for disaster recovery, ensure the seeding service waits for the primary to be writable before issuing role upserts. When you wire the AddDefaultIdentity call, consider raising the password complexity to a minimum length of 12, no common passwords, and ideally a check against the Pwned Passwords API. Local government and many enterprise customers will quietly fail your security review otherwise.

Defining policies that go beyond a single role

Once the roles are in place, the real work begins. In Program.cs, you register policies with AddAuthorization, which returns an AuthorizationOptions builder. The most common requirement is RequireRole, but it's only the start. RequireClaim lets you check for a custom claim — useful when a user has multiple roles and you need to know which state they operate in, a common pattern in the mutual banks that span NSW, VIC, and QLD. RequireAssertion is the escape hatch that lets you write a lambda against the AuthorizationHandlerContext, perfect for cross-claim rules like "the user's region claim must match the resource's region claim".

For more complex cases, build a custom IAuthorizationRequirement and its handler. A practical example is an OwnsClaimRequirement that lets a caseworker edit their own cases but only managers edit anyone's. Register the handler with DI as scoped, give the policy a stable name like CanEditCase, and you're done. Custom requirements are also a natural home for environment-aware checks — for instance, requiring that the user has accepted the latest terms of service version, which you can roll out incrementally as your legal team updates the wording for the Australian market.

Picking the right approach for a given surface is easier once you map the options against where they run, how granular they get, and what kind of rule they are best at expressing.

Applying policies in components and endpoints

The two most common ways to enforce a policy in a Blazor app are the [Authorize] attribute and the AuthorizeView component. Use the attribute on @page routes and on API controllers that back your interactive components — that way the framework redirects unauthenticated users to the login page and shows NotAuthorized content to authenticated users who fail the policy. AuthorizeView is the right choice when you want to show different markup to different roles within the same page, for example, hiding a "Refund" button from frontline staff while showing it to team leaders.

For Server-Side Blazor, the policy check happens on the server because the circuit is server-hosted, so you get the same guarantees as a regular ASP.NET Core app. For WebAssembly, the policy is evaluated in the browser using the claims shipped with the user's access token, which means your policy logic must be self-contained and cannot query a database. Most Australian teams build Blazor Server or Blazor United for internal tools and use Blazor WebAssembly only for the read-heavy public surface, which keeps the policy story simple.

When you do need resource-based checks on the client, send the data to a Web API endpoint that itself is protected by the same policy name — the client never makes the access decision alone. This is especially important for healthcare and financial products where a token-tampering bug would land you on the front page of a major newspaper, and where the ATO's notifiable data breach scheme kicks in quickly.

Programmatic checks, auditing, and production hygiene

Sometimes the policy name isn't enough and you need to ask a deeper question: "can this specific user perform this specific action on this specific record?". That's where IAuthorizationService.AuthorizeAsync(user, resource, policyName) comes in. Inject the service into your data layer, run the check before mutating state, and you'll get the same AuthorizationResult object the framework uses internally. This pattern is essential for row-level security in multi-tenant systems and is the basis for the kind of fine-grained audit trails APRA expects under CPS 234.

Speaking of audit trails, every authorization decision is worth logging. Capture the user ID, the policy name, the resource identifier, the result, and a timestamp. That last field is where Australian teams regularly trip up: servers run in UTC, users are spread across AEST, AEDT, ACST, and AWST, and logs often end up in an analytics platform with its own time zone defaults. The cleanest approach is to store every timestamp in UTC, then render it in the viewer's local zone at read time, ideally through a library that understands daylight saving transitions cleanly. If you're already using NodaTime elsewhere, the same approach in time zone handling globally applies directly to your access log pipeline.

Finally, write tests for your policies. The AuthorizationOptions you build in Program.cs can be exercised through PolicyEvaluator, and your custom handlers can be unit-tested by constructing a ClaimsPrincipal with the relevant claims and calling HandleRequirementAsync directly. A solid policy test suite is your best evidence during a security review, which the C# Corner crowd in Melbourne and Sydney keeps reminding each other about at the local .NET meetups.

Recommendations for shipping RBAC in Blazor to production

Putting it all together is less about clever framework tricks and more about consistency. The teams shipping Blazor securely to Australian customers treat role and policy definitions the way they treat database schemas: versioned, code-reviewed, and tested. Once you accept that frame of mind, a lot of the usual RBAC arguments — should this live in the database, in policy files, in attribute strings, or in feature flags — dissolve into a simple answer: the policy easiest to test is the one that will actually be correct.

• Keep the role list in a single constants file and reference it from the seeder, the policies, and any UI dropdowns so a rename never goes out of sync.
• Prefer policies over inline role strings on every public surface and treat raw [Authorize(Roles = "...")] as a code smell to refactor during the next sprint.
• Make the role seeder idempotent and reentrant so it survives container restarts and geo-failover between Australian regions without manual intervention.
• Log every authorization decision with a UTC timestamp and a stable policy name, then render timestamps in the viewer's zone to keep the experience sane for staff who fly between Perth and Sydney in the same week.
• Cover each custom policy with at least one positive and one negative unit test before it lands in the main branch.