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

发布时间：2020-12-16 03:29:53 所属栏目：asp.Net 来源：网络整理

导读：我刚刚开始在现有的Web应用程序上使用基于声明的安全性.我有很多项目很适合身份的声明,如电子邮件和名字和姓氏,但还有其他安全相关的项目,我不确定应该去那里. 例如,网站的不同区域有许多细粒度布尔权限,我不知道放在哪里.例如 – CanAccessX,CanAccessY,Can

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

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

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

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

谢谢.

解决方法

如果符合应用程序的要求,则将权限转换为声明通常是个好主意.基于声明的安全性的一个好处是用户的元数据(名称,角色,年龄,权限等)与应用程序安全性需求之间的分离.例如,如果某些“动作”要求用户具有特定年龄,则仅需要简单的检查HasClaim(c => c.Type == Age&& c.Value> = 18).如果它需要一个简单的权限,为什么不检查HasClaim(CanAccessX)？

许多应用程序(错误)使用诸如“CanAccessX”/“CanReadY”/“CanWriteZ”之类的组/角色来实现较不复杂(=更好)的安全机制.声称这个概念在某种程度上是自然的.

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

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

注意,已经有安全处理cookie内容的.NET机制：对于经典(当前)IIS应用程序,您可以使用Session Authentication Module,对于现代(未来)OWIN应用程序,您可以使用Cookie Authentication Middleware.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!