ASP.NET 身份和 ASP.NET 成员资格提供程序“混搭”

Question

我们有一个基于 MVC 和 SQL Membership 提供程序构建的现有 Web 应用程序，用于用户身份验证。该应用程序还包括用于创建/编辑用户、重置密码、激活帐户等的管理员管理屏幕……这是一个相当成熟的系统，已投入生产约 2.5 年。

我们现在有了一项新要求，即通过 API 从系统中公开一些数据，我们正在将 WebApi 视为一种候选技术。

我遇到的一个问题是关于身份验证的。我想利用我们应用程序中现有的用户/角色管理功能来创建和管理 API 帐户。但是，由于 WebAPI 的首选选项是使用 ASP.NET 身份（声明/持有者令牌等），所以我对最佳选项有点困惑。

以某种方式将现有的会员提供商用户/密码身份验证插入 Web api 身份验证机制是否可能或一个坏主意。在ApplicationOAuthProvider 中有一个方法，看起来我可以通过将IdentityUser user = await userManager.FindAsync(context.UserName, context.Password); 行替换为对MembershipProvider 的调用来进行操作。不过，这似乎非常笨拙。

非常感谢您的想法和选择。

Answer 1

不是真正的答案，只是我的 0.02 美分。

我认为您将花费尽可能多的时间将 MembershipProvider 换成新的 Identity，因为它需要正确更新到新的 Idenitty 框架。

我已经在 2 个不同的系统中完成了升级，这两个系统都不小（一个 200K，另外 70K 行代码），并且拥有更多的用户。较小的系统花了我 7 个工作日，较大的一个 5 天（我知道我第二次在做什么 - ）。两个系统都有扩展的用户管理代码，其中一个系统可以为管理员模拟另一个用户。一切都很顺利，没有停机。用户没有注意到差异。
但是，在使用用户管理/身份验证进行升级之后，事情变得如此简单，您将立即获得 5 天的升级时间。将其视为一项投资-))

我查看了 MembershipProvider 的源代码（在反编译器中），很多东西都是静态的、混乱的、密封的，而且根本无法管理。我会说它会更容易转储而不是构建更多遗留代码，只是为了维护垂死的库。

换句话说，更新所有内容而不是尝试重复使用旧内容会更容易。

Answer 2

这可以通过实现您自己的 UserStore 来完成。不过，我认为会有很多龙。您必须考虑所有其他情况并协调两者：忘记密码、电子邮件确认、登录失败计数和时间跨度等等。基本上，所有更新用户数据的事情都必须经过深思熟虑，并且可能在每组表中加倍完成。如果您可以将列添加到现有的成员资格表中以支持可能会有所帮助的 asp.net 身份接口，但在某些时候您最终会废弃大部分数据访问部分并实现完整的 UserStore 而不是您最常使用的委托给原始的基于实体框架的代码。

Answer 3

我想利用现有的用户/角色管理功能 在我们的应用程序中，创建和管理 API 帐户。然而 因为 WebAPI 的首选选项是使用 ASP.NET Identity （索赔/不记名令牌等......）我对什么是最好的有点困惑 选项将是。

在单个项目中混合现有的 SQL 成员资格提供程序和 Web API 并不是一个好主意。

在我的场景中，我创建了一个单独的 Web API 2 项目。然后我创建了一个单独的类库项目以将 IoC 容器保存在一个位置，并且 Web App 和 Web API 都引用该类库。

Web API 项目仍然可以使用 SQL Membership 提供程序的表。但是，您需要使用Membership Provider Encode Algorithm 自己验证用户，并自己使用 Claims 创建 IPrincipal 对象。然后分配给Thread.CurrentPrincipal。

对于基于令牌的身份验证，您可以只使用JSON Web Token。

更新：如果您有更多时间，可以使用this example 将 SQL 成员身份直接迁移到 ASP.NET 身份。然后您可以将 MVC 和 Web API 保留在一个项目中，因为它们都使用 ASP.NET Identity。