asp.net-mvc - MVC5 基于声明的身份验证 - 合适的声明项

Question

我刚刚开始在现有 Web 应用程序上使用基于声明的安全性。我有一些非常适合身份声明的项目，例如电子邮件和名字和姓氏，但还有其他与安全相关的项目，我不确定应该去那里。

例如，对于网站的不同区域，有许多精细的 bool 权限，我不确定该放在哪里。例如 - CanAccessX、CanAccessY、CanAccessZ 等。

有人可以告诉我这些元素是否可以转化为 claim ，或者它们是否属于其他地方？

作为次要问题，由于所有声明都被序列化到 cookie 中，加载太多声明是不是一个坏主意？将在哪一行进行身份验证后检索其他声明并仅将一小部分放在 cookie 上。

谢谢。

Answer 1

如果符合应用程序的要求，将权限转换为声明通常是一个好主意。基于声明的安全性的好处之一是用户的元数据(姓名、角色、年龄、权限等)与应用程序安全需求之间的解耦。例如，如果某些“ Action ”要求用户达到一定年龄，只需简单检查 HasClaim(c => c.Type == Age && c.Value >= 18)是必要的。如果它需要一个简单的权限，为什么不直接检查 HasClaim(CanAccessX) ?

许多应用程序(错误)使用“CanAccessX”/“CanReadY”/“CanWriteZ”等组/角色来实现不太复杂(=更好)的安全机制。有了 claim ，这个概念就变得自然而然了。

其次，cookie 膨胀可能是一个问题。例如，如果用户拥有太多的组/角色/权限/任何东西，使用 Kerberos 的 token 膨胀可能是一个问题。解决这个问题的一种方法可以是在基于声明的安全性之前使用某种基于角色的安全性:如果有 n 个角色用于 m 个权限(n 应该远小于 m)，则只能将 n 个角色写入 cookie，但是在一个简单的模块/中间件中在幕后转换它们。另一种解决方案可能是自定义身份/权限映射，因此您只需将用户身份写入 cookie，但在实际处理请求之前将其与其(缓存的)权限匹配。

我将从直接方法开始(只需将所有声明写入 cookie)。然后，如果它变得太大并影响应用程序的性能，您可以使用或多或少复杂的模块/中间件优化它的行为，这不应该影响实际的“代码”。

请注意，已经有 .NET 机制可以安全地处理该 cookie 内容:对于经典(当前)IIS 应用程序，您可以使用 Session Authentication Module ，对于现代( future )OWIN 应用程序，您可以使用 Cookie Authentication Middleware .