1. 1
PERMISSION-SENSITIVE CACHING
SOLUTIONS FOR CLOSED USER GROUPS
Content Management Entitlements in CQ 5

2. 2
INTRODUCTIONS
Paul McMahon – Vice President and Adobe Practice Lead at Acquity Group an
Accenture Interactive Company
Over 10 years of experience with CQ
Jon Ito – Senior Application Architect at Acquity Group an Accenture Interactive
Company
Over 5 years of experience with CQ
Acquity Group is a leading Brand eCommerce® and digital marketing company,
now part of Accenture Interactive. Acquity Group leverages the Internet, mobile
devices and social media to enhance its clients' brands and eCommerce
performance. It is the digital agency of record for a number of well-known global
brands in multiple industries. Acquity Group has served more than 600 companies
and their global brands through thirteen offices in North America.

3. 3
AGENDA
Outline
• What are Closed User Groups
• How to configure standard CUG implementation with the Dispatcher Session
Management feature
• Challenges with session management approach
• What is Permission Sensitive Caching (PSC)
• Implement PSC Servlet
• Configure Dispatcher
• Best Practices
• Questions

4. 4
WHAT ARE CLOSED USER GROUPS
And why would you need permission sensitive caching
What are closed user groups (CUGs)
Mechanism to allow authors to manage access to secured
content
Allows securing of content with having to manage normal JCR
permission structures
What is Permission Sensitive Caching
Mechanism allow Dispatcher to selectively return cached
secured content based on permissions
Leverages a servlet on the publish server to determine if a
user should have access to any piece of secured content.

5. 5
CLOSED USER GROUPS (CUG)
What is Closed User Groups (CUG) in CQ 5?
CUG is used to limit access to specific pages that reside within a published site
• Requires assigned Users to login and provide credentials for access
• Native Functionality in CQ
• Provides “White List” type of administration at a group Level
• Managed at the page level
• Configurable Properties:
– Login Page
– Realm
– Allowed Groups
• Inherited by child pages
• LinkChecker
– Redirect Pages

6. 6
SET UP CLOSED USER GROUPS
Configure Groups and Users
Create a Group for your CUG
No need to assign any permissions to the group
Assign users to the group
Activate any users assigned to the group
Activate the group
• Important Note – group membership is stored on the group nodes,
so the order of activation is important. If the users are not already
active when you activate the group the membership will not be
present. Once a user is active all group membership changes are
activated by replicating the group, not the member

7. 7
SET UP CLOSED USER GROUPS
Apply the CUG to Pages
Create a location in your site to hold security content
Easiest solution is to select a single location to hold all secure
content, however you can have multiple locations
Create content within the secured location
Open the page properties of the secured location and enable
CUG for this location:
• Select the Advanced Tab
• Select the login page (in the case the Geomettrix Login
Page)
• Select a group or groups that permitted to view the content
Activate the page(s) and view on the publish site (4503)

8. 8
SET UP CLOSED USER GROUPS
Integrating to Dispatcher
In the standard implementation Dispatcher’s session management feature is utilized
to allow the secured content to be cached:
• You could choose to not cache your secured content either by setting no cache
headers or by exempting it in dispatcher.any, however this is not a common choice.
• One key point about session management is that it applies at the farm level and when
enabled it assumes that all requests to the farm must be authenticated.
• Any request to the farm that isn’t authenticated is NOT RETURNED FROM CACHE.

9. 9
SET UP CLOSED USER GROUPS
Dispatcher Session Management Configuration
Steps to configure Dispatcher session management:
If you site contains both secure and non-secure content you must add a second
farm to you dispatcher configurations, one for the secure content and one for
the non-secure content.
The non-secure farm must deny the path to secure content in the filter section,
and the secure farm must deny all and only allow the secure content path.
The secure farm should add the session management element at the farm level
• /sessionmanagement
• {
• /directory "/apps/apache/httpd/Apache22/.sessions"
• /header "Cookie:login-token"
• }
The header value is based on the cookie used by the out of the box form
authentication handler – if your authentication mechanism uses a different
cookie or header that value must be specified.

10. 10
CHALLENGES
What doesn’t work
Dispatcher’s session management works well enough in the in an implementation with a simple
set of requirements. Key points where begins to encounter issues are:
Multiple Sets of secure content with different groups allowed to view content
• In this scenario each different set of secure content requires its own dispatcher farm and each group
must use a different authentication header
• Session management does not distinguish between authenticated users – either a user is
authenticated or not
• Just adding another farm doesn’t solve the problem – if the same authentication header is used for all
users then both farms will recognize each other’s authenticated users. You must implement a custom
authentication system that sets additional cookies – different cookie names for each CUG
• This approach doesn’t scale beyond a few sets of authenticated content. Any complexity in your
group or content structure will make this approach difficult to implement

11. 11
PERMISSION SENSITIVE CACHING (PSC)
What is Permission Sensitive Caching
What is permission sensitive caching
Permission-sensitive caching enables you to cache secured pages. Dispatcher
checks users' access permissions for a page before delivering the cached page.
• Dispatcher includes the AuthChecker module that implements permission-sensitive
caching.
• When the module is activated, the Dispatcher calls an AEM servlet to perform user
authorization check for the requested content. The servlet response determines whether
the content is delivered to the web browser

