Question

检索用户有权访问的所有资源的列表的推荐方法是什么？

在我看到的许多示例中，授权被放入一个单独的服务中 - 通常是一个公开类似于isAuthorized（）的方法，可以用于单个查询（“用户是否有权使用资源ABC？ “）以及批量查询（”用户是否有权使用以下任何资源列表？“）。

虽然授权服务中存在 authorization-logic ，但授权策略的强制保留在应用程序本身内（例如，用于实际实现的业务逻辑层）根据授权服务的结果访问资源;或者根据授权服务的结果显示/隐藏各个选项的表示层。）

例如，如果我的数据访问层有可能返回的数十亿“资源”，那么首选方法是什么？我的业务逻辑层是否查询所有数据（通过网络传递所有数据），然后将该巨型列表转发到授权服务（再次通过网络），只获得“ALLOW / DENY”的巨大列表发回业务逻辑？显然这听起来不太对劲。

这是否是我们无法对数据访问，授权逻辑和业务逻辑进行“干净”分离的情况？我是不是要求我的数据访问层只返回给我一个用户可以访问的所有资源的列表，这可能最终被实现为一个简单的数据库连接，但是然后需要一些逻辑来确定谁可以访问在什么条件下（即授权策略）嵌入数据访问代码中的哪些资源，因此这些策略将在我的代码库中传播（例如，某些授权逻辑将在我的数据访问中）层，有些会在我的授权层等等。）

也许性能胜过“干净”的架构，但是有更好的方法吗？

Answer 1

身份验证最好外部化。授权通常过于依赖于应用程序外部化。它可能适用于小系统。但是对于大型系统，您会遇到预期的扩展问题。

另一件事是返回庞大的数据集。在我看来，这更适合报道。因此，将第一个流程模块与报告模块分开，这些模块具有不同的要求，因为在业务流程中，您需要关注数据并报告海量数据和抽象。

授权不是一个层。这是一个方面。如果您不至少使用正确的模拟替换它，则应用程序可能无法在没有图层的情况下工作。但是，如果删除方面，则运行应用程序时应该没有问题。也许您的程序不会记录任何内容，或者您将能够看到比您可以看到的更多的数据，但它仍然有效。

那么授权是否应该从应用程序域外部化？不，它应该与业务逻辑分开吗？是。正确的机制：方面（AspectJ，代理模式，模板类模式）。这是我的一般建议。

我对业务流程中“巨大数据”的特别建议是：尝试正确划分您的域模型以获得很少的焦点数据（主题“可用性”或“用户体验”）。然后回到我的一般建议。

如果您必须处理业务流程中的大量数据：使用“让它工作正确使其快速”的最后一点。将其视为特殊数据请求的优化，这些请求是预期的或预计会很慢。在这种情况下，使用特殊的SQL查询，预加载，缓存等.DAO层可能是DAO层的正确位置，缓存方面或优化方面，它覆盖了“工作缓慢” - 实现的替代实现快。

我提出的建议涉及正常的商业用例。我不是在谈论大数据或报道。正如我所提到的，这些部门有不同的要求。

Answer 2

我对你的问题没有明确的答案，但我可以提供一些指示 -

你问了

我的业务逻辑层是否查询所有数据，然后转发那个巨人名单上的授权服务，只是为了得到一个巨人 “ALLOW / DENY”列表发送回业务逻辑？

嗯，这对我来说似乎不太可能。你能想到一个你想要向用户提供所有可用记录的情况吗？你想要进一步过滤那些记录（即按类型，日期等等）是不是更合理，而且你可能也想要对它们进行分页，以便用户获得一个一口大小的结果集。

除此之外，您很可能只是将记录的标识符传递给您的服务，您可能会发现这种方法对您来说是可行的。
另请注意，将您的授权逻辑作为“服务”并不一定意味着它必须驻留在不同的计算机上;您可以将其作为单独的逻辑模块实现，并且仍然可以在同一台计算机上运行（如果您愿意，可以在与应用程序相同的进程上运行），从而避免网络流量问题。
您的观察认为将授权作为数据访问的一部分实施可能很棘手是正确的。但是，有一些基础设施工具可以帮助您。例如 - oracle的virtual private database，(n)hibernate filters，我确信还有其他人。

同样，这些不是完整的答案，但它们可能会引导您找到适合您的解决方案我建议你谷歌'授权框架+ [你最喜欢的编程语言]';我确定有人已经在以前完成了它：）

Answer 3

我有一个萌芽的想法，不是基于任何实践经验，但乍一看它是合理的。

为什么我们有授权服务？我的主张是我们拥有该服务的一些功能，因为我们的数据源没有做完整的工作。如果我们只使用RDBMS数据库作为我们数据的来源，那么数据库可以监管主要类别的授权。我们可以使用Views并授予权限来访问这些视图，从而保护表和列。那时仍然有这类规则

员工的薪资信息可以显示给a）。员工， B）。他们的经理和二线经理，c）。人力资源部成员薪酬团队。

我认为这样的授权规则具有业务语义，最好由授权服务实现，并且该服务的表达式是业务对象：

 can This employee see That employee's salary?

它不是以表格，行和列的形式表达，而是以粗略的，商业意义的粒度表示。实现这一点需要构建一个表达授权规则的数据模型，严格来说这是业务逻辑，我们只需选择重构授权服务来封装实现。

将此与细粒度实体授权进行对比，以视图，表格和列表示。我的主张是，这恰当属于数据源，如果我们的数据源不能或不能实现它，那么我们需要在我们的数据访问层实现它。 DAO“知道”他们使用哪些视图/表，并且可能也知道代表谁正在运行请求的id，因此决定是否允许访问。

松散地说：DAO有SQL所以知道实体，所以可以决定。（是的，某些后端可能没有SQL，但是DAO是了解正在检索内容的对象。）可以通过一种方法来丰富它，以列出给定用户允许哪种访问方法。

 CustomerDAO.whatIsAuthorised("joeCoder") => READ, QUERY

 CustomerDAO.whatIsAuthorised("phb") => READ, QUERY, UPDATE

授权服务 - 返回授权资源列表

3 个答案: