IPetr, you haven't seen any other issues with this work around? For my users authenticatng via delegated azure ad I'm getting a cas client not authorized error which is misleading because the issue in logs show a tgt primary key constraint violation.
-psv On Tuesday, March 26, 2024 at 11:40:57 AM UTC-7 Petr Bodnár wrote: > Hi all, > > thanks for the fruitful discussion. Some more fresh remarks to the topic: > > 1) The order of "Set-Cookie" response headers indeed depends on the server > > While *Tomcat *clearly uses deterministic, insertion-time order (see its > Response.java > <https://github.com/apache/tomcat/blob/510c71b009085f94122bc18501d1981322846540/java/org/apache/catalina/connector/Response.java#L880>), > > *JBoss*/*WildFly *for some weird reason stores cookies in a *TreeSet*, so > their output order should be random (see its HttpServletResponseImpl.java > <https://github.com/undertow-io/undertow/blob/ddb4aeeb32f7ed58d715124acf1d464fc14b30dd/servlet/src/main/java/io/undertow/servlet/spec/HttpServletResponseImpl.java#L112> > > and from there, HttpServerExchange.java > <https://github.com/undertow-io/undertow/blob/ddb4aeeb32f7ed58d715124acf1d464fc14b30dd/core/src/main/java/io/undertow/server/HttpServerExchange.java#L1255> > ). > > 2) Since version 6.4.0, CAS deletes TGC cookie more aggressively > > In https://github.com/apereo/cas/commit/02e9c27a6b60505, a new method > *removeAll(request, > response)* was added (and is called) that additionally removes the cookie > only if it is present in the request. > > 3) Since version v7.0.0-RC2, CAS deletes TGC only when it is present in > the request > > In https://github.com/apereo/cas/commit/9454b38b8d95d7, just the > aforementioned new method *removeAll(request, response)* is used. > > 4) This issue doesn't affect just the delegated authentication, but also > authentication via Kerberos (SPNEGO) > > The Kerberos authentication seems to be affected in the very same way, but > possibly no one really noticed or cares, because the automatic login is > practically invisible to the user. > > 5) Conclusion > > All that being said, it looks like removing the unconditional call to > *ticketGrantingTicketCookieGenerator.removeCookie(response) > *actually IS the correct solution. And leaving just the new call to > *removeAll(request, > response)* should be just fine - because this call should be effective > only when being initially redirected to CAS login page with an invalid > (e.g. expired) TGC cookie. > > Feel free to correct me. > > Regards > Petr > > On Thursday 4 January 2024 at 04:39:17 UTC+1 Pablo Vidaurri wrote: > >> Ran into the same issue with v6.6.8 and v6.6.14. Also removed the line >> in InitialFlowSetupAction.java that sets empty cookie and I get proper >> session now. But this does not look like a correct fix. >> >> On Monday, January 11, 2021 at 4:00:17 PM UTC-6 Ulrich Mayring wrote: >> >>> Ray, >>> thanks a lot for your comments. I believe this more or less settles the >>> issue that we have a bug here, but it doesn't bite everyone. So I suppose >>> those, who are unaffected, can just carry on. >>> >>> We have fixed the issue in our overlay by simply removing the code that >>> sets the "empty" cookie. If you ever find that the order of cookies changes >>> on you, you can do the same thing. Our test suite is green, so I guess that >>> for our purposes this rather brute-force fix will work. I have no idea what >>> it would take to fix this in CAS main, but I did notice that the code to >>> remove a cookie was changed from using the Servlet API to a custom >>> implementation, where the header is set manually. So perhaps going back to >>> using the Servlet API (response.addCookie) would be enough. >>> >>> On Monday, 11 January 2021 at 17:25:28 UTC+1 Ray Bon wrote: >>> >>>> Ulrich, >>>> >>>> You are correct. >>>> And I do receive the cookies with the expired cookie first. >>>> >>>> Ray >>>> >>>> On Sat, 2021-01-09 at 11:39 -0800, Ulrich Mayring wrote: >>>> >>>> Notice: This message was sent from outside the University of Victoria >>>> email system. Please be cautious with links and sensitive information. >>>> >>>> Ray, >>>> the section you refer to applies to the "Cookie" header the browser >>>> sends back. However, I was talking about the "Set-Cookie" header sent by >>>> the server. Its semantics are defined in section 4.1.2 of the RFC and it >>>> clearly states that the server can delete a cookie by sending a Set-Cookie >>>> header with an expired date. >>>> >>>> What's more, RFC 6265 clearly states that the server SHOULD NOT include >>>> more than one Set-Cookie header field in the same response with the same >>>> cookie-name. So CAS clearly is in violation of that. Most user-agents will >>>> probably react to that by accepting the last Set-Cookie header and so the >>>> order of those headers really matters. >>>> >>>> Therefore my question to you was whether you are receiving the >>>> "Set-Cookie" headers in a different order than I am, because that would >>>> explain why your browser processes them differently. >>>> >>>> Kind regards, >>>> Ulrich >>>> On Friday, 8 January 2021 at 21:01:44 UTC+1 Ray Bon wrote: >>>> >>>> Ulrich, >>>> >>>> According to, https://tools.ietf.org/html/rfc6265, in particular >>>> 4.2.2, the order of cookies in the header should not matter. >>>> Is it possible that the app server is setting/modifying the order? >>>> I am using tomcat 9. >>>> >>>> Ray >>>> >>>> On Fri, 2021-01-08 at 10:01 -0800, Ulrich Mayring wrote: >>>> >>>> Notice: This message was sent from outside the University of Victoria >>>> email system. Please be cautious with links and sensitive information. >>>> >>>> Different workflow here. I access my application and it redirects to >>>> the CAS Login Page. On the CAS Login Page I can choose whether to log in >>>> directly (via CAS protocol) or externally (via Azure). To that end there >>>> is >>>> a button that will take me to the Azure login page. >>>> >>>> However, my browser will also have seen the "empty" cookie, since I'm >>>> passing through the CAS login page. But I don't think that can have any >>>> effect - what difference should it make to the browser, whether a cookie >>>> has been seen before? Have you checked in which order you receive the two >>>> cookies? Perhaps the "empty" cookie comes first in your case, so it is >>>> then >>>> overwritten by the "full" cookie? >>>> >>>> My cookie is also named TGC-1.2.3, I'm using the CAS default as well. >>>> >>>> cheers, >>>> Ulrich >>>> >>>> On Friday, 8 January 2021 at 18:29:19 UTC+1 Ray Bon wrote: >>>> >>>> Ulrich, >>>> >>>> Same versions of chrome and firefox on linux. >>>> When I use delegated auth to azure, I first pass through the cas log in >>>> page and it redirects to azure. Thus my browser has already 'seen' the >>>> empty TGC. >>>> Is this your flow, or do you go to azure first? >>>> >>>> Also, does your TGC have a suffix, '-1.2.3'? >>>> I am using the default cas setting that has no suffix, the cookie label >>>> is 'TGC'. This should not matter, but stranger things have happened. >>>> >>>> Ray >>>> >>>> On Fri, 2021-01-08 at 01:21 -0800, Ulrich Mayring wrote: >>>> >>>> Notice: This message was sent from outside the University of Victoria >>>> email system. Please be cautious with links and sensitive information. >>>> >>>> I have tested this with Firefox 84 and Chrome 87.0.4280.88 and in both >>>> cases no cookie is sent with the next request, thus failing to login the >>>> user. >>>> >>>> As far as I understand, the server is allowed to send multiple >>>> "Set-Cookie" headers with different values. The client (browser), however, >>>> is only allowed to send one "Cookie" header back. He can concatenate the >>>> multiple values into that one field, though. But it appears that in my >>>> case >>>> the browser looks at the two Set-Cookie headers seperately. The first one >>>> is accepted as a new cookie, but the second one without a value is >>>> apparently interpreted as "delete this cookie". Thus no cookie is sent >>>> with >>>> the next request. >>>> >>>> If I understand you correctly, then in your case the browser is sending >>>> the correct TGC-Cookie, even though you also receive the two Set-Cookie >>>> headers? >>>> >>>> Kind regards, >>>> Ulrich >>>> On Thursday, 7 January 2021 at 19:22:14 UTC+1 Ray Bon wrote: >>>> >>>> Ulrich, >>>> >>>> I see the two TGCs on return from azure. I can not tell which arrived >>>> first, but the stored TGC does have a value, and subsequent login does >>>> send >>>> this value. >>>> Could this be related to browser behaviour? >>>> >>>> I tested in firefox and chrome. The empty cookie has Expires=1970... >>>> and Max-Age=0; the one with a value has no Max-Age and no Expires but does >>>> have a SameSite. >>>> >>>> Ray >>>> >>>> On Thu, 2021-01-07 at 05:00 -0800, Ulrich Mayring wrote: >>>> >>>> Notice: This message was sent from outside the University of Victoria >>>> email system. Please be cautious with links and sensitive information. >>>> >>>> >>>> Before posting a bug report I'd like to hear your opinions - perhaps >>>> I'm on the wrong page. >>>> >>>> When authenticating with an application that uses CAS, the first thing >>>> that happens is that the CAS login form appears. Before that form is sent >>>> to the browser, CAS is internally trying to delete any TGC-Cookies that >>>> might exist. >>>> >>>> This happens in line 95 of this class: >>>> https://github.com/apereo/cas/blob/6.2.x/support/cas-server-support-actions/src/main/java/org/apereo/cas/web/flow/login/InitialFlowSetupAction.java >>>> >>>> The result is that the following header is sent to the browser (JSON >>>> notation as copied from the Firefox Dev Tools): >>>> >>>> "name": "set-cookie", >>>> "value": "TGC-1.2.3=\"\"; Version=1; Path=/mycas/; Secure; HttpOnly; >>>> Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT; Comment=\"CAS Cookie\"" >>>> >>>> The reason for that "empty" cookie is probably that the only way to >>>> delete a cookie as per the Servlet API is to set a new one with an empty >>>> value. Apparently CAS is trying to do that here. It doesn't matter much, >>>> because we are talking only about the login page, but this becomes >>>> important later on. >>>> >>>> When I login via CAS protocol, i.e . POSTing my credentials to >>>> https://cas-server/mycas/login?locale=de >>>> <https://172.16.16.16:8443/ooscas/login?locale=de> I'll get back a >>>> proper TGC cookie and am authenticated: >>>> >>>> "name": "set-cookie", >>>> "value": "TGC-1.2.3=eyJhbG...; Path=/mycas/; SameSite=None; Secure; >>>> HttpOnly" >>>> >>>> However, when I do the same thing via external authentication (Azure >>>> OpenID Connect), I am entering the OAuth2 Authorization Code flow and >>>> arrive at POSTing to the URL >>>> https://cas-server/mycas/login?code=0.ATAAHe5... - in other words, I >>>> am not sending my credentials, but an Authorization Code I have obtained >>>> from Azure. Upon POSTing to that URL I am getting both of the >>>> above-mentioned headers back. >>>> >>>> So the browser is getting the "full" TGC-Cookie and an "empty" one. >>>> Because the "empty" one arrives last, the browser sends it for its next >>>> request and obviously authentication fails at that point. >>>> >>>> I have debugged into the CAS code and found that the above-mentioned >>>> code in line 95 of InitialFlowSetupAction is called again during >>>> authentication, which results in the extra "empty" header. >>>> >>>> Bottom line: the TGC cookie is not removed properly, resulting in two >>>> "set-cookie" headers. But this only breaks external authentication. When >>>> authenticating directly with CAS the cookie removal code is not called >>>> during authentication and thus we only have one "set-cookie" header. >>>> >>>> I have noted that the code to remove cookies was changed between CAS >>>> 5.3 (where this issue does not exist) to CAS 6.2. So what do you think? Is >>>> this a bug or do I misunderstand something about cookie handling or CAS? >>>> >>>> -- >>>> >>>> >>>> Ray Bon >>>> Programmer Analyst >>>> Development Services, University Systems >>>> 2507218831 <(250)%20721-8831> | CLE 019 | [email protected] >>>> >>>> I respectfully acknowledge that my place of work is located within the >>>> ancestral, traditional and unceded territory of the Songhees, Esquimalt >>>> and >>>> WSÁNEĆ Nations. >>>> >>>> -- >>>> >>>> >>>> Ray Bon >>>> Programmer Analyst >>>> Development Services, University Systems >>>> 2507218831 <(250)%20721-8831> | CLE 019 | [email protected] >>>> >>>> I respectfully acknowledge that my place of work is located within the >>>> ancestral, traditional and unceded territory of the Songhees, Esquimalt >>>> and >>>> WSÁNEĆ Nations. >>>> >>>> -- >>>> >>>> >>>> Ray Bon >>>> Programmer Analyst >>>> Development Services, University Systems >>>> 2507218831 <(250)%20721-8831> | CLE 019 | [email protected] >>>> >>>> I respectfully acknowledge that my place of work is located within the >>>> ancestral, traditional and unceded territory of the Songhees, Esquimalt >>>> and >>>> WSÁNEĆ Nations. >>>> >>>> -- >>>> >>>> Ray Bon >>>> Programmer Analyst >>>> Development Services, University Systems >>>> 2507218831 <(250)%20721-8831> | CLE 019 | [email protected] >>>> >>>> I respectfully acknowledge that my place of work is located within the >>>> ancestral, traditional and unceded territory of the Songhees, Esquimalt >>>> and >>>> WSÁNEĆ Nations. >>>> >>> -- - 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/6a0fe106-2234-43ef-9fec-3f24b534cb0bn%40apereo.org.
