SAML and AEM login service going for infinite loop | Community
Skip to main content
R
Ravi_KS
Level 3
July 13, 2016

SAML and AEM login service going for infinite loop

  • July 13, 2016
  • 4 replies
  • 9521 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

4 replies

Tuhin_Ghosh
Tuhin_Ghosh
Level 8
July 13, 2016

HI,

 

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

 

Thanks

Tuhin

R
Ravi_KSAuthor
Level 3
July 13, 2016

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
Tuhin_Ghosh
Level 8
July 13, 2016
        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.
R
Ravi_KSAuthor
Level 3
July 14, 2016

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.

R
Ravi_KSAuthor
Level 3
July 15, 2016

Hi Ravi,

 

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

 

Thanks

Tuhin


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. 

K
Kkkrish
Level 4
July 14, 2016

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

R
Ravi_KSAuthor
Level 3
July 14, 2016

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
Tuhin_Ghosh
Level 8
July 14, 2016

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

L
LYUAN
Level 2
March 7, 2018

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
Terms & ConditionsAccessibility statement

Loading footer...