Level 2

Solved

Groups and ACLs for external vendors?

Forum|Forum|9 years ago
April 26, 2016
14 replies
6640 views

I have 2 scenarios that require that users be granted read access explicitly before they can access content in AEM.

We're expecting to run a large number of sites in our authoring environment and authors should by default only see what they've been granted access to so that they're not overwhelmed by content that's not relevant to their experience.

Secondly, we're allowing vendors to access assets and content, and for security reasons they shouldn't by default see all content that's in the authoring environment.

Currently, the 2 options that appear to be available are to use either the content-authors group or a customization of the mp-* groups. However, both are based on the contributor group which by default grants read access to jcr_root, then denies specific things.

Is there a group structure that is not based on contributor that supports this concept? If I deny access to content then allow access to only a specific folder in content, /sites.html/content breaks. I tried some permutations of rep:readNodes with the same result. There are a lot of folders in /content by default, something in there must be required by TouchUI to load the interface, but I'm not sure what that is.

Any help would be appreciated.

edit: As a followup, I can't create groups that deny access to everything that isn't the one folder that I want to grant access to because users may be responsible for several sites, or several folders in the DAM, and as such will need to belong to multiple groups that allow access to a different set of folders. If I deny things explicitly, it will be a maintenance nightmare as new sites or DAM folders are added (every user group would need to be edited to deny access to that new folder, or there may be conflicting permissions when a user is added to multiple groups).

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by jayproulx

Jörg Hoh wrote...

Hi Jay,

Basically I agree with the documentation, that you shouldn't use "DENY", but there is one big exception to this rule: You should have a group, which grants the minimal applicable permission set. For example you model a group "login only", which only allows to login to AEM, but not to see any regular content (for example denying ALL permissions on /content/* using wildcard ACL). Make sure, that this group is the very frist group in the group list of every user.

And the you can design more groups which allow you to access specific pieces of content. Then the order of these groups does not matter anymore. Then you also don't have to rework the "login only" group, because all subtrees below /content are implicitly covered by the wildcard ACL, so you can create them at will.

(I really though, that this is covered somewhere in the official documentation ...)

kind regards, Jörg

This keeps getting marked as the answer, but the answer really isn't here.

Here's what I'll mark as the answer:

If you're basing everything on the default contributor group (which has read access to everything in the JCR), and the only thing you need to restrict is write access to specific folders, following the official documentation is super easy: simply grant write access anywhere in the JCR that the user needs to be able to modify and boom, you're done.

If however you want to grant read access to only specific branches of a tree, you need to use denies at every level of the tree until you reach a point where everything becomes similar to the point above (i.e. the user can now read/write everything within a particular branch).

So, for example, say you have hundreds of sites published from your author cluster. Your authors would be overwhelmed (most likely) if they saw everything. Maybe you have external vendors managing content for you, and they should only have access on a "need to know basis". If this is the case, you need to lock down access to /content and /content/dam. /content/dam is a child of /content (clearly), so if you want to prevent a user from seeing all sites in /sites.html, you need to deny read access to /content, but then you need to grant it back for /content/dam.

The approach then looks like the following:

