Cas 6.1 SSO not working

[Rod B]

Hello Everyone!

I'm held up deploying 6.4.2 so I'm back on 6.1 for the Google App integration provided by it.

I'm able to log into a testing site in the /etc/cas/services directory. I'm redirected to the CAS login page. Once I authenticate, I continue to the testing site.

I'm also able to log into Google calendar where I'm redirected to the CAS login page. Once I authenticate I continue to the Google calendar.

However, when I log into the testing site and then attempt on another tab go to Google calendar, I'm redirected to the CAS login page and not SSO'd into Google Calendar.

This happens also if I log into Google Calendar and then attempt to access the testing site.

I believe this is the relevant bits of the /etc/cas/config/cas.properties file (I could be missing something)

cas.tgc.crypto.encryption.key=**redacted**

cas.tgc.crypto.signing.key=**redacted**

cas.webflow.crypto.signing.key=**redacted**

cas.webflow.crypto.encryption.key=**redacted**

This is how it looks for the two /etc/cas/services JSON files:

google_apps-44.json 

{

  "@class" : "org.apereo.cas.services.RegexRegisteredService",
  "serviceId" : "https://www.google.com/a/example.com/acs",
  "name" : "Google Apps",
  "theme" : "ourschool",
  "id" : 44,
  "accessStrategy" : {
    "@class" : "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",
    "ssoEnabled" : true
  }
"evaluationOrder" : 10
}

For the test site:

{
"@class" : "org.apereo.cas.services.RegexRegisteredService"
"serviceId" : "http://cas-test.dev.ourschool.ca/wp-login.php*",
"name" : "CasTest",
"id" : 1,
"accessStrategy" : {
"@class" : "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy"
"ssoEnabled" : true
  }
"theme" : "ourschool"
"evaluationOrder" : 1
}

I'm thinking I'm missing something in cas.properties as I don't think I need to put in the accessStrategy part, I was just seeing if it would work.

I do see that a TGC cookie is granted on the browser.

Thank you for any suggestions and help.

Rod

[Andy Ng]

Hi Rod,

Usually this happen when you setup your CAS as http instead of https.

- When CAS is in http, SSO will not work. Making sure it is https should make it work again.

- The services you provided seems fine, didn't see any issue on them.

- But the ssoEnabled part should be not neccesary since that would be the default

If the above still not able to solve your issue, then you might need to provide a little bit more information, like a full cas.properties (sensitive data removed of course). 

Cheers!

- Andy

[Rod B]

Hi Andy,

I've attached our cleansed cas.properties file. We do use https. I'm also including our virtual hosts set up that shows we redirect to https if a http request to the CAS server comes in.

Many thanks for having your eyes on this.

Rod

[Ray Bon]

Rod,

Use your browser developer tools to see the TGC sent from and to cas. Verify that there are no stale TGCs (there should only be one and it should not change during an sso session).

Does this behaviour happen in a new private window?

You can test repeated logins to your test app by removing its session cookie (NOT the TGC). This should trigger the test app to go to cas where you 'should' be SSOed.

You may want to turn up logging on the cas server to see what it thinks is going on.

Ray

On Thu, 2021-12-02 at 08:50 -0800, Rod B wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands, and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.

[Rod B]

Hi Ray,

I have confirmed there are no stale TGC's hanging around. Once we sign into the test site, opening another tab and going to the same test web page is SSO'd. It also works when I remove the Session cookie, open another tab and go to the same test site.

When I open an incognito browser, authenticate through the CAS page and am redirected to the registered test site. I think as expected no session cookie is set, however when I open a browser tab and put in the URL for the test site, I'm properly logged into the site through SSO.

The issue is happening where I authenticate through the test site and then attempt to go to https://www.google.com/calendar/hosted/testdomain.ca

I'm redirected to the CAS login page.

Whereas with our very old implementation the SSO kicks in and works.

I'll look up how to increase logging in the CAS server.

Thank you,

Rod

[Rod B]

Ok, I've sanitized the catalina.out log with the debug info. Nothing really sticks out to me. I see SSO is enabled. The only thing I do see is in the INFO section the CAS server doesn't know it's IP?

SERVER IP ADDRESS: unknown

However because SSO works logging into the same test site repeatedly, I think something else is afoot.

So the this debug log captures me going to the test site, being redirected to the CAS login page and then redirected to the test site. Then the next set of events is when I attempt to go to https://www.google.com/calendar/hosted/testdomain.ca. I stopped it when I was redirected to the CAS login page, because I thought this is the bit that should have captured the cookie being requested from my browser to SSO me in.

Thanks again for the eyes on this!

Rod

[Ray Bon]

Rod,

Nothing looks out of the ordinary in the log (except the lack of SSO).

Is it possible that the ticket store is not working/configured correctly?

Check the properties against those listed in the cas docs for 6.4. There may be some name changes.

Ray

[Andy Ng]

Hi Rod,

Agree with Ray, your cas.properties does not seems to have any out of the ordinary config.

Not able to see any issue with the log as well, but the cookie doesn't seems to works when you open Google Apps

Since I also don't know what is the issue, let's go through some alternative solution just want to make sure it is not some browser issue:

- Is your website or google loaded in an iframe?

  - Modern browser and iframe does not work really well together

- In the CAS properties for 6.2 forward, there is a config called "same-site-policy"

  - https://apereo.github.io/cas/6.2.x/configuration/Configuration-Properties-Common.html#cookie-properties

  - In some cases I found that I need to set TGC cookie same site policy to none in order for the SSO to load

  - You can try modifying it directly using Chrome debugger, see if the SSO show after the change

- You can try different browser

- You can try disable all cookie blocking mechanism for the browser (e.g. 3rd party cookie block, same site policy restriction, etc)

- Double check both your website and Google App are pointing to the same CAS domain (CAS server itself cannot be set using multiple domain)

Well, if the above not helping, then might be an CAS bug, maybe update to using a different CAS version then 6.1 and see if it works better?

Cheers!

- Andy

[Rod]

Hi Andy,

Thank you so much for your help. 

The issue was I was testing with one domain, and also using another. 

I.e externally CAS I was using example.com, internally I alaised the CAS server as example.net.

As I've now learned the hard way the CAS server cannot be set for multiple domains. 

Thanks to Ray and everyone else that looked at my configs and logs. I only hope I can help someone out on here someday too!

-Rod

[Andy Ng]

Hi Rod, Glad it helps! -Andy