Example of using Client Side Blazor with Identity and CSLA

[mtavares628]

I'm wondering if someone could provide an example of how to connect up the client side CslaUserService with the ClaimsPrincipal using .NET Core Identity. I've seen the client side authentication example in the Blazor book as well as the ProjectTracker application where the Login page is on the client, it uses the dataportal to call the data access layer to get the user and role info, and then takes that info and generates the ClaimsPrincipal on the client side and assign it to the UserService.

I was also looking at what the Client Side Blazor template does when you add authentication when creating the solution. It generates the login page on the app server (similar to server side Blazor) and will use the SignInManager of the Identity framework to perform the login.

What I can't wrap my head around is how I could utilize the Identity Framework on the server to send that ClaimsPrincipal back to the client if I were to utilize the template's server side login functionality. I'd like to take advantage of some of the built in functionality of Identity (like Lockout and 2FA) rather than rolling my own by building upon the ProjectTracker example.

Any help would be greatly appreciated. Thanks.

[rockfordlhotka]

I do have a server-side Blazor project that uses the aspnet user database concept.

I don't have a client-side Blazor project that does this.

I think the important thing is to understand the purpose of the AuthenticationStateProvider and user service.

Blazor doesn't rely on the thread's CurrentPrincipal or HttpContext to maintain the user's identity. Instead, they externalized that concept to your AuthenticationStateProvider. By convention, that provider typically relies on some sort of user service.

The CslaAuthenticationStateProvider and CslaUserService are very simple implementations of these concepts to support the simplest scenario, relying on Csla.ApplicationContext.User to maintain the current user identity in memory.

At the end of the day, CSLA itself relies on Csla.ApplicationContext.User having the current user identity. If the user principal is stored elsewhere (like in some other user service), then you need to create a custom CSLA application context manager that gets/sets the principal from that user service instead of using the default CSLA behavior.

[rockfordlhotka]

The MobileFormatter (recently) includes support to identify that a ClaimsPrincipal is in the object graph, and to serialize it. I'm pretty confident that this works, as it is used in the CslaAuthentication example in my Blazor book. The live code in that repo has been upgraded to .NET 5 and a 5.4.0 prerelease of CSLA (I still need to update it to the 5.4.0 release).

Update: OK, so looking at the sample, it doesn't actually have any functionality to try and transfer the principal through the data portal from client to server.

ProjectTracker does though, because it is a complete implementation, and the Blazor wasm client does rely on ClaimsPrincipal.

[mtavares628]

And I'm actually following the ProjectTracker model as a workaround. What I was trying to do was go in the opposite direction. Create the ClaimsPrincipal in the Dataportal on the Server side and send it back down as a property on the UserDto. So my UserDal looks like this:

public class UserDal : IUserDal
    {
        private readonly SignInManager<DadUser> _signInManager;

        public UserDal(SignInManager<DadUser> signInManager)
        {
            _signInManager = signInManager;
        }

        public UserDto Fetch(string username, string password, int advocacyGroupId)
        {
            // Combine to inject both the username and the advocacy group into the username field
            string usernameAndGroup = string.Format("{0}|{1}", username, advocacyGroupId);
            var result = _signInManager.PasswordSignInAsync(usernameAndGroup, password, false, lockoutOnFailure: false).Result;

            if (result.Succeeded)
            {
                var user = _signInManager.UserManager.FindByNameAsync(usernameAndGroup).Result;
                if (user != null)
                {
                    var roles = _signInManager.UserManager.GetRolesAsync(user).Result;

                    var principal = _signInManager.CreateUserPrincipalAsync(user).Result;
                    
                    return new UserDto
                    {
                        AdvocacyGroupID = advocacyGroupId,
                        Username = username,
                        EmployeeID = user.Id,
                        Roles = roles,
                        Principal = principal
                        
                    };
                }
                else return null;
            }
            else return null;
        }

        public UserDto Fetch(string username)
        {
            throw new NotImplementedException();
        }
    }

And then the fetch in my CredentialValidator looks like:

[Fetch]
        private void Fetch(Credentials credentials, [Inject] IUserDal dal)
        {
            var data = dal.Fetch(credentials.Username, credentials.Password, credentials.AdvocacyGroupID);
            if (data != null)
            {
                AuthenticationType = "Identity.Application";
                UserPrincipal = data.Principal;
                Name = data.Username;
                AdvocacyGroupID = data.AdvocacyGroupID;
                EmployeeID = data.EmployeeID;
                Roles = new MobileList<string>(data.Roles);
            }
        }

And the Login.razor LoginUser method just sets the CslaUserService user to the returned principal instead of creating it on the client side like the Project Tracker does:

 private async void LoginUser()
    {
        vm.Model.AdvocacyGroupID = 1;
      var validator =
        await Csla.DataPortal.FetchAsync<CredentialValidator>(vm.Model);
      var principal = validator.UserPrincipal();

      if (principal.Identity.IsAuthenticated)
      {
        userService.CurrentUser = principal;
        NavigationManager.NavigateTo("/");
      }
      else
      {
        ErrorText = "Invalid credentials";
        StateHasChanged();
      }
    }

Am I just totally wrong in thinking that the DataPortal would serialize the ClaimsPricipal going in the other direction?

[rockfordlhotka]

I see what you are saying.

It should be the case that MobileFormatter can serialize ClaimsPrincipal - though I know there's a bug with netfx (so if your server is .NET 4.x it won't work). It should work if your client is Blazor and server is netcore or net5.

Of course there could be a bug 😳

[mtavares628]

My server is currently netcore3.1. I'll try updating everything to net5 and see if it's still an issue. I'll let you know how I make out. Thanks.

[rockfordlhotka]

Hmm. So I added this test

  [TestClass]
  public class ClaimsPrincipalTests
  {
    [TestMethod]
    public void CloneClaimsPrincipal()
    {
      Configuration.ConfigurationManager.AppSettings["CslaSerializationFormatter"] = "MobileFormatter";
      var i = new ClaimsIdentity();
      i.AddClaim(new Claim("name", "Franklin"));
      var p = new ClaimsPrincipal(i);
      var p1 = (ClaimsPrincipal)Core.ObjectCloner.Clone(p);
      Assert.AreNotSame(p, p1, "Should be different instances");
      Assert.AreEqual(p.Claims.Count(), p1.Claims.Count(), "Should have same number of claims");
      var c = p1.Claims.Where(r => r.Type == "name").First();
      Assert.AreEqual("Franklin", c.Value, "Claim value should match");
    }
  }

And it passes, thus establishing that MobileFormatter does correctly serialize a ClaimsPrincipal as it should.