【问题标题】:role based access to methods基于角色的方法访问
【发布时间】:2011-04-25 20:16:04
【问题描述】:
我正在实现系统,该系统使用基于角色的访问类中的不同方法。例如,要执行任何操作,我需要检查使用它的用户是否可以执行此操作。
每种方法我都可以写:
if(User.IsInRole ...) {
} else {
return ... throw ... whatever
}
我正在考虑自动化这个过程,例如通过向这个方法或任何其他解决方案添加属性?
【问题讨论】:
标签:
c#
.net
security
methods
security-roles
【解决方案1】:
只要你使用主体,事情就已经存在了......
[PrincipalPermission(SecurityAction.Demand, Role = "A role available on your principal")]
public void Foo()
{
// Will throw an exception if the principal does not have the required role
// Otherwise the method will execute normally
}
【解决方案2】:
在构建时检查一次,如果不满足安全条件则抛出(或工厂返回NULL)。此后,持有对给定模型对象的引用就足以证明您在早些时候通过了安全检查。如果您担心这会导致TOCTTOU 问题,请确保这些对象在应用程序定义的“游戏回合”概念(通常是数据库事务)结束时变得不可用;无论如何,这是一个很好的做法。
这种安全方法称为capability discipline。将您的对象视为具有some authority inside them(在其私有变量中)的框。通过按下框上的按钮,您只能以对象程序员允许的方式行使该权限的一部分。
例如,假设您正在编写一个带有 SQL 后端的日历应用程序。有 SQLTransaction 对象,它不会超过事务(如上所述),但它仍然拥有应用程序使用的所有表的所有权限。这是您不想传递给 API 用户的很多功能(明确地或错误地,想想 SQL 注入)。相反,您分发 User 对象,这些对象模拟了仅写入用户表中该用户行的权限; User 还可以创建、读取、更新、删除 Appointment 对象,这些对象同样代表 Appointments 表中的有限权限。
要在整个 API 中维护 RBAC,您必须确保满足以下条件:
- 只有合法用户才能访问代表他们的
User 对象。这是您将身份验证系统连接到 User 构造函数的地方;
-
User 对象不 leak authority,即您必须审核您的 API 以确保通过对 User(或它们返回的任何相关对象,递归)执行方法调用,您无法读取或更改任何不属于该用户的资源。在这里您可以应用 facet 模式 - 例如,User.GetAppointments() 为该用户创建的约会返回真实的 Appointment 实例,但为其他人创建的约会返回只读包装器。