REST API 服务器上资源的细粒度权限
我正在使用类似 REST 的 API 构建数据交换服务器。它并不是严格意义上的 RESTful，因为服务器保存着某种状态，但我离题了。会话是使用 HTTP 身份验证和预先分配的 API 密钥的组合来构建的。 API 密钥允许服务器控制客户端可以访问哪些资源，以及在使用资源时可以执行哪些操作。
- 每个用户可以有多个密钥，但每个会话只能有一个。
- 某些密钥必须具有“平面”权限：它们只能查看和操作它们单独存储或以其他方式创建的数据。
- 其他密钥具有分层或基于角色的权限：除了查看和操作从属密钥之外，它们还可以执行平面密钥可以执行的所有操作。
- 将来，某些密钥可能会被授予特殊权限来创建、注册和委派自己的从属密钥。
- 总体而言，对所有资源的所有访问都将在“默认拒绝”的基础上进行。
考虑到这些要求并考虑到面向未来，我必须采取哪些选择才能实现这一目标？我看过很多基于 ACL 和/或基于角色的访问控制的解决方案，但我遇到的解决方案都没有能力进行如此细粒度的访问控制。
I'm building a data exchange server using a REST-like API. It's not strictly RESTful because there is some state being held by the server, but I digress. Sessions are built using a combination of HTTP Authentication and a pre-assigned API key. The API key allows a server to control which resources the client may access, and which actions they can take while using it.
- There can be multiple keys per user, but only one per session.
- Some keys must have "flat" permissions: they are only able to view and manipulate data that they alone have stored or otherwise created.
- Other keys have hierarchical or role-based permissions: they can do all that flat keys can, in addition to viewing and manipulating keys subordinate to them.
- In the future, some keys may be given special privilege to create, register and delegate their own subordinate keys.
- Overall, all access to all resources would be given on a "deny by default" basis.
Given these requirements and keeping in mind future-proofing, what sort of options do I have to accomplish this? I've looked at a lot of solutions based on both ACLs and/or Role-based access control, but none of the solutions I've come across have the ability to do such fine-grained access control.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我最终简化了系统要求：我最终没有使用 API 密钥作为会话标识符，而是采用完整的“RESTful”路线，并对每个请求进行身份验证，针对旨在处理该请求的 LDAP 后端。
对于授权，我使用了在 LDAP 中为用户分配的组集合作为该用户拥有的“角色”。它不像最初的设计那么灵活，但它足够实用，我可以在将来更改应用程序层，而不必担心设置后移植用户和权限。
I ended up simplifying the system requirements: instead of using API-keys as session identifiers, I ended up going the full "RESTful" route and authenticated on every request against an LDAP backend that was designed to handle it.
For authorization, I used the collection of groups a user is assigned in LDAP as the "roles" that user has. It's not as flexible as the original design, but it's pragmatic enough that I can change the application layer in the future and not worry about porting users and permissions after they're set up.