Csla 6 example of a Custom CslaClaimsPrincipal and ClaimsIdentity

[swegele]

Wondering if anyone has an example of these. I'm a little unclear how to migrate my old Csla 5 custom Identity which simply inherited from ReadOnlyBase and implemented IIdentity. I didn't find anything in the demo projects unless I missed it.

I see there is the Csla.Security.ICslaIdentity interface, but I got a little overwhelmed when I see all the stuff that would need to be implemented because of the three interfaces it is to implement:

public interface ICslaIdentity
  : IReadOnlyBase, IIdentity, ICheckRoles 

I also see the CslaClaimsPrincipal but that confuses me too because it implements Csla.Serialization.Mobile.IMobileObject but the methods are empty so I didn't know if this is like some stub and I'm supposed to know what to do with it:

protected CslaClaimsPrincipal(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context)
  : base(info, context)
{ }

void IMobileObject.GetChildren(SerializationInfo info, MobileFormatter formatter)
{ }

void IMobileObject.GetState(SerializationInfo info)
{ }

void IMobileObject.SetChildren(SerializationInfo info, MobileFormatter formatter)
{ }

void IMobileObject.SetState(SerializationInfo info)
{ }

EDIT : Followup question or perhaps even more relevant to first is, if you were upgrading to Csla 6 and you had extensively used a custom Principal and Identity previously (not claims type) with all kinds of helpful properties about the user, then where would you put that stuff now to play nice with the ClaimsPrincipal and ClaimsIdentity. My thought was to simply make my own that extends those types with my extra stuff. But maybe that's bad. I suppose I could keep the main CP and CI parts simple and make a ReadOnlyBase object that holds all my custom stuff and stick it in ApplicationContext.ClientContext so that it would flow up and down the portal?

[JacoJordaan]

I have rewritten my identity classes without using any of the csla identity classes as per Rocky's example.
I have found this to be the easiest solution.
I still have a Principle class, but this is just a factory class.

[swegele]

@JacoJordaan the more I think about this and read, the more I agree that sticking with a basic ClaimsIdentity is the way to go like you.

But I'm still left with the question of where do I put my "Other user details" object (which is likely a ReadOnly object) that holds all the important and oft accessed properties. It would feel hacky to stuff json versions of these things into claims. I "could" :

1. Store as a property on my custom CslaClaimsPrincipal but I'm not sure what I would have to do if anything to implement IMobileObject. Does proper serialization automatically come with the CslaClaimsPrincipal or do I need to implement it (given those 5 empty methods I mentioned above)?
2. Store in ApplicationContext.ClientContext and access it there when I need it, and delete it from there when user logs off

Thoughts anyone?
Just to clarify, Yes I'm aware of the extra baggage this adds to the payload size in a DataPortal serialization operation. We only use the LocalPortal so this is negligible. We've already been using this for years and it works great.

[JacoJordaan]

Here is the gist of how I do this:

Login method to fetch the data via dataportal. The identity object is a normal ReadOnly csla object:

        public bool Login(string username, string password, string userInfo)
        {
            _credentialsCriteria.SetCredentialsCriteria(username, password, userInfo);
            var identity = Portal.Fetch(_credentialsCriteria.GetCredentialsCriteria());
            return SetPrincipal(identity);
        }

The SetPrincipal method to create a new ClaimsIdentity and ClaimsPrincipal object and assign this to ApplicationContext.User:

        private bool SetPrincipal(CredentialValidator identity)
        {
            var baseidentity = new ClaimsIdentity(identity.AuthenticationType);
            baseidentity.AddClaim(new Claim(ClaimTypes.Name, identity.Name));

            baseidentity.AddClaim(new Claim("UserId", identity.UserId));
            baseidentity.AddClaim(new Claim("FullName", identity.FullName));
            baseidentity.AddClaim(new Claim("CustomerId", identity.CustomerId));
            baseidentity.AddClaim(new Claim("CustomerUserId", identity.CustomerUserId));
            baseidentity.AddClaim(new Claim("ResponsibilityCenter", identity.ResponsibilityCenter));

            if (identity.Roles != null)
                foreach (var item in identity.Roles)
                    baseidentity.AddClaim(new Claim(ClaimTypes.Role, item));

            var principal = new ClaimsPrincipal(baseidentity);
            ApplicationContext.User = principal;

            return identity.IsAuthenticated;
        }
    }

