cas 6.6.X : saml client : Authentication statement is too old error

[Mohamed Amdouni]

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.

[Mohamed Amdouni]

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,

[Mohamed Amdouni]

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 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 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.

[Arnauld Peyrou]

I had that error one Time, 

The main cause was the différence of date between the server of cas and the server of applications... 3 minutes 

And WE had exactly the same error message.

Arnauld Peyrou
Inrap
Chef de service Infrastructure et Sécurité.
121 rue d'Alésia 75014
07 62 60 45 63 / 01 40 08 80 48

--
- 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+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CALmwvcZfkWhiYx2OV2ZzXPAwrDNDt420Ms96p%3DVP8-KRPJMQLQ%40mail.gmail.com.

[Mohamed Amdouni]

thank you Arnauld for your contribution.

The clock is the same. I even tested in a local installation for both client and cas.

The error appears only after 2Hours of idle client, since CAS send always the first Authentication Date when the TGT was created.

In version 5.X the Authentication date get updated because Assertions are built from the ST ticket when calling validate ticket.

In version 6.X the Authentication date is the same as the TGT because the CAS assertions are built from TGT....

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAE5VfR1SqywkBLSr5fEeX%3DHeXjK5MVL5n2A31wE%3DAz1zUF87-w%40mail.gmail.com.

[David Gelhar]

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

[Mohamed Amdouni]

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 <david....@gmail.com> 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 <me.am...@gmail.com> 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.