Thanks Ray.
I hadn't known about the .har file which certainly made network tracing
much easier. We didn't notice a situation where we were getting old TGC
cookies sent, but we confirmed that subsequent requests from different
services would generate a new TGC/TGT and link it to the CAS server
session, thus orphaning older ones. We ended up finding the pre-existing
TGT on the RequestContext object and thus implemented an override action
with this relevant code.
if (context.getRequestScope() != null && context.getRequestScope().get(
TGT_ATTRIBUTE_PARAM) != null) {
TicketGrantingTicket tgt =
this.centralAuthenticationService.getTicket((String)
context.getRequestScope().get(
TGT_ATTRIBUTE_PARAM));
WebUtils.putTicketGrantingTicketInScopes(context, tgt);
return success();
}
On Monday, November 22, 2021 at 1:52:38 PM UTC-5 Ray Bon wrote:
> Ian,
>
> We recently [currently] are experiencing a situation where the browser,
> definitely chrome and maybe others, seems to be storing expired cookies,
> TGC's. The old cookie and the new cookie are being sent to cas with the old
> cookie sent first. Cas extracts the first [expired] TGC which of course
> sends the user to the the login page. Perhaps you are experiencing a
> similar behaviour, but since you delegate your auth, it remembers the user
> session, so user does not see the login screen, but cas creates a new one.
>
> The delegated session would be associated with the first TGT and the one
> service associated with it, explaining the behaviour you are observing.
> (Assuming the logout is triggered by Auth0 -> cas -> services).
>
> Step through the browser network panel to see what cookies are being sent
> and received.
>
> I was not able to reproduce this behaviour in my lab, but I got a user to
> send me a .har file; which is easier to process than clicking through the
> browser's network panel.
>
> IMPORTANT: the .har file will include the raw user input, so it must be
> scrubbed of passphrases by the user generating it.
>
> We have not come up with a solution other than to close the browser or use
> a private window.
>
> These loggers may help on the cas side:
>
> <!-- DEBUG TGT and ST
> on logout ST and service -->
> <AsyncLogger
> name="org.apereo.cas.AbstractCentralAuthenticationService" level="error"
> includeLocation="true">
> <!-- DEBUG service status and logout process and a lot of details
> -->
> <AsyncLogger name="org.apereo.cas.logout" level="info" />
> <!-- INFO Performing logout operations for [TGT-...]
> [number] logout requests were processed
> DEBUG ST, principal and URL -->
> <AsyncLogger name="org.apereo.cas.logout.DefaultLogoutManager"
> level="info">
> <Filters>
> <ThresholdFilter level="INFO" onMatch="ACCEPT"
> onMismatch="NEUTRAL" />
> <RegexFilter regex="Captured logout request.*"
> onMismatch="DENY" />
> </Filters>
> </AsyncLogger>
> <!-- DEBUG Logout request will be sent to but does not print
> anything when login was through SAML 1.1 -->
> <AsyncLogger
> name="org.apereo.cas.logout.DefaultSingleLogoutServiceLogoutUrlBuilder"
> level="warn" />
> <!-- DEBUG preparing, processing and logout with URL and ST -->
> <AsyncLogger name="org.apereo.cas.logout.slo" level="warn" />
> <!-- DEBUG SAML logout payload -->
> <AsyncLogger
> name="org.apereo.cas.logout.SamlCompliantLogoutMessageCreator" level="warn"
> />
>
> Ray
>
> On Mon, 2021-11-22 at 09:59 -0800, Ian Shoemaker wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
>
> Hello,
>
> We're updating our CAS server to federate authentication to Auth0. The
> work has been completed, but one of the features we still intend to use is
> CAS's SLO (both front and back channel.) In our testing, we've noticed that
> when a user is logged in and has accessed multiple services registered with
> CAS, SLO is only enacted for the most recently requested service and not
> all of them.
>
> In our debugging we've found that the TGC cookie does exist and the CAS
> server does find this along with a corresponding TGT correctly, however,
> the spring session does not appear to get established with the expected
> user. What I'm attempting to understand is if that may be intentional after
> moving to federated auth as it could be perceived that the auth provider is
> the source of truth for being logged in and that CAS shouldn't rely on its
> own session. I haven't found documentation describing this or related
> configuration options from the CAS docs.
>
> The outcome ends up being that every subsequent service request propagates
> to the auth provider AND a new TGC/TGT is generated each time for the same
> user. This in turn resets the list of LogoutRequest records and we only log
> out of one service.
>
>
> CAS version 5.1.3 - Upgrading isn't out of the question, but looking to
> understand what the expectation is first.
>
> Thanks,
> Ian Shoemaker (iss...@gmail.com)
>
> --
>
> Ray Bon
> Programmer Analyst
> Development Services, University Systems
> 2507218831 <(250)%20721-8831> | 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.
>
--
- 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+unsubscr...@apereo.org.
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/57ab110a-55df-4188-aff3-376ab880d857n%40apereo.org.
