How to redo authentication in asp.net mvc3?

Question

ASP.NET

Hello!
when using the standard authentication system in asp.net mvc3, the User property is available in the controller context, which implements the System.Security.Principal.IPrincipal interface.
Everything would be fine, but in this context only the username is available through User.Identity.Name, but, for example, UserId or something like that, alas, no.
You can override MembershipProvider, overload the GetUser() method, which will return an object of type MembershipUser, which, in turn, will contain the standard ProviderUserKey property - exactly the identifier that I need.
Thus, to get the userid, you will need to call
System.Web.Security.Membership.GetUser().ProviderUserKey
Question:
1. What is the life cycle of the object returned by the User property (the one available in the controller class)?
2. Is it possible to somehow remake this life cycle so that after authentication, the User controller property returns something that would contain the UserId, and possibly something else? (what confuses me in the method described in the previous two paragraphs is that the GetUser () method does a "big" job of extracting the UserId by its name, and every time you need to get it, you want to get the userid once during authentication and use it everywhere without unnecessary costs.)
Thank you for your attention.

Answer 1

Thank you.
With the use of WIF, I decided to wait a while.
If you look at using IPrincipal, then there is no place for UserID in it, but you can make your own class that implements IPrincipal, which will contain the necessary properties, or you can store an additional object in the user session to store this information.
This is where an interesting (for me) point arises: at what point is this information saved in the session or in the HttpContext. If authentication is performed by the Form method, then on the login and password entry page, but there is another interesting point: the user can ask to “remember” it so as not to enter the login and password next time, while the user will be logged in in the next session, although no authentication will not be performed, and even the user may no longer be such on the site.
Where is the best place to generate user context information in this case?

Answer 2

authenticate confuses me that it is executed at each http request. Forming a security context with each http request seems unreasonable to me from a performance point of view.
An alternative is to use Session_Start in Global.asax. Are there any contraindications in this case?