AEM SAML Authentication - SlingAuthenticator getAnonymousResolver: Anonymous access not allowed

[raymuirhead]

Hi,

We are configuring AEM SAML Authentication with Azure AD according to the guide at:

https://blog.developer.adobe.com/saml-authentication-in-aem-using-microsoft-azure-active-directory-3...

This is working successfully in our Test environment, which is setup with a single Author, Publisher, and Dispatcher.  In this environment we are able to log in and it is working end to end.

In the Stage environment we are having trouble getting it working.  The Stage environment is set up with a single Author, two Publishers, two Dispatchers (one for each publisher), an AWS load balancer, and Cloudfront CDN.

In the Stage environment, we are getting an error with the Sling Authentication interfering and popping up a login prompt when trying to load a page that requires authentication.  The expected result here is that it should redirect to the Microsoft SSO login page, allow the user to log in, and then redirect back to the saml_login page.

In the logs there is an error:

01.09.2022 16:07:00.335 *INFO* [qtp518345557-2345] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials

This only occurs when accessing via the Dispatcher (with Cloudfront in front of the Dispatcher).  Loading the page directly on the Publisher redirects to the Microsoft SSO login page as expected, but fails later at the point when redirecting to saml_login (via the Dispatcher).

We are also opening an Adobe support ticket, but thought I would open this up to the community as well to see if anyone has ideas as to what might be the cause?  The configuration for the SAML Authentication Handler and Sling Authentication Service is identical between the Test and Stage environments, the only difference is that Stage has a different certificate.

[Chandra_Hire · Accepted solution]

Hi @raymuirhead,

When client requests AEM resource (from publisher e.g. page), requests reaches to one of the publishers and this publisher redirects the request to Authentication server (in your use case Azure AD) for authenticate, then client gets notified for credentials (in this case login page) upon successful authentication, response gets received by publisher to synchronize respective user (in AEM from Azure AD ) and provide access to requested resource based on access available to the synced user. In case of multiple publishers especially external load balancers available in front of dispatchers, it can be possible that the publisher which redirects request to Azure AD doesn't receive the response from Azure AD rather another publisher in the farm receives the response and this publisher is unware of the user details hence Anonymous access error can occur.

We need to make sure that complete authentication request-reponse flow should be handled by same publisher and it can be achieved multiple ways and combination like modifying architecture, sticky session (dispatcher-publisher), session management at network end and/or CDN end.  

Hope this helps

[raymuirhead]

Thanks Chandra - that was not the case in my particular scenario as we already had load balancing with sticky sessions in place (via Adobe Managed Services), but is generally helpful information.

[raymuirhead]

It turns out the issue was Cloudfront - we had to allow Authorization header through to the dispatcher.