CAS 6.3 extracting the ST from the redirect response location?

90 views
Skip to first unread message

Baron Fujimoto

unread,
Jun 24, 2021, 11:05:56 PM6/24/21
to CAS Community
We have another strange issue with our CAS 5.0 to 6.3 upgrade. We have a homebrew regression test for 5.0 that parsed the HTML for the service ticket from the Location header in a 302 redirect response after authentication. E.g.:


But with our 6.3 instance, we don't seem to see this 302 and Location header after authentication from our homebrew test. Nor do the logs show an ST being issued after an apparently successful authentication from the test. Browser developer tools seem to show a number of scripts being executed after authentication via "normal" sample client. Is the missing ST perhaps because we don't execute these scripts in our regression test? If so, can anyone tell us which script is responsible, or a possible workaround?
-- 
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

King, Robert

unread,
Jun 25, 2021, 8:06:34 AM6/25/21
to cas-...@apereo.org

Is your resource path correct in that URL?  Normal cas login URI tends to end in “/cas/login” and your instance you have the two reversed.

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL2-xuxeZ%3Dhyb1nvgGYKRF9poiX%3DamVPgXHGC4vW8nJfeQ%40mail.gmail.com.

Baron Fujimoto

unread,
Jun 25, 2021, 12:10:49 PM6/25/21
to CAS Community
Yes, I believe so. The same regression test works for our CAS 5.0 instances, which uses the same /cas/login path. And the AuthN succeeds when we run it against CAS 6.3, so I think that's also further evidence that at least that much is correct. The (mildly redacted) sample location response header I provided was obtained from a browser's developer console trace of an actual working CAS client using our CAS 6.3 instance. This was the sort of response we expect to see in our regression test but don't seem to be.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/5f08b2aec6a54226a96da067e498240e%40mun.ca.

Ray Bon

unread,
Jun 25, 2021, 12:24:55 PM6/25/21
to cas-...@apereo.org
Baron,

My dev tools show the 302 and location header (with ST) on the POST. We do not have any other scripts running

Do you have any modifications to the log in page or the log in flow?

Ray

On Thu, 2021-06-24 at 17:05 -1000, Baron Fujimoto wrote:
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

Baron Fujimoto

unread,
Jun 25, 2021, 1:04:47 PM6/25/21
to CAS Community
Our regression test is a homebrew perl-based thing. With the "real" CAS client, we see the 302 with location header in the response from the CAS server, but unfortunately we can't use the same browser dev tools on our script-based tests. Something must differ though. Looks like we'll have to put time and effort into closely going over our logs carefully and examining what we're sending and receiving with our regression test.

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/3cbe7a3608edb6aedd78634e10d14bf72ea6a772.camel%40uvic.ca.

Baron Fujimoto

unread,
Jul 2, 2021, 9:12:12 PM7/2/21
to CAS Community
My colleague was able to work through this.

He reports that we basically didn't have to call Duo with 5.0 in order to get the ticket back from CAS. We used to submit username and password to the CAS login screen, and the response would be a 302 with a URL that embedded the ticket. No interaction with Duo was required prior to the ticket being returned to the browser.

Now we submit the username and password, get back a form with hidden inputs such as 'execution' and some Duo data in an iframe with the id duo_iframe.  We then have to perform a GET and a POST with that Duo data in order to get back a js_cookie value that's embedded in the response content. We use that js_cookie and data from the duo_iframe, as well as the prior 'execution' input, and resubmit all that to CAS to get back the 302 response with the ticket.

Clearly we have Duo MFA enabled for our CAS instance, but this does seem to be a change from how things worked with Duo enabled for 5.0.

It was also noted that the SAML responses differed for samlValidate.

The SAML from CAS5 includes xmlns attributes, e.g.:

<saml1:AttributeValue
    xsi:type="xsd:string">
   uid=testuser
</saml1:AttributeValue>

Whereas the SAML returned by CAS 6.3 doesn't, e.g.:

<saml1:AttributeValue>
    uid=testuser
</saml1:AttributeValue>


Finally, there seems to be a bug(?) for CAS 6.3 where SSO doesn't work if your first CAS session has renew=true. If we try this sequence of URLs with CAS 5.0,  it works as expected:

Use a new private/incognito window to test CAS 5.0:


Then:


Close the prior private window, and use a new private/incognito window to test CAS 6.3:


Then:


SSO doesn't work for the second URL. The bug seems to have to do with starting with renew=true from the start. If you start without it, it works as expected. Behind the scenes, the renew=true seems to prevent the TGC cookie from being sent.


Dustin J Luck

unread,
Jul 6, 2021, 11:26:58 AM7/6/21
to CAS Community, baron
The renew=true issue was resolved in 6.3.5.

Baron Fujimoto

unread,
Jul 6, 2021, 5:01:41 PM7/6/21
to CAS Community
CAS 6.3.5 does seem to have fixed the problem originally described, but now there seems to be a different bug for /validate and /serviceValidate.

If we first establish an SSO session by logging in to app1, then we login to app2 (without setting renew=true) and attempt to either /validate or /serviceValidate app2 with renew=true, we expect this to fail, but instead it succeeds. It does fail as expected with /samlValidate, so this behavior is not consistent among the validation methods. This is a change from 6.3.4.

Reply all
Reply to author
Forward
0 new messages