我有一个通过REST公开的API,并且正在考虑将权限限制放在何处。
我已经读到,有一种关于保护服务层的最佳实践,因为它是完成工作的那一层,您不知道将在何处调用它,但是我不确定关于WS的最佳实践是什么。层。
我的一个想法是,我需要在服务层上有一个非常细粒度的授权模型,在WS层上有一个非常粗粒度的授权模型,这样一方面可以最大程度地减少破坏DRY的原理,但仍然需要注意以下几点:纵深防御。
例:
对于Users
资源,有一个UserWS
和一个UserService
。管理员可以创建/更新/删除用户,而用户可以阅读有关其他用户的信息。
假定UserWS
绑定到,%root%/users
我将为intercept-url
具有该ROLE_USER
权限的URL 定义一个,该权限仅表示您必须是用户才能到达那里,但是服务层本身将为相关方法指定特定的权限。
其他选项是:
在服务和WS
-Pro 上都设置相同的授权要求- 您将尽早过滤掉入侵者(如果使用spring mvc,则保存例如参数的转换)
-配置重复是一项维护问题,容易出错=>安全问题
如果来自WS Con来,则仅将授权要求尽快放在WS -Pro-Filter上
。服务层可能在不同的上下文中使用
仅在服务上授权授权要求-
禁止重复复制
-允许“直截了当”的无效请求到达服务层的开销
非常感谢您对选项的任何反馈
Ittai,在WS和Service层使用完全相同的安全性机制被认为是在重复您自己-且需要在这两个级别进行维护。在WS层上没有任何安全性是一件坏事-因为您实际上让任何人都可以进入您的系统(即使您稍后再阻止他们-许多人也认为这是一件坏事)。简而言之,我认为您应该将两者混为一谈-在WS层使用一种非常粗糙的机制,在服务层使用一种非常强大的机制,这就是您不会重复自己并且不必在两个地方都维护代码的方式(因为不是相同的安全级别); 这样您就可以尽快过滤掉规模较小的用户,但仍应将其放置在很高的安全级别。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句