我刚开始使用现有Web应用程序的基于声明的安全性。我有很多项目很适合身份的声明，如电子邮件和名字和姓氏，但还有其他安全相关的项目，我不确定应该去那里。
例如，网站的不同区域有许多细粒度布尔权限，我不确定放在哪里。例如 - CanAccessX ， CanAccessY ， CanAccessZ 等。
有人可以告诉我这些物品是否可以转为索赔或者是否属于其他地方？
作为次要问题，因为所有声明都被序列化到cookie中，加载太多声明是不是一个坏主意？什么是在验证后检索附加声明的行，并且只在cookie上放置一小部分。
感谢。
答案 0 :(得分：4)
如果符合应用程序的要求，则将权限转换为声明通常是个好主意。基于声明的安全性的一个好处是用户的元数据（名称，角色，年龄，权限等）与应用程序安全性需求之间的分离。例如，如果某些“操作”要求用户具有特定年龄，则只需要进行简单的检查HasClaim(c => c.Type == Age && c.Value >= 18)。如果需要简单的权限，为什么不检查HasClaim(CanAccessX)？
许多应用程序（mis）使用像“CanAccessX”/“CanReadY”/“CanWriteZ”这样的组/角色来实现一个不太复杂（=更好）的安全机制。声称这个概念在某种程度上是自然的。
其次，cookie膨胀可能是一个问题。例如，如果用户具有太多的组/角色/权限/等等，则使用Kerberos的令牌膨胀可能是一个问题。解决此问题的一种方法可以是基于声明的安全性之前的某种基于角色的安全性：如果 m 权限具有 n 角色（ n 应该远小于 m ），您只能将 n 角色写入cookie，但在简单的模块/中间件中将其转换为幕后。另一种解决方案可能是自定义身份/权限映射，因此您只需将用户的身份写入cookie，但在实际处理请求之前将其与其（缓存）权限相匹配。
我将从直接方法开始（只需将所有声明写入cookie）。然后，如果它变得太大并且损害了应用程序的性能，您可以使用或多或少复杂的模块/中间件来优化它的行为，这不应该影响实际的“代码”。
注意，已经有安全处理cookie内容的.NET机制：对于经典（当前）IIS应用程序，您可以使用Session Authentication Module，对于现代（未来）OWIN应用程序，您可以使用{{3} }。