In case I just missed them, are there some comparable projects to this? Is there an established library in the space?
But we do not have any multi tenant requirements.
However, usually major programming languages have some sort of ACL/RBAC module around.
For anyone struggling with permissions, it might be easier to think about them in terms of which actions are available to a user at each endpoint, something along the lines of this with HATEOAS and filtering links:
A few things that ACLs can potentially break:
* PUT/PATCH requests: every relationship (and every attribute if using field-level security) of every resource needs permissions checks
* Database consistency: if logic is too complex to put in triggers, then permissions table can get out of sync with roles
* Russian doll caching (and caching in general): views now vary by user based on what subviews are visible
There are so many ramifications with permissions systems that it's worth implementing them early on in your project if you know you'll need them, or approaching them from a different angle like how Firebase rules are implemented declaratively and inherited per-resource.
It's called the Capability Model: https://en.wikipedia.org/wiki/Capability-based_security
Oh that sounds...
"...is inspired by AWS IAM Policies."
Oh god no.
My day to day work is debugging IAM polices that have accidentally given global s3 write access or everyone but admins, admin access.
For services I write I've been using simple permission strings. Call them scopes on the form:
Each client is then associated a set of scopes, if a scope ends with '' it matches all suffixes. And then you just ask if a client has a set of scopes.
By only allowing at the end, and otherwise just having permission as a set of strings you can most interesting operations:
between any two sets of scopes.
Hence, you can do do automated reasoning about permissions assigned. For example you check automatically verify an assumption that no role grants a scope A to a user who also has scope B.
Lack of support for doing combining IAM policies makes it hard to verify your policies with high-level assertions.
The hydra ( http://github.com/ory/hydra ) project for example has groups, which allow you to set e.g. an admin group and then assign people to it. I think this helps a lot with managing policies!
The inclusion of boolean logic in the policies is the root cause.
Specifically, having not resources, or not principals and their interaction with the other policies in the account.
The second highest common cause is misunderstanding how the default deny works.
Again, not really an issue with the landon project, but more an observation on how added power (complexity) to access control systems can sometimes make things less secure.
This policy looks reasonable to a casual observer, but actually gives * access to everything in the account. IAM policies are _hard_.
- Learn the programming environment: https://golang.org/doc/code.html
- Learn the idioms and best practices: https://golang.org/doc/effective_go.html
... and most importantly, go practice and build something!
This is a good example for separation of concerns. LDAP is for authentication, ladon is for Authorization. Don't mix those.