MVC身份验证以及其他用户详细信息

Question

我们目前正在开始使用MVC，现在正在考虑身份验证。 .net身份验证不一定是我们最强的观点，所以寻找一些建议或指点。

我们目前的设置： -

• 基本Windows身份验证
  • 系统使用经过身份验证的用户查询第三方系统以获取其当前角色
  • 然后将这些角色存储在会话变量中，并在需要授权时使用
  • 根据需要从各种表格中调用任何其他用户详细信息

我们想要实现的目标： -

• 基本Windows身份验证（可能在其背面创建表单身份验证cookie）
  • 系统用户通过身份验证的用户查询第三方系统以获取其当前角色，
  • 这些角色存储在cookie中，可以通过User.Roles等访问
  • 将在身份验证时调用任何其他用户详细信息（即用户喜欢的颜色），并针对用户配置文件进行存储。其他用户详细信息将作为键值对存储在单个表中。

这是正确的方法吗？我们正在努力寻找任何样本等以匹配我们所追求的情景。

不幸的是，我们需要使用此第三方系统来访问角色，这是通过Web服务调用实现的。

MVC 4是否有任何新进展可以通过其他用户详细信息更好地处理身份验证？ 任何帮助，或建议将不胜感激。 ：）

Answer 1

听起来像联合身份验证的完美候选人。您甚至可以使用WIF（Windows Identity Foundation），它现在是基类库的一部分。

通常，联合身份验证由以下部分组成：将身份验证委派给外部身份提供程序，使用身份提供程序的响应，在本地持久保存身份（可能在cookie中）。

WIF针对所有这些问题提供解决方案，它是围绕WS-Federation协议构建的。这样做的真正好处是，您可以轻松地在不同的身份提供商之间切换。这是你可以认为无用的东西，直到你看到它在行动中并立即开始创建复杂的业务场景。

使用WIF需要一些知识，并且可以轻松回答具体问题。然而，在你获得至少一些基本知识之前，这听起来像个笨蛋。你一定要从这里开始阅读免费的电子书，基于声明的身份和访问控制

http://msdn.microsoft.com/en-us/library/ff423674.aspx

只需下载并开始阅读。我保证你会立即找到你的许多问题的答案，并逐页逐页，你会觉得这是不变的“哇，所以那是应该怎么做！”。

只是为您提出一个问题的具体答案：用户数据可以保存在身份验证Cookie中。如果您坚持使用WIF的声明模型，则表达任意数据是很自然的：声明是一对（声明类型，声明值）。但是，这需要切换到 SessionAuthenticationModule ，因为表单身份验证模块可能会生成过大的cookie：

http://www.wiktorzychla.com/2012/09/forms-authentication-revisited.html

（会话认证模块有一个特殊的“会话”模式，其中大部分身份存储在会话容器中的服务器本地，以便cookie真的很小）

是的，联合身份模型适用于MVC授权标签。类型角色的声明被解释为用户角色。然后，远程身份提供者甚至可以设置用户角色，您可以通常的方式保护您的MVC控制器。

Answer 2

如果您很幸运，您的第三方组件可能会带有声明提供商，以便您可以使用基于声明的身份验证，并让声明提供商以声明的形式提供您可以使用的其他用户数据在你的申请中。有关教程，请参阅此link。
如果您无法访问声明提供程序，已知安全构建块仍可用于MVC。因此，对于您的其他角色，您可以创建一个RoleProvider，用于请求角色并在您的应用程序中对其进行配置。然后，您可以使用Authorize属性保护控制器或操作。
为了优化角色请求，以便您不必一遍又一遍地从第三方系统请求它，有一些替代方案：

• 正如您在问题中提议的那样，您可以将它们存储在 Cookie 中。但请注意，Cookie存储在客户端计算机上并可能被篡改。因此，如果您有可以使用的Forms身份验证cookie，则可以将其存储在此cookie的UserData中。此cookie已加密，因此用户无法轻松更改。由于您希望至少在第一步中使用Windows身份验证，因此您没有可以使用的Forms身份验证cookie。在安全性的背景下，总是建议建立一个广泛使用且经过良好测试的框架，因此我不建议创建自己的cookie并将角色存储在那里（尽管它不会太令人生畏在这种特定情况下加密/签署cookie数据的任务）。
• 您还可以将角色存储在会话变量中。缺点是会议过了一段时间，你必须为此案做好准备。另一方面，会话内存位于服务器上，因此用户不容易被篡改（如果可能的话，你还有很多其他问题）。
• 您可以使用的另一个组件是服务器上的缓存;虽然您不得不小心不要为各种用户混合数据，因为它在用户之间共享，但它也位于服务器上，并且在数据无效时提供更细粒度的控制。因此，您可以配置一个时间范围，之后任何用户都将获得新角色集的授权，以防它被更改。

您的RoleProvider需要实现缓存技术（Cookie，会话或缓存）。
至于你关于用户配置文件的最后一点，我可以想象ASP.NET 2.0的用户配置文件仍然有效。我对此没有任何经验，所以我不能就是否使用它给你一个建议。另一方面，这些数据似乎不太安全，因此一旦用户通过身份验证，您也可以将它们存储在cookie或会话内存中。