Thank you David for these explanations and links. I tested the two solutions, it works fine when
1- setting TGT timeout < *maxAuthenticationAge* 2- setting a timeout for specific service using ExpirationPolicy. I have now workarounds if client apps can't modify the *maxAuthenticationAge* *Best regards.* Le ven. 1 déc. 2023 à 16:51, David Gelhar <[email protected]> a écrit : > Hi Mohamed, > > The thing is, the SAML standard is specific that AuthnInstant means "the > time when the user authenticated to the IdP". > > > This isn't just CAS that does this, other identity providers like Okta or > Microsoft Entra ID work the same way, for example: > > > https://support.okta.com/help/s/question/0D50Z00008C3jeaSAB/saml-authninstant-validation-on-sp?language=en_US > Okta will send a value of the time of authentication for AuthnInstant. > > > https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol > > - The AuthnInstant attribute specifies the time at which the user > authenticated with Microsoft Entra ID. > > > On Dec 1, 2023, at 9:50 AM, Mohamed Amdouni <[email protected]> wrote: > > Hello David, > > Thank you for your reply. > > This is what I'm trying to avoid : change all client applications to adapt > the maxAuthenticationAge which has 7200 seconds by default for Spring > Applications. > > From a *client perspective*, the authenticationDate is when responding to > the AuthenticationRequest (in my opinion) What CAS uses internally should > be kept internally (f CAS return a SAML response from a TGT or from > validating a Spnego token etc ). > > If it's the final solution in CAS, I think that we lose the advantages of > TGT and SSO when we set TGT timeout to 8Hours or above. > I think that I will try to implement one of these workarounds (since the > client's SAML applications are not in my scope). > 1- Set TGT timeout to less than 7200 seconds --> problem : increase the > authentications between CAS and the AD > 2- Keep TGT timeout as it is (8H), and set the expiration policies of TGT > to less than 7200 for Spring clients > > But I would prefer if there were a fix in CAS, if maintainers agree that > from client perspective, it should be a new date not the initial TGT date. > > Best regards. > > > Le ven. 1 déc. 2023 à 13:26, David Gelhar <[email protected]> a > écrit : > >> Yes, it is a bug -- in CAS 5. CAS 6 is doing the right thing here; it was >> the old version of CAS that had it wrong. >> >> The SAML AuthnInstant is supposed to indicate when authentication occured >> (when the user entered their password TGT was issued), not when the most >> recent service ticket was issued. >> >> We saw similar issues with some specific Spring-based applications after >> upgrading to CAS 6, and the solution was to configure those applications so >> that their maxAuthenticationAge setting (the oldest AuthnInstant they are >> willing to accept) aligns with the CAS server's TGT lifetime. >> >> This may prove helpful >> https://stackoverflow.com/questions/30528636/idp-initiated-saml-login-error-authentication-statement-is-too-old-to-be-used/30543585#30543585 >> >> On Thursday, November 30, 2023 at 5:31:07 AM UTC-5 Mohamed Amdouni wrote: >> >>> Hello, >>> >>> When comparing the behavior between cas 5.X and cas 6.X there are some >>> differences in building the SAML2 Response : >>> >>> *CAS 5.X :* >>> The authenticationDate is returned from the validateTicket method here >>> <https://github.com/apereo/cas/blob/ebf8a8e192ca0569ef92f95421039ad68b44fe3d/support/cas-server-support-saml-idp-web/src/main/java/org/apereo/cas/support/saml/web/idp/profile/sso/SSOSamlProfileCallbackHandlerController.java#L129> >>> which uses an updated date from the ST ticket, not the TGT one. >>> Assertions (AuthnDate) are built from the ST Ticket. >>> >>> *CAS 6.X : * >>> The build cas assertions method here >>> <https://github.com/apereo/cas/blob/7dc053c83bde300b50027d70b5102a391057435c/support/cas-server-support-saml-idp-web/src/main/java/org/apereo/cas/support/saml/web/idp/profile/AbstractSamlIdPProfileHandlerController.java#L150> >>> uses the authenticationDate of the TGT ticket which is an old date, so if >>> the TGT timeout is set to more than 2Hours Spring Saml2 Clients will reject >>> the response because it's an old date. >>> Assertions (AuthnDate) are built from TGT ticket. >>> >>> Is it a bug ? Is there a property that will restore the old behavior? >>> >>> Thank you. >>> >>> >>> >>> Le ven. 24 nov. 2023 à 16:59, Mohamed Amdouni <[email protected]> a >>> écrit : >>> >>>> Hello, >>>> >>>> When I test with the old version of cas 5.3.X (same saml client) --> >>>> there is no issue even after 1hour2 or 3 hours. >>>> >>>> When I test with the new version 6.6.X (same SAML client) --> first >>>> response OK , second OK, after 2 hours : problem with the SAML response : >>>> Authentication >>>> statement is too old error >>>> >>>> The same configuration of TGT (10H) and st timeouts is applicable for >>>> the two versions : >>>> >>>> >>>> - cas.ticket.tgt.timeout.max-time-to-live-in-seconds=36000 >>>> - cas.ticket.st.time-to-kill-in-seconds=120 >>>> >>>> >>>> The problem is with the SAML response which is different in the two >>>> versions. In version 6.6.X the saml:AuthnStatement/AuthnInstance is >>>> not updated. In the version 5.3.X the date is updated even if it is with >>>> the same TGT, so the client does not display error messages. >>>> >>>> >>>> Do you know which parameter in cas 6.6.X that update the >>>> *AuthnInstance* when used with the same TGT but not the same ST? >>>> >>>> Thank you. >>>> >>>> >>>> >>>> Best Regards, >>>> >>>> Le jeudi 23 novembre 2023 à 06:38:55 UTC+1, Mohamed Amdouni a écrit : >>>> >>>>> Hello, >>>>> >>>>> I’m testing a saml client after cas migration from 5.3 to 6.6. >>>>> >>>>> The saml authentication is processed successfully ( using spnego & >>>>> Kerberos): no login details are entered, the spnego token is sent and >>>>> validated .After a long idle period, if I refresh the page I got an error >>>>> on the wall client saying that « Authentication statement is too long » >>>>> which is not the cas in the old version 5. >>>>> No error are generated in the cas server. >>>>> >>>>> I would like to know if there are some default values that are not >>>>> used any more in the new version of cas that could be related to this >>>>> issue. >>>>> >>>>> >>>>> I also detected that the time zone is no more sent in the assertions. >>>>> >>>>> It seems that the locale are no more detected automatically ? No value >>>>> are specified in the old version but the time zone is returned in the >>>>> assertions. >>>>> >>>>> In debug mode some locale error are detected about messages but the >>>>> langage is correct when cas displays some screens ( I don’t have any >>>>> custom >>>>> translation) >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> >>>>> > -- - 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/CALmwvcaiPqyO_M1JNCF-Z3E8NTMLRsu%3DWk-EuuMZ2qOSnB4-aQ%40mail.gmail.com.
