Sof*_*ons 6 architecture service authorization
检索用户有权访问的所有资源的列表的推荐方法是什么？
在我看到的许多示例中,授权被放置在一个单独的服务中 - 通常是一个公开类似于isAuthorized()的方法,可以用于单个查询("用户是否有权使用资源ABC？")以及批量查询("用户是否有权使用以下任何资源列表？").
虽然授权服务中存在授权逻辑,但授权策略的实施保留在应用程序本身内(例如,用于实际实现对资源的访问的业务逻辑层,基于授权服务的结果;或者演示文稿图层,用于根据授权服务的结果显示/隐藏各个选项,等等.
例如,如果我的数据访问层有可能返回的数十亿"资源",那么首选的方法是什么？我的业务逻辑层是否查询所有数据(通过网络传递所有数据),然后将该巨型列表转发到授权服务(再次通过网络),只获得一个巨大的"允许/拒绝"列表发回业务逻辑？显然这听起来不太对劲.
这是否是我们无法对数据访问,授权逻辑和业务逻辑进行"干净"分离的情况？我是不是要求我的数据访问层只返回给我一个用户可以访问的所有资源的列表,这可能最终被实现为一个简单的数据库连接,但是然后需要一些逻辑来确定谁可以访问在什么条件下(即授权策略)嵌入数据访问代码中的哪些资源,因此这些策略将在我的代码库中传播(例如,某些授权逻辑将在我的数据访问中)层,有些会在我的授权层等等)？
也许性能胜过"干净"的架构,但是有更好的方法吗？
我对你的问题没有明确的答案，但我也许可以提供一些建议——
我的业务逻辑层是否查询所有这些数据，然后将该巨大列表转发到授权服务，只是为了将“允许/拒绝”的巨大列表发送回业务逻辑？
再加上您很可能只在您的服务之间传递记录的标识符，您可能会发现这种方法对您来说是可行的。
另请注意，将授权逻辑作为“服务”并不一定意味着它必须驻留在不同的计算机上；您可以将其实现为单独的逻辑模块，并且仍然让它在同一台计算机上运行（如果您愿意，可以与您的应用程序在同一进程上），从而避免网络流量问题。
您认为将授权作为数据访问的一部分实施可能很棘手，这是正确的。然而，有一些基础设施工具可以帮助您做到这一点。例如，oracle 的虚拟专用数据库、(n)hibernate 过滤器，我确信还有其他的。
同样，这些并不是完整的答案，但它们可能会引导您找到适合您的解决方案。
我建议你谷歌“授权框架+ [你最喜欢的编程语言]”；我确信之前已经有人做过了:)