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. On Tue, Jul 6, 2021 at 5:27 AM Dustin J Luck <[email protected]> wrote: > The renew=true issue was resolved in 6.3.5. > > > > On Friday, July 2, 2021 at 6:12:12 PM UTC-7 baron wrote: > >> 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/dd2c7ec2-4e83-4290-941d-f438309e5ae9n%40apereo.org > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/dd2c7ec2-4e83-4290-941d-f438309e5ae9n%40apereo.org?utm_medium=email&utm_source=footer> > . > -- 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/CAAjLUL1XpOSggiyb4xinfafh8wSHB4c_7RYXZ9RG%2BMs_-AY_xw%40mail.gmail.com.
