I'm swimming in the relationships and hierarchies of a web application that I'm trying to secure with custom sql membership and role providers. I'm a little fuzzy on forms authentication, principals, and the like. So --
The web.config is set up for forms authentication with a custom membership provider and custom roles provider.
When my fictional web app starts, it validates user logins from the database using methods from my custom membership provider.
At this point, I assume that it sticks the providerUserKey into a principal object that is stored, encrypted, in a cookie?
If I want to include other information in each page about a user, such as a foreign key (ID) to another table in my existing system, what's the best way to persist it to avoid round-tripping to the database?
Do I extend the principal to include this extra field? Do I extend the membership object to include this extra field? Do I create a custom profile provider and use that to store the extra field?
Where are all of these identifiable pieces of information stored? I had assumed that a custom profile provider would be accessible without a database round trip once the user had logged in.