Putting a breakpoint on Application_AuthenticateRequestwithin VS2010 and examining the Call Stack (ensuring that ‘Show External Code’ is checked in the context menu) shows:
(extraneous info omited for brevity)
So it would appears that the .Net Framework Request Processing Pipeline fires this event – and fires it for every request.
WHEN the event fires depends on whether there are Custom Modules in the pipeline.
After the initialization, when the AuthenticateRequest fires, the event handlers are called in the order they where initialized, so:
- FormsAuthenticationModule.AuthenticateRequest event handler
- CustomModule.AuthenticateRequest event handler
- Global.AuthenticateRequest event handler
- Global.Application_AuthenticateRequest method
Theevent signals that the configured authentication mechanism has authenticated the current request
So if Windows Authentication is being used, then we must assume that the code to perform this authentication has already been executed and has been successful by the time the Application_AuthenticateRequest fires.
Similarly, if FormsAuthentication is being used, then we must assume that the code to perform this authentication has already been executed and has been successful.
Therefore, at this stage in the request processing pipeline, we should be able to safely assume that there exists an Authentication Ticket in the request (either as a Cookie, in the RequestURL or in the QueryString array) containing the users details.
From this we can create a Principle and assign it to HttpContext.User so that the our application can safely rely on this value to retrieve the information of our authenticated user eg to conduct Authorization checks and see what resources the user can/cannot access.