MVC5基于声明的身份验证 - 适用的声明项目

Question

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

例如,网站的不同区域有许多细粒度布尔权限,我不知道放在哪里.例如 - CanAccessX,CanAccessY,CanAccessZ等.

有人可以告诉我这些物品是否适合变成索赔或者是否属于其他地方？

作为次要问题,由于所有声明都被序列化到cookie中,因此加载太多声明是不是一个坏主意？什么是在验证后检索附加声明并且只在cookie上放置一小部分的行.

谢谢.

Answer 1

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

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

其次，cookie 膨胀可能是一个问题。例如，如果用户拥有太多组/角色/权限/其他内容，Kerberos 的令牌膨胀可能会成为一个问题。解决此问题的一种方法可以是在基于声明的安全性之前采用某种基于角色的安全性：如果有n 个角色对应m 个权限（n应该远小于m），则只能将n 个角色写入 cookie，但是在简单的模块/中间件中在幕后转换它们。另一种解决方案可能是自定义身份/权限映射，因此您只需将用户的身份写入 cookie，但在实际处理请求之前将其与其（缓存的）权限进行匹配。

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

请注意，已经有 .NET 机制可以安全地处理 cookie 内容：对于经典（当前）IIS 应用程序，您可以使用会话身份验证模块，对于现代（未来）OWIN 应用程序，您可以使用Cookie 身份验证中间件。