Dear All,
I have integrated SAML on publisher and it works fine in few scenarios. But when the page is cached and If we try to access the same page from a different browser, it gives me a popup saying the session is expired and it then request to login via our SAML login page which is expected. But then once I login, it goes to infinite loop.
When I did a SAML tracer, what happened is, the intial request was intercepted by the authchecker which then requested to login via AEM login service whcih then redirected to SAML. Hence for the SAML request, the referrer was the AEM login service -
http://localhost/system/sling/login.html?resource=%2Fcontent<complete url>. Due to this, I think its going to infinite loop as SAML redirects to AEM login service which then redirects back to SAML login. Can someone please help what need to be done in this case. How can we fix this infinite loop once we log in.
dispatcher log
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Found farm website for localhost
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] checking [/system/sling/login.html]
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] request contains a query string: resource=%2Fcontent%2Fobi%2Fstg%2Fen%2Fhome
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] cache-action for [/system/sling/login.html]: NONE
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Connected to backend rend01 (127.0.0.1:4503)
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: Host
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: User-Agent
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: Accept
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: Accept-Language
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: Accept-Encoding
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: Cookie
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: Via
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: X-Forwarded-For
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] Adding request header: Server-Agent
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] response.status = 200
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] response.headers[Date] = "Wed, 13 Jul 2016 02:41:19 GMT"
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] response.headers[X-Content-Type-Options] = "nosniff"
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] response.headers[Set-Cookie] = "saml_request_path=/system/sling/login.html?resource=%2Fcontent%2Fobi%2Fstg%2Fen%2Fhome;Path=/;Expires=Wed, 13-Jul-2016 02:46:19 GMT"
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] response.headers[Expires] = "Thu, 01 Jan 1970 00:00:00 GMT"
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] response.headers[Content-Type] = "text/html"
[Wed Jul 13 12:41:19 2016] [D] [6244(604)] response.headers[X-Powered-By] = "Jetty(9.2.9.v20150224)"
[Wed Jul 13 12:41:19 2016] [I] [6244(604)] "GET /system/sling/login.html?resource=%2Fcontent%2Fobi%2Fstg%2Fen%2Fhome" 200 1567 26ms
[Wed Jul 13 12:41:54 2016] [D] [6244(604)] Found farm website for localhost
[Wed Jul 13 12:41:54 2016] [D] [6244(604)] checking [/libs/granite/csrf/token.json]
[Wed Jul 13 12:41:54 2016] [D] [6244(604)] Authorization checker: URI does not match filter, will not be checked: /libs/granite/csrf/token.json
[Wed Jul 13 12:41:54 2016] [D] [6244(604)] cache-action for [/libs/granite/csrf/token.json]: DELIVER
[Wed Jul 13 12:41:54 2016] [D] [6244(604)] request declined
[Wed Jul 13 12:41:54 2016] [I] [6244(604)] "GET /libs/granite/csrf/token.json" - - 1ms
[Wed Jul 13 12:46:54 2016] [D] [6244(604)] Found farm website for localhost
[Wed Jul 13 12:46:54 2016] [D] [6244(604)] checking [/libs/granite/csrf/token.json]
[Wed Jul 13 12:46:54 2016] [D] [6244(604)] Authorization checker: URI does not match filter, will not be checked: /libs/granite/csrf/token.json
[Wed Jul 13 12:46:54 2016] [D] [6244(604)] cache-action for [/libs/granite/csrf/token.json]: DELIVER
[Wed Jul 13 12:46:54 2016] [D] [6244(604)] request declined
[Wed Jul 13 12:46:54 2016] [I] [6244(604)] "GET /libs/granite/csrf/token.json" - - 1ms
[Wed Jul 13 12:51:54 2016] [D] [6244(604)] Found farm website for localhost
[Wed Jul 13 12:51:54 2016] [D] [6244(604)] checking [/libs/granite/csrf/token.json]
[Wed Jul 13 12:51:54 2016] [D] [6244(604)] Authorization checker: URI does not match filter, will not be checked: /libs/granite/csrf/token.json
[Wed Jul 13 12:51:54 2016] [D] [6244(604)] cache-action for [/libs/granite/csrf/token.json]: DELIVER
[Wed Jul 13 12:51:54 2016] [D] [6244(604)] request declined
[Wed Jul 13 12:51:54 2016] [I] [6244(604)] "GET /libs/granite/csrf/token.json" - - 1ms
Views
Replies
Total Likes
HI,
Please add everyone and content-authors in the groups and see if that works
Thanks
Tuhin
Views
Replies
Total Likes
I have added everyone group already but still the same issue. Its done at the publisher so not sure if we have to add content-author group.
Views
Replies
Total Likes
Views
Replies
Total Likes
I will add and will check the outcome.
Views
Replies
Total Likes
Tuhin Ghosh wrote...
kindly try adding content -author group and see if that solves the issue. The ootb saml integration sometime wants an additional group other than everyone. If that works you could change it to more meaningful custom group later.
Hi Tuhin,
I updated the default group to be content-author but it did not helped. Its still going to the infinite loop. As I marked earlier, its looping between AEM login service and SAML login service. One is redirecting to other infinitely.
Views
Replies
Total Likes
Hi Ravi,
I guess you have not removed the everyone group. both 'everyone' and 'content-authors' are there, correct?
Thanks
Tuhin
Views
Replies
Total Likes
Tuhin Ghosh wrote...
Hi Ravi,
I guess you have not removed the everyone group. both 'everyone' and 'content-authors' are there, correct?
Thanks
Tuhin
Hi Tuhin,
I had both groups in the default list but still it didnt worked.
Views
Replies
Total Likes
The SAML logged in user is belonging to administrators group? Some times i have observed AEM will not allow the user which has admin (privileges) to login to AEM via SAML and it goes to infinite loop.
Thanks,
KK
Views
Replies
Total Likes
No. The user does not have admin privilege. The flow is that the saml gives the user data only; at that point of time he does not belong to any group. I have added in SAML config the default group to be everyone. Hence once the user logs in he will then be marked to default everyone group.
Views
Replies
Total Likes
Hi Ravi,
Yes, thats how the SAML should work, its not necessary to have the user present in the crx.
Just wondering if you have tested adding the content-authors group in the settings and check once.
Thanks
Tuhin
Views
Replies
Total Likes
Tuhin Ghosh wrote...
Hi Ravi,
Yes, thats how the SAML should work, its not necessary to have the user present in the crx.
Just wondering if you have tested adding the content-authors group in the settings and check once.
Thanks
Tuhin
Hi Tuhin,
What do you mean by adding in settings? I have added the default group list in SAML configuration.
Views
Replies
Total Likes
Also observed that everytime it loop in, it creates a new user token. I checked in tokenmagr and it keep adding new user token as we loop in. But if we stop the loop and then hit the URL then it repects that user. So to conclude, somehow the SAML and AEM login service are not coordinating properly.
Views
Replies
Total Likes
By settings I meant configuration in the config manager. sorry for the confusion. Actually when I was doing a POC with SAML I also faced this infinite loop issue, but then adding everyone and content-authors in the default group solved the infinite loop issue for me. If that is not working for you, then it is something else which may be causing this issue. idp_cert file is also correct I guess. You may refer to some of the below community articles. See if these helps.
Please have a look at these old forum posts with similar problem and solution to it:-
//SAML Identity provider - Infinite loop
//AutoCreate CRX users/ Add to groups for SAML handler does not work [AEM 6.1]
//AEM SAML integration, added users to CRX repo after authentication
//SAML AEM infinite loop
Thanks
Tuhin
Views
Replies
Total Likes
Tuhin Ghosh wrote...
By settings I meant configuration in the config manager. sorry for the confusion. Actually when I was doing a POC with SAML I also faced this infinite loop issue, but then adding everyone and content-authors in the default group solved the infinite loop issue for me. If that is not working for you, then it is something else which may be causing this issue. idp_cert file is also correct I guess. You may refer to some of the below community articles. See if these helps.
Please have a look at these old forum posts with similar problem and solution to it:-
//SAML Identity provider - Infinite loop
//AutoCreate CRX users/ Add to groups for SAML handler does not work [AEM 6.1]
//AEM SAML integration, added users to CRX repo after authentication
//SAML AEM infinite loop
Thanks
Tuhin
Hi Tuhin,
Thanks for the links. Much appreciated. I will check these and will let you updated,
Thanks,
Ravi
Views
Replies
Total Likes
We've experienced identical issue with 6.3 (6.3.1.2) as well. Is there a way to prevent this from happening?
It occurs when login-token expired and user being redirected to /system/sling/login.html?resource=%2faem%2fstart.html for re-authentication. I managed to reproduce the issue consistently with following steps:
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies