Setting the Principal on ApplicationContext.User before DataPortal Executes (Http)

[MarkOverstreet]

We are trying refresh our claims before the remote DataPortal (server) executes. We tried implementing middleware which didn't work and we tried to implement a custom Interceptor based on the RevalidatingInterceptor, which didn't work.

We implemented a jwt token scheme that sends the token via the authorization header. Blazor WASM sets the header on each request to the server. When the DataPortal request is made, we want to inspect that token, update the roles (in case the roles might have changed) in a way that allows the DataPortal to Revalidate the business rules after we have updated the Principal.

Any ideas on the proper/recommended way to do this?

[MarkOverstreet]

The custom interceptor looked promising, but we couldn't figure out how to get the token out of the request header (tried injecting both IHttpContextAccessor and HttpContext) and it appeared to fire after the business rules have been checked and this could break functionality if the user's roles have changed.

[rockfordlhotka]

In your data portal controller on the server, have you tried overriding the PostAsync method so you can get the header and set the current user before calling base.PostAsync?

    public override Task PostAsync([FromQuery] string operation)
    {
      // do stuff here
      var result = base.PostAsync(operation);
      return result;
    }

[TheCakeMonster]

Another option is to deal with this in a custom middleware.

CSLA delegates authentication and authorization functions to the host, presumably in your case ASP.NET Core. ASP.NET Core offers the ability extend the pipeline, and so you could add a middleware that does the reload of the principal on your behalf, before CSLA even gets involved.

The advantage of this approach is that it works for ALL requests, including any that bypass the data portal - such as requests for static resources.

The middleware would interact with the HttpContext type's User property. Middleware is pretty easy to create. There are three approaches, I tend to implement the IMiddleware interface, but the other two options will work too. Your custom middleware would probably need to be registered between the UseAuthentication() and UseAuthorization() calls, so that the principal has been loaded for you, but not yet used by anything.

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-7.0

[MarkOverstreet]

Yeah, we started with the middleware approach (and others), but nothing worked until we found the code below. So ultimately, we went back to using middleware and this on both the client and the dataportal side.

builder.Services.AddCsla(cfg => cfg .DataPortal(dpo => dpo .AuthenticationType("Windows") ));

Here is the article for others to read ... https://blog.dotnotstandard.com/blog/csla-data-portal-security

[rockfordlhotka]

The AuthenticationType setting controls whether the data portal flows the principal/identity from the client to the server with each data portal call. Setting it to Windows prevents the value from flowing to the server, allowing (requiring) that you set the principal/identity on the server using some other means.

In CSLA 7 this changes. The AuthenticationType setting is gone, replaced with a more obvious setting that indicates whether the user identity should flow from client to server (thank you @TheCakeMonster). Also, in v7 the default is to NOT flow the identity, while in previous versions the default was TO flow the identity.