Question

我们已经开始构建一个asp.net mvc应用程序。应用程序将包含一个主数据库，其中包括用户，项目，公共表等...以及许多数据库（都具有相同的结构）以及与特定项目相关的数据。使用可以有一些全局角色（存储在主数据库中）和一些项目特定角色（存储在项目数据库中），每个用户可以链接到许多项目。

我的目标是构建一个支持经典用户名/密码身份验证的身份验证系统，以及OpenID身份验证（我们正在使用DotNetOpenAuth）以及支持上述角色系统的授权系统。

但是我遇到了几个问题： 1.）我认为我们应该为单个用户支持（用户名/密码和Ppenid）身份验证选项，以便用户/密码用户在决定使用OpenId时不需要创建额外的帐户，我认为我们应该为SO这样的单个用户支持几个OpenId（如果某个提供商已关闭）。

2.）我认为最好的数据库是：

table Users (UserId (PK), LastActivityDate)
table UsernameLogins (UserId (PK,FK), Username, Password, IsApproved, IsLockedOut, LastLoginDate, LastLockedOutDate, etc...)
table OpenIdLogins(OpenIdUrl (PK), UserId(FK),LastLoginDate)
table Profiles(UserId(PK,FK), DisplayName(Unique), Email (Unique), FirstName, LastName, Address, Country, etc...)
table Roles(RoleName (PK), RoleType(1=GlobalRole,2=ProjectRole).
table UserRoles(UserId(FK,PK), RoleName(PK)).

3.。）我应该创建自己的提供者（MembershipProvider，ProfileProvider，RoleProvider）吗？似乎MembershipProvider不适合OpenId身份验证（当然我只能支持基本方法（GetUser，ValidateUser））？我应该只为用户名/密码登录实现MembershipProvider吗？我认为ProfileProvider和RoleProvider不会那么难实现？我应该只使用FormsAuthentication并使用我自己的“服务”吗？

我们也在使用NHibernate和Spring进行DI。

任何建议都将受到赞赏。

谢谢！

Answer 1

1。）我认为我们应该同时支持（用户名/密码和Ppenid）单个身份验证选项用户，以便用户/密码用户不需要创建额外的当他们决定他们时将使用OpenId，我认为我们应该支持几个OpenId 像SO那样的单个用户（如果有的话）提供商失败了。）

这似乎很合理。我喜欢你为用户设计多个OpenID的方式。 StackOverflow将用户限制为仅两个，但用户通常拥有更多，并且可能希望将所有用户绑定。我认为如果您的目标受众需要OpenID，用户名/密码是一个不错的选择。 StackOverflow是一个很好的例子，说明当它的纯OpenID时简单登录。它可以使登录不那么忙，不提供用户名/密码。但同样，提供两种选择似乎最以客户为中心，因为它给了他们选择。 DNOA的未来版本将在其OpenID登录系统中提供InfoCard Selector的集成版本，以便您甚至可以直接接受InfoCards，但其外观和感觉就像OpenID，因此您的系统不需要任何更改。

2.）我认为最好的数据库是：<snipped/>

这看起来像一个合理的架构。正如您所发现的那样，分离凭证表可以为您提供最大的灵活性。

3.。）我应该创建自己的提供者（MembershipProvider，ProfileProvider，RoleProvider）吗？

MembershipProvider当然不适合OpenID。如果你只是支持OpenID登录，我会说把它抛出来并且不打算实现你自己的。 RoleProvider与OpenID完美配合，因此是一个守护者。我从别人那里听说ProfileProvider需要一个MembershipProvider才能运行。我不知道这是不是真的。但是ProfileProvider要求您使用ASP.NET Membership SQL数据库模式，如果您可以编写自己的db模式，我认为这种模式很差。如果您正在编写自己的数据库，那么存储有关用户的其他数据应该是微不足道的，因此您不需要配置文件提供程序。

如果你同时使用用户名+密码和OpenID，那么拥有你自己实现的MembershipProvider很可能，但根据我的经验，包含任何OpenID代码的大多数MembershipProvider都是kludgey甚至有安全漏洞。如果OpenID在您的系统中有任何位置，我仍然会避开MembershipProvider。

Answer 2

我想知道......支持多个重要的OpenID。看起来这更像是OpenID提供商的角色。例如，我使用ClaimID，我得到的内容基本上等于“识别转发”（在电子邮件转发的意义上），以便我可以将其重新绑定到不同的身份。现在我不经常重新提供服务提供商，但提供商可以这样做（即当你被重定向到他们的登录页面时，他们可能会问你最想呈现哪个身份）。所以问题是......这真的是要实现的应用程序工作吗？

实现多数据库，多提供商认证系统

2 个答案: