SAML Authentication generates anonymous user session instead of authenticated user

[courtthreeGDC]

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.

[Jaideep_Brar]

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

[courtthreeGDC]

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?

[Gaurav-Behl]

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

/sessionmanagement

  {

  /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

https://www.albinsblog.com/2017/03/how-to-protect-content-from-anonymous-saml-cq5-aem.html#.XLCeYehK...

[courtthreeGDC]

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.

[courtthreeGDC]

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

[Jaideep_Brar]

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

[courtthreeGDC]

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?

[courtthreeGDC]

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.samlThen 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.

[shivama92274331]

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