8

我有一个通过 REST 公开的 API，我正在考虑在哪里设置权限限制。
我读过有一个关于保护服务层的最佳实践，因为它是做工作的那个，你不知道它会在哪里被调用，但我不确定关于 WS 的最佳实践是什么层。
我的一个想法是，我需要在服务层有一个非常细粒度的授权模型，在 WS 层有一个非常粗粒度的授权模型，以尽量减少违反 DRY 原则，但仍然有一些概念纵深防御。

例子：

对于Users资源，有 aUserWS和 a UserService。管理员可以创建/更新/删除用户，用户可以阅读其他用户的信息。
假设UserWS绑定到%root%/users我将intercept-url为该 url定义一个ROLE_USER权限，它只是说您必须是用户才能到达那里，但服务层本身将指定相关方法的特定权限。

其他选项包括：

  • 对服务和 WS
    -Pro 设置相同的授权要求-您将尽可能早地过滤掉入侵者（如果您使用的是 spring mvc，则保存例如参数转换）-
    重复配置是一种维护问题并且容易出错=>安全问题


  • 如果来自 WS Con，请尽快将授权要求仅放在 WS -Pro-Filter 上
    -可能从不同的上下文中使用服务层

  • 仅在服务上列出授权要求-
    Pro- No Duplication
    Con- 允许“直言不讳”的无能请求到达服务层的开销

非常感谢有关选项的任何反馈

4

2 回答 2

6

Ittai，在 WS 和 Service 层使用完全相同的安全机制被认为是重复自己 - 它需要在这两个级别进行维护。在 WS 层没有任何安全性是一件坏事——因为你实际上让任何人进入你的系统（即使你稍后会阻止他们——许多人认为这是一件坏事）。简而言之，我认为您应该将这两者混为一谈——在 WS 层使用非常粗糙的机制，在服务层使用非常强大的机制，这样您就不会重复自己并且不必在两个地方维护代码（如它不是相同的安全级别）；并且您将能够尽快过滤掉身材矮小的用户，但仍然具有非常高的安全级别，应该放置它。

于 2012-05-20T07:05:28.743 回答
0

如果你有时间，我会说两者，如果没有，只有服务层。

保护演示文稿和服务总是好的，因为如果您将服务公开给演示文稿以外的其他内容（例如公开 Web 服务），那么您的安全性已经到位并且已经完成。

此外，如果有人找到绕过您的表示层的方法（例如您有层并且您的服务在远程机器上运行），您仍然可以确保安全。

于 2012-05-16T08:45:16.727 回答