Thread.CurrentPrincipal set in Application_AuthenticationRequest is not set later in the app

Question

In the global.asax file for the Application_AuthenticationRequest I'm setting the Thread.CurrentPrincipal to a custom principal. I also set the HttpContext.Current.User to the same principal.

However later in the app when I need to cast the Thread.CurrentPrincipal to our custom type, I get a runtime error saying: Unable to cast object of type 'System.Web.Security.RolePrincipal' to type 'OurCustomPrincipal'.

How did the Thread.CurrentPrincipal get reset to RolePrincipal, and more to the point how do I keep it at the CustomPrincipal we set in the global.asax

Thanks in advance

Answer 1

Please verify that you have implemented a class for IIDentity & Iprincipal interface and then you are using something like the following code to assign the currentprincipal.

    Dim userIdentity As CustomIdentity
    userIdentity = New CustomIdentity(username, True,"forms", sessionId)

    Dim principal As New CustomPrincipal(userIdentity, arrRoles)
    HttpContext.Current.User = principal
    System.Threading.Thread.CurrentPrincipal = principal

Answer 2

You surely have resolved your problem by now but just in case, if you are using the RoleProvider from ASP.NET, the RoleManagerModule overwrites the GenericPrincipal object created by the FormsAuthenticationModule and replaces it with a RolePrincipal object during the PostAuthenticateRequest: http://www.asp.net/Learn/Security/tutorial-11-vb.aspx

Answer 3

Ugh. I've been wrestling with a similar problem for days now. Even sent an email to Scott Mitchell requesting his advice --- but got no response.

I followed the instructions to a "t" in Mitchell's third security tutorial on www.asp.net, "Forms Authentication Configuration and Advanced Topics," specifically, Steps 4 and 5 for "Storing Additional User Data in the Ticket" and "Using a Custom Principal," respectively.

Admittedly, Mitchell presents that tutorial before presenting any discussion of ASP.NET's roles framework. Consequently, the instructions cited above don't take roles into consideration.

But later, in his eleventh tutorial in the ASP.NET security tutorial series, "Role-Based Authorization," Mitchell acknowledges that most real-world security implementations use roles, and he doesn't indicate how the custom principal implemented in tutorial 3 can be updated to support them.

I have found that when one implements Mitchell's custom principal in an ASP.NET application utilizing the standard ASP.NET membership and role providers, URL security ceases to work.

Apparently (although I haven't fully confirmed this yet), the standard role provider's RoleManagerModule runs in the HTTP application's PostAuthenticateRequest event AFTER the event handler that Mitchell describes for creating the custom principal in tutorial 3, replacing one's CustomPrincipal with a RolePrincipal object containing a FormsIdentity object rather than the CustomIdentity object also described in Mitchell's tutorial.

Custom user data stored in the UserData string of my authentication ticket also survives.

But all forms of roles based authorization fails.

To emphasize, everything works if I simply include the following code in my Login page's Submit Button event handler.

    If Membership.ValidateUser(user_name_register.Text, password_register.Text) Then
        FormsAuthentication.RedirectFromLoginPage(user_name_register.Text, persistent_cookie_p_register.Checked)
    End If

Any help would be greatly appreciated.