[Feature] Allow configuring restrict-client-auth-authenticator-display-name for each step based on the Access Provider

[nh4ttruong]

Is there an existing feature request for this?

• I have searched the existing issues

Is your feature related to a problem? Please describe.

I set up a flexible flow starting with "Restrict Authentication using policy," followed by evaluating "Restrict Authentication using client." Both use the "Alternative" requirement in the post-login flow.

My authentication test flow:

• The user will first be restricted by the policy first and then receive the message: "You are not allowed to access this site due to policy.":

• The user will click "Try another way" and receive:

The confusing restrict-client-auth-authenticator-display-name and restrict-client-auth-authenticator-help-text appeared, but the sub-flow still worked as expected. When I clicked the second restrict-client-auth-authenticator-display-name, it functioned properly.

Describe the solution you'd like

The plugin should allow configuring restrict-client-auth-authenticator-display-name for each step based on the Access Provider. This way, users can easily identify which type of restriction they are permitted to access through an alternative method.

Describe alternatives you've considered

No response

Anything else?

No response

[sventorben]

@nh4ttruong Thanks for the request and for the detailed example.

What you are trying to do is not really what this authenticator was designed for. That is also the reason why it currently only supports Required and Disabled, but not Alternative. In an alternative setup, the more natural behavior would probably be to evaluate all alternatives first and only show an error if none of them grants access.

The other part of your request (customizing the displayed text per authenticator instance / execution) is unfortunately not something this extension can currently support. That is a limitation of Keycloak's authenticator model rather than of this extension itself.

What I can improve on my side is the generic naming. So even if per-instance customization is not possible, I could at least provide a clearer and more user-friendly default name/text here.

[nh4ttruong]

Thank you for considering my case @sventorben!

I hope this authenticator plugin can support more flexible approaches. In practice, applications whether they are in the minority or majority that integrate with KeyCloak authentication are managed in different ways (like my example above).

I used an attached client role for the minority and a policy-based approach for the majority. If it works, it will help me a lot in managing hundreds of people without having to manually attach client roles or manage groups.

Do you think it would be worthwhile to introduce a new method to address that?

[sventorben]

Do you think it would be worthwhile to introduce a new method to address that?

Thanks for the follow-up, but I need to understand what you mean by "method" before I can give a useful answer. Could you clarify:

1. What exactly are you expecting the user to experience?
   When the policy-based restriction denies the user and they click "Try another way," what should happen next? Should Keycloak:
   • Silently evaluate the client-role restriction and either grant or deny access — without the user actively choosing anything?
   • Show the user a selectable alternative they consciously pick?
   • Something else?

This matters a lot, because the "Try another way" flow in Keycloak is designed for the user to actively switch between authentication methods (e.g. password vs. passkey). Using it with a restriction authenticator means the user can intentionally bypass the first restriction by selecting the second. I'm not sure that is actually what you want.

2. What is the intended access control logic?
   From your description it sounds like you want: "grant access if the user passes the policy check OR if they have the required client role." Is that correct? If so, this reads more like an OR-condition on the restriction itself rather than two separate alternatives the user navigates between.

3. What does "new method" mean concretely?
   Are you thinking of:

   • A new configuration option on the existing authenticator?
   • A new authenticator type (e.g. one that internally evaluates multiple providers and grants if any match)?
   • Something in the flow structure?

The display name problem I can address independently. But before considering any deeper change I'd like to understand the full expected behaviour - ideally described as: "given user X with properties Y, when they log in to client Z, I expect Keycloak to do A, and if that fails, B.