@bwaidelich I am personally not sure whether groups actually solve this problem, because of the following reasoning.
As I’ve tried to formulate here, the following rules (mostly) apply to the permission system:
- Rule 1: All “things” that are NOT matched by a Privilege Target are allowed.
- Rule 2: All “things” matched by a Privilege Target are forbidden, if no explicit GRANTs or DENIES are given.
- Rule 3: Always work with GRANT (Suggestion)
- Rule 4: If several Privilege Targets apply to a thing, access is permitted, as soon as the user has granted ONE of these Privilege Targets …
(Sidenote: I feel that Rule 4 is not properly implemented by the EntityPrivileges, because the permissions are not "OR"ed together, but "AND"ed. Of course that would be really hard to change and totally breaking; but still it’s quite inconsistent currently IMHO).
My problem with groups is that by adding parameters to PrivilegeTargets, it is not possible anymore to find whether a “thing” is matched by a privilegeTarget or not, because you cannot know all possible parameter values beforehand.
So, that’s why unless proven otherwise, I think having groups will actually make the permission system more complex, not more easy. - and I wouldn’t even know how to build this properly.
@david.sporer - I am not fully sure if the dynamic privileges solve the issue fully; I’ve experimented with dynamic creation of policies here in this package (not fully working, but a rough draft).
If you like, we can have a call this or next week to discuss that topic in more depth? I’d definitley be interested in this (and maybe others want to join as well - I’ve at least talked to @christianm and @markusguenther about it beforehand).
All the best,