How to set ApplicationContext.User in a background/non-HTTP execution context for multitenancy?

[bashinamwila]

Environment

• CSLA.NET 10.0.0
• Blazor Wasm (InteractiveAuto render mode)
• .NET 10

---

Background

We have a multitenant Blazor application built on CSLA.NET. Our TenantResolver
reads the TenantId claim from ApplicationContext.User to scope every data portal call
to the correct tenant. This works perfectly inside the Blazor UI — ApplicationContext.User
is fully populated with the authenticated user's ClaimsPrincipal and the tenant resolves
correctly on every data portal call.

---

The Problem

We have a background processing component that runs outside the Blazor/HTTP pipeline.
It receives work requests via a REST API, processes them in its own execution context, and
calls back into our CSLA business objects through the data portal.

When our CSLA business objects execute inside this background component,
ApplicationContext.User is an empty anonymous ClaimsPrincipal — zero identities,
zero claims. This causes our TenantResolver to fail because it cannot find the TenantId
claim, and all data portal calls are effectively unauthorised.

This makes sense — there is no HttpContext in this background execution context, so CSLA
has nothing to populate ApplicationContext.User from automatically.

---

What We Know About the Execution Context

• The background component has its own DI container scope, separate from the Blazor
  circuit scope.
• It can resolve services from DI — including ApplicationContext.
• It receives each work request as a JSON payload sent from the Blazor UI via REST.
• We control both sides — the Blazor UI that sends the request and the background component
  that processes it.

---

Our Current Approach

Since we control both sides, our current approach is to serialise the user's claims into
the JSON payload on the Blazor side and deserialise them on the background side, then
manually set ApplicationContext.User before making any data portal calls:

Blazor side — serialise the ClaimsPrincipal into the request payload

public class SerializedClaim
{
    public string Type  { get; set; } = "";
    public string Value { get; set; } = "";
}

public class WorkflowClaimsBag
{
    public string UserId   { get; set; } = "";
    public string TenantId { get; set; } = "";
    public List<SerializedClaim> Claims { get; set; } = new();

    public static WorkflowClaimsBag FromPrincipal(ClaimsPrincipal user) => new()
    {
        UserId   = user.FindFirst(ClaimTypes.NameIdentifier)?.Value ?? "",
        TenantId = user.FindFirst("TenantId")?.Value ?? "",
        Claims   = user.Claims
            .Select(c => new SerializedClaim { Type = c.Type, Value = c.Value })
            .ToList()
    };

    public ClaimsPrincipal ToClaimsPrincipal() =>
        new(new ClaimsIdentity(
            Claims.Select(c => new Claim(c.Type, c.Value)),
            authenticationType: "BackgroundTransfer"));
}

We capture the bag in OnInitializedAsync while the Blazor circuit's AuthenticationState
is still live:

var authState = await AuthStateProvider.GetAuthenticationStateAsync();
_claimsBag = WorkflowClaimsBag.FromPrincipal(authState.User);

And include it in every request payload sent to the background component:

var payload = new
{
    ClaimsBag = _claimsBag,
    Data      = new { /* form fields */ }
};

Background component side — rehydrate and set ApplicationContext.User

// Deserialise the ClaimsBag from the incoming JSON payload
var bag = JsonSerializer.Deserialize<WorkflowClaimsBag>(claimsBagJson);

// Reconstruct the ClaimsPrincipal
var principal = bag.ToClaimsPrincipal();

// Set it on CSLA's ApplicationContext before any data portal call
var appContext = serviceProvider.GetRequiredService<ApplicationContext>();
appContext.User = principal;

// Now data portal calls work — TenantResolver finds the TenantId claim
var employee = await portal.CreateAsync();

---

Our Questions

1. Is manually setting ApplicationContext.User before data portal calls the correct
   and supported approach for a background/non-HTTP execution context in CSLA 8? Or is
   there a more idiomatic way to inject the ClaimsPrincipal for the duration of a
   background operation?

2. Is ClaimsIdentity with a custom authenticationType string sufficient for CSLA's
   authorization pipeline to treat the user as authenticated? We are currently using
   "BackgroundTransfer" as the authentication type string. Will CSLA's IsInRole,
   object-level authorization rules, and property-level authorization rules all behave
   correctly given this identity?

3. Is there a CSLA-native mechanism we should be using instead — for example, a way
   to configure a custom IPrincipal provider that the ApplicationContext uses in
   non-HTTP scopes?

4. Are there any thread-safety concerns with setting ApplicationContext.User in a
   background scope where multiple work items may be processing concurrently? Does each
   DI scope get its own ApplicationContext instance, or is there shared state we need
   to be aware of?

---

Summary

The core question is: what is the correct CSLA pattern for propagating a known,
authenticated ClaimsPrincipal into a background processing scope that has its own DI
container but no HTTP context?

We want to make sure we are not working against the framework. Any guidance from the
community would be greatly appreciated.

[rockfordlhotka]

This isn't a problem unique to CSLA. It is something people have to solve with angular, react, or any scenario where code running on the client device calls an API on a server, where there's no automatic authentication from the client to the server.

The most common solutions are JWT tokens or API keys - either one of which generally gets passed from the client to the server via the HTTP header so aspnetcore middleware (not your business code - before your business code) can verify the inbound token before allowing the call to be processed on the server.

Where your client code gets that token - now that's the trick. Usually a JWT comes from an oauth process, where the user logged into the app using some oauth workflow through Entra Id, Google, etc.

If you are using API keys, those are usually created via some admin web site and provided to each client that calls the server. This isn't a great user experience in most cases, at least as compared to the more common oauth process.