Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

How to utilize rep:glob restrictions in permission settings?

akaria
Level 2
Level 2

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...

 

ACL ACL permissions AEM Permissions
1 Accepted Solution
akaria
Correct answer by
Level 2
Level 2

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, @Arun_Patidar and @markus_bulla_adobe !

View solution in original post

4 Replies
markus_bulla_adobe
Employee
Employee

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
Level 2
Level 2
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?
Arun_Patidar
Community Advisor
Community Advisor

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
Correct answer by
Level 2
Level 2

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, @Arun_Patidar and @markus_bulla_adobe !

View solution in original post