AEM Cloud Service - Fix Publish Dispatcher SAML Login Loop with IDP

If you are experiencing a login (authentication) loop with IDP while integrating AEM Publish/Dispatcher with an IDP like Azure AD using SAML2, the following fix might help...

The Login Loop

1) /en.html has the following redirect configured in dispatcher vhost file eg. dispatcher\src\conf.d\available_vhosts\eaem.vhost, rewriting the url /en.html to /content/marketing-hub/en.html when sent to publish aem...

RewriteRule ^/en(.*) /content/marketing-hub/en$1 [PT,L]

2) Page structure /content/marketing-hub in Publish is protected using SAML authentication configured in ui.config\src\main\content\jcr_root\apps\eaem-mkthub-sample\osgiconfig\config\com.adobe.granite.auth.saml.SamlAuthenticationHandler~eaem.cfg.json

"path": [ "/content/marketing-hub" ],
"idpCertAlias": "$[env:SAML_IDP_CERT_ALIAS;default=certalias___11111]",
"spPrivateKeyAlias": "$[env:SAML_PRIVATE_KEY_ALIAS;default=certalias___1111]",
"keyStorePassword": "password",
"idpIdentifier": "$[env:SAML_IDP_ID;default=]",
"idpUrl": "$[env:SAML_IDP_URL;default=]",
"serviceProviderEntityId": "$[env:SAML_AEM_ID;default=]",
"useEncryption": false,
"createUser": true,
"userIntermediatePath": "",
"defaultRedirectUrl": "/content/marketing-hub/en.html",
"addGroupMemberships": true,
"defaultGroups": [

3) User makes request to a SSO protected page eg., internally gets rewritten to /content/marketing-hub/en.html, activating SAML authentication handler on publish, redirecting to the IDP login page...

4) User enters credentials and after successful authentication, IDP posts the SAML assertion to AEM Dispatcher url */saml_login

5) AEM validates the SAML assertion (after some decryption process) and redirects to user requested page /eh.html

6) At this point, since the response of /en.html was cached at CDN, when request was made in step 3 and the cached response is a request to IDP login page, user is redirected back to IDP login page with response header x-cache:HIT, resulting in a loop (until the cached response at CDN expires with default TTL set, may be 5 mts)...

Fix the Loop

1) DoNot cache protected pages at Fastly CDN using the proprietary header Surrogate-Control

<LocationMatch "^/content/marketing-hub">
Header unset Surrogate-Control
Header always set Surrogate-Control "no-store, no-cache"

2)  With the Surrogate-Control header set for requests starting with /content/marketing-hub, responses of these pages are not cached at CDN resulting in a x-cache:MISS and requests are passed to dispatcher and subsequently to Publish (assuming Permission-Sensitive Caching was not implemented)

No comments:

Post a Comment