应用域级权限的位置

Question

我认为，允许/授权(而不是身份验证)是一个交叉的问题。

在洋葱体系结构或六角体系结构中，应该在哪里执行许可？所需许可的例子如下：

• 过滤返回到前端的数据(UI、API或其他)
• 验证完全可以执行业务操作

理想情况下，通过单一责任原则，执行业务操作和返回数据的代码根本不需要知道用户的权限。该功能的实现应该知道如何执行业务操作或查询存储库或域服务--仅此而已。

实现与执行业务操作的类相同的接口或返回数据的包装/外观是否是放置此权限的地方？还是有更好的方法？

此外，如果最佳实践是按活动而不是通过角色进行权限，那么说允许应该由一个服务执行是否仍然有效，其目的仅仅是返回数据？

Answer 1

可以说，访问检查应该始终尽可能接近执行操作的代码，以减少某人找到绕过访问检查的侧通道的可能性。尽管如此，如果您可以使用一个包装类来保证在生产系统中，访问检查总是在适当的位置，我认为这是好的。

验证完全可以执行业务操作

我发现，将访问检查放在包装器中是否可以执行是非常自然的。包装器代码通常是简单的粘合剂，它理解传递给受保护函数的参数，并将这些参数转换为适合于进行授权决策的表单。

过滤返回到前端的数据(UI、API或其他)

这样，我假设您的意思是根据调用方的权限从查询的响应中筛选行。例如，如果部门经理询问每个人的薪资，经理将只返回向他/她报告的人的薪资，因为他们没有获得他人薪资的许可。

对于这种类型的过滤，我从未找到一种将其实现为横切关注点的方法。我要么已经对业务逻辑进行了过滤，要么回到了一个简单地由于缺乏权限而拒绝执行查询的模型上。

我面临的问题是，要启用筛选，安全代码必须查看返回的数据，并能够将权限与其关联起来。在简单的情况下这样做似乎需要相当多的工作，而在复杂的情况下则完全是多毛的(假设返回的数据集是几个数据库操作的联接)。

尽管如此，我并不反对内容过滤。我只是还没找到一个很好的解决办法。

Answer 2

按活动划分的权限是您拥有由授权API检查的权限和活动的地方。这与角色和权限是一样的，授权是通过检查我们指定角色的业务对象的权限来完成的。这提供了灵活性，因为唯一固定的是权限，但是我们可以有不同的角色--在DB中定义的角色完全独立于权限。

将授权逻辑与返回显示对象的服务和业务层完全分离开来的一种方法是使用自定义授权属性。在这些属性中，您可以指定用户在MVC控制器中执行操作所需的权限。

检索用户拥有权限的业务对象，并在调用服务或存储库时使用它们作为输入，是将授权逻辑与服务逻辑分离的好方法。这方面的例子是-我是用户x，可以访问客户y、t、g和l-给我所有客户的订单。