2

我们已经开始构建一个 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 并使用我自己的“服务”吗？

我们还在为 DI 使用 NHibernate 和 Spring。

任何建议将被认真考虑。

谢谢！

4

2 回答 2

1

1.）我认为我们应该支持单个用户的（用户名/密码和 Ppenid）身份验证选项，以便用户名/密码用户在决定使用 OpenId 时不需要创建其他帐户，我认为我们应该像 SO 那样为单个用户支持多个 OpenId（如果某些提供程序已关闭）。

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

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

这看起来是一个合理的模式。正如您所发现的，分离凭证表为您提供了最大的灵活性。

3.) 我应该创建自己的提供商（MembershipProvider、ProfileProvider、RoleProvider）吗？

MembershipProvider 肯定不太适合 OpenID。如果你只支持 OpenID 登录，我会说把它扔掉，不要费心实现你自己的。RoleProvider 与 OpenID 完美配合，因此它是一个守门员。我从其他人那里听说 ProfileProvider 需要 MembershipProvider 才能发挥作用。我不知道这是不是真的。但是 ProfileProvider 要求您使用 ASP.NET Membership SQL 数据库架构，如果您可以编写自己的数据库架构，我认为这很糟糕。而且，如果您正在编写自己的数据库，那么存储有关用户的其他数据应该是微不足道的，因此您不需要配置文件提供程序。

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

于 2009-05-15T14:13:35.783 回答
0

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

于 2009-05-15T14:20:15.640 回答