SAML and AEM login service going for infinite loop

[Ravi_KS]

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

[Tuhin_Ghosh]

HI,

Please add everyone and content-authors in the groups and see if that works

Thanks

Tuhin

[Ravi_KS]

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.

[Tuhin_Ghosh]

        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.

[Ravi_KS]

I will add and will check the outcome.

[Ravi_KS]

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.

[Tuhin_Ghosh]

Hi Ravi,

I guess you have not removed the everyone group. both 'everyone' and 'content-authors' are there, correct?

Thanks

Tuhin

[Ravi_KS]

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. 

[Kkkrish]

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

[Ravi_KS]

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.

[Tuhin_Ghosh]

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

[Ravi_KS]

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.

[Ravi_KS]

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.

[Tuhin_Ghosh]

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

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//SAML Identity provider - Infinite loop

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//AutoCreate CRX users/ Add to groups for SAML handler does not work [AEM 6.1]

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//AEM SAML integration, added users to CRX repo after authentication

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//SAML AEM infinite loop

Thanks

Tuhin

[Ravi_KS]

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

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//SAML Identity provider - Infinite loop

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//AutoCreate CRX users/ Add to groups for SAML handler does not work [AEM 6.1]

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//AEM SAML integration, added users to CRX repo after authentication

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

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

[scotty13086097]

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:

1. Have a working AEM SAML integration enabled on '/' (I also enabled auto create user and administrators in default groups)
2. Sign in AEM with SAML
3. Within the same browser, go to AEM location http(s):/HOST:PORT/system/sling/login.html?resource=%2faem%2fstart.html