Custom Authentication & Authorizaton in Blazor 8 & Csla 8.2.0

[ecaldentey]

Hello,

In a Blazor .NET 8 project with CSLA 8.2.0, what is the recommended approach to implement custom authentication and authorization for the various types of interactivity that Blazor 8 allows?

In the ProjectTracker project, there is an implementation, but it is not documented and uses a custom CSLA implementation which I understand is server-based with SignalR, am I correct?

Can JWT or another mechanism be used?

My idea is to be able to use my database tables that I query through stored procedures executed from the DAL, which in turn is invoked from CSLA BusinessClasses, and I would like to maintain this method of authenticating my users.

How can I use the security incorporated in CSLA to use, for example, JWT? Is there documentation for the security incorporated in CSLA 8.2.0?

Any guidance on this matter would be appreciated.

Thanks.

[rockfordlhotka]

I've been too busy solving the problems and testing to make sure they work to document much yet - beyond my blog.

ProjectTracker is using the standard aspnetcore/Blazor authentication mechanism. It is the same technique from .NET 6/7, but it is much easier to implement in Blazor 8 because we now have access to server-static pages.

The Login and Logout pages are server-static pages, which means that they can use HttpContext. Because they can use HttpContext, they can use the standard aspnetcore sign in and sign out APIs.

The only CSLA part of the code is that a business object is used to verify the credentials - on the server.

CSLA does provide some extra functionality for the WebAssembly client, because Blazor doesn't automatically provide wasm-interactive pages with access to the user principal/identity. The new session state management features in CSLA 8 that enable the use of LocalContext and ClientContext across all the render modes in Blazor 8 (including wasm-interactive) also includes the ability to flow a copy of the user principal/identity from the server to a wasm client.

When this happens, the server-side ClaimsPrincipal is "cloned" to the wasm client. The real principal is managed by aspnetcore on the server - having nothing to do with CSLA. However, with a copy of the principal/identity available on the wasm client, this means your authorization business rules (in your business classes and in Blazor itself) work as expected in your wasm-interactive pages.

[rockfordlhotka]

Regarding the use of a JWT, I think @TheCakeMonster might be a better person to answer than me. I haven't explored using a JWT with Blazor 8.

I am guessing that you would

1. Have the user log into the aspnetcore server (like in ProjectTracker)
2. As part of that login process you'd create a JWT (????)
3. The JWT could be added as a claim to the user's ClaimsIdentity (????)
4. CSLA can ensure that the user's identity is cloned to the wasm client
5. The wasm client can use the JWT from the identity to call your app server (????)