基于角色的方法访问

发布于 2024-09-27 17:54:47 字数 227 浏览 1 评论 0原文

我正在实现一个系统，该系统使用基于角色的访问来访问类中的不同方法。例如，要执行任何操作，我需要检查使用它的用户是否可以执行该操作。

我可以在每个方法中写入：

if(User.IsInRole ...) {
} else {
return ... throw ... whatever
}

我正在考虑自动化此过程，例如通过向此方法添加属性或任何其他解决方案？

原文

I'm implementing system which uses role based access to different methods in classes. For example to perform any action I need to check whether user which uses it can do it.

I can write in each method:

if(User.IsInRole ...) {
} else {
return ... throw ... whatever
}

I was thinking about automating this process for example by adding attributes to this methods or maybe any other solution?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

美人骨 2024-10-04 17:54:47

只要你使用principles，事情就已经存在了......

[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
}

As long as you use principals things are already there...

[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
}

回复收藏 0 原文

人│生佛魔见 2024-10-04 17:54:47

在构造时检查一次，如果不满足安全条件，则抛出（或从工厂返回 NULL）。此后，持有对给定模型对象的引用就足以证明您在较早的某个时刻通过了安全检查。如果您担心这可能会导致TOCTTOU问题，确保这些对象在应用程序定义的“游戏回合”概念（通常是数据库事务）结束时变得不可用；无论如何，这是一个很好的做法。

这种安全方法称为能力规则。将您的对象视为具有内部具有某些权限的盒子< /a> （在他们的私有变量中）。通过按下框上的按钮，您只能按照对象程序员允许的方式行使此权限的定制部分。

例如，假设您正在编写一个带有 SQL 后端的日历应用程序。 SQLTransaction 对象的寿命不会比事务长（如上所述），但它仍然拥有应用程序使用的所有表的所有权限。您不想将这些强大的功能传递给 API 的用户（无论是明确的还是错误的，例如 SQL 注入）。相反，您分发 User 对象来模拟仅写入 Users 表中该用户的行的权限； User 还可以创建、读取、更新、删除 Appointment 对象，这些对象同样代表 Appointments 表中的有限权限。

要在整个 API 中维护 RBAC，您必须确保满足以下条件：

只有合法用户才能访问代表他们的 User 对象。您可以在此处将身份验证系统连接到 User 构造函数中；
User 对象不会泄漏权限，即，您必须审核您的API，以确保通过对User（或它们递归返回的任何相关对象）执行方法调用，您无法读取或更改不属于该用户的任何资源。您可以在此处应用 facet 模式 - 例如 User.GetAppointments() 为该用户创建的约会返回真实的 Appointment 实例，但为其他人创建的约会返回只读包装器。

Do the check once at construction time, and throw (or return NULL from the factory) if the security condition is not met. Thereafter, holding a reference to a given model object is enough proof that you passed the security check at some earlier point. If you are worried that this could cause TOCTTOU issues, ensure that these objects become unusable at the end of an application-defined concept of "game turn" (typically the database transaction); this is a good practice anyway.

This approach of security is called capability discipline. Think of your objects as boxes that have some authority inside them (in their private variables). By pressing the buttons on the box, you can only exercise a tailored down fraction of this authority in the ways that the programmer of the object allows you to.

For example, say you are writing a calendar application with an SQL backend. There is the SQLTransaction object, which doesn't outlive the transaction (as per above) but still it has all the rights to all the tables that the application uses. That's a lot of power that you don't want to be passing around to users of your API (explicitly or by mistake, think SQL injection). Instead you hand out User objects that model the authority to write only to that user's row in the Users table; also a User can create, read, update, delete Appointment objects, which similarly represent limited authority in the Appointments table.

To maintain RBAC throughout your API, you must ensure that the following hold:

Only legitimate users can get access to the User object that represents them. This is where you wire up the authentication system into the User constructor;
The User objects do not leak authority, ie you have to audit your API to make sure that by exercising method calls on a User (or any related object they return, recursively) you cannot read or alter any resources that do not belong to this user. This is where you can apply the facet pattern — eg User.GetAppointments() returns real Appointment instances for appointments created by this user, but read-only wrappers for those created by someone else.