Blazor WASM - Upgrading from CSLA 6 to CSLA 8 - Setting ApplicationContext User throws Not Supported Exception

[saulyt]

I have a Blazor WASM app that I am upgrading CSLA 8. I use AddMsalAuthentication to setup login with Azure AD and AddAccountClaimsPrincipalFactory to set a custom ClaimsPrincipalFactory. In my claims principal factory, I am overrideing the CreateUserAsync method and setting the ApplicationContext as such

ApplicationContext appcontex = _serviceProvider.GetService<Csla.ApplicationContext>();
appcontex.User = user;

This code throws an unsuported exception in when I attempt to upgrade to CSLA 8. If I remove the line that sets the user everything works, but I then lose the user when I navigate from one page (component) to the next.

I assume this somehow relates to this but I don't really understand that discussion and also that was not a WASM app.

What would be the correct way to set the user in a CSLA 8 Blazor WASM app so that I would not lose the identity after the initial login?

For clarity as to what I am doing here is the entire method:

        public async override ValueTask<ClaimsPrincipal> CreateUserAsync(TAccount account, RemoteAuthenticationUserOptions options)
        {
            var user = await base.CreateUserAsync(account, options);
            if (account != null)
            {
                var identity = user.Identity as ClaimsIdentity;
                if (_appUser == null)
                {
                    var userPortal = _serviceProvider.GetService<IDataPortal<User>>();
					_appUser = await userPortal.FetchAsync(User.GetEmailAddress(identity));
				}
                if(_appUser != null)
                {
                    ApplicationContext appcontex = _serviceProvider.GetService<Csla.ApplicationContext>();
                    appcontex.User = user;
                    foreach (var claim in _appUser.Claims)
                        identity?.AddClaim(new Claim(claim.ClaimType, claim.ClaimValue));
                }
            }
            return user;
        }

[rockfordlhotka]

The reason CSLA no longer allows setting the User or Principal properties in Blazor webassembly is because the only way to reliably maintain the user principal in that runtime is through the use of an AuthenticationStateProvider. Specifically, a custom provider, and so there's no standard API by which CSLA can set the principal into an unknown implementation of this provider.

Here's an example of a custom AuthenticationStateProvider: https://github.com/JasonBock/BlazorTopToBottom/blob/main/src/Rocky/BlazorAuthentication/BlazorAuthentication/BlazorAuthentication.Client/ServerAuthenticationStateProvider.cs

In that example, the provider is calling a server endpoint to get the user principal object on request. How you authenticate the user and where you create that authenticated ClaimsPrincipal/ClaimsIdentity pair can vary a lot, and that's why there's no way for CSLA to set the value.

fwiw, I talk about this in my VS Live Blazor talks and in my online Blazor class.

[saulyt]

@rockfordlhotka, thank you for the reply. When reading the upgrade guide, I was under the impression that the state management controller was needed for the new Blazor Interactive app. I did not realize that it applies to the old Blazor WASM app. I added a CslaStateController to my Web API project and I now receive an error "Unable to resolve service for type 'Csla.State.ISessionManager'" when attempting to activate the CslaStateController. The samples Blazor projects do not seem to be using a standalone Web API. They call AddServerSideBlazor which seems to wire up the ISessionManager. Can you offer any guidance when using a standalone Web API. Do I now need to add CSLA.Blazor to the Web API to get this to work?

[rockfordlhotka]

I'm not talking about a state controller or state manager - those should be left alone.

I'm talking about a custom AuthenticationStateProvider, which is part of Blazor authentication.

[saulyt]

Thanks @rockfordlhotka , I totally misunderstood you.
I'm really struggling with how this should work. The user is logging in via Azure Entra ID which is setup via the call to AddMsalAuthentication. If I add a custom AuthenticationStateProvider to the project I get an InvalidCastException consistent with this stack overflow issue. Exception aside, I'm not at all clear on how the custom AuthenticationStateProvider would work with the Azure Entra ID login. The whole thing is fuzzy. It seems that the custom account factory is still the recommended way to customize a user when using Azure Enrtra ID with Blazor WASM. Is there a way to get these custom claims to stick in CSLA?

[saulyt]

Sorry, never mind. This started working without a custom AuthenticationStateProvider and without setting appcontex.User = user in the ClaimsPrincipalFactory. I don't know why it started working. Perhaps updating CSLA from 8.2 to 8.2.2 🤷‍♂️.

[rockfordlhotka]

It could be something we fixed or changed in CSLA.

It is also the case that CSLA doesn't manage the user principal at all. It relies entirely on the underlying ASP.NET Core and Blazor infrastructure, so if you have Blazor set up correctly then CSLA will work.