透明授权可靠性

Question

我需要在业务逻辑类中进行自定义授权。它必须是基于权限的系统，但我无法决定如何将授权规则应用于方法。

我的第一个想法是将自定义属性应用于方法。

[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
     // some code goes here
}

我的业务逻辑类有接口，所以我可以使用，例如，统一拦截行为，并在运行时签入当前用户是否具有所需的权限。如果他没有，就抛出一个例外。

但现在我担心这个方法的可靠性。

通常由统一容器注入对业务逻辑类的引用。因此，没有问题，因为它被配置为应用接口拦截机制。

但是，如果某些开发人员将直接实例化我的业务逻辑类，怎么办？然后将不应用任何拦截，即使当前用户没有权限执行某些操作，甚至没有身份验证，他也可以调用任何方法。

也有人可以改变统一容器的配置，完全关闭拦截扩展。再一次，我的授权系统将无法工作。

我看到ASP .NET MVC正在使用类似的授权机制。只有在通过标准方式(IController.Execute)请求时才应用授权规则。在这种情况下，我认为这不是一个问题，因为控制器的最终用户(web用户)无法直接访问控制器类。

在我的例子中，业务逻辑的最终用户是开发前端的程序员，他可以有意或无意地拧碎东西--创建业务逻辑类的实例并调用任何方法。

你能给我什么建议？你是如何处理这种问题的？

谢谢。

Answer 1

.NET框架支持一种不依赖于统一拦截或其他“外部”AOP的声明性权限验证机制。为了利用这一点，您的属性必须从System.Security.Permissions.CodeAccessSecurityAttribute继承。BCL中包含的System.Security.Permissions.PrincipalPermissionAttribute就是使用此机制评估用户权限的一个例子。如果它不适合您的需要，没有什么可以阻止您创建您自己的属性。

Answer 2

如果您的构造函数是内部的，并且您的对象是从工厂实例化的，开发人员将无法通过错误绕过您的安全性。

如果有人真的，真的想在没有安全性的情况下创建你的视图，他仍然可以使用反射来实现，但这是非常有意的。