我们的产品构建在客户端 - 服务器架构之上，服务器用Java实现（我们在Spring框架中使用POJO） . 我们在服务器上有两个API级别：
-
external API ，它使用REST Web服务 - 对外部客户端和与其他服务器的集成很有用 .
-
internal API ，它使用纯Java类 - 对于内部的实际代码很有用（业务逻辑多次调用API调用），以及与在公司内部开发并作为产品部分部署的plusins集成 . 外部REST API也使用内部API .
我们在内部API中实现了权限检查（使用Spring安全性），因为我们希望控制最低API级别的访问 .
But here comes the problem ：在API级别上定义了一些被视为当前登录用户禁止的操作，但应由服务器本身顺利执行 . 例如，可以禁止用户删除某个实体，但服务器可能希望删除该实体作为用户执行的某些其他操作的副作用，并且我们希望允许这样做 .
那么允许服务器执行可能被实际登录用户禁止的操作（在某种超级用户模式下）的最佳方法是什么？
在我看来，我们有几个选项，每个选项都有其优点和缺点：
-
在外部级API（REST）中实施权限检查 - 不好，因为插件将绕过权限检查 .
-
在请求被授予后关闭当前线程的权限检查 - 太危险了，我们可能允许太多应该被禁止的服务器操作 .
-
明确要求内部API级别以特权模式执行操作（就像java安全框架中的PrivilegedAction一样） - 太详细了 .
由于上述方法都不理想， I wonder what is the best-practice approach for this problem?
谢谢 .
3 回答
安全性应用于模块的边界 . 如果我了解您，您的系统会在（大致）相同API的两个抽象级别上应用安全性 . 这听起来很复杂，因为您必须对整个两个API进行双重安全检查 .
考虑将REST所需的方法从内部API迁移到外部API，并删除内部API中的安全性内容 .
外部API将管理外部客户端的安全性（在应用程序的边界）
内部API将严格保留用于内部应用程序和插件使用（你会很高兴破解它，因为没有外部客户端限制它）
您真的需要控制插件对应用程序逻辑的权限吗？它有充分的理由吗？毕竟，插件是由贵公司开发的 . 也许正式文档向插件的开发人员解释不应该做什么，或者插件的安全测试套件验证（例如断言插件不称为“此”方法）也可以完成这项工作 .
如果您仍然需要将这些插件视为“不受信任”，请将他们需要的方法添加到您的外部API（在您的应用程序边界上），并为每次使用创建特定的安全配置文件：“restProfile”，“clientProfile”和“pluginProfile” . 每个人都拥有外部API方法的特定权利 .
听起来你需要两个级别的内部API，一个暴露给插件，一个不暴露 .
启用它的最佳方法是使用OSGi（或Spring Modules） . 它允许您明确说明其他模块（即REST模块和插件模块）可以访问哪些包和类 . 这些将是您的新内部API的暴露级别，您将使用Spring Security进一步有选择地进一步限制访问 . 内部包和类将包含执行所有低级内容（如删除实体）的方法，您将无法直接调用它们 . 一些公开的API只会通过安全检查复制内部API，但这没关系 .
最好的方法的问题是Spring Modules让我觉得有点太不成熟，甚至投入一个新的webapp项目 . 我不可能把它变成一个旧项目 .
您可以使用Spring Security和AspectJ实现类似的功能，但令我印象深刻的是性能开销过高 .
如果您可以重新构建系统，那么一个非常酷的解决方案是将需要安全性提升的任务脱机，或者使它们异步 . 使用Quartz和/或Apache Camel（或者正确的ESB）您可以使“删除我的帐户”方法创建一个离线任务，该任务可以在将来的某个日期作为管理主机的原子工作单元执行 . 这意味着您可以在完全独立的线程中对请求删除帐户的用户进行安全检查，以实际删除 . 这样做的好处是可以使Web线程更具响应性，尽管您仍然希望立即执行某些操作以保留所请求的操作已完成的错觉 .
如果你使用Spring，你也可以充分利用它 . Spring提供AOP，允许您使用拦截器并执行这些跨系统检查，并且在未经授权的情况下，阻止该操作 .
您可以在Spring的在线文档here中阅读更多相关信息 .
希望这可以帮助...
Yuval = 8-）