contributor
1. deny jcr:read /content rep:glob=/* (deny all read access to all children of /content, but not content itself)
2. grant jcr:read /content/dam (grant read access back to /content/dam)
3. deny jcr:readNodes /content/dam rep:glob=/* (now deny access to all children of /content/dam)
4. Also, you might want to do similar for /apps and /etc/designs, depends on how tightly locked down you want it to be.

Contributor is used as the example base group for most of the Geometrixx samples and provides for the least amount of re-work. You might want to create a base-group that inherits from contributor to add the denies that I've added above, but you also might not want to have a group that provides full read access to the JCR by default. You now have a basic group with read access to everything except /content, which will cover most of the basic UX features of Touch-UI, but there will probably be explicit things outside that folder structure that the user might have access to but shouldn't. Also, if Adobe adds extra explicit permissions for contributor in the future, you'll get the benefit of inheriting that for your users.

Now you can create project groups with specific access to things in /content and /content/dam, and those groups should all inherit from contributor.

contributor
1. geometrixx-media-reviwer
  1. grant jcr:read /content/geometrixx-media
  2. grant jcr:read /content/dam/geometrixx-media
2. geometrixx-gov-reviewer
  1. grant jcr:read /content/geometrixx-gov
  2. grant jcr:read /content/dam/geometrixx-gov

Now you can assign one or more of these groups to one or more users and they'll then only see things that they're explicitly granted access to.

But wait, my use cases are more complicated, what if my geometrixx-media project also includes some peripheral print design, I want to store my digital assets with my print assets, what do I do?

Then you'll need to push those denies further down one more level and provide a group structure to support it. For example

contributor
1. geometrixx-media-users
  1. grant jcr:read /content/dam/geometrixx-media
  2. deny jcr:readNodes /content/dam/geometrixx-media rep:glob=/*
  3. geometrixx-media-reviewers
    1. grant jcr:read /content/dam/geometrixx-media
  4. geometrixx-media-print-reviewers
    1. grant jcr:read /content/dam/geometrixx-media
    2. deny jcr:readNodes /content/dam/geometrixx-media rep:glob=/*
    3. grant jcr:read /content/dam/geometrixx-media/print
  5. geometrixx-media-website-reviewers
    1. grant jcr:read /content/geometrixx-media
    2. grant jcr:read /content/dam/geometrixx-media
    3. deny jcr:readNodes /content/dam/geometrixx-media rep:glob=/*
    4. grant jcr:read /content/dam/geometrixx-media/website

Unfortunately, this is due to the fact that jcr:readProperties doesn't actually do anything without also having jcr:readNodes. (jcr:read is an aggregate of jcr:readProperties and jcr:readNodes). jcr:readNodes is also badly named, it's not just "readNodes", it's "readThisNodeAndReadAllChildNodes". There's no way to do this super cleanly, you can't just grant non-recursive jcr:readProperties to a single node to allow someone to see that and nothing else, you need to also grant jcr:readNodes and then deny them on the children in order to access the node itself.

p.s. Good luck granting read access only to things that are necessary to log in. Those things are liberally spread throughout the JCR, and some things are mixed in with author-accessible content. For example, there are things in /etc/designs required for rendering Touch-UI, so you can't blanket deny /etc/designs, you need to deny things explicitly, and of course those things can change in the future. Trying to figure out the "minimum access requirements" to log into AEM is effectively just endless trial and error.

jayproulxAuthor

Level 2

I think I've resolved my issue, but it goes against the Documentaion suggestion that only allows be used:

Use Deny sparingly. As far as possible use only Allow.

Using deny can cause unexpected effects if the permissions are applied in a different order than the order expected. If a user is a member of more than one group, the Deny statements from one group may cancel the Allow statement from another group or vice versa. It is hard to keep an overview when this happens and can easily lead to unforeseen results, whereas Allow assignments do not cause such conflicts.

Adobe recommends that you work with Allow rather than Deny see Best Practices.

When a new /content/dam/* or /content/* folder is added I can deny jcr:all to the contributor group, but as above it's possible that ACLs could be read in the wrong order. So this clearly isn't the ideal.

joerghoh

Adobe Employee

Hi Jay,

Basically I agree with the documentation, that you shouldn't use "DENY", but there is one big exception to this rule: You should have a group, which grants the minimal applicable permission set. For example you model a group "login only", which only allows to login to AEM, but not to see any regular content (for example denying ALL permissions on /content/* using wildcard ACL). Make sure, that this group is the very frist group in the group list of every user.

And the you can design more groups which allow you to access specific pieces of content. Then the order of these groups does not matter anymore. Then you also don't have to rework the "login only" group, because all subtrees below /content are implicitly covered by the wildcard ACL, so you can create them at will.

(I really though, that this is covered somewhere in the official documentation ...)

kind regards,
Jörg

Tuhin_Ghosh

Level 8

Hello jayproulx,

Please mark resolve this question, so that it shows as resolved.

Thanks

Tuhin

jayproulxAuthor

Level 2

This issue is not yet resolved, I'll mark it as resolved as soon as I've found a solution to my issue.

smacdonald2008

Level 10

Joerg provided a good answer. Have you implemented his suggestion? What happened?

jayproulxAuthor

Level 2

Hi Scott,

First of all, the answer is contradictory to the documentation: “Don’t use deny except for a certain group that all users should belong to which should do a wildcard deny”. I’ve been working on trying to create a group of users by following the documentation and granting only read access where required. Contributor has been the group that i’ve modeled my access after, however, removing jcr:read from / (and granting jcr:read to /apps and /libs, /etc) ends up breaking all of the UI’s (sites.html, assets.html etc).

So despite the documentation, I have no choice but to use a wildcard deny on content. I agree with the documentation, you don’t want to grant access to anything that the user shouldn’t have access to by default, but there doesn’t seem to be a scenario where that’s possible. The only thing that works is Jörg’s suggested to use a wildcard deny on just /content/*, but what else does that give the user access to that they shouldn’t by default? What are all of the other paths across the JCR that shouldn’t have read access by default? The answer leaves us with a working UI but it’s weak when it comes to production access standards. There’s also no documentation covered in the Security Checklist to cover those scenarios.

So, at the moment I don’t have an answer to the question...

jayproulxAuthor

Level 2

As an aside, I’m also not receiving email updates when someone replies to this thread (in my inbox or spam), so I replied quickly previously from my phone when I received a satisfaction survey for this thread and saw that there were new replies.

jayproulxAuthor

Level 2

In addition, there are commonly used folders like /etc/designs that contain a mix of AEM and project specific code. It’s relatively easy to blanket deny /content/* and /apps/*, but the same doesn’t apply for /etc/designs/* since there are a number of folders in there that are used by the system. We could deny all and then grant back all of the specific folders, but this sends us down a road where we’re using deny in all circumstances to define the base level of user access.

It seems to me that what we need is (as Jörg mentions above) a basic login group where we can build on top of the permissions as necessary for project specific access. Is there no such group available out of the box? Perhaps at least as an ACS download? My only option at the moment is to build that group via trial and error.

smacdonald2008

Level 10

We will work with the doc team to get this missing piece of information into the docs. As Joerg points out:

(I really though, that this is covered somewhere in the official documentation ...)

jayproulxAuthor

Level 2

Thanks Scott!

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded