As "Anonymous" asked about my referenced solutions to the hack to resolve issues with MS KB928365, I figured instead of simply writing a follow-up comment, I would simply create a follow-up post. That said, I can imagine at least two primary solutions to this, each depending on your exact situation.
First off, with regards to my situation, I can create a provider pattern solution for looking up the enterprise provided AUTHID, such that if I want to fake it, my code isn't directly coupled to a value out of the header, but simply an interface that provides an AUTHID. I would then create two separate implementations of the interface. The first implementation would be the DEV simulation implementation, which would read the AUTHID out of the XML configuration file that we are currently using to inject into the request headers (for use in DEV). The second interface implementation would be one that reads the value off of the request headers (for use in PROD). You then configure which one is in use via your web.config, or via your Dependency Injection (DI) or Inversion of Control (IoC) framework (i.e., StructureMap, Windsor, Spring.NET).
Second, if you don't have that level of control of the situation, you are probably stuck with having to create a custom reverse proxy server to sit in front of your application that injects the AUTHID before making the request directly to your application.
Overall, the first solution is an order of magnitude more desirable. It is very much the "proper" object oriented approach, as it creates a loosely coupled solution that can be easily reconfigured, and more importantly, tested. And I would also highly recommend against even considering deploying the second solution in a production environment. It should only be used for simulating things for development purposes.