Pull request overview

This PR overhauls the claim-based authorization documentation set to align terminology (“claim-based”), focus the main article on Blazor (Razor component) scenarios, and add dedicated MVC and Razor Pages variants with updated navigation.

Changes:

• Reworked the main claim-based authorization article to use Blazor-focused examples and added cross-links to new MVC/Razor Pages versions.
• Added new MVC and Razor Pages claim-based authorization articles under their respective security/authorization nodes.
• Updated ToC entries and adjusted “claims-based” → “claim-based” wording in related authorization docs.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 10 comments.

Approved with some minor suggestions. Looks great. Note the issue on "Founders" vs "Founder" for the policy code vs the text referring to it.

... and @halter73 should look at that bit to make sure that I'm stating it correctly. The 🧀 moves a bit among BWA, Blazor Server, and MVC/RP. I think what I have is correct based on project template API; however, it's a little tricky given the deltas.

Yes, the guidance is correct. I confirmed in the aspnetcore source that WebApplicationBuilder.ConfigureApplication() auto-adds UseAuthorization() when IAuthorizationHandlerProvider is registered, and this has been the behavior since .NET 8. So BWAs (which are .NET 8+) don't need an explicit call. The guidance to still call it explicitly for Blazor Server apps is technically redundant for .NET 8+ (since Blazor Server also uses WebApplication), but it's not harmful, calling it twice is a no-op due to the dedup check, and being explicit about middleware ordering is good practice for Blazor Server apps that may be migrating from older patterns.

Note @halter73 that I'm adding a bit Blazor WASM stating that AddAuthorizationCore is called in the Program file. The rubber 🦆 says to add it to the Roles article, too, because our Blazor WASM with Identity sample adds it and has attributes for role-base auth (e.g., @Attribute [Authorize(Roles = "Editor")]). I assume thus far that I'm stating the correct guidance on it ... it's needed for role- and claim-based authz (and any other authz) in Blazor WASM apps.

Yes. Blazor WASM runs client-side and doesn't have the ASP.NET Core server-side middleware pipeline. AddAuthorizationCore registers the core authorization services (IAuthorizationService, IAuthorizationPolicyProvider, etc.) without the policy evaluation middleware.

If a Lookup<> is preferred anyway, and perhaps we'll yield to @halter73 to make the call, then I'll update the seeding code in the sample app, which has no bearing on the article content. Here are the new bits in the sample app ...

Either is fine. List<KeyValuePair<>> is straightforward and appropriate for iterating claims into a user's identity. Lookup<> would be overkill for this scenario. No change needed.

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 9 comments.

## Claim case sensitivity

Claim *values* are compared using [`StringComparison.Ordinal`](xref:System.StringComparison?displayProperty=nameWithType). This means `Admin` (uppercase `A`) and `admin` (lowercase `a`) are always treated as different roles, regardless of which authentication handler created the identity.

Separately, the claim *type* comparison (used to locate role claims by their claim type, such as `http://schemas.microsoft.com/ws/2008/06/identity/claims/role`) may be case-sensitive or case-insensitive depending on the <xref:System.Security.Claims.ClaimsIdentity> implementation. With `Microsoft.IdentityModel` in ASP.NET Core 8.0 or later (used by <xref:Microsoft.Extensions.DependencyInjection.JwtBearerExtensions.AddJwtBearer%2A>, <xref:Microsoft.Extensions.DependencyInjection.OpenIdConnectExtensions.AddOpenIdConnect%2A>, <xref:Microsoft.Extensions.DependencyInjection.WsFederationExtensions.AddWsFederation%2A>, and <xref:Microsoft.Identity.Web.AppBuilderExtension.AddMicrosoftIdentityWebApp%2A>/<xref:Microsoft.Identity.Web.AppBuilderExtension.AddMicrosoftIdentityWebApi%2A>), <xref:Microsoft.IdentityModel.Tokens.CaseSensitiveClaimsIdentity> is produced during token validation, which uses case-sensitive claim type matching.