Highlighted

SAML Authentication generates anonymous user session instead of authenticated user

Avatar

Avatar

courtthreeGDC

Avatar

courtthreeGDC

courtthreeGDC

01-04-2019

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.

Replies

Highlighted

Avatar

Avatar

jbrar

Employee

Avatar

jbrar

Employee

jbrar
Employee

02-04-2019

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

Highlighted

Avatar

Avatar

courtthreeGDC

Avatar

courtthreeGDC

courtthreeGDC

12-04-2019

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?

Highlighted

Avatar

Avatar

Gaurav-Behl

MVP

Total Posts

1.1K

Likes

226

Correct Answer

281

Avatar

Gaurav-Behl

MVP

Total Posts

1.1K

Likes

226

Correct Answer

281
Gaurav-Behl
MVP

12-04-2019

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

Highlighted

Avatar

Avatar

courtthreeGDC

Avatar

courtthreeGDC

courtthreeGDC

14-04-2019

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.

Avatar

Avatar

courtthreeGDC

Avatar

courtthreeGDC

courtthreeGDC

15-04-2019

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

Highlighted

Avatar

Avatar

jbrar

Employee

Avatar

jbrar

Employee

jbrar
Employee

15-04-2019

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

Highlighted

Avatar

Avatar

courtthreeGDC

Avatar

courtthreeGDC

courtthreeGDC

15-04-2019

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?

Highlighted

Avatar

Avatar

courtthreeGDC

Avatar

courtthreeGDC

courtthreeGDC

16-04-2019

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.

Highlighted

Avatar

Avatar

shivama92274331

Avatar

shivama92274331

shivama92274331

20-02-2020

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