如何在 ASP.NET 中允许多种身份验证方法？
我正在构建一个新的 ASP.NET MVC 应用程序（用 C# 编写），其中一个要求是创建一个新的成员数据库。为此，我们需要角色来管理不同类型的成员，并需要配置文件来管理附加到每个成员的附加元数据。到目前为止一切顺利，只需使用作为 .NET Framework 的一部分提供的标准 MembershipProvider、RoleProvider 和 ProfileProvider。
然而，问题是我想允许不同的身份验证方法。我希望帐户和登录凭据具有一对多关系（一个帐户可以附加多个登录凭据）。例如，用户的帐户可能同时附加了 OpenID 和 ActiveDirectory 帐户。
然而，在尝试了几种方法之后，我们选择了 MembershipProvider 路线（在下面的答案中解释了它是如何实现的）。
我的问题是，人们以前是如何做到这一点的？人们会建议我如何处理它？这似乎是在相当多的网站上实现的，但在这里搜索并没有返回任何可靠的内容。
编辑：经过一夜和今天早上的好几个小时的观察后 - 我仍然不相信屠杀单个 MembershipProvider 是最简单的选择。拥有多个 MembershipProvider 是否会产生相同的效果？
赏金编辑：如果没有回应，我假设没有比我作为答案发布的解决方案更好的解决方案。事实真的如此吗？我提供赏金来尝试看看是否有人对此有任何进一步的想法以及是否有更好的选择。
赏金接受编辑：我认为 WIF 是下面接受的答案，适用于 .NET 4 版本，也可能是其他版本，因为它可能适用于 3.5。除此之外，也许被屠杀的会员提供者或经过改造的会员提供者可能仍然具有相关性。
I'm building a new ASP.NET MVC application (in C#) and one of the requirements is to create a new database of members. For this, we'd need roles to manage the different types of members and profiles to manage the additional metadata attached to each member. So far so good, just use the standard MembershipProvider, RoleProvider and ProfileProvider provided as part of the .NET Framework.
However, the catch is that I'd like to allow different authentication methods. I'd like Accounts and Login Credentials to have a one-to-many relationship (one account can have a number of login credentials attached). A user for example, might have both an OpenID and ActiveDirectory account attached to their account.
However, after experimenting with a few ways we opted for the MembershipProvider route (explained how it was achieved as an answer below).
My question is, how have people done this before and how would people suggest I approach it? It appears to be something that is achieved on quite a number of sites, yet a search on here doesn't return anything solid to play around with.
EDIT: After looking around for a good period of hours overnight and this morning - I'm still not convincinced that butchering a single MembershipProvider would have been the easiest option. Does having multiple MembershipProviders give the same effect?
BOUNTY EDIT: With no responses, I am assuming that there is no more optimal solution that the one I posted as an answer. Is this really the case? I'm offering a bounty to try and see if anyone has any further thoughts on this and whether there are better alternatives.
BOUNTY ACCEPT EDIT: I think that WIF is the answer as accepted below, for a .NET 4 release and maybe other versions as it probably works with 3.5. Other than that, maybe a butchered MembershipProvider or adapted one may still be relevant.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，执行此操作的“真正方法”是将联合与 WIF< /a>（Windows Identity Foundation，以前的Geneva 框架）。
这个想法是将身份验证与授权分开。身份验证由所谓的 STS（安全令牌服务）执行，它管理您想要支持的所有可能的登录机制。当用户通过身份验证后，STS 会发出一个包含一组声明和用户身份的令牌。
该令牌被发送到网站（在该行话中称为依赖方），网站根据令牌中的声明确定用户可以访问网站的哪些部分。 WIF 提供从令牌中提取信息的成员资格和角色提供者。
您可以在此处了解如何创建索赔感知网站。
这种方法的优点之一是身份验证和授权之间的关注点分离。您的网站中不需要任何复杂的会员资格和角色提供者。此外，STS 可以重复用于对您可能拥有的其他应用程序的用户进行身份验证，而无需用户多次注册（有效实现单点登录）。
缺点是您必须花一些时间研究这些概念并编写 STS 代码。请注意，使用 WIF 编写 STS 并不困难，但这也不是一个 100% 微不足道的任务。
如果我成功引起了您的兴趣，我建议您首先阅读 本白皮书。
亲切的问候，
克劳斯
In my opinion, the "real way" of doing this is to use federation with WIF (Windows Identity Foundation, formerly Geneva framework).
The idea is that you separate authentication from authorization. The authentication is performed by a so-called STS (Security Token Service) and it manages all the possible login mechanism that you want to support. When a user has been authenticated the STS issues a token containing a set of claims and the user's identity.
This token is sent to the web site (called a relying party in this lingo), and the website determines which parts of the site the user has access to based on the claims in the token. WIF supplies both membership and role providers that extract information from token.
You can read about creating a claims aware website here.
One of the pros of this approach is the separation of concerns between authentication and authorization. You do not need any complex membership and roleproviders in your website. Furthermore the STS can be reused to authenticate users to other applications you might have without them having to register more than once (effectively achieving single sign-on)
The downside is that you will have to spend some time studying these concepts and coding your STS. Mind you, it is not hard to code an STS with WIF, but it is not a 100% trivial task either.
If I have managed to tickle your interest I would recommend that you start out by reading this whitepaper.
Kind regards,
Klaus
我们遵循的一个想法是创建一个自定义的成员资格/角色/配置文件提供程序。我们显着定制了登录/身份验证方法，并有一个额外的登录表。该表基本上只包含：
在上面的内容中，LoginSystemID 是到外部查找表的链接，该表帮助系统确定要使用的身份验证服务（例如 Standard、AD、OpenID、FacebookConnect 等）。
我们遇到的问题是，MembershipProvider 中的 Username 字段不能为空，而在我们的架构中，每个人都有一个 UserID（这是他们的帐户名），但他们没有唯一的用户名。我们必须通过生成 GUID 并使用它来解决这个问题。这当然对用户隐藏，并且可以显示用户表中的 DisplayName 属性。
这一切都是通过 FormsAuthenication 完成的（AD 检查是通过 LDAP 检查完成的）。然而，在 IIS 中添加了一个带有适当设置的附加层（Web 表单），该层提供了自动 Windows 身份验证的方法 - 在我们认为用户可能是内部用户（基于 IP 地址）的情况下，我们会重定向到那里。
One idea we've followed is to create a custom Membership / Role / Profile provider. We customised the login / authentication methods significantly and have an additional table of logins. This table basically just contained:
Within the above, the LoginSystemID was a link to a foreign lookup table which helped the system to determine which authentication service to use (e.g. Standard, AD, OpenID, FacebookConnect - etc).
The problem we ran into was that the Username field in the MembershipProvider couldn't be empty and while in our schema everyone had a UserID (it was their account name), they didn't have a Username that was unique. We had to get around this by generating a GUID and using that. This of course is hidden from the user and a DisplayName attribute from our Users table can be displayed instead.
This was all done via FormsAuthenication (the AD checks were done via LDAP checks). However, an additional layer (a webform) was added with appropriate settings within IIS that provided a means for automatic WindowsAuthentication - we redirect to there in the instance that we feel the user is likely to be internal (based on IP address).
使用标准框架的东西。请参阅http://blogs.teamb.com/craigstuntz/2009/09/ 09/38390/
您可以为一个帐户附加无限数量的身份验证方法，神奇之处在于
FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);语句Use standard framework stuff. See http://blogs.teamb.com/craigstuntz/2009/09/09/38390/
You can have an unlimited number of authentication methods attached to one account, the magic is in the
FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);statement