For services I write I've been using simple permission strings. Call them scopes on the form:
'service:action:resource/sub-resource...'
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:
- intersection
- union
- empty-set
- sub-set
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.
Why do those policies make it there in the first place? Could you share some scenarios? I'd love to improve the managibility of policies :)
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.
Yeah, I can see how using "Not" as opposed to "Inverted" would trip up people here. However, I would say that's a naming issue and (for some reason) a resiliency to using explicit deny policies.
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.