我有一个API，我通过REST公开，我正在考虑在哪里放置权限限制。
我已经读到有一个关于保护服务层的最佳实践，因为它正在进行工作，你不知道它将被调用到哪里但是我不确定什么是关于WS的最佳实践层。
我有一个想法是，我需要在服务层上有一个非常精细的授权模型和WS层上非常粗糙的授权模型，以便最大限度地减少破坏DRY原则，但仍然有一些概念深度防守。
示例：
对于Users资源，有一个UserWS和一个UserService。管理员可以创建/更新/删除用户，用户可以阅读其他用户
假设UserWS绑定到%root%/users，我将为{url}定义一个intercept-url ROLE_USER权限，只是说你必须是一个用户才能到达那里但是服务层本身将指定相关方法的特定权限。
其他选项包括：
对服务和WS-发出相同的授权要求
Pro-你会尽早过滤掉入侵者（如果你使用的是弹簧mvc，请保存参数转换）
配置的复制是一个维护问题，容易出错=＆gt;安全问题
仅将授权要求放在WS-上 如果来自WS，请尽快过滤 Con-服务层可能来自不同的上下文
仅在服务上填写授权要求 -
Pro-No Duplication
允许“直率”无效请求到达服务层的开销
非常感谢有关选项的任何反馈
答案 0 :(得分：6)
以太， 在WS和Service层使用相同的安全机制被认为是重复自己 - 它需要在这两个级别进行维护。 在WS层没有任何安全性是件坏事 - 因为你实际上让任何人进入你的系统（即使你以后会阻止他们 - 很多人认为这是一件坏事）。 简而言之，我认为你应该混淆这两个 - 在WS层使用非常粗略的机制，在服务层使用非常强大的机制，这就是你不会重复自己而不必在两个地方维护代码的方式（如它不是SAME安全级别）;并且您将能够尽快过滤掉尺寸不足的用户，但仍然应该具有非常高的安全级别。
答案 1 :(得分：0)
如果你有时间，我会说两者，如果没有，我会说服务层。
它总是很好地保护演示文稿和服务，因为如果您将服务暴露给演示文稿以外的其他内容（例如，您公开了Web服务），那么您将获得安全性并已经完成。
此外，如果有人找到绕过您的表示层的方法（假设您有自己的层并且您的服务在远程计算机上运行），那么您仍然可以获得安全保障。