Hi,
I might add my two cents since we’re tackling a similar challenge right now but it’s our Flow-only project, so the Neos UI stuff is something we don’t have in that case.
Before I start that - regarding your questions: The accountIdentifier is part of the default Flow-Accounts if I remember correctly from the top of my head. The rest may be stuff that needs to be created. Can’t really answer the other questions but I think this forum is fine and if you have something more specific can be moved to GitHub and be referenced there.
In our case it’s not a city but it’s large corporations where they want to have the chance to grant access to only some functions (MethodPrivileges) and some entities (EntityPrivilege).
E.g. imagine a car manufacturer that is managed centrally or a large hotel chain. The car manufacturer wants to provide our service to dealerships worldwide and also wants to make sure that everything can be managed centrally in general but each local subsidiary has the chance to change some things. E.g. dealership one may be able to create new objects whereas dealership two is only allowed to edit stuff and dealership three is not allowed to create or edit anything because they pay the headquarter to manage it for them but wants to see statistics but for billing purposes, they need to access that part which is not important for the other dealerships.
That’s roughly the situation we need to solve and we’re already half-way through solving it - the thing that’s missing is a more dynamic way for MethodPrivileges.
What we did so far:
- We’ve created a database-based Role model. Users can assign entities to that role which defines what a user may access (what objects, doesn’t tell anything about what features, yet).
- Something similiar like this is being used: https://gist.github.com/bwaidelich/731dc47a02027346d5a4153010f62e34
In our custom context we basically read the role (our database-role) that is assigned to a user and read all IDs of assigned objects which then results in doctrine filters applied by the EntityPrivilege. If the user has no database-role assigned or the database-role doesn’t have any object-assignments we assume that the user may access all objects of the customer he’s assigned to. - We’ve defined what features do exist. This is always a combination of some actions currently (usually CRUD, e.g. someone can create an object of Type A he needs to be able to access action A, B and C of Controller D). This means there’s one methodPrivilege for each function - which is a lot. Right now there are around 70 privileges.
What we need to solve:
Basically we need a way of managing that stuff and give users a way to define who has access to what features and currently there’s some different ways I can imagine:
- Our database-role is extended in a way that the functions can be selected. This would mean that either the privileges can be selected or we create a role for each function I’ve described above which would then be assigned to the account in some way.
- If privileges are selected instead of roles we would need a way of creating a dynamic role (a Flow role in this case). This role would then accept a class name as a parameter that is returning the privileges that are assigned to our database-role resulting in some sort of dynamic flow-role.
- Don’t know? Maybe there’s a better way
To be honest I don’t 100% grasp if this is similar to what Bastian described with the groups. Creating such dynamic role would keep the Policy.yaml a bit shorter which is bloated already.
Would be grateful if someone could think about this as well.
There’s also another topic on this forum regarding our entity privileges which I’ll update once we’re finished: EntityPrivilege persistence_object_identifier and in operator
Thanks,
David