我正在尝试使用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")属性修饰操作方法。我如何管理索赔？我是否需要将它们添加到数据库中并通过我的应用程序向不同用户授予/撤销这些声明？
答案 0 :(得分：6)
原则上，角色和索赔之间没有太大的区别。我已经全神贯注于基于声明的授权，完成了大量的研究和一些测试项目。在一天结束时，一切都归结于你决定使用哪一个。
正如您所说，角色是作为声明类型添加的。因此，在交货方面，它没有任何区别。但是MVC / WebApi已经有内置的基础设施来处理角色，并且如果用户没有所需的角色则拒绝。所以你不必自己做很多事 但是你必须在控制器/操作上提出一系列属性，并确保它们都存在于数据库中，因此可以将用户分配给它们。
然而，我发现你可以拥有太多的角色，而且他们的维护成本太高。此外，您无法为用户分配太多角色 - 他们的身份验证cookie将变得庞大，最终由于浏览器中的cookie大小限制而无法登录（每个cookie为4K，所有HTTP头为16K）。
通过声明，您可以更灵活。您可以有许多不同类型的声明（我们每个控制器少于一个）和一些声明值（读取，创建，编辑，删除）。对于下降大小的应用程序（我们有100以上），您必须有很多角色（每个控制器4个）来建模这种级别的权限控制。对于声明，我们对声明类型（人员，产品，订单）enum以及enum声明值（创建，读取，编辑，删除）。在cookie中，您可以将整数设置为声明类型和声明值 - 这可以在身份验证cookie上节省大量空间。
但声称您必须自己编写身份验证机制代码。
我一直在使用这个概念here，这对于MVC来说是authentication filter，但WebApi过滤器看起来非常相似。现在这个原型的结果正在生产中并且运行良好。
总的来说，你的问题的答案是＆＃34;它取决于＆＃34;。主要是关于身份验证的细化程度以及应用程序的大小。