0

I am implementing the single sign on functionality using WSO2 identity server as the identity provider, PHP-SimpleSamlPhp package and Drupal following this article https://wso2.com/library/articles/2014/10/wso2-identity-server-single-sign-on-with-drupal/

Everything has been setup successfully as below.

  1. Access the drupal app login page and click on the federated link
  2. This redirects you to the WSO2 IS login page as expected
  3. You enter the credentials (stored in WSO2) and click login
  4. The page redirects you to the samlsso URL https://localhost:9443/samlsso?SAMLRequest=fZJNT....
  5. This page keeps loading forever and the SAMLRequest value in the above URL keeps changing.

Logs

  • This shows up at the point 2 above

TID: [-1234] [] [2020-04-12 18:48:14,334] [http://localhost/drupal-8.8.5/en/saml_login] INFO {org.opensaml.core.config.InitializationService} - Initializing OpenSAML using the Java Services API

  • This shows up at point 5 above
TID: [-1234] [2020-04-12 18:53:06,793] [http://localhost/drupal-8.8.5/en/saml_login]  INFO {AUDIT_LOG} - Initiator=wso2.system.user Action=Get-User-List Target=null Data={"Claim Value":"ebdefe27-3912-4502-ad48-5b1a2ee30224","Users":["wickrema"],"Claim":"http://wso2.org/claims/userid"} Outcome=Success

TID: [-1234] [2020-04-12 18:53:06,793] [http://localhost/drupal-8.8.5/en/saml_login]  INFO {AUDIT_LOG} - Initiator=wso2.system.user Action=Get-User-Claim-Values Target=wickrema Data={"Claims":{"http://wso2.org/claims/username":"wickrema","http://wso2.org/claims/userid":"ebdefe27-3912-4502-ad48-5b1a2ee30224","http://wso2.org/claims/created":"2020-04-11T20:53:00.424Z","http://wso2.org/claims/role":"Internal/everyone","http://wso2.org/claims/fullname":"wickrema","http://wso2.org/claims/modified":"2020-04-11T20:53:33.922Z","http://wso2.org/claims/emailaddress":"wickrema@abc.com","http://wso2.org/claims/lastname":"Edirisooriya","http://wso2.org/claims/givenname":"Wickrema","http://wso2.org/claims/resourceType":"User","http://wso2.org/claims/userprincipal":"wickrema"}} Outcome=Success

TID: [-1234] [2020-04-12 18:53:06,794] [http://localhost/drupal-8.8.5/en/saml_login]  INFO {AUDIT_LOG} - Initiator : wickrema | Action : Login | Target : ApplicationAuthenticationFramework | Data : { "ContextIdentifier" : "4f08f619-e1dd-43be-8119-6cc7ea7238ee","AuthenticatedUser" : "wickrema","AuthenticatedUserTenantDomain" : "carbon.super","ServiceProviderName" : "simplesamlphp","RequestType" : "samlsso","RelyingParty" : "simplesaml","AuthenticatedIdPs" : "eyJ0eXAiOiJKV1QiLCAiYWxnIjoibm9uZSJ9.eyJpc3MiOiJ3c28yIiwiZXhwIjoxNTg2NzA2Nzg2NzcxMzAwMCwiaWF0IjoxNTg2NzA2Nzg2NzcxLCJpZHBzIjpbeyJpZHAiOiJMT0NBTCIsImF1dGhlbnRpY2F0b3IiOiJCYXNpY0F1dGhlbnRpY2F0b3IifV19." } | Result : Success

Images

Page that keeps loading after redirection from the WSO2 login page

  • More from the HTTP logs

0:0:0:0:0:0:0:1 - - [12/Apr/2020:20:04:20 +0300] GET /samlsso?SAMLRequest=fZJRT4MwEMe%2FCuk7a2EdyxpYMrcYl0wlG%2Frgi%2BlokSalxV5x%2Bu0FpnG%2B7KnN3f3%2B%2F7trU%2BCNbtmq87XZy%2FdOgg8%2BG22AjYkMdc4wy0EBM7yRwHzJDqv7HYsnhLXOeltajS6Q6wQHkM4ra1Cw3WTolc5oRZOjmJMpp1WViGRBovmUz%2BKSCCGiOJmRhSA0Iih4lg56MkO9UI8DdHJrwHPj%2BxCJSUhoGMVFNGeEspi8oGDTT6MM9yNVe98Cw1jbkuvagmcLSqd46BnAomD129raGuga6Q7SfahSPu13Z%2FiSxaCaVssBxo0VXX8dlTC04xmHvIRJW7f4BDYOoUVB%2FrOsG2WEMm%2FX93Q8FwG7K4o8zB8PBVqmgzAb53bLP%2F8UX8bT83s%2B9IrbTW61Kr%2BCW%2Bsa7q8bDhElwmosZd5xA0oa369Fa3taO8m9zJB3nUR4ebb8%2F2uW3w%3D%3D&RelayState=http%3A%2F%2Flocalhost%2Fdrupal-8.8.5%2Fen%2Fsaml_login HTTP/1.1 200 6020 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36 Edg/80.0.361.111 0.043

  • Below is the authsources and identity provider configuration

Find my authsources.php and identity provider configuration

  • When I did a cookies check as suggested in the comments, this is what I found.

Cookie information

Community
  • 1
  • 1
Kalema Edgar
  • 369
  • 5
  • 17
  • what is your IS version? – Buddhima Udaranga Apr 12 '20 at 19:00
  • My IS version is 5.10.0 @Buddhima – Kalema Edgar Apr 12 '20 at 19:42
  • 1
    Can you perform a browser trace https://brainshark.zendesk.com/hc/en-us/articles/205043644-Performing-a-Browser-Trace-Chrome and check whether there is a cookie named commonauthId. It should have the session details and the host name that session is created for. – Buddhima Udaranga Apr 12 '20 at 20:07
  • 1
    Seems this is your application is sending continuous authentication requests to the identity server. For you first request, WSO2 prompts the login page and send a success SAML response to your applications ACS URL(along with cookies). Application is supposed to read the response and create a application session. Instead it seems the application triggers authentication requests in a loop. As now they are coming with the `commonAuthId` ccockie, WSO2 doesn't prompt login, rather sends back success SAML responses to your ACS. This hapens in a loop. It seems... – Nipun Thathsara Apr 13 '20 at 16:18
  • Thanks @BuddhimaUdaranga and NipunThathsara, I have seen the cookie named commonAuthId as well as the multiple requests being sent. Over 56 requests in a second. I have updated the question with the image after following brainshark instructions since I cannot add an image to the comment. How can I resolve this? – Kalema Edgar Apr 14 '20 at 17:37
  • @NipunThathsara, I found the cookie commonAuthId when I did a trace and I have updated the question with the screnshot. How can I resolve this please. – Kalema Edgar Apr 14 '20 at 17:40
  • 1
    As for me since the cookie domain is localhost the cookie will be omitted. https://stackoverflow.com/questions/1134290/cookies-on-localhost-with-explicit-domain It is recommended that you use a hostname that is not localhost to avoid browser errors. Modify the /etc/hosts entry in your machine to reflect this. https://is.docs.wso2.com/en/5.9.0/learn/deploying-the-sample-app/#deploying-the-playground2-webapp – Buddhima Udaranga Apr 15 '20 at 04:47
  • Thanks @BuddhimaUdaranga. This worked fine once I changed the domain to localhost.com. Can you post the steps to the question so I can mark that as the answer. – Kalema Edgar Apr 15 '20 at 19:00
  • @EdgarKalema added – Buddhima Udaranga Apr 17 '20 at 04:38

1 Answers1

3

Adding answer as steps as requested

By design, domain names must have at least two dots; otherwise the browser will consider them invalid. (See reference on http://curl.haxx.se/rfc/cookie_spec.html)

When working on localhost, the cookie domain must be omitted entirely.

Modify the file /etc/hosts by adding the following entry

localhost.com 127.0.0.1

Then use the domain as localhost.com

For better cookie tracing in your browser, also follow the steps in the link https://brainshark.zendesk.com/hc/en-us/articles/205043644-Performing-a-Browser-Trace-Chrome

Kalema Edgar
  • 369
  • 5
  • 17
Buddhima Udaranga
  • 943
  • 7
  • 10