Expanding upon my speculations: Membership, RoleProvider and ProfileAPI implementation
So, yesterday I jumped out on a limb and speculated how I thought that application architecture might include a wrapper around Membership and the Profile API in ASP.NET Whidbey. Then the guy who created it chimed in with a comment to let me know that I'm wrong! So either he's wrong or I am.
http://weblogs.asp.net/dneimke/archive/2005/01/31/363437.aspx
ScottGu is obviously a very smart guy who also knows this technology better than anybody. So it must be me who's wrong, right? Well no, not necessarily. I think that the problem was that I didn't set up enough context about the problem that I was thinking of when I wrote that entry.
At lunchtime Mitch and I had an extended - and at times lively - exchange of ideas about this topic. It took most of lunch before Mitch was able to get me to understand exactly what it was that I was talking about - gee it's good to have someone like Mitch to bounce ideas off of! As we were chatting away over our lunches, Mitch had a small epiphany which I'd like to try and elaborate on here...
Regarding users and authentication there's 2 primary models and I'll use examples to demonstrate them:
Model #1 : Security User data is separate from application data
You are building the web application for the local telephony company. The application has application data which revolves around "people". These "people" are the people who have phone accounts.
You also have people who can manage the data via a web application. These users might be employees of the telephony and can view, edit, and create new records. These users are "Security Users" because they must be known to the application before there authorization is determined.
Model #2 : Security User data is application data
You are building a community web application such as ProjectDistributor or .Text. Users in this application manage their own data. The security layer must ensure that the user who is altering a project or blog entry is the same user as the currently authenticated user.
So, that's the two primary user data models. Now that I've taken some time to set up the context of the problem I plan on uploading some examples to the new ASP_Whidbey group that demonstrate how each model might work at an implementation level.