Permissions & Access Management UI

Hi Neos Community,

we currently have a Client who wants to have control over Permission-Management for their Users.
Basically they want to control everything which is possible with the policy.yaml in a User Interface.


  1. Are there any plans around making Permissions editable by the Backend-User?
  2. Is it possible right now to implement something like this by writing a custom Backend Module?
  3. Would you accept funding to implement this into Neos Core?

Thank you for your help :slight_smile:

1 Like

Hey Torben,

welcome here in the Neos community :heart:

I’ve recently thought about that concept, and I think this is doable. I’ve created a WIP to test out the concept at - but I guess this won’t make sense to anybody except me as it is very rough. In my idea though, you would not be able to make all policy permissions editable in the Neos UI, but a “sensible subset” - mostly dealing with node permissions. Could you elaborate some more on the use cases?

I personally am quite busy right now; but I’ve discussed the concept with @markusguenther at the last sprint :slight_smile: - so maybe he wants to implement something? :slight_smile: I’d be happy to provide my thoughts and guidance though!

All the best,

1 Like

Hi Torben and congratulations to your first post here :slight_smile:

Basically they want to control everything which is possible with the policy.yaml in a User Interface.

I totally agree that we are missing some UI features for permission management and visualization. But personally I’d be very strongly against some kind of fully-fledged Policy Editor for productive environments because that could be quite dangerous and error prone.

We used to have the Roles defined in the database but changed this a long time ago because we now consider a Role something that should not be specific to one instance of neos but rather a concept of the whole application.
The same thing holds true for privilegeTargets IMO.

Here’s my vision of some measures we could take to improve the situation:

  1. Improve the UI so that it is much easier to visualize the permissions of each individual user
  2. Create some ACL Editor (maybe based on the one Sebastian shared) but not meant to be used within a productive site (IMO) but more as a kickstarter that can export Policy.yaml files
  3. Introduce the notion of a User Group

The last part is IMO the most profound and it would require a change in the Flow Core.
The idea is basically that you can assign a Backend User to some Role (like today) but at the same time be able to specify some parameters. For example: User X has the role NewsEditor for category xyz

It is described here. Unfortunately we never got around finishing that because there was no urgent need. But as it comes up from time to time I’d love to tackle this one at some point…

The question is, whether this would solve your specific use case. So, like Sebastian, I’d like to know more about that :slight_smile:

1 Like

Hi :sunny:

first of all thank you both, for the kind replies.
It already sounds quite promising :blush:

I will be in a meeting today at 15:30, in which we will discuss the specific needs of our client(s).
After that I will post the results here. Maybe then we can discuss possible implementation-details a little better.

:heart:, Torben

1 Like

Hey :blush:

you can find our clients needs listed below, ordered from highest to lowest priority.

  1. New Roles can be created by the end-user (in Production)

  2. Permissions can be granted per Page (Neos.Neos:Document)
    2.1 Permissions are „Create“, „Read“, „Update“, „Delete“ (I thought about something like this for the UI:)

    2.2 Sub-Pages inherit permissions from the next higher specified permissions
    2.3 NodeTypes placed on a Page inherit the permissions from the Page

  3. Roles do have „global“ Permissions
    3.1 May see the Backend
    3.2 May see the „Media“-Module
    3.3 May see „User Management“-Module
    3.4 … (could be a list of all Backend-Modules)

  4. New Role: „Permission / Role Admin“
    4.1 May create new Roles
    4.2 May change Permissions on Pages

  5. New View: „Which users are in which role“

  6. Lock user from logging in
    6.1 Lock with checkbox
    6.2 Lock after specific Date

  7. New Role „Everyone“ or „Anonymous“ (every user who is not logged in)
    7.1 This may come in handy, when showing content only to users who are logged in. But this is probably already possible in some other way, right?

  8. Password Guidelines
    8.1 minimum x characters
    8.2 minimum x numbers
    8.3 minimum x special characters

  9. A user may only create users with the same or „lower“ roles
    This would imply some sort of role-hierarchy and is probably too hard to implement. But for the sake of completion, I wrote it down anyway :smile:

Thank you for your time and effort :heart:,

1 Like

Thanks for putting this together. Could you elaborate on a higher level on what they are trying to achieve. Especially the “add new roles in production” part.
As I wrote above I’m convinced that this is a dangerous path to follow and one that wouldn’t easily scale to multiple (testing) stages.

Hey Bastian :blush:,

the Problem is, that the Website is for a City.
In most cases cities don’t have their own editors. They give an Account to for example the press officer of the local fire station. He then has to only have permissions to edit (and not publish) one specific page of the website.

They can’t provide us all the possible Accounts with their permissions in advance, so they have to be created in production.
Also sometimes a new account has to be created relatively fast so we cant always add them for them.


That’s exactly one use case that would be possible with the suggested groups feature described above.

You would define a role with the privilege to edit certain node types and worlspaces like today. And when they assign that role to an account in the backend, they would have to specify the required parameters (in this case for example the root node for which this privilege applies).

I don’t know 100% how the UI for this should look like, but I have some rough ideas and could provide a mockup when I’m back from holidays

You are absolutely right. I didn’t really get it until now. :blush:

What do you think has to be done to move this forward?
I would love to help implement something like this. But I am more a Frontend-Dev, so I could probably only help with the UI…or would need some help in the Backend :smile:

Right now we are planning for the website to go online next year in summer.
Do you think, we could have something at least usable by then?

That would be awesome :+1:
I could probably also get a Designer from my agency to provide some tips, if there is a need for that :slightly_smiling_face:

But for now: Happy holidays :sunny:

1 Like

Hi :blush:

I did take a look at the issue on github and now I have a few questions. I could be wrong at any time, because I don’t 100% understand the underlying construct but i thought i would share them and maybe move the issue a bit forward (hopefully) :smile: or at least get a better understanding of what needs to be done.

  1. Would we have to create a new Database-Table including the accountIdentifier, role and parameters or can this be represented / saved another way?

  2. Regarding backwards compatibility. Would it be a good idea, to keep the parameters in the Policy.yaml and just make it possible “override” them later on? That way, the parameters in the Policy.yaml would act like a fallback / default and you wouldn’t have to migrate anything, right?

  3. Is this Forum the right place for discussions like this or should this go into the issue itself?

Thank you,