1

PERMISSION-SENSITIVE CACHING SOLUTIONS FOR CLOSED USER GROUPSContent Management Entitlements in CQ 5

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 C Q

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

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

WHAT ARE CLOSED USER GROUPSAnd why would you need permission sensitive caching

What are closed user groups (CUGs)

Mechanism to allow authors to manage access to secured contentAllows securing of content with having to manage normal JCR permission structures

What is Permission Sensitive CachingMechanism allow Dispatcher to selectively return cached secured content based on permissionsLeverages a servlet on the publish server to determine if a user should have access to any piece of secured content.

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

SET UP CLOSED USER GROUPSConfigure Groups and Users

Create a Group for your CUG

No need to assign any permissions to the groupAssign users to the groupActivate any users assigned to the groupActivate 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

SET UP CLOSED USER GROUPSApply 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 locationsCreate content within the secured locationOpen 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

contentActivate the page(s) and view on the publish site (4503)

8

SET UP CLOSED USER GROUPSIntegrating 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

SET UP CLOSED USER GROUPSDispatcher 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

CHALLENGESWhat 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

PERMISSION SENSITIVE CACHING (PSC)What is Permission Sensitive Caching

What is permission sensitive cachingPermission-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

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

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

IMPLEMENTING PSCCreate 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 authenticationAuthorization will be based CUGsLogin Redirect must be managed using the Error/State Handler (500, 400, 300, etc.) at Application level.

15

IMPLEMENTING PSCCreate 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 200If 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

IMPLEMENTING PSCCreate the Authorization Servlet

Create and Deploy a Authorization ServletThe 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

IMPLEMENTING PSCCreate the Authorization Servlet

Create and Deploy a Authorization ServletThe 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

IMPLEMENTING PSCCreate the Authorization Servlet

Create and Deploy a Authorization ServletMake 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.htmlAdd 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

IMPLEMENTING PSCCreate the Authorization Servlet

20

BEST PRACTICESConfiguration 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

BEST PRACTICESConfiguration 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

Questions

Q&A

23

Paul McMahon – Adobe Platform Architect – Acquity Grouppaul.mcmahon@acquitygroup.com

Jon Ito – Senior Application Architect – Acuity Groupjon.ito@acquitygroup.com

Closed User Groups:http://dev.day.com/docs/en/cq/current/howto/create_apply_cug.htmlPermission Sensitive Caching:http://dev.day.com/docs/en/cq/current/deploying/dispatcher/permissions_cache.html

SUMMARYDocumentation/Resources