We have a Web Api application that's been working for a long time.
We have implemented our own System.Web.Http.AuthorizeAttribute to initialize our user state and role providers, and during our overload of IsAuthorized() we set HttpContext.Current.User and Thread.CurrentPrincipal to our own GenericPrincipal initialized with all our stuff.
That's been working fine a long time.
Now we've been asked to stand up some Odata apis, so we fetched v6.15 from git, and it's dragged along a lot of other dlls (newer/different mvc dlls for example) that have changed the behavior of how System.Web.Http.AuthorizeAttribute actions fit in the pipeline.
Now, while our [Authorize (Roles="OurFoo")] correctly authorizes, Thread.CurrentPrincipal is getting reset/swapped out with something else before we actually get into our method. That's breaking
[PrincipalPermission(SecurityAction.Demand, Role = "OurFoo")]
permissions lower down in our callstack.
Has anyone else run into this and figured the proper workaround?
I've found Stack articles about using System.Web.Mvc.AuthorizeAttribute as a base instead of System.Web.Http.AuthorizeAttribute but the signatures are different and it was unclear if that would do anything about the Thread.CurrentPrincipal getting reset issue.
Not sure if anyone has a better answer (other than telling me to re-write the entire app "the new way") but I found a work around.
I broke up our authentication logic from our authorization in our IsAuthorized() function and put it in a MessageHandler, hoping that would get processed early enough in the pipeline that setting Thread.CurrentPrincipal would persist. That appeared to work.