我正在构建一个新的ASP.NET MVC应用程序（在C＃中），其中一个要求是创建一个新的成员数据库。为此，我们需要角色来管理不同类型的成员和配置文件，以管理附加到每个成员的其他元数据。到目前为止，只需使用标准MembershipProvider，RoleProvider和ProfileProvider作为.NET Framework的一部分提供。
然而，问题是，我想允许不同的身份验证方法。我希望帐户和登录凭据具有一对多的关系（一个帐户可以附加一些登录凭据）。例如，用户可能同时将OpenID和ActiveDirectory帐户附加到其帐户。
然而，在尝试了几种方法后，我们选择了MembershipProvider路线（解释了它是如何实现的，如下所示）。
我的问题是，人们之前是如何做到这一点的？人们如何建议我接近它？它似乎是在很多网站上实现的东西，但在这里搜索并没有带来任何可靠的东西。
编辑：在隔夜和今天早上四处寻找好几个小时之后 - 我仍然没有意识到屠杀一个会员提供者将是最简单的选择。拥有多个MembershipProviders会产生同样的效果吗？BOUNTY EDIT：没有回复，我假设没有更优化的解决方案，我发布的答案。这是真的吗？我正在提供奖励，试着看看是否有人对此有任何进一步的想法以及是否有更好的选择。
BOUNTY接受编辑：我认为WIF是下面接受的答案，对于.NET 4版本以及可能与3.5一起使用的其他版本。除此之外，也许一个被屠杀的MembershipProvider或改编后的可能仍然是相关的。
答案 0 :(得分：16)
在我看来，这样做的“真正方式”是使用WIF联合（Windows Identity Foundation，以前的日内瓦框架）。
您的想法是将身份验证与授权分开。身份验证由所谓的STS（安全令牌服务）执行，它管理您要支持的所有可能的登录机制。当用户通过身份验证后，STS会发出包含一组声明和用户身份的令牌。 此令牌被发送到网站（在该术语中称为依赖方），并且网站基于令牌中的声明确定用户可访问的站点的哪些部分。 WIF提供从成员资格中提取信息的成员资格和角色提供者。
您可以阅读有关创建claims aware website here。
的信息这种方法的优点之一是在身份验证和授权之间分离关注点。您的网站不需要任何复杂的成员资格和角色提供者。此外，STS可以重复用于向用户验证您可能拥有的其他应用程序，而无需他们多次注册（有效实现单点登录）
缺点是您将不得不花一些时间研究这些概念并编写STS编码。请注意，使用WIF对STS进行编码并不困难，但它也不是100％的简单任务。
如果我设法引起您的兴趣，我建议您先阅读this whitepaper。
亲切的问候，
克劳斯
答案 1 :(得分：4)
我们遵循的一个想法是创建自定义成员资格/角色/配置文件提供程序。我们显着地定制了登录/身份验证方法，并有一个额外的登录表。该表基本上只包含：
LoginID (Auto-Incremental ID, PK)
UserID (FK)
LoginSystemID (FK)
...blah blah
在上述内容中，LoginSystemID是指向外部查找表的链接，该表帮助系统确定要使用的身份验证服务（例如Standard，AD，OpenID，FacebookConnect等）。
我们遇到的问题是MembershipProvider中的Username字段不能为空，而在我们的架构中，每个人都有一个UserID（这是他们的帐户名），他们没有唯一的用户名。我们必须通过生成GUID并使用它来解决这个问题。这当然对用户是隐藏的，而且可以显示Users表中的DisplayName属性。
这一切都是通过FormsAuthenication完成的（AD检查是通过LDAP检查完成的）。但是，在IIS中添加了一个附加层（一个webform），其中提供了一种自动Windows身份验证的方法 - 我们在实例中重定向到我们认为用户可能是内部的（基于IP地址）。
答案 2 :(得分：4)
使用标准框架内容。见http://blogs.teamb.com/craigstuntz/2009/09/09/38390/
您可以将无限数量的身份验证方法附加到一个帐户，神奇的是FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);声明