ASP.NET MVC custom IPrincipal injection

Question

I'm working on an application using ASP.NET MVC 1.0 and I'm trying to inject a custom IPrincipal object in to the HttpContext.Current.User object.

With a traditional WebForms application I've used the Application_AuthenticateRequest event to do this as follows.

protected void Application_AuthenticateRequest(object sender, EventArgs e)
    {
        if (HttpContext.Current.User != null)
        {
            if (HttpContext.Current.User.Identity.IsAuthenticated)
            {
                if (HttpContext.Current.User.Identity is FormsIdentity)
                {
                    // Get Forms Identity From Current User
                    FormsIdentity id = (FormsIdentity)HttpContext.Current.User.Identity;
                    // Get Forms Ticket From Identity object
                    FormsAuthenticationTicket ticket = id.Ticket;
                    // Create a new Generic Principal Instance and assign to Current User
                    SiteUser siteUser = new SiteUser(Convert.ToInt32(id.Name));

                    HttpContext.Current.User = siteUser;
                }
            }
        }

    }

So using this I was able to access my custom IPrincipal by either explicitly casting the User object to type SiteUser. I actually did this by having a custom class that all Pages were inheriting from which did this under the covers for me.

Anyhow, my problem is that with ASP.NET MVC the Application_AuthenticateRequest seems to fire whenever any request is made (so for JS files, images etc.) which causes the application to die.

Any help or suggestions as to how I can go about injecting my custom IPrincipal in to the HttpContext.Current.User object within ASP.NET MVC 1.0 would be greatly appreciated. I did see the following post on SO, but it didn't seem to cater for what I'm trying to achieve: ASP.NET MVC - Set custom IIdentity or IPrincipal

TIA.

Deathless

That shouldn't die, regardless of the file type - what error are you seeing? – Endodontics

I get a "hit" on the Application_AuthenticateRequest method for each and every resource that's requested. It makes the pages render painfully slowly compared to running without the Application_AuthenticateRequest method in place. The constructor for the SiteUser object doesn't do anything particularly spectacular, just gets the user details and role list from the DB. – Deathless

Well of course you do, that's how IIS7 works - I had thought you mean dying with an error – Endodontics

Answer 1

my problem is that with ASP.NET MVC the Application_AuthenticateRequest seems to fire whenever any request is made (so for JS files, images etc.) which causes the application to die.

This isn't an uniquely MVC problem - if you ran your application on IIS7 with the integrated pipeline in place then you would see the same thing.

If the problem with the lookup is scalability then I assume the actual problem is within

FormsAuthenticationTicket ticket = id.Ticket;
SiteUser siteUser = new SiteUser(Convert.ToInt32(id.Name));

I'd guess that your SiteUser class does some sort of database lookup. If you examine how forms auth works the ticket contains all the information necessary to produce a FormsIdentity (this doesn't hold true for roles, unless you specifically enable roles caching to a cookie). So you ought to look at the same approach. The first time you construct your siteUser object cache it within a signed cookie, then use the cookie to rehydrate your SiteUser properties on subsequent requests.

If you do this then you can go one step further, replacing the Thread principle with your SiteUser, or at least a custom IPrincipal/IUser combination which has the same information as your SiteUser class would have.

So inside AuthenticateRequest you'd have some flow like

SiteUserSecurityToken sessionToken = null;
if (TryReadSiteUserSecurityToken(ref sessionToken) && sessionToken != null)
{
    // Call functions to attach my principal.
}
else
{
    if (HttpContext.Current.User != null && 
        HttpContext.Current.User.Identity.IsAuthenticated && 
        HttpContext.Current.User.Identity is FormsIdentity)
    {
        // Get my SiteUser object

        // Create SiteUserSecurityToken

        // Call functions to attach my principal.
    }
}

And the function to attach the principal would contain something like

HttpContext.Current.User = sessionSecurityToken.ClaimsPrincipal;
Thread.CurrentPrincipal = sessionSecurityToken.ClaimsPrincipal;
this.ContextSessionSecurityToken = sessionSecurityToken;

You'll want to make sure that the functions which write the Security Token to a cookie add, at a minimum, a checksum/MAC value, and, if you like, support encryption using the machine key if it's configured to do so. The read functions should validate these values.

Endodontics

That's excellent, thank you. A schoolboy error on my part! Many thanks. – Deathless

Answer 2

This sounds like a job for a custom Authorization Filter.

Cowfish

I did consider this but I'd like to be able to use my strongly typed user object in other ways too. I was hoping I wouldn't have to produce a custom Authorization filter and then start wiring up my User objects in a custom base controller class but it's looking like that might be the way to go. I don't really want to implement a custom membership provider either. Thank you for the suggestion anyhow :) It's rapidly looking like it's the approach I'll be forced to take. – Deathless

If you explain why you are injecting a custom principal, perhaps there are other, more ASP.NET MVC, ways to solve your problem. – Cowfish