I connected my KC to the company LDAP. However, I would like to prevent users (with correct credentials) from accessing my application (client). I would like only users to whom the administrator has assigned at least one of the available roles among the client roles to be able to access. I tried using the authorization section of the client, setting a role policy, but it didn’t work. Is this the correct procedure?
There’s a good extension that allows you to restrict Client auth based on things like Roles. GitHub - sventorben/keycloak-restrict-client-auth: A Keycloak authenticator to restrict authorization on clients
Is it possible that something this “simple” isn’t included in Keycloak by default? So, basically, any user with valid credentials can access the clients? And is there no way to configure access restrictions?
If I use this extension, can I check that the user has at least one role?
Thanks
This has been discussed enough in the past!
It’s not in the primary responsibility to decide and to enforce, if a user has access to a client or not. The PEP (policy enforcement point) is still the client/application!
Additionally: Depending on the implementation of the clients and the whole environment, there are ways around this. So, this is not a complete security feature, but more a convenience feature.
And before you come with something like “but MS Entra ID can do this”…
- MS and Entra ID is not what the world calls standard
- Just because MS is doing something, it’s not necessarily the proper solution
- It’s not Entra ID, it’s the whole integrated Azure platform. Keycloak is an IdP, not a platform!
Thanks for the details, so according to the standards, it should be the application and block the user from accessing it? Should the logic be applied on the application side?
Short: yes
Longer:
There is no standard for this (yet)!
OAuth is for 3rd party authorization of services, not users.
OIDC is about user identity, no about authorizations.
An IdP can/may serve information, which can be used by a client to determine authorization.
I vote for @dasniko doing a video on this subject. It’s true, it’s been discussed so many times, but I still don’t think it’s clear to most what the real role of OIDC and OAuth. Most of the commercial IdPs (Entra, Okta, etc.) have some idea of “assigning” users/groups to “applications” (Clients), and this has become the expectation, despite the fact that there are ways around this. I totally get why Sven-Torben’s extension is so popular, despite not 100% agreeing that people should use it and expect it to completely block access. However, it does git people that warm, fuzzy, easy button feeling.
Thanks, @xgp
Well, this could be a topic in one of my next year’s KFC sessions…
There are far more interesting topics to discuss with Niko than the IdP acting as a PEP based on roles, it feels like we’re back in the 1990s ![]()
Agreed @embesozzi , but never underestimate the value of repetition to get people to really understand something. I’ve been telling my kids the same things for years, and they still don’t…
I have twins, 100% agree, it’s all about repetition ![]()