[swegele]

Thanks @JacoJordaan , it helps to see that...and that is exactly where I ended up too 👍 (that is comforting)

• My new JTClaimsPrincipal will inherit from CslaClaimsPrincipal
• The JTClaimsPrincipal will use a normal ClaimsIdentity (populated from my legacy JTIdentity)
• The JTClaimsPrincipal will also have a custom property on it that keeps my legacy JTIdentity
• When Login is called, I will fetch a JTIdentity and create a ClaimsIdentity from copying the authtype, name, and roles from it

The only difference is I need to keep my old JTIdentity around somehow (It's so ubiquitously used I can't ditch it entirely). As a property of JTClaimsPrincipal, I can get access to all it's goodies.

Now I could put that object into ApplicationContext.ClientContext if need be, but it's cleaner if I can to have it on the custom claims principal because if that goes away (after Logoff) then so does all the identity stuff. I won't have to remember to clean up anything from app context.

So then, my only remaining question is, do I have to do anything special on JTClaimsPrincipal to handle the serialization of this property (through IMobileFormatter methods) or do I need to make that property look a certain way to facilitate this?
@rockfordlhotka I ask because there is a little custom logic around CslaClaimsPrincipal serializing/deserializing that I see in the MobileFormatter so I want to get this right.

[Serializable()]
public class JTPrincipal : Csla.Security.CslaClaimsPrincipal
{
...
    private JTIdentity _jtIdentity;
    public JTIdentity LegacyIdentity
    {
        get
        {
            return _jtIdentity;
        }
    }

[rockfordlhotka]

As an overall strategy, everyone should be moving from custom principal/identity pairs to ClaimsPrincipal and ClaimsIdentity. This is the direction Microsoft is going, and they are already there with aspnetcore and Blazor.

Custom values can be stored as claims in the identity, so you have what amounts to a dictionary of values you can store.

You can use extension methods on the ClaimsPrincipal or ClaimsIdentity types to make it easier for code to access those custom properties from the list of claims.

Csla.ApplicationContext.Principal is a new property that returns the current principal as a ClaimsPrincipal so you don't need to cast the User property all the time.

[swegele]

So are you saying we should not use Csla.Security.CslaClaimsPrincipal at all? Because it does inherit from ClaimsPrincipal. So I'm wondering where would the problem come in? I've done this and it works great in my app, so where is the gotcha. Maybe when using a remote data portal or ...?

And your suggestion is that if we have some extra objects we need to send with the principal / identity...that we should use extension methods to:

• Serialize the object into an Identity claim.
• Deserialize the object out of a claim when needed

[rockfordlhotka]

CslaClaimsPrincipal exists because ClaimsPrincipal can't be directly serialized, so MobileFormatter does some wrapping of ClaimsPrincipal into CslaClaimsPrincipal to serialize the principal/identity.

It won't hurt for you to use CslaClaimsPrincipal - but you'll find that some UI technologies (aspnetcore) will convert your type back to ClaimsPrincipal at some point, because they don't actually support subclasses of the type.

To be clear: you can not create custom subclasses of ClaimsPrincipal and expect them to work. Microsoft (for whatever reason) has chosen to hard-code the use of ClaimsPrincipal in some of their framework code, so subclasses get lost.

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.

There's no reason for you to ever use CslaClaimsPrincipal itself - it gets used behind the scenes by MobileFormatter.

[swegele]

Ahh ok that helps hearing the more detailed "why" part.

This is an important post for devs like me that think "Hey I can still use this or that" and it "kind-of" works (with a nasty treat later :-)
Perhaps an xml comment on CslaClaimsPrincipal with something bold like "NOT FOR DIRECT USE" and you could even link to an article?
Regardless, thank you again!