TGT problem with mfa-trusted

[Jeremy Benmouha]

Hello, 

I have a problem with the MFA Gauth and the trusted device.
We are currently in 6.5.4 (I also tested in 6.3.7 and 6.5.3), the mfa-gauth works fine, but when I activate the trusted device (stored in mysql or mongodb database) we have a strange behavior:
-at the first connection on a clean browser, we go through the mfa and the trusted device registration (bypass because we set the parameter to assign the device-name automatically), once this is done we have no problem, the TGT ticket is well created, the mfatrusted too, and on the cookies side, we have everything (JSESSIONID, MFATRUSTED, TGC)
-if we disconnect from CAS on this same browser, the TGC and JSESSIONID cookies are destroyed, as well as the TGT on the CAS side (normal), but the MFATRUSTED remains (expected behavior, so far so good)
-if we connect again, it is there that it spoils, we do not need to put the MFA (normal because the MFATRUSTED cookie is always present), on the other hand once the connection carried out, we do not manage any more to have the TGC cookie (of the TGT which is created well on the CAS side) and thus the SSO does not function any more...., the cause seems to come from the MFATRUSTED, as long as this one is present, impossible to re-obtain the TGC cookie.
On the logs side during the connection, here is the Warn that we can observe:
 
WARN [org.apereo.cas.gauth.web.flow.GoogleAuthenticatorValidateSelectedRegistrationAction] - <Unable to determine google authenticator account>

if we activate the debug mode of the webflow logs, this is what we get:

ERROR, text = 'Unable to accept this authentication request. The selected device or given credentials is invalid.']]]]

Have you ever seen this malfunctioning? I haven't found any info about this problem on the CAS google group or in the doc, the mfa and trusted device work in itself, but it's really the TGC cookie and thus the SSO that is the problem, behavior that doesn't happen outside of MFA Trusted.
the last version where I can confirm that we did not have this problem is 6.0.5.1 (our old production version recently updated).

here are the configuration parameters in cas.properties:

cas.tgc.crypto.encryption.key=(replaced)
cas.tgc.crypto.signing.key=(replaced)

cas.webflow.crypto.signing.key=(replaced)
cas.webflow.crypto.encryption.key=(replaced)

cas.authn.mfa.trusted.core.device-registration-enabled=true
cas.authn.mfa.trusted.core.auto-assign-device-name=true
cas.authn.mfa.trusted.crypto.encryption.key=(replaced)
cas.authn.mfa.trusted.crypto.signing.key=(replaced)

cas.authn.mfa.trusted.device-fingerprint.cookie.crypto.encryption.key=(replaced)
cas.authn.mfa.trusted.device-fingerprint.cookie.crypto.signing.key=(replaced)

cas.authn.mfa.gauth.core.issuer=
cas.authn.mfa.gauth.core.label=
cas.authn.mfa.gauth.crypto.encryption.key=(replaced)
cas.authn.mfa.gauth.crypto.signing.key=(replaced)

cas.ticket.st.time-to-kill-in-seconds=30
cas.ticket.tgt.primary.max-time-to-live-in-seconds=86400
cas.ticket.tgt.primary.time-to-kill-in-seconds=21600

cas.ticket.registry.hazelcast.cluster.core.instance-name=
cas.ticket.registry.hazelcast.cluster.network.members=
cas.ticket.registry.hazelcast.cluster.network.port-auto-increment=true
cas.ticket.registry.hazelcast.cluster.core.timeout=60
cas.ticket.registry.hazelcast.crypto.signing.key=(replaced)
cas.ticket.registry.hazelcast.crypto.encryption.key=(replaced)
cas.ticket.registry.hazelcast.crypto.enabled=true
cas.ticket.registry.hazelcast.core.enable-compression=true




Thanks in advance

[Jeremy Benmouha]

Hello,

After checking, the problem is only present on the undertow servlet.

If we use the tomcat servlet, there is no problem.
The TGC ticket is well recreated at each authentication after caching the mfatrusted.