Date post: | 02-Dec-2014 |
Category: |
Technology |
Upload: | evolve-aem-summit |
View: | 1,307 times |
Download: | 4 times |
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 [email protected]
Jon Ito – Senior Application Architect – Acuity [email protected]
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