RBAC is impossible to set up


first of all I appreciate very much all the work done on Keycloak but I hit the wall trying to configure and understand the access control in Keycloak. Spend a lot of time trying to setup simple RBAC which seems impossible - to be exact: I have defined a few resource permissions, which i need to now assign into concrete Roles (client or realm I do not care) (eg. admin, user, customer-support .) like in proper RBAC. Now to be exact there are 2 issues:

  1. from my understanding and what I have seen in the docs I have only the possibility to: assign policy to the permission? By default, permission should be a simple string representing access right on the resource, so I do not see a point of anyone assigning something to the permissions. Even if I accept this paradigm of assigning permissions to the policies - the policies then become the kind of “roles” so this is very confusing for everyone - is there some other way how to assign permission to the role?

  2. I have seen various examples(even in the https://github.com/keycloak/keycloak-quickstarts.git) of a of REST APIs protected by keycloak by keycloak.protect([“role”]), is this official expected way how to protect resources? Doing this is an antipattern in the RBAC(and I believe in all other authorization systems) since one should use only permissions to protect resources (think about when you want to update role and remove some permission from the role in this case you need to touch code in the other case you can just remove permission from the role and you have the effect instantly)

So in short, instead of having some nice hierarchy of Role representing set Permission (and whatever another layers you can came up with like policy and so on):

a. there is no clear hierarchy

b. permission = some overly complex thing that should be simple

c. policy ~= role

d. role ~= permission

Thank you for the clarification.

this is the actual diagram of what Keycloak does simplified to the bone:


it is clear that RBAC is not possible and mentions about how it is possible to set up should be removed from all docs and from everywhere

as you can notice everything has its “own” meaning that goes agains the conventions

See: Angular, OAuth 2.0 and Keycloak

In previous posts, I wrote about Getting started with Keycloak and Angular, OpenID Connect and Keycloak.

In this post, I take a look at Keycloak’s support for OAuth 2.0 scopes.


Serendipity has four roles:

  • Guest
  • User
  • Manager
  • Administrator

Serendipity’s REST API uses scopes to protect resources, for example:

  • individual:post
  • individual:get
  • individual:patch
  • individual:delete