Authentication flow for Requried Action

[Francis Augusto Medeiros-Logeay]

Hi,

We are setting up a custom required action for configuring 2FA. We want to force the user to step up his authentication via an external IDP before he can manage his credentials.

As I understood it, One can use any client to trigger a Required Action via kc_action. This could potentially made it possible for users to by pass the step up.

Is there a way to either block the triggering of a required action via kc_action, or choose an specific authentication flow for a required action?

Best.

Francis

[Alexander Schwartz]

Hi Francis,

• A required action should IMHO be safe to trigger from all places, as it is in your case to set up a 2FA. 
• Performing the step-up is not a required action, but an authenticator that is part of the authentication flow which checks credentials. 
• If you do not want a custom required action to be called as an AIA, make sure not to implement the "initiatedActionSupport" method, and then it will default to "NOT_SUPPORTED". 
• When writing your own custom action, that should react differently when running as an AIA, you can check during execution time as follows:
  https://github.com/keycloak/keycloak/blob/88eea73cdcc77920785ebe46515897067744af32/services/src/main/java/org/keycloak/authentication/requiredactions/VerifyEmail.java#L130-L132

Best,
Alexander

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/keycloak-user/0A5BC996-8374-4C5D-86D3-F82ACAF8C110%40med-lo.eu.

--

Alexander Schwartz, RHCE

He/Him

Principal Software Engineer, Keycloak Maintainer

alexander...@ibm.com

IBM Data Privacy Statement 

IBM Deutschland Research & Development GmbH

Vorsitzender des Aufsichtsrats: Wolfgang Wendt

Geschäftsführung: David Faller

Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

[Francis Augusto Medeiros-Logeay]

Hi Alexander, and thank you so much for replying! Here are a few comments, even though I think I got to where I wanted: 

• A required action should IMHO be safe to trigger from all places, as it is in your case to set up a 2FA. 

In our organization, there’s this wish that we should require a higher proof-of-identity when setting up 2FA. That’s why we need a bit tighter control for that.

• Performing the step-up is not a required action, but an authenticator that is part of the authentication flow which checks credentials. 

Yeah, I got it, and should’ve explained it better: 

My point is that I am using a special flow inside my Required Action. It redirects to an external IdP, get a token, and authorize the setup of a particular 2FA-method. It works pretty well, fortunately.

• If you do not want a custom required action to be called as an AIA, make sure not to implement the "initiatedActionSupport" method, and then it will default to "NOT_SUPPORTED". 

Oh, this is great! So it will still be available from the account portal and during authentication? Awesome!

• When writing your own custom action, that should react differently when running as an AIA, you can check during execution time as follows:
  https://github.com/keycloak/keycloak/blob/88eea73cdcc77920785ebe46515897067744af32/services/src/main/java/org/keycloak/authentication/requiredactions/VerifyEmail.java#L130-L132

Great, thanks a lot! But is it possible to detect whether it was triggered during the authentication flow or if it was triggered on the account console? Or is triggering from the account console indistinguishable from an AIA?

Best,

Francis 

[Alexander Schwartz]

Hi Francis,

> But is it possible to detect whether it was triggered during the authentication flow or if it was triggered on the account console? Or is triggering from the account console indistinguishable from an AIA?

The account console is using AIA, so those two are identical. So you could distinguish an authentication flow with a required action from an application initiated action. 

If you need to go deeper: You could check in your custom action for the client that triggered the flow and the AIA, but the account console is a public client, so anyone can trigger them. Things might be different if you have a confidential client with pushed-authorization-request (PAR) where the user can't manipulate the contents in the URL. This is then going very deep, and I recommend to not go so deep into the specifics in case things break or change over time. The more specific and custom your solution is, the more difficult it becomes to upgrade.  

Best,

Alexander

Best,

Alexander

[Francis Augusto Medeiros-Logeay]

Thank you so much for your explanation, Alexander.

Yeah, I thought about checking the account client + the AIA. It’s not so bad that a user can trigger that on that client, as it is a client with a stringent authentication flow. So I can add logic to prevent execution from other clients. 

Best,

Francis