12. 12
PERMISSION-SENSITIVE CACHING (PSC)
(continued)
What is Permission-Sensitive Caching (PSC)? (cont.)
Request Flows:
• User Requests a Cached Page, User Authorized
• User Requests a non-cached Page, User Authorized
• Users Request a non-cached page, user not Authorized

13. 13
PERMISSION-SENSITIVE CACHING (PSC)
(continued)
What is Permission-Sensitive Caching (PSC)? (cont.)
Request Flows:
• User Requests a cached Page, User Not Authorized
• User Requests a non-cached Page, User Not Logged

14. 14
IMPLEMENTING PSC
Create the Authorization Servlet
PSC Supports a variety of authentication and authorization methods, however for a
CUG implementation certain assumptions can be made:
Authentication will be through standard CQ/Sling authentication
Authorization will be based CUGs
Login Redirect must be managed using the Error/State Handler (500, 400, 300,
etc.) at Application level.

15. 15
IMPLEMENTING PSC
Create the Authorization Servlet
Override the doHead method:
Check if the user has read rights to the requested path using the Resource
Resolver:
• Respects ACL
• Respects CUG
If the user does have read rights return 200
If the user does not have read rights check to see if they are logged in
• If the user is not logged return 401 code which will cause Dispatcher to send the request
back to the publish server and the normal CUG functionality will handle redirecting to
the login page.
• For the logged in user return a 403 and allow application to handle the error display. In
the case of a CUG implementation

16. 16
IMPLEMENTING PSC
Create the Authorization Servlet
Create and Deploy a Authorization Servlet
The servlet should extend the SlingSafeMethods class to ensure it is generally
available.
Only the doHead method needs to be overridden but the servlet will only receive
head requests.

17. 17
IMPLEMENTING PSC
Create the Authorization Servlet
Create and Deploy a Authorization Servlet
The HTTP status code determine how dispatcher will treat the request:
• 200 indicates that the user is authenticated and can view the content. If the content is
available in cache dispatcher returns it, if not dispatcher sends the request back to the
publish instance.
• 403 indicates that the user does not have access to the content

18. 18
IMPLEMENTING PSC
Create the Authorization Servlet
Create and Deploy a Authorization Servlet
Make the servlet available at the path of your choosing – for example
/bin/permissioncheck – the path is configured in dispatcher.
Dispatcher includes the URL being checked in the uri request parameter when it
calls the servlet – for example
/bin/permissioncheck?uri=“/content/site/secured.html
Add the auth_check section to dispatcher.any as child of the farm element:
• Include the url element set to the path of your deployed servlet.
• Use the filter section to control which requests are subject to the check this decision is
somewhat of a balancing act between giving authors flexibility to add more secured
content over time and performance impact of making the author check call.

19. 19
IMPLEMENTING PSC
Create the Authorization Servlet

20. 20
BEST PRACTICES
Configuration and Component Development Considerations
Taxonomy Considerations:
If your project’s requirements keep all secured content in one branch of your
site tree.
• This enables you to reduce number of requests that will require a call to the PSC servlet
and the overhead associated with the call.
• Keep in mind however that the point of a CUG implementation to enable authors to
control which content is subject to security. Configuring too narrow a PSC scope will
result frustrated authors.
Create non-protected redirect pages for the secured content. There are two
reasons to take this approach:
• Links directly to the protected content will be suppressed by the Link Checker for an
unauthenticated user at runtime, so if you want to be able to display a link on your
public pages to the secure content you will need to use redirect pages.
• Links directly to protected content can cause inconsistent results for unsecure pages. If
a unsecure page is flushed from cache, and an authenticated user is the first user to
view it then that page would be cached with valid links to the secure content. This can
result in a situation where sometimes a link might be displayed and other times not.

21. 21
BEST PRACTICES
Configuration and Component Development Considerations
Component Development Considerations
Navigation and Listing Components
• Remember that authenticated users will be browsing the site and content may be
cached that was generated for an authenticated user (even though the content is not
secured.
• This raise the possibility of inconsistent behavior in non-secured pages if your navigation
and listing components don’t filter out secure content on non-secure pages.
• Consider coding your navigation and listing components that are not specific to the
secured content to ignore any content subject to CUG security.
Personalized Components
• For components that should be personalized – displaying different navigation to
authenticated users vs. non-authenticated users consider combining an AJAX
approach with the PSC servlet/CUG to allow caching of group/realm specific content in
a secure manner.

22. 22
Questions
Q&A

23. 23
Paul McMahon – Adobe Platform Architect – Acquity Group
paul.mcmahon@acquitygroup.com
Jon Ito – Senior Application Architect – Acuity Group
jon.ito@acquitygroup.com
Closed User Groups:
http://dev.day.com/docs/en/cq/current/howto/create_apply_cug.html
Permission Sensitive Caching:
http://dev.day.com/docs/en/cq/current/deploying/dispatcher/permissions_cach
e.html
SUMMARY
Documentation/Resources