Muh*_*hid 5 claims-based-identity asp.net-web-api owin asp.net-identity asp.net-web-api2
我正在尝试使用Windows Identity Foundation 2来保护asp.net web-api 2.0.我必须做出的选择是基于角色的授权和基于声明的授权.作为一种做法,我添加了一个用户DbInitializer
并为他分配了两个角色(管理员和经理).当我使用该用户登录时,我发现ClaimsPrincipal
在调试模式下,它已经将这些角色(Admin和Manager)关联为声明.所以这里是问题:
如果角色也被视为声明,那么b/w角色和声明的区别是什么?
如果我远离角色,我如何使用声明来保护web api控制器和相关的操作方法.就像,我有一个包含CRUD方法的订单控制器.我希望一个用户(比如一个经理)可以访问Create and Get方法,而第二个用户(一个管理员)可以访问所有这些方法.
我该怎么办?使用基于角色的系统,我只需用适当的Authorize(Role = "Admin")
属性修饰动作方法.我如何管理索赔?我是否需要将它们添加到数据库中并通过我的应用程序向不同用户授予/撤销这些声明?
原则上,角色和索赔之间没有太大的区别.我已经全神贯注于基于声明的授权,做了大量的研究和一些测试项目.在一天结束时,一切都归结于你决定使用哪一个.
如您所述,角色被添加为声明类型.因此,在交货方面,它没有任何区别.但是MVC/WebApi已经有内置的基础设施来处理角色,并且如果用户没有所需的角色则拒绝.所以你不必自己做很多事情.
但是你必须在控制器/操作上提出一些属性,并确保它们都存在于数据库中,因此可以将用户分配给它们.
但是我发现你可以拥有太多的角色,而且他们的维护成本太高了.此外,您不能为用户分配太多角色 - 他们的身份验证cookie将变得庞大,最终由于浏览器中的cookie大小限制而无法登录(每个cookie 4K,所有HTTP头16K).
声称您可以更灵活.您可以有许多不同类型的声明(我们每个控制器少于一个)和一些声明值(读取,创建,编辑,删除).对于下降大小的应用程序(我们有100以上),您将需要有很多角色(每个控制器4个)来建模这种级别的权限控制.对于索赔,我们有enum
索赔类型(人员,产品,订单)和enum
索赔值(创建,读取,编辑,删除).在cookie中,您可以将整数设置为声明类型和声明值 - 这可以在身份验证cookie上节省大量空间.
但有了声明,您必须自己编写身份验证机制的代码.
我一直在玩这个概念在这里,这是验证过滤器的MVC,但的WebAPI过滤器会看起来非常相似.现在这个原型的结果正在生产中并且运行良好.
总的来说,你的问题的答案是"它取决于".主要是关于身份验证的细化程度以及应用程序的大小.
归档时间: |
|
查看次数: |
3552 次 |
最近记录: |