Need ability to set the DataPorta.SetPrincipal in report portal

[CProsRodneyWorkman]

Is your feature request related to a problem? Please describe.
I am using .Net 7 Azure Functions and Azure Functions does not allow me to use JWT authentication instead it is using Azure AD by default. I have been unable to get my Identity into the .Net Identities. As a measure of last resort I validate my JWT token and created my principal object. When I attached the principal to the ApplicationContext I get the NoPrincipalAllowedException.

Describe the solution you'd like
I would like a remote configuration option to attach my principal object without using EnableSecurityPrincipalFlowFromClient.

Describe alternatives you've considered
I am unable to configure Azure Functions to .AddAuthentication and to .UseAuthentication so .Net will not process my Bearer token. That is what I tried. What I found is that in a Azure Function I have no option to hook into the request pipeline before the function actually starts so I am unable to UseAuthentiaction.

Additional context
Add any other context or screenshots about the feature request here.

[rockfordlhotka]

@CProsRodneyWorkman I have converted this to a discussion, because I don't think this is a missing feature of CSLA as much as it is figuring out how to accomplish your goal within the context of Azure Functions and CSLA configuration.

I haven't tried what you are doing, but can explain the basic expectations/behaviors of CSLA itself.

The data portal can be configured in two ways.

First and by default, the principal from the client doesn't flow to the server. This means that some code (yours? others?) has a way to flow the user identity from the client to the server. In this model, CSLA relies on the client and server environment to manage the user identity, and CSLA just picks up the identity from the environment.

Second, with EnableSecurityPrincipalFlowFromClient, the data portal serializes the principal from the client and sets the deserialized principal to be current on the server. This has very real security implications, which is why it isn't the default.

What I am hearing from your post is that you prefer the first option (which is good), and that you are having trouble passing the user identity from the client to the server using JWT when the server is hosted in an Azure Function.

This is why I've converted this to a discussion, because the core problem here is how to pass a user identity into an Azure Function and set the current principal in the function before your code (and CSLA) starts to execute.

I don't personally know the answer to this, but maybe someone else does?

[CProsRodneyWorkman]

Thank you for making this a discussion.

In my case my JWT authentication token is received in the header in the azure function server side.

What I am unable todo is to configure the middleware to "UseAuthentication" in Azure Function .net 7. Out of the box, Azure functions are configured to use Azure Ad for authentication.

As a work around I validated my own token, created my own principle object and tried to set the principle with the ApplicationContext. CSLA then threw an error as it did not allow the setting of a principle server side.

[rockfordlhotka]

The ApplicationContext relies on something called an IContextManager to manage the current principal (and some other things). This is because different .NET runtime environments store the principal in different locations (current thread, HttpContext, AuthenticationStateProvider, etc.).

I don't know for sure which context manager is being used within an Azure Function. It depends a lot on how you are configuring things within the services.AddCsla() call as your function starts up.

(I'm assuming CSLA 6+)

Without the exception stack trace it is hard for me to guess which context manager is being used and why it would fail.

Two things you can do:

1. Get the exception ToString result and post here
2. In your app, after you have the DI provider initialized in Program.cs, do this to find the type name of the context manager

var ApplicationContext = provider.GetRequiredService<ApplicationContext>();
var managerTypeName = ApplicationContext.ContextManager.GetType().AssemblyQualifiedName;

[CProsRodneyWorkman]

The error was "No principal object should be passed to DataPortal when using Windows integrated security"

The package I am using is "Csla.AspNetCore"

Below is how I configured CSLA:
IServiceCollection c = services.AddCsla(o => o
.AddAspNetCore()
.DataPortal(dpo => dpo
.AddServerSideDataPortal()
.UseLocalProxy()));

//here is how I attempted to set my principal.
var cprosPrincipal = CProsClaimsPrincipalFactory.GetPrincipal(authorizationToken);
_applicationContext.User = cprosPrincipal;

[rockfordlhotka]

This is using CSLA 7? Or something older?

We implemented a change (I think in CSLA 6 or 7) where the data portal does not, by default, pass the client-side principal to the app server, and the app server won't accept a principal passed from the client.

The exception you are reporting indicates that the client is configured to pass the principal to the server, and that the server is configured to NOT accept a principal from the client, so the configurations are out of sync.