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
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
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:
https://cas50.example.edu/cas/login?service=https://www.example.com/regression/app1&renew=true
Then:
https://cas50.example.edu/cas/login?service=https://www.example.com/regression/app2
Close the prior private window, and use a new private/incognito window to
test CAS 6.3:
https://cas63.example.edu/cas/login?service=https://www.example.com/regression/app1&renew=true
Then:
https://cas63.example.edu/cas/login?service=https://www.example.com/regression/app2
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.
On Fri, Jun 25, 2021 at 7:04 AM Baron Fujimoto <[email protected]> wrote:
> 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.
>
> On Fri, Jun 25, 2021 at 6:24 AM Ray Bon <[email protected]> wrote:
>
>> 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.
>>
>> 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.:
>>
>> Location:
>> https://casdemo.example.edu/casdemo/login/cas?ticket=ST-2-ujMo86d2pYcEebVDEFzWvAKghxE-cas
>>
>> 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 <[email protected]> :: UH Information Technology Services
>> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
>>
>> --
>> - 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 [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/a/apereo.org/d/msgid/cas-user/3cbe7a3608edb6aedd78634e10d14bf72ea6a772.camel%40uvic.ca
>> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/3cbe7a3608edb6aedd78634e10d14bf72ea6a772.camel%40uvic.ca?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> Baron Fujimoto <[email protected]> :: UH Information Technology Services
> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
>
--
Baron Fujimoto <[email protected]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL1L62ZRD_KU2OWNv46GbLo%2BaLF67C_aoUuRMMmAweFFyg%40mail.gmail.com.
