SAML Authentication and AEM Permissions Sensitive Caching

SAML Authentication and AEM Permissions Sensitive Caching


I recently helped resolve an interesting issue from a former project. The issue was that un-authenticated users were getting access to assets were supposed to be protected by AEM Dispatcher permission-sensitive caching.

Permission-sensitive caching is a feature in the AEM Dispatcher where content permissions are checked before serving content out of cache. This feature is useful for caching large documents or files while controlling access at the user / group level. For example if you are serving product manuals or documentation for proprietary products.

Permissions sensitive caching

Image Credit: Caching Secured Content - Adobe Experience League

This feature in the dispatcher works by sending a head request back to a servlet on the renderer with the path of the resource to check and based on that response determine if the content should be served or not.

To configure Permissions-Sensitive Caching, you would add something like the configuration below and implement a servlet at /bin/permissioncheck to check the requested user’s access to the requested resource.

/auth_checker
  {
  # request is sent to this URL with '?uri=<page>' appended
  /url "/bin/permissioncheck"
      
  # only the requested pages matching the filter section below are checked,
  # all other pages get delivered unchecked
  /filter
    {
    /0000
      {
      /glob "*"
      /type "deny"
      }
    /0001
      {
      /glob "/content/dam/secure/*"
      /type "allow"
      }
    }
  # any header line returned from the auth_checker's HEAD request matching
  # the section below will be returned as well
  /headers
    {
    /0000
      {
      /glob "*"
      /type "deny"
      }
    /0001
      {
      /glob "Set-Cookie:*"
      /type "allow"
      }
    }
  }

The second part of the issue is that the client is using AEM’s SAML Authentication for logging into their Single Sign On service. With SAML, users are authenticated to AEM by redirecting the user to a SAML Identity Provider to perform Single Sign On and be redirected back to AEM.

SAML Authentication Diagram

Image Credit: AEM Infrastructure Series: A Guide to SAML2 SSO on AEM 6.x by Greg Dawson

These two features came together to create the issue because AEM Dispatcher’s permission-sensitive caching considers any 200 response a success. Since AEM SAML’s implementation works by redirecting the user using a client-side redirect from AEM to the SAML IDP, the AEM Dispatcher’s permission-sensitive caching module considered the AEM SAML authentication response to be successful and therefore served the assets out of cache when an un-authenticated user accessed the content.

Luckily, this is a pretty easy issue to resolve. We need to have AEM not perform SAML authentication for the cache check url, which can be done via the Apache Sling Authentication Service configuration as shown below:

Sling Authentication Service Configuration

Once the Apache Sling Authentication Service is configured to no-longer require authentication, unauthenticated users who access assets restricted by the permissions-sensitive caching will no longer be served the assets out of cache and will have to authenticate.


← Lambda, Optional and Streams with Apache Sling A Short, Semi-Accurate History of Web Content Management →