Let's step through what's happening here...

• A user visits the login page.
  • The server returns the login page's markup, which is displayed in the user's browser.
    
• The user enters their credentials and clicks the Login button. A postback occurs.
  • The incoming request enters the ASP.NET pipeline.
  • The Application_Authenticate event fires. At this point, the ASP.NET runtime doesn't know who the user is, so User.Identity.IsAuthenticated = false
  • The login page's lifecycle beings
  • The Login control's Authenticate event fires and a forms authentication ticket is created because you set e.Authenticated to true.
  • The Login control's LoggedIn event fires. At this point, we're still on the same request, so User.Identity.IsAuthenticated is still false!

In short, the User object is set earlier in the ASP.NET pipeline, long before the requested ASP.NET page's code is executed. Now, on the subsequent visit, the ASP.NET runtime will see the forms authentication ticket and User.Identity.IsAuthenticated will be true, but not on this request.

I really hope this makes sense.

In any event, in the LoggedIn event handler there's no need to check if the user is authenticated - you already know they are! The LoggedIn event wouldn't fire otherwise. Also, you won't be able to get the username from User.Identity.Name. Instead, use LoginControlID.Username.

Happy Programming!