Google OAuth MFA activation flow does not work as expected

[Iago Alonso Alonso]

I am working on a project that uses Apereo CAS 5.x.x to handle user authentication and users can activate MFA. When logging in, the user can use their Active Directory credentials or log in via Google OAuth (which it is supported as shown in the documentation). Unfortunately, we have found that when the user logs in via Google OAuth, the MFA flow is broken.

If the user logs in with the AD credentials and tries to activate MFA, the operation works as expected. The user gets the page to activate MFA and after that the user is sent to the page to copy the codes, finish binding the authenticator application and is shown the success message at the end.

But if the user logs in with their Google account, the user is able to go to the initial page of the MFA activation process and when the Activate button is clicked, the user is stuck in that view.

Researching how Apereo CAS works in their documentation, I have discovered that the process gets stuck here as in the browser the URL looks like that:

Also, in the application logs I have observed that when the AD credentials are used CAS says:

Bypass rules determined MFA should execute for user [XXXXX] for provider [mfa-gauth]

But if the Google credentials are used CAS says:

Bypass rules determined MFA should NOT execute for user [XXXXX] for provider [mfa-gauth]

And because of that, CAS issues a new session ticket:

Finalizing authentication transactions and issuing ticket-granting ticket Finalizing authentication event... Creating ticket-granting ticket, potentially based on [********************************************************] Located ticket-granting ticket in the context. Retrieving associated authentication Resulting authentication is different from the context Attempting to issue a new ticket-granting ticket...

I guess the crux of the matter is in this sentence:

Resulting authentication is different from the context

Because the application does the redirection as how it should be done with something like:

https://server/cas/login?renew=true&service=http%3A%2F%2Fwww.service.com/mfa&authn_method=mfa-gauth

As it is explained here in the documentation with the third example.

What is being done wrong? I am quite lost and have not been able to make any progress.

[Ray Bon]

Iago,

If you are using Cas 5, upgrade, then check if the problem still happens.

Ray

On Mon, 2023-02-20 at 03:04 -0800, 'Iago Alonso Alonso' via CAS Community wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

I am working on a project that uses Apereo CAS 5.x.x to handle user authentication and users can activate MFA. When logging in, the user can use their Active Directory credentials or log in via Google OAuth (which it is supported as shown in the documentation). Unfortunately, we have found that when the user logs in via Google OAuth, the MFA flow is broken.

If the user logs in with the AD credentials and tries to activate MFA, the operation works as expected. The user gets the page to activate MFA and after that the user is sent to the page to copy the codes, finish binding the authenticator application and is shown the success message at the end.

But if the user logs in with their Google account, the user is able to go to the initial page of the MFA activation process and when the Activate button is clicked, the user is stuck in that view.

Researching how Apereo CAS works in their documentation, I have discovered that the process gets stuck here as in the browser the URL looks like that:

Also, in the application logs I have observed that when the AD credentials are used CAS says:

Bypass rules determined MFA should execute for user [XXXXX] for provider [mfa-gauth]

But if the Google credentials are used CAS says:

Bypass rules determined MFA should NOT execute for user [XXXXX] for provider [mfa-gauth]

And because of that, CAS issues a new session ticket:

Finalizing authentication transactions and issuing ticket-granting ticket Finalizing authentication event... Creating ticket-granting ticket, potentially based on [********************************************************] Located ticket-granting ticket in the context. Retrieving associated authentication Resulting authentication is different from the context Attempting to issue anew ticket-granting ticket...

[ial...@denodo.com]

Hi,

What if it's not possible, any clue why the bypass rules are not applied? Also, I have found that using Google, the id in the credentials object is "NotYetAuthenticated-XXXXX" because in the ClientCredential class in the getID method this.userprofile is null.

But I am supposed to be authenticated, as I have logged in before trying to activate MFA.

Regards.

[ial...@denodo.com]

After some more digging I found that the problem is that after activating MFA with Google SSO, if you try to log in there is an error because the template is expecting a OneTimeTokenCredential but it is receiving a ClientCredential.

How can I convert a ClientCredential to a OneTimeTokenCredential?

Greetings.

[ial...@denodo.com]

Hi,

After a bit more research I have discovered the scenario and the cause of the problem but I am not sure how to fix it despite going through the documentation.

Logging in with Google OAuth works if MFA is disabled, I can log in and enable MFA correctly. The problem is when after enabling MFA you log out and try to log in again, in that scenario CAS gives an error because in the template that is generated to put the MFA code (casGoogleAuthenticatorLoginView.html) it expects an instance of OneTimeTokenCredential(token=null) but it is getting an instance of ClientCredential that does not have a token attribute:

Caused by: org.springframework.expression.spel.SpelEvaluationException: EL1008E: Property or field 'token' cannot be found on object of type 'org.apereo.cas.authentication.principal.ClientCredential' - maybe not public or not valid?

So my question is, why does the ClientCredential instance becomes OneTimeTokenCredential when MFA is not enabled and I can enable it, but after enabling MFA and trying to log in again it fails because the ClientCredential does not become a OneTimeTokenCredential instance?

I have been debugging the resolveInternal method of the CustomWebflowEventResolver I have (which extends AbstractCasWebflowEventResolver) and I am not able to see the difference between the scenario of activating MFA and logging in after activating MFA to see what is happening. In both scenarios if I debug:

Authentication authentication = WebUtils.getAuthentication(context);

In the credentials attribute I see an object BasicCredentialMetaData with and ID "NotYetAuthenticated-XXXXXXXX" and a credentialClass attribute of type org.apereo.cas.authentication.principal.ClientCredential. Before activating MFA the values are the same, so I don't understand why in one case it works and converts to an OneTimeTokenCredential instace and in the case where MFA is activated it does not.

Best regards.