Advice on DynamicIdpRedirectAuthenticator config

[luisalves00]

I'm trying to setup you DynamicIdpRedirectAuthenticator as https://issues.redhat.com/browse/KEYCLOAK-1515 is not done yet.

My Authentication flow is the following:

Current problem is that it's not executed if it's an Alternative, only if Required. I've attached a break point and the constructor is called, but the authorize method is not. Can you give me some hints what I'm doing wrong?

I think it's related with this:

    /**
     * This method creates the list of authenticators that is presented to the user. For a required execution, this is
     * only the credentials associated to the authenticator, and for an alternative execution, this is all other alternative
     * executions in the flow, including the credentials.
     * <p>
     * In both cases, the credentials take precedence, with the order selected by the user (or his administrator).
     *
     * @param model The current execution model
     * @return an ordered list of the authentication selection options to present the user.
     */
    private List<AuthenticationSelectionOption> createAuthenticationSelectionList(AuthenticationExecutionModel model) {
        return AuthenticationSelectionResolver.createAuthenticationSelectionList(processor, model);
    }

so password takes precedence over DynamicIdpRedirectAuthenticator, but not 100% sure.

[luisalves00]

So I think the DynamicIdpRedirectAuthenticator is working as expected but the user cannot have password.

I guess if the DynamicIdpRedirectAuthenticator had precedence he couldn't login with password ever again (in fact is what I want - but not sure how to achieve it, yet).

[luisalves00]

I got it to work with a comment that @thomasdarimont did here: https://groups.google.com/g/keycloak-user/c/lk407fQ-kJ0
So the trick is:

• import users without password
• mark them with some attribute. E.g.: TARGET_IDP_ATTRIBUTE = "targetIdp"
• on the ftl check if the attribute is there to hide the update password and the otp forms (note: this is a client side solution - probably user can call some endpoint to get his password changed)

Might need some more tweaks, but overall I think the solution works fine.
In the future might fiddle with Username Form, because it check the user exists on keycloak database, so when doing the idp redirect the user must already exists, which will never trigger a creation of a new user from the idp.

@thomasdarimont please close the "Bug". Thanks for the extension.

[yushae]

@luisalves00 So how does your final authentication flow looks like . Let suppose if a user logs first time you don't have user created in Keycloak with identity link , does it work in that case too .. I tried and it fails with UserName not found