Hi,
But I will never be offered this tool anyhow !
I am using my main production logfile at "/etc/cas/config log4j2.xml", with all levels between "trace" and "debug". And I see plenty of debug messages so I think it's ok.
I am now studying the problem with a simple CAS instance built from the sources, with a dummy JSON service and the internal "casuser" account. I just added "cas-server-support-json-service-registry", ""cas-server-support-gauth" and "cas-server-support-gauth-couchdb" and the related "cas.properties" configuration directives :
##########################
# MFA (global settings) #
##########################
cas.authn.mfa.triggers.global.global-provider-id: mfa-gauth
#cas.authn.mfa.triggers.global.global-provider-id: mfa-simple
########################
# Google Authenticator #
########################
cas.authn.mfa.gauth.core.multiple-device-registration-enabled: true
cas.authn.mfa.gauth.core.issuer: CAS
cas.authn.mfa.gauth.core.label: OUR_CORP
cas.authn.mfa.gauth.couch-db.create-if-not-exists: true
cas.authn.mfa.gauth.couch-db.db-name: cas_gauth
cas.authn.mfa.gauth.couch-db.password: password
cas.authn.mfa.gauth.couch-db.username: admin
CouchDb is running as a local Docker container, with a persistent volume (I had to create the database manually, as in spite of having set "cas.authn.mfa.gauth.couch-db.create-if-not-exists" to true, there are no design documents inside and authenticators registering can not work. There is an older post in this ML about that, I used the informations they provided and it works after manually creating the missing items).
When I login for the first time, I am asked to pair a new authenticator and the process is successful. And can login again and again it's ok.
If I check the database, I have a record related to this authenticator, having a name, and id and user name.
If I restart CAS, the database content is still the same of course but the codes provided by the authenticator are not working anymore, as if they were wrong. And I have an error message in the logs :
2023-08-25 11:04:22,487 ERROR [org.apereo.cas.authentication.DefaultAuthenticationManager] - <Authentication has failed. Credentials may be incorrect or CAS cannot find authentication handler that supports [GoogleAuthenticatorTokenCredential(super=OneTimeTokenCredential(token=********), accountId=1692865323865)] of type [GoogleAuthenticatorTokenCredential]. Examine the configuration to ensure a method of authentication is defined and analyze CAS logs at DEBUG level to trace the authentication event.>
2023-08-25 11:04:22,487 ERROR [org.apereo.cas.authentication.DefaultAuthenticationManager] - <[GoogleAuthenticatorAuthenticationHandler]: [Secret cannot be null.]>
I still have this record in the databasen with id=1692865323865 in the database, related to the "casuser" and the registered authenticator". The "secretKey" property is still not null.
I have set "cas.authn.mfa.gauth.core.multiple-device-registration-enabled" to true, and I am indeed allowed to pair additional authenticators with my accounts. But doing so gives no result, there is still only one record in the database.
If I manually add a forged record corresponding to a second authenticator, it's better, I have a list of authenticators I can choose.
So I decided to study the internals a bit further, by adding logging directives here and there.
But I have more and more the feeling something is wrong or is beyond my current understanding to say the least.
As you suggested, maybe I am looking at the wrong place, expecting to see log messages from methods which are never called in this use case ?
There is some gargabe collector removing the old tokens (and it's working flawlessly) logging something like :
2023-08-25 11:01:11,218 DEBUG [org.apereo.cas.gauth.token.GoogleAuthenticatorCouchDbTokenRepository] - <Removing tokens older than [2023-08-25T11:00:41.218288]>
After greping the whole source tree, it seems this message is unique and indeed located in "cleanInternal" method from "support/cas-server-support-gauth-couchdb/src/main/java/org/apereo/cas/gauth/token/GoogleAuthenticatorCouchDbTokenRepository.java". Sounds logical.
So my idea was to simply alter the message, rebuild the app and see if this simple modification is working.
And guess what ... it's not working as expected.
After starting from scratch ("gradlew clean" and deletion of "~/.gradle/caches"), I built the app again and even tried to execute the war from "cas/webapp/cas-server-webapp-jetty/build/libs/cas-server-webapp-jetty-6.6.11-SNAPSHOT.war"
It's running but the log message is still displayin the same text as in original source code.
Just for science, I tried with "bootRun" and it's still the same.
So I used the Fernflower package provided with Idea installation to see the source code from the generated classe.
The compiled class from the code I have modified has the expected content (support/cas-server-support-gauth-couchdb/build/classes/java/main/org/apereo/cas/gauth/token/GoogleAuthenticatorCouchDbTokenRepository.class).
And it's been created or modified a couple of minutes after I modified the source code and rebuilt. So far it's normal.
So what is used in the webapp ?
After exploding "webapp/cas-server-webapp-jetty/build/libs/cas-server-webapp-jetty-6.6.11-SNAPSHOT.war" and its "WEB-INF/lib/cas-server-support-gauth-couchdb-6.6.11-SNAPSHOT.jar" package, I discovered two things :
- the file "org/apereo/cas/gauth/token/GoogleAuthenticatorCouchDbTokenRepository.class" has a modification time set ... two days ago, at a time I am not even at work.
- the content is still the original one, without my modifications.
Having cleaned the build tree and destroyed all cache, I have no explanations.
So maybe I am right and wrong at the same time, having put debug outputs at the right locations but unable to see them because of another code being executed.
So far i am a bit stuck in the middle of the twilight zone.
Regards