How to utilize rep:glob restrictions in permission se...

[akaria]

Hi,
I'm new to permission (ACL) management in AEM, and I need your help in setting permissions properly.

Here are some basic infos:

• AEM 6.5.8
• Multi-site
• Multi-region/countries
• Operators are currently using useradmin (Classic UI) to set permissions
• Likely to use Permissions console (Touch UI) in the near future

Example site structure:

- project
-- us
--- en
---- products
----- item1
----- item2
----- item3
---- about-us
-- fr
--- fr
---- products
---- about-us

Example group structure:
- content-authors (a big group for authoring contents)
-- groupA (responsible for authoring "project/us" and below)
-- groupB (responsible for authoring "project/fr" and below)
-- groupC (responsible for authoring "project/us/en/products" and below)

To be concise, every group should not able to read other directories (e.g. "project/fr" is not visible to groupA).
In above case, how should I set permissions for groupA, B, and C?

I've read that rep:glob restrictions can help us set flexible, fine-grained permissions but I don't have any idea how to implement that. [2] shows how to set restrictions in the console, but it doesn't tell me this-will-do-what.

Could you guide me step by step?
Thanks in advance

I've also checked these docs/tips out:
[1] https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/security.html?l...

[2] https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/touch-ui-princi...

[3] https://blogs.perficient.com/2020/05/20/why-you-should-be-using-the-principal-permissions-view-in-ae...

[markus_bulla_adobe]

Hi @akaria!

Using globbing in permission management is a powerful technique but often a bit tricky and hard to get right.

As someone from "the old days" I still refer to CRX Explorer and it's ACE Editor to prototype and test my permission setups, especially when it comes to globbing.

For actual management and deployment of permissions, I recommend to not manage them manually but to leverage Netcentrics ACL Tool that allows you to define your groups and permissions in a yaml syntax and deploy them consistently along with your application code to all your environments.

Coming back to your question about globbing (rep:glob), you may want to check the Oak documentation on this topic as it comes with a couple of examples that can help you understand how globbing works.

Hope that helps!

[akaria]

Hi @markus_bulla_adobe, thank you very much for your comment. I'll look up the references you introduced to me, I do appreciate it, but I'm afraid this is not the answer I want for the moment. Can anyone help me out?

[arunpatidar]

Hi,

As already mentioned by @markus_bulla_adobe , how to use rep:glob but in your case you don#t have to use it,

you can esily set the permission of more restricted group to restricted path

e.g

set read for permission for groupA at /content/project/us

set read for permission for groupB at /content/project/fr

set read for permission for groupC at /content/project/us/en/products

No need to use rep:glob or rep:restriction 

[akaria · Accepted solution]

I managed to set the permissions for the destination paths by adding a simple Allow jcr:read statement:
Allow | jcr:read | (No restrictions)

e.g.
project/us/en/products | Allow | jcr:read | (No restrictions)

As for intermediary paths like "project" and "project/us/en", add these two to each path:
Allow | jcr:read | rep:glob=""
Allow | jcr:read | rep:glob="/jcr:content/*"

e.g.
project/us/en | Allow | jcr:read | rep:glob=""
project/us/en | Allow | jcr:read | rep:glob="/jcr:content/*"

This will let them pass to the destination path in the Sites Console while other unintended subtrees are unseen.

I will close this case since it's resolved

Thank you for your kind comments, @arunpatidar and @markus_bulla_adobe !

[vishalgera]

Had a similar use case and was able to fix it after applying glob restrictions in an proper order only.. PFB usecase and ACL permissions

Use case need to provide

read access to all nodes under level 0

no access at level1 and level 2

provide read/write access at level3

Level 0 Path - content/dam/language-masters/en/level0  -->  allow | jcr:read

Level 1 Path - /content/dam/language-masters/en/level0/level1 -->  deny | jcr:all | rep:glob="/*"

Level 1 Path - /content/dam/language-masters/en/level0/level1 -->  allow | jcr:read | rep:glob="/jcr:primaryType"

Level 2 Path - /content/dam/language-masters/en/level0/level1/level2  -->  allow | jcr:read

Level 2 Path - /content/dam/language-masters/en/level0/level1/level2  -->  deny | jcr:all | rep:glob="/*"

Level 3 Path - /content/dam/language-masters/level0/en/level1/level2/level3  -->  allow | jcr:write, jcr:read

Thanks!!

Vishal Gera