Expand my Community achievements bar.

July 31st AEM Gems Webinar: Elevate your AEM development to master the integration of private GitHub repositories within AEM Cloud Manager.

SAML Authentication generates anonymous user session instead of authenticated user


Level 3

Hi everyone,

We have done a successful integration of Okta with our 6.2 instance of AEM via the OOTB SAML Authentication handler.

The integration works great when executed directly on our publish instance via port 4503. However, when we perform the same actions via the dispatcher, the authenticated user session is not available in code. When we try to access the user, we find that, even though the new user is successfully created in the CRX via the SAML integration, the active user session is of the anonymous user - not the user we just authenticated!

Of course, I need to assume that there is a misconfiguration in the dispatcher but I could do with a steer of where to look for something that could be causing this behaviour.

Any thoughts welcome as always and thank you in advance for your time.

9 Replies


Employee Advisor

Can you check if CSRF settings are correct on dispatcher[1]

Also make sure POST request to */saml_login is allowed

[1] Configuring Dispatcher to Prevent CSRF Attacks


Level 3

Hi Jaideep,

Thank you for picking this up mate. I have followed your instructions to the letter but to no avail. We are still experiencing the same issue. FYR, a quick snippet of the code we're using to pick up the user is as follows:

resourceResolver = request.getResourceResolver();

Session session = resourceResolver.adaptTo(Session.class);

UserManager userManager = resourceResolver.adaptTo(UserManager.class);

Authorizable auth = userManager.getAuthorizable(session.getUserID());

log.info("user path " + auth.getPath());

String userCookie = cookieSetterService.setTheCookie(auth);

So, you see, it's nothing unusual and, like I said, it works directly on the publish instance. Do you have any further thoughts?


Level 10

couple of pointers:

1) validate the referrer header is set to Okta's host name and header is allowed in dispatcher.any

2) allowauthorized is set to 0 and session is enabled  -- assuming you want that

3) On publish, CSRF and Sling Referrer filter have appropriate configs for Okta's host/method or allow empty for testing



  /directory "/usr/local/apache/.sessions"

  /encode "md5"

  /header "HTTP:authorization"

  /timeout "800"


Configuring Dispatcher

Single Sign-On (SSO) Integration With Okta In AEM 6.3 | Bounteous



Level 3

Thank you. This is really helpful.

I have noted that the line 'allowAuthorized "0"' is commented out in our dispatcher.any file.

I have uncommented it and resubmitted it for upload. This won't happen until tomorrow but I am hopeful you may have cracked it. I will revert after the test.


Level 3

I'm afraid that wasn't the answer (in our case at least). We will keep looking and update you all accordingly.


Employee Advisor

Please log a daycare ticket with the following data:

- DEBUG level dispatcher logs

- SAML Request

- SAML Response

- HAR file[1]

- DEBUG level logger on "com.adobe.granite.auth.saml"

[1] Generating an HAR file / Troubleshooting your Tender site / Knowledge Base - Tender Support


Level 3

Thanks again for staying on board.

I have done this (a week or so ago at Adobe's request). They have just come back with the following:


I saw on the SAML response that no field "uid" was returned in the "AttributeStatement", [0][1]

in an OOTB instance this is used to map the user to an AEM principal (see com.adobe.granite.auth.saml.SamlAuthenticationHandler > userIDAttribute)


We are in the process of changing this so that Adobe will continue helping but my initial view is that this would not explain why it works directly in the publish instance (via 4503) and not in the dispatcher. Do you guys have a view?


Level 3

As suspected, this did not move us on. Adobe have now requested the following:

At this point could you setup a custom logger for the classes below,

* org.apache.sling.auth.core
* org.apache.jackrabbit.oak.security
* org.apache.jackrabbit.oak.spi.security
* com.adobe.granite.auth.saml

Then perform a login and provide it in addition to this logs files

* apache log file,
* dispatcher log file
* aem error.log
* aem access.log
* aem request.log

We are in the process of compiling these but we are also going to ask the hosts to disable the Cloud Front CDN so we can localise the problem.


Level 2

Hi, did you find the solution for this issue? i am also having similar issue.