我认为，许可/授权（不是身份验证）是一个跨领域的问题。
在洋葱架构或六边形架构中，应该在哪里执行权限？所需许可的示例是：
理想情况下，通过单一职责原则，执行业务操作和返回数据的代码根本不需要知道用户的权限。该功能的实现应该知道如何执行业务操作或查询存储库或域服务 - 就是这样。
实现与执行业务操作或返回数据的类相同的接口的包装器/外观是否是放置此权限的地方？或者，还有更好的方法？
此外，如果最佳实践是按活动而不是按角色进行许可，那么说许可应该由其目的只是返回数据的服务执行是否仍然有效？
有人可能会争辩说，访问检查应始终尽可能靠近执行操作的代码，以减少有人找到绕过访问检查的侧通道的机会。也就是说，如果您可以使用包装类来保证在生产系统中访问检查将始终到位，我认为这很好。
验证业务操作是否可以执行
我发现在包装器中放置访问检查以确定是否可以执行操作是很自然的。包装器代码通常是简单的胶水，它可以理解传递给受保护函数的参数，并将这些参数转换为适合做出授权决策的形式。
过滤返回到前端的数据（UI、API 或其他）
我假设您的意思是根据调用者的权限从查询响应中过滤行。例如，如果部门经理查询每个人的工资，则该经理将仅返回向他/她报告的人员的工资，因为他们无权访问其他人的工资。
对于这种类型的过滤，我从未找到将其作为横切关注点来实现的方法。我要么将过滤融入业务逻辑，要么退回到一个模型，该模型由于缺乏权限而拒绝执行查询。
我面临的问题是，要启用过滤，安全代码必须查看返回的数据并能够将权限与之关联。在简单的情况下执行此操作似乎需要大量的工作，而在复杂的情况下则非常麻烦（想象一个返回的数据集是多个数据库操作的连接）。
也就是说，我不反对内容过滤。我只是还没有看到一个好的解决方案。
Permissions by Activity 是您拥有权限和正在由授权 API 检查的活动的地方。这与角色和权限相同，授权是通过检查我们已指定角色已授权的业务对象的权限来完成的。这提供了灵活性，因为唯一固定的是权限，但我们可以有不同的角色——在数据库中定义完全独立于权限。
将授权逻辑与返回对象进行显示的服务和业务层完全分离的一种方法是使用自定义授权属性。在这些属性中，您可以指定用户需要拥有哪些权限才能在 MVC 控制器中执行操作。
检索用户有权访问的业务对象并在调用服务或存储库时将其用作输入，这是将授权逻辑与服务逻辑分开的好方法。例如——我是用户 x，可以访问客户 y、t、g 和 l——给我所有客户的订单。