EVOLVE'13 | Enhance | Permission Sensitive Caching | Paul McMahon & Jason Rapasky


Published on

Published in: Technology
  • Be the first to comment

EVOLVE'13 | Enhance | Permission Sensitive Caching | Paul McMahon & Jason Rapasky

  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 19 IMPLEMENTING PSC Create the Authorization Servlet
  20. 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. 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. 22 Questions Q&A
  23. 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