Closed User Group (CUG) not working as expected and allowing all users to login

[chintan97patel]

I am testing out Closed User Group (CUG). I followed basic steps for adding CUG for a page (https://experienceleague.adobe.com/docs/experience-manager-64/administering/security/cug.html#securi...). After following the steps, it adds restrictions to the page and requires login to the page as expected. However, it allows every valid users to login in the page. 

To elaborate, if I have group G1 having user U1 part of group and add G1 under Closed User Group from page properties, it should only allow U1 to login to the restricted page. However, it allows other users (U2, U3 for example) as well to access CUG restricted page which is not an expected scenario. To summarize, it allows all valid users to login to the CUG restricted page. To add, I am testing from publisher side, so no dispatcher changes would come into affect here. 

[Vijayalakshmi_S]

Hi @chintan97patel,

Could you please share the level of permissions for U2 and U3 and its groups, if any associated to the same.

Also, just as an additional check, cross check the CUG group and its users/permissions from being in Publish instance. 

[arunpatidar]

Hi,

Can you please confirm:

• Page has only one group(G1), you can varify from crxde as wll the principals stored in rep:cugPolicy node
• User U2 and U3 does not have any group(or at least Group G1)
• anonymous user can't access the protected page as well

[chintan97patel · Accepted solution]

Adding my update for the issue for someone who visits this.

So, CUG will allow the users (U2, U3) to login and will not send error response for "authentication". And it will set the login-token cookie. However, since the user is not authorized to view the content for the page, it will show up 404 page. In your case, if you have setup a default 404 page, it will show up content from that page after setting the login-token cookie. Now since the default 404 page content might be part of /apps/<your-site>, you will need to give read permission (to U2 and U3, make sure you don't mess up ACLs on publishers) to that path as well (pretty much the issue I had where the 404 page content was not being rendered properly). 

To summarize, even if the user is not "authorized" to view the content since it is not part of group G1, it will set the login-token cookie but render 404 page. If the user is part of group G1, it will show up the content of the page. I had all the required permissions set from /content/ but read permission under /apps/<site> were missing which is holding some default designs.