Migrating to ClaimsPrincipal/ClaimsIdentity

[ajohnstone-ks]

We now have our code compiling again against Csla 7 and I'm trying to get our integration tests working. I quickly hit an issue using the http portal, so am trying to run things locally instead to see if that at least works.

In trying to using just ClaimsPrincipal/ClaimsIdentity, I hit an unexpected issue. As part of our login code, we add two claims to the identity, an id and token which we use server side to get the login info. Initially ApplicationContext.LocalContext was being lost, so I configured the context manager to be ApplicationContextManagerStatic, which seems to have fixed that problem but now in our Authorizer code we get a ClaimsPrincipal with a null Identity (as so of course there are no claims).

Any ideas what might cause that? I am also using EnableSecurityPrincipalFlowFromClient so that the id/key claims mentioned earlier flow to the data portal server.

[StefanOssendorf]

Hi. Could you post the CSLA configuration snippets from your client/server please.

[ajohnstone-ks]

ServiceCollection.AddCsla(
				x => {
					x.PropertyChangedMode(ApplicationContext.PropertyChangedModes.Windows);
					x.RegisterContextManager<Csla.Core.ApplicationContextManagerStatic>();

					x.DataPortal(
						y => {
							y.EnableSecurityPrincipalFlowFromClient();
						}
					);
				}
			);

[ajohnstone-ks]

@StefanOssendorf On startup just setting ApplicationContext.User = new ClaimsPrincipal(new ClaimsIdentity). That was ok and it worked for calling our Login command, the issue was when we were back in logical client side code we'd attempt to set an id & key as claims, and the ApplicationContext.User has a ClaimsPrincipal with a null Identity, so the code blew up. To work around I detect this and reset it then add the claims, and things seem to work ok from then on.

Hmm I just looked at the changes referenced by that commit and it looks like its just the Csla tests, nothing in Csla actually changed, so I doubt that relates to my issue.

[StefanOssendorf]

I'll take a look tomorrow at work. We are setting the Csla user once and don't touch it until re-login.

[ajohnstone-ks]

@StefanOssendorf Well this particular issue isn't blocking us. It seems to happen after out login call round-trip, and I just detect it and set a new principal identity before trying to add the claims and then its fine. Are we supposed to set the principal on the server though if we are flowing the principal to the server? B/c we're just configuring the principal client side only right now.

[ossendorf-at-hoelscher]

We are doing this once on the client:

var principal = new ClaimsPrincipal(identity);
_applicationContext.Principal = principal;
_applicationContext.User = principal;

And do this in the client

.Security(s =>
{
    s.FlowSecurityPrincipalFromClient = true;
    s.AuthenticationType = cslaOptions.Authentication;
})

where the Authenticationtype = "Custom".

And on our server side we do this:

.Security(s =>
{
    s.AuthenticationType = "Custom";
    s.FlowSecurityPrincipalFromClient = true;
})

[ajohnstone-ks]

> var principal = new ClaimsPrincipal(identity);
> _applicationContext.Principal = principal;
> _applicationContext.User = principal;

We're doing that before we call the login command; when we come back we just add the claims to the identity

> .Security(s =>
> {
>     s.FlowSecurityPrincipalFromClient = true;
>     s.AuthenticationType = cslaOptions.Authentication;
> })

I don't see those off of the Security method; I'm on Csla 7. I think we are doing the equivalent although not setting AuthenticationType to custom, maybe that's my missing piece.

This is our client setup

ServiceCollection.AddCsla(
x => {
	x.PropertyChangedMode(ApplicationContext.PropertyChangedModes.Windows);
	x.RegisterContextManager<Csla.Core.ApplicationContextManagerStatic>();

	x.DataPortal(
		y => {
			y.EnableSecurityPrincipalFlowFromClient();
		}
	);
}
);

And server

services
.AddCsla(x => {
        // I tried this but it doesn't help either
	//x.RegisterContextManager<Csla.Core.ApplicationContextManagerAsyncLocal>(); 

        x.RegisterContextManager<Csla.Web.Mvc.ApplicationContextManager>(); 
	x.DataPortal(
		y => {
			y.EnableSecurityPrincipalFlowFromClient();
			
			y.AddServerSideDataPortal(
				z => {
					z.RegisterExceptionInspector<OurExceptionInspector>();
					z.RegisterAuthorizerProvider<OurDataPortalAuthorizer>();
				}
			);
		}
	);
});

[ajohnstone-ks]

Since my actual login command seems to work I'm going to close this.