我正在编写一个Web应用程序，我希望它能够使用指向SQL数据库的表单身份验证，或者在Web应用程序的不同安装中使用集成身份验证。我正在使用任一提供商对用户进行身份验证都很好，但是我对如何构建数据库有疑问。

目前，我正在使用的代码是：

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();
     }
   }
 }

然后，我使用返回的键(取决于提供程序，它是aspnetdb数据库中的UserID还是Windows SID)作为它们创建的项目上的UserID，等等。就像我们传统上那样

有更好的方法来解决这个问题吗？我曾考虑过创建一个用户表，其中包含用户ID(内部)和外部ID(用于存储Windows SID或者来自aspnetdb的ID)两个字段，然后在整个应用程序中使用内部UserID，但这样的成员资格并不那么干净C＃中的类。

似乎有很多应用程序可以让我们在集成身份验证和FBA之间切换(首先想到的是SharePoint Server 2007)，但是我在网上找不到任何有关如何设计解决方案的优秀教程。任何帮助将不胜感激。谢谢。

解决方案

回答

为什么不只使用两个不同的成员资格提供程序(Windows和Forms，而不是专门使用LogonUserIdentify)？在我们发布的代码示例中，可以为任何提供程序在Membership名称空间中使用相同的方法。我们可以更改Web.config文件中默认的提供程序。我同意使用特定于"集成身份验证"的代码是不干净的。这是一个例子：

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

然后，更改defaultProvider。处理成员资格的ASP.NET控件(例如，登录控件)具有一个属性，可让我们选择成员资格提供程序，这意味着我们可以通过编程方式选择一个。

用户ID仅在提供者的上下文中相关，因此似乎不需要使用"内部"用户名，而在我们自己的数据存储区中使用提供者名称和外部用户ID(因为同一用户ID可能存在于多个提供者中)。

通常不需要创建我们自己的用户ID，因为ASP.NET提供程序将在后台进行处理。例如，如果使用ASP.NET配置文件提供程序，则将具有每个用户的配置文件信息，而与使用哪个成员资格提供程序对用户进行身份验证无关。