Blazor Web Assembly Authentication and Authorisation

[adrianwright109]

Hi,

I have taken the CSLA Blazor Web Assembly sample from this repo and have started creating a new app with it.

I now need to add Authentication and Authorisation to the application but not sure the approach to take.

I know that when creating a new non CSLA based Blazor Web Assembly app from the template built into Visual Studio you can add Authentication (additional tickbox) which will add the ASP.NET Core Identity.

This would be my preferred method as it handles a user registration, login, forgotten passwords etc.

It's working out how that will work with CSLA as I want to be able to authenticate a user and once authenticated then be able check which roles/permissions that user has.

Ideally the permission checks should be available in the Blazor Client and Sever e.g. (in a Blazor component as well as in the CSLA DataPortal API / Fetch methods).

I have a rough idea that Jwt tokens will need to be sent in the headers on a request from the Blazor client to the DataPortal API.

My plan is to create a new Blazor Web Assembly app using the default template in Visual Studio and then compare that project to the CSLA Blazor Web Assembly sample app I've been working on to work out the difference and try and retro fit ASP.NET Identity into my app.

Anyone had experience of doing this?

[rockfordlhotka]

The problem space is illustrated by this diagram.

Your client will have a ClaimsPrincipal as a result of the client-side authentication. Presumably your authentication process will have fully populated that principal (actually its ClaimsIdentity) with all the user's claims (roles, etc.) so you can use authorization rules in your business layer code.

When you make a data portal call to the app server, the app server also needs that ClaimsPrincipal and its identity (with the claims). So the question is: how do I either transfer the client-side principal to the server, or how do I have the server recreate the principal on each request?

There are a couple primary models to consider.

First, you can let the data portal do the work for you, because if there's a current principal on the client, it can flow that principal to the server with each data portal call, and the server-side data portal will make sure that principal is set on the server thread before the server-side data portal does any work.

Second, you can not have the data portal flow the principal to the server, in which case it is up to you to tell the server about the user identity on each data portal call. That can be done using tokens, an arbitrary value in the http request header, or many other ways. It is then up to you to write server-side code to intercept that identity indicator and create a principal object on the server for use on that data portal request thread.

The easiest approach is to let the data portal do all the work. The downside is that it will serialize the principal/identity pair from client to server, and if your identities have a lot of claims that can add bulk to the byte stream from client to server. If you don't tend to have a ton of claims, then it might be the best answer.

The harder approach is to write the infrastructure yourself that passes a user identity indicator (I'd say token, but that word is overloaded in this context, because it doesn't need to be a token, just a token 😄 ). Whatever indicator value you send will be handled by the app server either before calling the data portal, or in a custom IAuthorizeDataPortal provider. Your server-side code will take that indicator value and use it to retrieve the user's claims from a database or somewhere, create a ClaimsPrincipal and ClaimsIdentity, set that as the current user on the server, and let the data portal work as normal from there.

[adrianwright109]

First, you can let the data portal do the work for you, because if there's a current principal on the client, it can flow that principal to the server with each data portal call, and the server-side data portal will make sure that principal is set on the server thread before the server-side data portal does any work.

How do I go about getting the DataPortal do the work for me and flow the Principal from the client through to the server?

[rockfordlhotka]

I believe that is the default behavior, though I haven't had my ☕ yet this morning. There is a data portal config setting as to how it handles authentication, and the default (iirc) is "Csla", which means the data portal flows the ApplicationContext.User value to the server.

[adrianwright109]

@rockfordlhotka - you're right it does just work, although I had to add

        public static async Task Main(string[] args)
        {
             ...

            // detect when the authentication state changes, and update Csla ApplicationContext.User
            var authStateProvider = host.Services.GetRequiredService<AuthenticationStateProvider>();
            authStateProvider.AuthenticationStateChanged += AuthStateProvider_AuthenticationStateChanged;

            await host.RunAsync();
        }

        private static void AuthStateProvider_AuthenticationStateChanged(Task<AuthenticationState> task)
        {
            var cslaPrincipal = new Csla.Security.CslaClaimsPrincipal(task.Result.User);
            ApplicationContext.User = cslaPrincipal;
        }
    }