AEM SAML Authentication - SlingAuthenticator getAnonymousResolver: Anonymous access not allowed | Community
Skip to main content
R
raymuirhead
September 1, 2022
Solved

AEM SAML Authentication - SlingAuthenticator getAnonymousResolver: Anonymous access not allowed

  • September 1, 2022
  • 2 replies
  • 1100 views

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-30d668338a8f

 

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Chandra_Hire

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

2 replies

Chandra_Hire
Chandra_HireAccepted solution
September 2, 2022

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

    R
    raymuirheadAuthor
    September 14, 2022

    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.

      R
      raymuirheadAuthor
      September 7, 2022

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

        Terms & ConditionsAccessibility statement

        Loading footer...