Blazor WebAssembly with IdentityServer and remote data portal.

[DuncanSpence]

I have a Blazor WebAssembly app using Identity Server that connects to a remote DataPortal (i.e. the DataPortal is running under a different web application from the Blazor CoreHosted application).
Everything is working well, except that my update templates on the DataPortal use the Csla.ApplicationContext.User.Identity to store details of the last user to update the record. From another post I've found that I have to prevent the user from flowing out by adding AuthenticationType("Windows") in the DataPortal configuration on the WebAssembly client, but because I'm using a remote DataPortal, no login takes place there and so the Csla.ApplicationContext.User is always empty.
Is there a way of flowing that data to the remote data portal, or do I need to do my final changes to the record before it leaves the WebAssembly app?

[rockfordlhotka]

Hi @DuncanSpence

CSLA doesn't generally manage the user principal itself, it relies on the underlying .NET platform to handle it. How .NET handles the principal is different per-platform. The Csla.ApplicationContext.User value adapts per-platform to abstract whatever .NET is doing in WPF, WinForms, aspnetcore, Blazor, etc.

The data portal, when in remote mode, defaults to serializing the principal from the calling process (client-side) to the server-side data portal. This can be turned off if you are doing your own impersonation, or allowing the underlying platform (like Windows) to do that work.

I'm providing this background to help tease apart what's necessary here.

Your client-side Blazor app typically needs the user principal/identity so it can run local role-based authorization rules. And it sounds like you do have the principal set in the client app right?

By default, every time the client invokes the data portal server, the data portal will flow the client principal to the server. You have disabled this via AuthenticationType, which means you've told CSLA that you (or the underlying platform) will handle the impersonation.

You have two choices. Either remove the AuthenticationType setting so CSLA does flow the principal to the server, or come up with your own mechanism to flow the principal to the server.

[DuncanSpence]

Thanks, when I was doing my first investigation I wasn't using a fully remote portal and I forgot that the rules change a bit when you're not going back to the .Net Core hosted part of the WebAssembly app. Removing the AuthenticationType from the client and the remote data portal does the trick for me.