ASP.net Membership Provider - Switching Between Forms and Integrated Auth

Question

I'm writing a web application that I want to be able to use forms authentication pointing to a SQL database, or use integrated authentication in different installations of the web app. I'm authenticating users just fine with either provider but I have a question on how to architect my database.

Currently what I'm doing is using the code:

public static string UserID
{
  get
  {
     if (HttpContext.Current.User.Identity.AuthenticationType == "Forms")
     {
       //using database auth
       return Membership.GetUser().ProviderUserKey.ToString();
     }
     else
     {
       //using integrated auth
       return HttpContext.Current.Request.LogonUserIdentity.User.ToString();
     }
   }
 }

I'm then using the returned key (depending on the provider it's the UserID from the aspnetdb database, or the windows SID) as the UserID on items they create, etc. The UserID fields are not relational to a Users table in the database though like you would traditionally do.

Is there a better way to go about this? I've thought of creating a users table with two fields of UserID (internal), and ExternalID (which stores the windows SID or the ID from aspnetdb) then using the internal UserID throughout the application, but then it's not as clean with the membership classes in c#.

It seems like there's a lot of apps that allow you to switch between integrated auth, and FBA (Sharepoint 2007 comes to mind first) but I couldn't find any good tutorials on the web on how to architect the solution. Any help would be greatly appreciated. Thanks.

Answer 1

Why not just use two different membership providers (Windows and Forms, instead of using LogonUserIdentify specifically)? In the code example you posted, you could use the same method in the Membership namespace for any provider. You can change which provider is the default in the Web.config file. I agree that using code specific to "integrated authentication" is not clean. Here's an example:

<membership defaultProvider="1">
 <providers>
  <clear/>
  <add name="1" ... />
  <add name="2" ... />
 </providers>
</membership>

Then, change the defaultProvider. The ASP.NET controls that deal with Membership (e.g. the Login control) have a property that lets you choose a Membership provider, which means you can select one programatically.

The user ID is only relevant in the context of the provider, so using an "internal" user name seems unnecessary - use the provider name and the external user ID (since the same user ID could exist in several providers) in your own data store.

There usually isn't any need to create your own user IDs, since the ASP.NET providers will take care of that behind the scenes. For example, if you use an ASP.NET Profile provider, you will have per-user profile information, independent of which Membership provider was used to authenticate the user.