The authentication mechanism (implementing IPrincipal and IIdentity) stores information about the user's permissions in an array. Where is this array stored at run time?

Once the user is authenticated and his profile is loaded, where is it actually stored? It doesn't seem logical that every call to every page will go to the database and bring up the user's permissions again and again. Is this info stored on the server for the duration of the session and fetched from memory using the encrypted authentication cookie as a token?

If so, what happens in a web farm scenario where each request might be directed to a different server each time?

Good point. This might defeat the purpose in high traffic application. Ideally those roles should be saved to the cookie as string with Pipe as separator. "User | Admin | Guest" rather than storing them in runtime array.

Thanks
Musa

You can try storing it in a Session variable:

Web-Farm Session State. ASP.NET session state lets you share session data user-specific state values across all machines in your Web farm. Now a user can hit different servers in the web farm over multiple requests and still have full access to his/her session. And since business components created with the .NET Framework are free-threaded, you no longer need to worry about thread affinity.
-From: http://www.asp.net/whitepaper/whyasp...ndex=0&tabid=1

Doing this opens a huge security hole. If you put authentication or authorization info in a cookie, and it gets sent to the client, then the client can modify the cookie contents, granting himself Admin privileges.

Your code must never trust data that passes out of its control, which cookies do. Store sensitive information in session variables!