Role claims guidance in standalone WASM w/Identity article

[guardrex]

Description

Add some basic guidance for the front-end (web API call) and setting up the web API on the backend with some dummy claims sent down. Then, the dev will merely need to flesh out the web API side given their user data store.

dotnet/blazor-samples#124 (comment)

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/standalone-with-identity?view=aspnetcore-8.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/security/webassembly/standalone-with-identity.md

Document ID

c4e6ec41-7bea-e600-6473-c5c870aab082

Article author

guardrex

[Ogglas]

It would be good with documentation similar to this: https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-identity-server?view=aspnetcore-7.0&tabs=visual-studio#name-and-role-claim-with-api-authorization

A lot of hosted Blazor apps with individual user accounts use this.

[famda-vestas]

I also need some guidance on this.
I'm looping around and not being able to flow the claims properly.

[guardrex]

I'm mired in cross-link updates for the new 8.0 BWA sample app that just went up this morning. I think it will take a couple of days to get all of these link updates in place. I might be able to reach this at the end of the week, but I can't make any promises on it given the workload right now. If you need assistance for your own implementation in the meantime, we recommend the usual public support forums for discussing code ...

• Stack Overflow (tag: blazor)
• ASP.NET Core Slack Team
• Blazor Gitter

If anything significantly delays my reaching this issue by the end of this week, I'll leave a comment here.

[guardrex]

I took a break from the snippet sample app work to START to get something in place for roles.

Now, I say "start" because I think the PU is going to need to work on it. I ran into some PITA JSON serializer problems with an ordinary Claims[] array, so I kind'a hacked 🙈 my way to making it work with plainer, less performant code.

Anyway ... the basics of the approach should be sound and are a good way to get the ball rolling.

The really good news thus far is that I'm also adding SEEDED DATA to the mix 🎉🕺💃🍻. NO more having to re-register a test user over and over ... and OVER 😠. I needed that because we want our user to be created with role claims for testing, so it fixes two needs in one shot ... test user(s) and test role claims.

🥁🥁🥁🥁🥁 plz ........

dotnet/blazor-samples#140

... and cc: @adrianjcalvert on this, who asked on dotnet/blazor-samples#124 about it.

[julioct]

Why limit this guidance to roles only? Roles are only one small subset of the many claims that a Blazor WASM client might need to use for authorization purposes.

There was something like this in the Identity endpoints implementation before:

group.MapGet("/manage/info", async Task<Results<Ok<InfoWithClaimsResponse>, ValidationProblem, NotFound>>
    (ClaimsPrincipal claimsPrincipal, UserManager<GameStoreUser> userManager) =>
{
    if (await userManager.GetUserAsync(claimsPrincipal) is not { } user)
    {
        return TypedResults.NotFound();
    }

    var email = await userManager.GetEmailAsync(user) ?? throw new NotSupportedException("Users must have an email.");

    var response = new InfoResponse(
        email,
        await userManager.IsEmailConfirmedAsync(user),
        claimsPrincipal.Claims.ToDictionary(c => c.Type, c => c.Value));

    return TypedResults.Ok(response);
})

But it was removed for some security reasons (for which I would love more details).

If this new example suggests returning the roles is OK, then we can also return all claims? Or is that not secure?

[guardrex]

AFAIK, all claims can be returned. I think Jeremy will say that it should be done like the PR does (or your example ☝️) from an API endpoint after authentication. I used the user's Claim collection, and you could easily just change this to return all of them or any subset you want. This particular case is specifically about roles, so I'm focusing the PR on that. I think that if it works as a good example for roles that devs can use this approach generally for other sets of claims or all claims ...

app.MapGet("/roles", (ClaimsPrincipal user) =>
{
    if (user.Identity is not null && user.Identity.IsAuthenticated)
    {
        var identity = (ClaimsIdentity)user.Identity;
        var roles = identity.FindAll(identity.RoleClaimType)
            .Select(c => 
                new
                {
                    c.Issuer, 
                    c.OriginalIssuer, 
                    c.Type, 
                    c.Value, 
                    c.ValueType
                });

        return TypedResults.Json(roles);
    }

    return Results.Unauthorized();
});

... and IDK if he'll want to do something different. I had trouble working with a Claim[] array directly. The JSON serializer was choking 💥 on me with no parameterless ctor for Claim. It's all explained out on the PR. Jeremy and/or Halter may have an approach to address that problem or have something completely different in mind.

We'll see how it plays out. As you see on the other issue, I'm more of HackRex™ 🦖 than a real security guru. I rely heavily on the product unit engineers to tell me when my code/remarks are going off the rails.