Month: November 2017

Static Initializers vs. Static Constructors

Static types generally have static member variables that need to be initialized before an instance of the type can be used. There are a couple of common ways to do that. A static constructor can initialize those variables before they are accessed. They are a good option when you need to have logic built into the initialization process. Static initializers are useful when you only have to allocate the static member.

        private static readonly WeatherMan _instance = new WeatherMan();
        static WeatherMan()
        {
            _instance = new WeatherMan();
        }

If there is a reasonable chance that initializing a member variable could result in an exception, you may want to consider using a static constructor. You can’t catch an exception from a static initializer, with a static constructor you can. If an exception occurs in a static constructor, your program will terminate with an exception. If the caller of the static constructor tries to catch the exception, future attempts to create an instance of the type will fail until the AppDomain is unloaded. Ouch. So the only real option is to catch the exception in the static constructor, and add some recovery logic.

ASP.Net Core Claims Authorization

What are claims?
One of the significant changes to .NET Core is how user’s identity is modeled. In the past, .NET used the IPrincipal interface to access who the current user of an application was. Microsoft is moving to a Claims based model, which should help solve the problems developers are currently facing.

At the heart of the matter, a claim is a key-value pair that tells something about the user. ASP.NET Core uses claims as a way to model identity information. Those claims could come from any number of sources, such as an identity server, database, or even local storage. A claim doesn’t describe what a user can do. It tells something about who the user is. Each claim consists of two string properties, a Type and a Value. Generally the Type property will be populated with constants from the ClaimsType class. It’s also important to know who is providing the claim, so an Issuer can be included in the constructor.

const string Issuer = "https://fansgatherhere.com";
var claims = new List<Claim>();
claims.Add(new Claim(ClaimTypes.Name, "Jeff", ClaimValueTypes.String, Issuer));

What is the difference between a ClaimsIdentity and a ClaimsPrincipal?
In many ways, a ClaimsIdentity is like a passport. A passport can have information such as name, height, age, and a photo. Each piece of information is analogous to a claim. To create a new identity, we need to provide the constructor with an authentication type, then add the list of claims. The authentication type is just a string to remind you of what is required for the used to prove their identity.

var userIdentity = new ClaimsIdentity("SuperSecureLogin");
       userIdentity.AddClaims(claims)

With the ClaimsIdentity created, we can move on to the ClaimsPrincipal. 

var userPrincipal = new ClaimsPrincipal(userIdentity);

When you examine the properties of the ClaimsPrincipal, you’ll find that there is a collection of ClaimsIdentity objects associated with it. Just like a person can have driver’s license and a passport, a user can have multiple ways identifying themselves. Those identities could come from Twitter, Facebook, Microsoft, or your own store.

Using Claims In Controllers:
Using claims in ASP.NET Core should feel very familiar to working with Authorization in classic ASP.NET. I’ll begin by adding a claim to the ClaimsPrincipal, which I’ll call BackStagePass. 

claims.Add(new Claim(ClaimTypes.UserData, "BackStagePass"));

Normally this is something that you would get from a service, or your own data store, but for this example, I’ll just create it in code. Now that I know that the user has the claim, I need to add it to the Authorization service. In the Startup.cs file, I’ll add the Authorization service with a “PassHolders” policy that requires that the user has a “BackStagePass”. 

services.AddAuthorization(options =>
       {
                options.AddPolicy("PassHolders", policy => policy.RequireClaim(ClaimTypes.UserData, "BackStagePass"));
        });

Once the policy is added to the authorization service, it can be used in declarative authorization checks. Those checks specify which claims the user must possess, and can require the values that those claims hold.

    [Authorize(Policy = "PassHolders")]
    public class DressingRoomController : Controller

In this example, accessing the controller’s actions will require that the user have a “BackStagePass” claim.