How do IIdentity, IPrincipal, OWIN, IdentityUser and IUser<string> fit together?

Question

I am struggling to work out which .Net authentication concepts are still relevant in the world of OWIN, and which are now obsolete. From the pre-OWIN ASP.Net days, I am used to dealing with the .Net constructs: FormsAuthentication, FormsAuthCookie, IPrincipal, IIdentity and also custom implementations of IPrincipal (inheriting from GenericPrincipal). With the latest version of MVC (5) much of the authentication seems to have been changed be to OWIN based. Two things I am trying to understand in particular:

1)Where does IPrincipal and IIdentity and GenericPrincipal fit in? With FormsAuthentication, custom data could be stored in the FormsAuth cookie. This could then used in the ASP.Net PostAuthenticate event to create a CustomPrincipal object, and override the default IPrincipal on the HTTPContext (per code example below). How (or does) OWIN change this?:

protected void Application_PostAuthenticateRequest(Object sender, EventArgs e) 
{
    //Decrypt forms authentication cookie and retrieve some userdata        

    ...

    //Create CustomPrincipal (which inherits from GenericPrincipal)
    var principal = new CustomPrincipal(userId, roles, someAdditionalUserDataFromCookie);

    //Replace standard IPrincipal object on HTTPContext with custom principal
    HttpContext.Current.User = newUser
}

2) Where can custom auth data be stored? In the pre-OWIN days I used the UserData value of the AuthCookie to store custom identification information (in addition to the username) - such as OrgID. Can this now be stored as a Claim in the ClaimsIdentity object? Is this a good idea? Can it still be stored in the AuthenticationTicket? Am I looking at this all wrong?!

Thanks for any help.

Answer 1

You will use CookieAuthenticationMiddleware instead of FormsAuthenticationModule. CookieAuthenticationMiddleware still creates a cookie with an authentication ticket but the format is different. With CookieAuthenticationMiddleware, things are designed for claims from the ground up. So, by default, you get ClaimsPrincipal with ClaimsIdentity although these classes implement IPrincipal and IIdentity.

Regarding custom authentication data, store them as claims part of the identity. One good thing about the new world is that you no longer need to use PostAuthenticate to restore your principal based on the custom data in the ticket. If you create your identity with all the required claims before calling SignIn, CookieAuthenticationMiddleware takes care of serializing claims part of identity into the ticket in the cookie and back into the identity in its entirety. Also, you will not use HttpContext.Current.User to read the principal. You will read from the OWIN context using the extension method available on the request object like so.

Request.GetOwinContext().Authentication.User returns ClaimsPrincipal Request.GetOwinContext().Request.User returns same as above but as IPrincipal

From the controller, you can use User which is IPrincipal, which again returns the one from the context.