Question about getting/setting Claims in ClaimsPrincipal using extension methods

[GreatBarrier86]

Hi All,

According to this link (#2806 (reply in thread)), Rocky recommends creating extension methods for getting/setting claims since we can no longer create our own ClaimsPrincipal classes.

The quote is "Therefore, as a strategy, you should use ClaimsPrincipal and ClaimsIdentity as they are, and put any custom data you need into Claims. You can then direct access those Claims, or use extension methods to make it a little easier within your code."

My issue with that is that while it's fine to store primitive types in Claims, it becomes a problem when you have to store complex types, such as CSLA classes. This would require the use of the MobileFormatter, which now requires an ApplicationContext in the constructor. We have several MobileDictionary<> properties that we converted into Claims, but obviously those can't set directly into Claim.

So the options i see are as follows:

1. Change the extension methods to operate off of ApplicationContext, which would work but is slightly peculiar because really, Claim access belongs on the Principal.
2. Pass in the ApplicationContext as a parameter in the extension method, which would also be pecuilar because you'd be doing this.ApplicationContext.User.GetMyClaim(this.ApplicationContext)

Or possibly I have a fundamental misunderstanding of how this should work?

[rockfordlhotka]

You can't store anything other than primitive types in a ClaimsIdentity. afaik the type only supports basically storing string values as a claim.

I haven't given any thought to more complex types that might be "part of a claim".

My first instinct is to suggest that the claim would provide the key necessary to retrieve any more complex object. You'd only retrieve the complex object in the case that an authorization rule is executing to check the claim, and so you'd get the complex object within the rule's execute method.

[GreatBarrier86]

My issue with your suggestion is that if we have, for instance, 10 complex-type properties on our old ClaimsPrincipal implementation. Within those 10 properties, each class has 5 properties, and so on. In your scenario, you'd be adding 50 additional extension methods AND you'd be losing any the ability to use any functions those 10 properties had defined in them.

Let's imagine one of those properties was a set of MobileList<UserSetting> that defines how a certain user defines the default parameters for their reporting requirements. When the user logs in, one of the sets of the login is to fetch all their settings, which we would then store in the Principal. Within UserSetting, you have the Name, Value, and Disabled properties. I can't see those being split out into primitive types in a reliable way.

My current implementation uses the AppCtx and serializes it to a byte[], which I then convert to a Base64 string, and I have confirmed this does work, but it's awkward as hell. I think it's relatively clever implementation though :)

[StefanOssendorf]

A claim is not supposed to contain complex data just from a Claim perspective. I would suggest, too. To use a Claim with an identifier for example and fetch the necessary data seperatly after establishing identity.

[GreatBarrier86]

So, let's say we fetch the data like you said. This may be something we want to cache as it doesn't change per application instance. Where would you suggest we then store it? I'm willing to accept that some of our designs aren't as they should be, but even if we fetch it on-demand, we'd still need somewhere to store it on the context-level.

[StefanOssendorf]

It depends on the application you have. WPF, WinForms, Blazor? I'd probably use a singleton cache on the client side to have those data readily available.

[rockfordlhotka]

If you have a smart client scenario, you may want to look at the new client-side caching support we added in CSLA 8.

There's a simple example in the current ProjectTracker.

[GreatBarrier86]

There is one mobile app, two asp.net ones, and one WinForms one. I wonder if skipping the Claim implementation and using Rocky’s client side caching support is better.

@rockfordlhotka, does that support our multi client implementation?

[rockfordlhotka]

The client-side cache is something you configure in the client-side data portal. The client-side data portal routes all operations through a cache handler, and that handler can either delegate to the normal data portal pipeline or can return the value from the cache.

It works on any client technology, though implementing the cache on a shared server "client" (like aspnetcore) would be a little trickier than on a smart client (which is inherently single user).

The trick with aspnetcore, of course, is that you probably need to externalize the cache from the web server so it is available from your server cluster, and also ensure that the cache data is per-user using some per-user identifier.

[rockfordlhotka]

The thing that occurs to me, is that you already have some way to rehydrate your identity object on the web server right? So you can probably just use that as the location to retrieve the cached values.

[StefanOssendorf]

This is a part of the in memory cache I'm using at work. Maybe it helps/gives ideas to implement yours: #3645 (comment)

[GreatBarrier86]

I think that's probably the only workable way. thank you.