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.
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.