Disallow username/password access for a group of users


  • I configured a LDAP user federation with “real humans” and so called service accounts, the later ones are used for automation purposes (think CI, SonarQube).
  • Additionally I configured an (internal SAML) Identity Provider used as broker with the same accounts.
  • Now I want humans to use that IdP exclusively for login to Keycloak while service accounts must exclusively login via the username/password form in Keycloak.
  • I am able to differentiate real humans from service accounts in LDAP, the later ones having one distinctive LDAP attribute.

Any hints are welcome :slight_smile:

Best Regards

PS: Asked on the mailing-list as well: https://groups.google.com/g/keycloak-user/c/ELUEMJuB5h8/m/8TgpMUINBAAJ

I just did something similar for a customer.

First, please don‘t use the term „service account“ for something which should authenticate via the browser login forms/flows. A service account in Keycloak terms is a client which is able to authenticate via the client_credentials grant. Users usually use the authorization_code grant (implicit and password grant are deprecated and should/must not be used).

This would also be the best way to handle real „service“ accounts, aka „technical users“, aka non-human users. They should be clients in Keycloak, with „service accounts“ enabled and using the client_credentials grant. Unfortunately, it‘s not possible to sync technical users via a federation as service account (at least not without some serious effort in customization).

However, with your scenario, this authentication flow might work:

  • …some other alternative authenticator executions …
  • generic flow/subflow (alternative)
    • username form (required)
    • generic subflow (conditional)
      • condtion - user attribute (required) - configure with the user attribute/value which should require redirection to and idp
      • identity provider rediretcor (required) - configure the idp alias to which the user should be redirected in case condition is true
    • password form (required)

This way, the flow will abort and redirect if the user should be redirected to the idp (upon user attribute value). If not, the password form will be shown.


1 Like

Hi @dasniko

thanks a lot for the quick answer and sorry about the term service accounts I used here (the term is used in our holding’s identity management system).

The flow you suggested looks like it could solve my problem :relaxed:.

I would configure the default browser flow to always redirect to the IdP. So humans may go the applications and are logged in automatically.

And only for the realm’s account client I would use your flow so the technical users would always have to login via this way. As they do so mostly to create e.g. application specific auth tokens this is acceptable :relaxed:

Thanks again

Tried it out, does work. I replaced the IdP step for humans by Deny Access with an error message, because login via IdP is a possibility anyways on the initial page :slight_smile: Thanks again @dasniko

1 Like