[Feature] Prevent users with associated home IdP to change credentials

[sventorben]

Is there an existing feature request for this?

• I have searched the existing issues

Is your feature related to a problem? Please describe.

Assume a user has a home IdP associated either via configured domain per IdP or an IdP with associated email is linked to user's account. In such a scenario users may not need credentials, because they are authenticated by the home IdP. In these scenarios it may be benefical to prohibt resetting credentials for users to prevent them from logging in locally.

Note that users without a home IdP that have a local account should still be able to reset credentials.

Describe the solution you'd like

I see two options here:

• prevent users with a home IdP from login with local credentials
  • via conditional authenticator to check if user has home IdP and use "deny access" in such a flow to deny login with local credentials
  • via custom authenticator
• prevent credential reset via a custom authenticator in reset credential flow
  • via conditional
  • via custom authenticator

I think this still needs more clarification on what is needed (prevent password reset or prevent login with local account).

Describe alternatives you've considered

No response

Anything else?

See also:

• [Feature] Provide IdpAuthenticator that checks email domains #166
• [BUG] Unable to login for non IDP users #263

[toddkazakov]

We provision our third-party IDPs in such way that a special role is associated to the user when they sign in. We then deny the authentication user username and password if the user has this role set.

[LucasVanHaaren]

We provision our third-party IDPs in such way that a special role is associated to the user when they sign in. We then deny the authentication user username and password if the user has this role set.

Hello @toddkazakov, can you elaborate on how to achieve this flow ?
I want to setup a similar flow by setting a user attribute (or role) for users with an identity linked, then deny username/password login for those one. But I can't manage to build a working Authentication flow for now ...

[toddkazakov]

@LucasVanHaaren in the IDP settings I have added a mapper which assigns "brokered" role. In the login flow I then check if the user has this role and deny access if that's the case.

[LucasVanHaaren]

I finally managed to do it (I think and hope there is no side-effect), but my authentication flow is now kinda complex.
I'm pretty new to keycloak so can you tell me if this is right, or if there is an simpler one ?

I tried to do only with one condition but local login was refused each time (with role brokered or not)

UPDATE : sorry for the inconvenience, I finally reached my goal with a simpler authentication flow !

[awoimbee]

I think this feature should be expended to not only prevent login via credentials but also to prevent login via other identity providers that are not tied to the domain.

e.g. I want [email protected] to use the IdP tied to company.com, but I want [email protected] to be able to login via Google.

We provision our third-party IDPs in such way that a special role is associated to the user when they sign in. [...]

Cool solution, but the user needs to login once with the special IdP to get the role, that might not be the case everywhere.

---

I think we need:

• for direct-grant: a way to reject login if email matches a domain-linked idp
• for browser-flow:
  • a way to reject after the social login (like for direct-grant)
  • a way to show IdPs only on the username-password form page and not on the home-idp-discovery email page (so users with domain-linked idps are already gone by that stage)

flowchart LR
    subgraph browser-flow
        social-login(["social login (maybe not shown)"]) -->|domain-matches-idp| corpo-idp-login
        social-login -->|no-match| logged-in
        enter-email -->|domain-matches-idp| corpo-idp-login
        corpo-idp-login --> logged-in
        enter-email -->|no-match| social-or-password-login
        social-or-password-login --> logged-in

    end
    subgraph direct-grant-flow
        give-email-password --> domain-matches-idp
        domain-matches-idp -->|yes|reject
        domain-matches-idp -->|no|OK
    end

Loading