透明授权可靠性
我需要一个用于业务逻辑类中的自定义授权的齿轮。它必须是基于权限的系统，但我无法决定如何将授权规则应用于方法。
我的第一个想法是将自定义属性应用于方法
[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
// some code goes here
}
我的业务逻辑类具有接口，因此我可以使用 Unity 拦截行为并在运行时检查当前用户是否具有所需的权限。如果他没有，则抛出异常。
但现在我担心这种方法的可靠性。
通常是对unity容器注入的业务逻辑类的引用。所以没有问题，因为它配置为应用接口拦截机制。
但是，如果某些开发人员直接实例化我的业务逻辑类怎么办？然后，将不会应用任何拦截，即使当前用户无权执行某些操作或者甚至未通过身份验证，他也将能够调用任何方法。
也有人可以更改 Unity 容器配置，完全关闭拦截扩展。我的授权系统再次无法工作。
我看到 ASP .NET MVC 使用类似的授权机制。仅当请求通过标准方式（IController.Execute）发出时才应用授权规则。我认为在这种情况下这不是问题，因为控制器的最终用户（网络用户）无法直接访问控制器类。
在我的例子中，业务逻辑的最终用户是开发前端的程序员，他可以有意或无意地搞砸事情 - 创建业务逻辑类的实例并调用任何方法。
你能给我什么建议？您如何处理此类问题？
谢谢。
I need a gear for custom authorization in business logic classes. It has to be permissions based system, but I can not decide how to apply authorization rules to methods.
My first thought was to apply custom attributes to method
[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
// some code goes here
}
My business logic class has interface, so I can use, for example, Unity Interception behavior and check in runtime if current user has required permissions. And throw an exception if he has not.
But now I'm concerned about reliability of this method.
Usually the reference to business logic class injected by unity container. So there is no problem because it is configured to apply interface interception mechanism.
But what if some developer will instantiate my business logic class directly? Then no interception will be applied and he will be able to call any method even if current user has not permissions to make some actions or even he is not authenticated.
Also somebody can change unity container configuration, turn off Interception extension completly. Again my authorization system will not work.
I saw ASP .NET MVC is using similar mechanism for authorization. Authorization rule is applied only when request came by standard way (IController.Execute). I think this is not a problem in this case because end user of controller (web user) has no way to access controller class directly.
In my case end user of business logic is a programmer who develops front end and he can intentionally or unintentionally screw things - create instance of business logic class and call any methods.
What can you suggest me? How do you deal with this kind of problems?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
.NET Framework 支持声明性权限验证机制，该机制不依赖于 Unity 拦截或其他“外部”AOP。为了利用这一点，您的属性必须继承自 System.Security.Permissions.CodeAccessSecurityAttribute。 System.Security.Permissions.PrincipalPermissionAttribute BCL 中包含的是使用此机制评估用户权限的示例。如果它不能满足您的需求，没有什么可以阻止您创建自己的满足需求的属性。
The .NET Framework supports a mechanism for declarative permission verifications that does not depend on Unity interception or other "external" AOP. In order to take advantage of this, your attribute must inherit from System.Security.Permissions.CodeAccessSecurityAttribute. The System.Security.Permissions.PrincipalPermissionAttribute that is included in the BCL is an example of using this mechanism to evaluate user permissions. If it does not suit your needs, there's nothing stopping you from creating your own attribute that does.
如果您的构造函数是内部的，并且您的对象是从工厂实例化的，那么开发人员将无法错误地绕过您的安全性。
如果有人真的非常想在没有安全性的情况下创建你的对象，他仍然可以使用反射来做到这一点，但这将是非常有意这样做的。
If your constructors are internal and your objects instantiated from a factory, a developper won't be able to bypass your security by error.
If someone really, really wants to create your objets without the security, he could still do it using reflection, but this would have be pretty intentional to do so.