Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

11.4. The "Primary Key" for Membership

I have alluded to the fact that the Membership feature considers a username to be part of the "primary key" for the Membership feature. Because the feature is provider-based, and all the ASP.NET 2.0 and ASP.NET 3.5 SQL providers support an "applicationName" attribute in configuration, the precise statement is that the Membership feature implicitly considers the combination of applicationName and username to be an immutable identifier for users. Although a more database-centric definition of a primary key could have been modeled in Membership and other related features, the intent was to keep the user identifier as simple and as generic as possible.

Because it is likely that just about any conceivable Membership store ever devised will support a string type, choosing username and application name seems pretty safe. This also means that it is possible for developers to write custom features that link to Membership data at an object level in a reliable manner. For example, if you had an inventory application running off in a corner somewhere that you needed to integrate with a website running Membership, it is pretty likely that you will at least be able to find a string-based username in the inventory system that has some mapping and relevance to your website. Using a database primary key/foreign key relationship probably will not work if your inventory system is running on some "interesting" relic that has been repeatedly upgraded over the ...