会话身份验证等同于FormsAuthentication？

Question

我正在使用登录表单对用户进行身份验证。

FormsAuthentication是正确的，因为它将敏感的用户/角色成员身份存储在cookie的客户端或URL中。在URL中存在巨大的安全风险，因此我甚至不会涉及到这一点。随着 FormsAuthentication cookie，这会产生a）安全性的问题，其中客户端处于指示其自身角色的位置;和b）存储在cookie中的数据太多。由于我没有通过安全获得任何东西并且在用户数据存储空间上花费大量时间，所以我宁愿只使用Sessions。

我想重用FormsAuthentication这样的基本登录表单处理功能。但我宁愿让它将用户数据服务器端存储在Session中，而不是客户端存储在一个cookie中。我宁愿只对某种会话令牌进行身份验证。

我有 no 数据库，禁止用户数据的本地磁盘存储。我依赖第三方身份验证服务提供商，并且要求我必须减少与此服务的聊天。因此，临时存储用户信息的会话。很糟糕，但这不一定是我要问的问题。另外，一个要求是我必须设置/使用HttpContext.user和可能的Thread.CurrentPrincipal，以便稍后在AuthorizeAttribute这样的东西中使用，以便在视图中显示用户信息等。

因此FormsAuthentication将所有用户数据客户端存储在Cookie中。 Session将所有数据存储在服务器端，而仅依赖于简单的客户端令牌cookie。但是，在asp.net启动和身份验证步骤中，Session无法在任何地方使用。是否存在等效的“成员资格”提供程序，它将所有数据存储在会话服务器端而不是客户端？

如果没有Session等效...

1. 我在哪里设置HttpContext.user 和 Thread.CurrentPrincipal，使两个MVC应用程序的其余两个值都可用，而不会干扰或搞乱其他MVC组件？
2. Hinging＃1，是否在该入口点提供会话？如果没有，我如何使其可用，以便我可以使用Session？
中存储的数据创建Principle / Identity对象
3. 这不可能是一个独特的要求。是否有可以处理此问题的库？

Answer 1

Session也将信息存储在客户端cookie中！ （如果没有cookie，则在URL中）。

如果您要对客户端进行身份验证，他必须提供某种凭据 - 通常是在登录后在Cookie中加密的令牌。如果不是cookie，那么你的建议是什么？

您应该使用FormsAuthentication。存储在客户端cookie中的敏感信息使用只应为Web服务器所知的密钥加密。 “加密方法是公共知识”并不意味着您可以在不访问相应加密密钥的情况下解密数据。

您提到“角色”和“第三方身份验证提供商”。如果您的第三方也提供角色（即“授权提供者”以及“身份验证提供者”），那么在服务器上缓存从提供者获得的角色是合理的。在授权请求时，会话不可用，因此最佳解决方案是使用Cache（System.Web.Caching.Cache）。

我个人会将其封装在custom RoleProvider中。自定义RoleProvider将通过在第一次调用时从第三方获取角色，然后在缓存中缓存它们来实现GetRolesForUser。

Answer 2

不确定我是否喜欢我建议的内容，但您可以执行以下操作：

• 利用应用程序状态或System.Cache作为用户凭据的全局存储。

• 使用InMemory数据库（如RavenDb），它也可以加密（在内存中，我相信）。

  使用应用程序状态作为存储相对常见/频繁的东西的地方我认为不是一个好地方，因为

  • 缩放/锁定问题？ ＆lt; - 只是一种直觉。
  • 永久数据？所以你有网站内存中的用户..那么网站崩溃或回收等等......现在这些数据会发生什么？
  • RavenDb很棒 - go.use.it.now。

我知道你没有在本地存储任何东西，所以每当用户点击你的系统时，你需要刷新你的内存缓存，等等。 f'ing屁股很疼，但很好。 （编辑：除非数据已缓存在内存中......）

Anywys，两个建议。

<强>普罗蒂普：

哦！远离基于角色的shiz并开始使用Claims based identity内容。是的，它仍然适用于IPrincipal和HttpContext.User等。所以以前的所有代码都没有被破坏。但现在它已经融入了.NET 4.5

Awesome Video on this for you, me, everyone！

最后 - 奖金建议

使用Facebook / Google / Twitter认证的一个不错的软件包。你说你在另一个网站上保留用户信誉（好动！）。如果您正在使用其他提供商，请坚持使用DNOA或SS。

GL！