RESTful服务中的资源级授权
令 /users/{id}
为 RESTful 服务中的资源 url。
启用基本身份验证,仅允许经过身份验证的用户访问该 url。
示例场景:
User_1
& User_2
是经过身份验证的用户,其 userId 为 1 & 2. 由于两者都经过身份验证,因此它们都可以访问
/users/1
/users/2
但期望 User_1
应该具有访问权限到 /users/1
而不是 /users/2
或其他 userId。
问题: 如何在RESTful服务中进行资源级授权?
注意:我正在使用 Jax-RS 实现 RESTful(使用 Apache CXF 实现),如果您能用 Jax-RS 进行解释,将会很有帮助。
-Barath
编辑:
正如 Donal 提到的,我不是在寻找基于角色的授权,而是在寻找资源级别的授权。
举个例子,假设 /users/{id}/photos/{photoId} 是另一个资源 URL。应授予 User_1 访问仅属于他的照片的权限。如果 photoId 为 2 属于 user_2,那么当请求 /users/1/photos/2 时,我们应该为 user_1 提供 http_404 错误代码。[由于 User_1 也是经过身份验证的用户,因此他可以调用 /users/2/photos/2,所以我们必须根据身份验证参数而不是通过资源 url 来识别用户 id]
我能想到的唯一解决方案是,包含确定每个查询中的授权的唯一 id,
而不是SELECT * FROM PHOTO_TBL WHERE PHOTO_ID=2;
使用 SELECT * FROM PHOTO_TBL, USER_TBL WHERE PHOTO_ID=2 AND USER_ID=1 AND USER_ID=PHOTO_ID;
使用此资源可提供以下数据:属于特定用户。 [应该有一种机制来防止客户端修改用于决定授权的唯一 ID(在本例中为 userId),因为所有请求都是无状态请求]
警告每一个查询应该足够智能,能够理解安全问题并包含额外的联接。将安全逻辑与每个业务功能联系起来是一个糟糕的设计。
我还没有研究 Spring security 以及如何在这个用例中使用它。
Let /users/{id}
be a resource url in RESTful service.
Basic authentication is enabled and only authenticated users are allowed to access the url.
Example Scenario:
User_1
& User_2
are authenticated users with userId 1 & 2.
Since both are authenticated, both of them are having access to,
/users/1
/users/2
But the expectation is User_1
should have access to /users/1
and not to /users/2
or other userId.
Question:
How to do resource level authorization in RESTful services?
Note: I am implementing RESTful using Jax-RS (with Apache CXF implementation), helpful if you could explain with Jax-RS.
-Barath
Edit:
As Donal mentioned, I am not looking for role based authorization rather resource level authorization.
To give an example, lets say /users/{id}/photos/{photoId} be another resource url. User_1 should be given access to the photos belong to him only. If photoId of 2 belonging to user_2, then we should give http_404 error code for user_1 when a request /users/1/photos/2 is requested.[Since User_1 is also authenticated user he can invoke /users/2/photos/2, so we must identify the user id based on authentication parameters than via resource url]
Only solution I can think of is, include the unique id which determines the authorization in each query like,
Instead of SELECT * FROM PHOTO_TBL WHERE PHOTO_ID=2;
use SELECT * FROM PHOTO_TBL, USER_TBL WHERE PHOTO_ID=2 AND USER_ID=1 AND USER_ID=PHOTO_ID;
with this resources are delivering data that belongs to specific user. [There should be a mechanism to prevent the modification of the unique id in client side which is used to decide on authorization(userId in this case), since all requests are STATELESS request]
Caveat: Each and every query should be intelligent enough to understand the security concerns and include extra join. This is a bad design to tie up security logic to every business function.
I am yet to look into Spring security and how it can be used in this use case.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我建议不要在 url 中包含用户 ID(就好像它受到 Basic Auth 标头的“限制”,那么您也可以通过 Basic Auth 标头“指定”它)。这将降低引入直接对象引用漏洞的风险 - https://www. owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)
在这种情况下,您可以有以下之一urls:
由于照片是子资源,因此您可以在用户中创建带有“序列号”的照片。在 SQL 数据库中,这意味着在用户列和照片列上都有一个“复合键”。
然后你的 SQL 看起来像这样:
“Basic Auth Headers”的一个很好的解释:
http://en.wikipedia .org/wiki/Basic_access_authentication
I would recommend not having the user id in the url (as if it's being 'limited' by a Basic Auth header then you may as well just have it 'specified' by the Basic auth header). This will reduce the risk of introducing a Direct Object Reference Vulnerability - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)
In this case you could have one of the following urls:
As photos is a sub resource then you could just create the photos with a "sequence number" within the user. In a sql database this would mean having a "compound key" across both user and photo columns.
Your SQL would then look something like:
A good explanation of "Basic Auth Headers":
http://en.wikipedia.org/wiki/Basic_access_authentication
JAX-RS 指定子资源其中不是在方法中处理请求,而是将处理委托给其他对象 - 子资源。
使用子资源就足以处理根资源,并且嵌套资源也将得到保护。
在示例中,您可以看到 UserResource 及其所有子资源仅对授权用户可用。
JAX-RS specifies sub-resource where instead of handling request in a method, processing is delegated to other object - sub-resource.
Using sub-resources it's enought to take care of the root resource and nested ones will be secured as well.
In the example you can see UserResource and all it's sub-resources available only to authorized user.