You're right I have changed this line https://github.com/apereo/cas/blob/1504d96ecd11368f3491b00d93880ee2aeee8919/support/cas-server-support-saml-idp-web/src/main/java/org/apereo/cas/support/saml/web/idp/profile/builders/subject/SamlProfileSamlSubjectBuilder.java#L78 in my 6.3.5 instance and it's working as excpected now and it looks like it's already in place for 6.3.6.
Thanks Le lundi 12 juillet 2021 à 16:23:57 UTC+2, Olivier Begon a écrit : > Hi Stephane, > > I have experienced the same behavior with the 6.4.0-SNAPSHOT (CAS Commit > Id: 10186408101c29180fa4818b788f47ecbaa86101) version. A fix has been > released and should be available today for the 6.4.0-SNAPSHOT, I hope for > you that ig the fix is working, it will also be applied to the 6.3.5. > This is the fix I'm referring to: > https://github.com/apereo/cas/commit/1504d96ecd11368f3491b00d93880ee2aeee8919 > > Thanks. > Olivier. > > > On Thursday, July 8, 2021 at 12:37:53 PM UTC-4 Stéphane Delcourt wrote: > >> Hi All, >> >> I've just noticed in 6.3.5 the notonorafter timestamp in the saml subject >> confirmation is always set to the authentication date. >> So the saml envelope is valid only on the first login but then sso is not >> working for saml few seconds after login. >> I've enabled the notbefore to show the differences: >> >> First auth: >> <saml2:SubjectConfirmationData >> InResponseTo="ARQd805dd1-db66-44a6-8c19-7d8fbb112dde" >> NotBefore="2021-07-08T16:12:43.464Z" >> NotOnOrAfter="2021-07-08T16:12:58.454Z" Recipient="xxxxxxxxxx" /> >> >> second: >> >> <saml2:SubjectConfirmationData >> InResponseTo="ARQf767fe6-a726-4d15-8d48-445c5558f9d2" >> NotBefore="2021-07-08T16:13:38.391Z" >> NotOnOrAfter="2021-07-08T16:12:58.150Z" Recipient="xxxxxxx" /> >> >> And one more >> <saml2:SubjectConfirmationData >> InResponseTo="ARQ07157b7-6f18-4d50-ba6d-818668259e70" >> NotBefore="2021-07-08T16:14:29.350Z" >> NotOnOrAfter="2021-07-08T16:12:58.150Z" Recipient="xxxxxx" /> >> >> The first timestamp is slightly different but then they are all the same >> and the timeframe is obviously invalid. >> >> It's on my dev cas instance running cas 6.3.5. >> On production running cas 6.2.8 the timestamp is correct. >> >> Anyone experiencing this ? >> Am I missing some configuration here ? >> >> Thanks >> >> Stéphane >> > -- - 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/7291cb61-d750-4a35-8cf5-2fde914dd5dan%40apereo.org.
