Complete Implementation Guide for Custom IIdentity and IPrincipal in ASP.NET MVC

Introduction and Background

In ASP.NET MVC application development, there is often a need to extend default user identity information to include custom properties. Many developers find that standard IIdentity and IPrincipal interfaces cannot meet business requirements, especially when needing to access user IDs, roles, or other business-related attributes. This article provides a complete, efficient custom identity implementation based on practical development experience.

Core Concept Analysis

The IIdentity interface represents user authentication information, while the IPrincipal interface contains user identity and role information. In ASP.NET MVC, the HttpContext.User property stores the current user's IPrincipal object. By extending these interfaces, developers can add custom properties such as user ID, name, etc.

It is worth noting that with the evolution of the .NET ecosystem, ClaimsPrincipal is gradually replacing traditional IPrincipal in modern applications. However, in traditional frameworks like ASP.NET MVC, IPrincipal remains the standard approach. This article focuses on IPrincipal-based implementation to ensure compatibility with existing MVC frameworks.

Custom Principal Interface Design

First, define an extension interface inheriting from IPrincipal:

interface ICustomPrincipal : IPrincipal
{
    int Id { get; set; }
    string FirstName { get; set; }
    string LastName { get; set; }
}

This interface adds three custom properties: user ID, first name, and last name. Choosing to extend IPrincipal rather than IIdentity simplifies implementation since there is no need to implement both interfaces simultaneously.

Concrete Implementation Class

Next, implement the concrete CustomPrincipal class:

public class CustomPrincipal : ICustomPrincipal
{
    public IIdentity Identity { get; private set; }
    public bool IsInRole(string role) { return false; }

    public CustomPrincipal(string email)
    {
        this.Identity = new GenericIdentity(email);
    }

    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

The constructor accepts an email address and creates a GenericIdentity. In practical applications, the IsInRole method can implement role checking logic based on business requirements.

Serialization Model Design

To store custom data in authentication tickets, define a serialization model:

public class CustomPrincipalSerializeModel
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

This simple POCO class is used for serializing and deserializing user data during the authentication process.

Login Process Implementation

When a user logs in, create an authentication ticket containing custom data:

if (Membership.ValidateUser(viewModel.Email, viewModel.Password))
{
    var user = userRepository.Users.Where(u => u.Email == viewModel.Email).First();

    CustomPrincipalSerializeModel serializeModel = new CustomPrincipalSerializeModel();
    serializeModel.Id = user.Id;
    serializeModel.FirstName = user.FirstName;
    serializeModel.LastName = user.LastName;

    JavaScriptSerializer serializer = new JavaScriptSerializer();
    string userData = serializer.Serialize(serializeModel);

    FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
         1,
         viewModel.Email,
         DateTime.Now,
         DateTime.Now.AddMinutes(15),
         false,
         userData);

    string encTicket = FormsAuthentication.Encrypt(authTicket);
    HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
    Response.Cookies.Add(faCookie);

    return RedirectToAction("Index", "Home");
}

The key advantage of this implementation is that user data is serialized and stored in the authentication ticket, avoiding performance overhead from database access on every request.

Global Authentication Handling

Override the Application_PostAuthenticateRequest method in Global.asax:

protected void Application_PostAuthenticateRequest(Object sender, EventArgs e)
{
    HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];

    if (authCookie != null)
    {
        FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);

        JavaScriptSerializer serializer = new JavaScriptSerializer();
        CustomPrincipalSerializeModel serializeModel = serializer.Deserialize<CustomPrincipalSerializeModel>(authTicket.UserData);

        CustomPrincipal newUser = new CustomPrincipal(authTicket.Name);
        newUser.Id = serializeModel.Id;
        newUser.FirstName = serializeModel.FirstName;
        newUser.LastName = serializeModel.LastName;

        HttpContext.Current.User = newUser;
    }
}

This method executes during the post-authentication phase of each request, reading from the cookie and reconstructing the custom principal object to ensure user data is available throughout the request lifecycle.

Access Methods in Views

Access custom properties in Razor views:

@((User as CustomPrincipal).Id)
@((User as CustomPrincipal).FirstName)
@((User as CustomPrincipal).LastName)

Access in code:

(User as CustomPrincipal).Id
(User as CustomPrincipal).FirstName
(User as CustomPrincipal).LastName

Advanced Integration Solutions

For more elegant access, create a base controller:

public class BaseController : Controller
{
    protected virtual new CustomPrincipal User
    {
        get { return HttpContext.User as CustomPrincipal; }
    }
}

Have other controllers inherit from this base controller:

public class AccountController : BaseController
{
    // Controller logic
}

This allows direct access in controllers:

User.Id
User.FirstName
User.LastName

For improved access in views, create a custom WebViewPage:

public abstract class BaseViewPage : WebViewPage
{
    public virtual new CustomPrincipal User
    {
        get { return base.User as CustomPrincipal; }
    }
}

public abstract class BaseViewPage<TModel> : WebViewPage<TModel>
{
    public virtual new CustomPrincipal User
    {
        get { return base.User as CustomPrincipal; }
    }
}

Configure in Views/web.config:

<pages pageBaseType="Your.Namespace.BaseViewPage">
  <namespaces>
    <add namespace="System.Web.Mvc" />
    <add namespace="System.Web.Mvc.Ajax" />
    <add namespace="System.Web.Mvc.Html" />
    <add namespace="System.Web.Routing" />
  </namespaces>
</pages>

After configuration, access directly in views:

@User.FirstName
@User.LastName

Performance and Security Considerations

This solution serializes user data into authentication tickets, avoiding database access on each request and significantly improving performance. Meanwhile, authentication tickets are encrypted, ensuring data security. In actual deployment, adjust ticket expiration time and encryption strength based on security requirements.

Comparison with Modern Authentication Standards

Although this article is based on the traditional IPrincipal interface, it is worth noting that in modern frameworks like ASP.NET Core, ClaimsPrincipal has become the standard. ClaimsPrincipal, based on the concept of claims, provides a more flexible way to manage identity information. For new projects, consider using a claims-based authentication system.

Conclusion

This article provides a complete solution for implementing custom user identity in ASP.NET MVC. Through reasonable interface design, serialization mechanisms, and global event handling, it achieves efficient and secure access to custom properties. This solution maintains code simplicity while ensuring good performance and maintainability, making it an ideal choice for extending user identity information in traditional ASP.NET MVC projects.