ASP.NET身份验证和ASP.NET成员资格提供程序的"Mashup"

Question

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

我们现在有一个新的要求，需要通过API公开一些来自系统的数据，并且我们正在考虑WebApi作为候选技术。

我遇到的一个问题之一是身份验证。我想利用我们应用程序中现有的用户/角色管理功能，创建和管理API帐户。然而，由于WebAPI的首选选项是使用ASP.NET Identity（claims/bearer tokens等），我有点困惑最佳选择是什么。

是否可能或者说是一个不好的主意，将现有的Membership提供程序用户/密码验证某种方式塞进Web API身份验证机制中。在ApplicationOAuthProvider中有一个方法，看起来我可以通过替换行IdentityUser user = await userManager.FindAsync(context.UserName, context.Password);调用MembershipProvider来进行操作。尽管这似乎非常笨拙。

欢迎分享您的想法和意见。

- Eoin Campbell

Answer 1

这并不是一个正式的答案，只是我的个人观点。

我认为你花在将MembershipProvider集成到新的Identity框架中所需要的时间，与花在正确地更新到新的Identity框架所需的时间相同。

我已经升级了两个不小的系统（一个200K，另一个70K行代码），并且都有大量用户。较小的系统花了我7天，较大的一个花了5天（第二次我知道自己在做什么-）。两个系统都有大量用户管理代码，其中一个系统还有一种管理员模拟另一个用户的方法。一切都进行得非常顺利，没有任何停机时间。用户甚至没有注意到任何区别。
但是，在升级后，用户管理/身份验证方面的事情变得更加容易，你花费的5天升级时间很快就能收回来。把这看作是一项投资-))

我查看了MembershipProvider的源代码（在反编译器中），发现有许多东西是静态的、混乱的、封闭的和难以管理的。我认为放弃它会更容易，而不是构建更多的遗留代码，只是为了维护即将死亡的库。

换句话说，更新所有内容比尝试重用旧的东西更容易。

- trailmax

Answer 2

我希望利用现有应用程序中的用户/角色管理功能来创建和管理API账户。然而，由于WebAPI的首选选项是使用ASP.NET身份验证（声明/令牌等），我对最佳选项有些困惑。

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

在我的情况下，我创建了一个单独的Web API 2项目。然后，我创建了一个单独的类库项目，以将IoC容器保留在一个位置，并且Web应用程序和Web API都引用该类库。

Web API项目仍然可以使用SQL成员资格提供程序的表。但是，您需要自己使用成员资格提供程序编码算法验证用户，并自己创建具有声明的IPrincipal对象。然后分配给Thread.CurrentPrincipal。

对于基于令牌的身份验证，您可以直接使用JSON Web Token。 更新： 如果您有更多时间，可以使用 this example 直接将 SQL Membership 迁移到 ASP.NET Identity。然后，您可以将 MVC 和 Web API 保留在一个项目中，因为两者都使用 ASP.NET Identity。

- Win

Answer 3

这可以通过实现自己的UserStore来完成。我认为会遇到许多问题。你必须考虑所有其他场景并协调两者：忘记密码、电子邮件确认、登录失败计数和时间范围等等。基本上，更新用户数据的所有事情都必须经过深思熟虑，并且可能需要在每组表中二次执行。如果您可以将列添加到现有成员资格表中以支持asp.net身份验证的接口，则可能会有所帮助，但最终您将不得不放弃大部分数据访问部分，并实现完整的UserStore而不是大多委托给原始基于Entity Framework的代码。

- Philip Nelson