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.
Views
Replies
Total Likes
Can you check if CSRF settings are correct on dispatcher[1]
Also make sure POST request to */saml_login is allowed
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
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"
}
Single Sign-On (SSO) Integration With Okta In AEM 6.3 | Bounteous
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
I'm afraid that wasn't the answer (in our case at least). We will keep looking and update you all accordingly.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Hi, did you find the solution for this issue? i am also having similar issue.
Views
Likes
Replies
Views
Likes
Replies