How to setup CUG

Question

How to setup Closed User Group (CUG) in CQ5?

CUGs are sections on a public website that need login to access.

Goal

• it must be possible to define a page or a tree of pages on the author to be protected on the publish instance
• protected means that it's necessary to login to see the corresponding page(s) on the publish instance
• it must be possible to select a group per CUG. All members of this group must have read access to the page(s) in the CUG

Answer, Resolution

Scenario Setup

You need an author and a publish instance with activated replication.

Preparation

Important: Install HotFix 24321 on the author and publish system. You will most likely need to restart the systems after installing the content package, as the included security module is a dependency of a number of other core CQ components and the system doesn't seem to recover from the live bundle update well enough.

A. Users & Groups

1. create a new group "membersonly"
2. create a new user "mister x"
3. make "mister x" user member of the "membersonly" group
4. make "membersonly" group member of the "surfer" group
5. make "anonymous" user member of the "surfer" group (because of (1))
6. activate (Note: The order below is important! Group memberships are not correctly replicated if the members do not already exist on publish)
   • "mister x"
   • "membersonly"
   • "surfer"
7. remove "anonymous" user membership from the "surfer" group - and do not activate (because of (1))

(1): The "anonymous" user hast to be member of the "surfer" group on publish instances only, but not on author instances (otherwise it's not necessary to login on an author instance anymore and everyone can see your whole author instance!)

Note: If you don't want to do this procedure with adding and removing the" anonymous" user membership from the "surfer" group you can also create a separate group (i.e. CugRootGroup) which is member of the surfer group and set the specific CUG groups (as i.e. group "membersonly") as member of this group. With this you have to activate the "surfer" group just one time and after only this separate group when you add a specific CUG group.

B. Secure Content

1. choose a page you want to secure
2. open page properties on the tab "CUG"
3. enable CUG and select the "membersonly" group - see screenshot
4. activate the page

C. Provide access

1. create a link on a public page to a page inside the CUG
2. activate that page
3. go to publish instance
4. visit the page last activated
   1. click on the link
   2. you get redirected to the login page - login with "mister x"
   3. you should now see the content that is secured

Product Issues / Workarounds

Bug 22360: link checker removes links into CUG:

Workaround:

1. login to http://<host>:<port>/system/console/configMgr/com.day.cq.rewriter.linkchecker.impl.LinkCheckerImpl
2. add your CUG path into the "Link Check Override Patterns" - see screenshot
3. save the configuration

Bug 23060: membership changes not replicate on member

Workaround:

1. replicate the group too

Bug 24422: CUG: Group member replication order is important

Workaround:

1. always activate users first, then the groups containing those users, and finally groups containing groups (e.g. the surfer group)

Bug 24983: configured login page is ignored

Workaround:

1. you can overlay the login form component at /libs/wcm/auth/components/login on the publish instance with one in apps (/apps/wcm/auth/components/login). In the /apps/wcm/auth/components/login/login.jsp you can for example add your project specific logic for separate login forms per CUG i.e. by redirect or implementing directly in this jsp.

Note: There are some isolated reports of the OSGi configuration settings or the JSP and JavaScript files in the content package not getting activated when the package is installed. In such cases:

• refresh your browser cache (if you see activation problems in the User Manager)
• check and re-save (cug.supported should be true, no changes needed) the OSGi configuration of the HTTPAuthHandler component (if CUG pages are not protected on publish)
• update the jcr:lastModified date of the /libs/sling/servlet/errorhandler/404.jsp/jcr:content node in CRX explorer (if you get a 404 error instead of the login screen for CUG pages on publish)

Applies

CQ5.2.1 with HotFix 24321