Scalability of Keycloak Authorization

[Anton Mazkovoi]

Hi,

Firstly, would like to thank everyone who has contributed to Keycloak. We are using it for all user management and authorization and are extremely happy with it.

As the number of protected resources in our deployment has grown over time I noticed that Keycloak’s CPU began to spike from time to time.

Our web application has quite a few pages that list protected resources which the user has permissions to see, and allow the user to page through them. A pattern I believe is very common to almost any application 🙂

To back those pages, our application asks Keycloak for an RPT in order to work out what resources the user has permissions to see. From what I understand based on a brief dive into Keycloak’s code, unless asked to evaluate specific resources, Keycloak selects all permissions from the database and loops over them, one-by-one for evaluation. It is possible to supply a max value for the number of positive evaluations, however, if the user has permissions only for a small subset of resources, and the total number of resources is quite large, it can still take some time (and CPU) to build this list.

While this approach of permission evaluation is extremely flexible (e.g. based on my understanding Keycloak allows to create custom permissions using e.g. JS), it limits scalability. We only use group and user based permissions, and I was hoping Keycloak would e.g. push the resolution of these permissions to the db, where db indexes could be used to speed up evaluation.

Is there any guidance around the recommended maximum number of resources that should be used with Keycloak's authorization?

I would love to hear what others have experienced using Keycloak’s authorization with hundred thousand (or more) resources? How long does it take to receive a response for RPT?

Are there any plans to improve the scalability of Keycloak’s authorization?

Again, thanks a lot for making Keycloak a reality!

Cheers,

Anton 

[Kevin Hertwig]

Hello Anton,

I have no answer to your question, but I have a question, I hope this is ok. I have a very similar approach in my application, I am sharing resources with different levels of permissions. There are resources I shared by configuring Authorization inside the admin console as well as resources with owner as the resource server itself. Then I defined policies and permissions. When I request an RPT, everything is fine and I get the expected token with all permissions to the resources I have access to. Even dynamically adding and removing policies to resources where the resource server itself is the owner via UMA (/uma-policy endpoint) works and the RPT delivers the expected output. However, when I create UMA resources and policies with owner as an actual user and share for example scope 'view' and 'edit' with user X, I don't get this information inside the RPT when requesting an RPT as user X. So somehow user generated UMA policies don't seem to appear in RPT tokens. Only the owner of the resource get's this information inside his RPT with the scopes that he shared with other user, what additionally is not what I would expect. It would make sense to me if the owner would get this information inside his RPT with the full scopes of the resource or no information about this resource at all.

So the only way to know if user X has 'view' or 'edit' permissions on this resource is to explicitly request this with specific parameters. This means, that user X would need to request permissions for each shared resource to know the permissions. However, I want to have that information in the frontend available to adjust the UI depending on the levels of permissions for resources. For example if user X can't edit this resource, I would like to hide an 'edit' button. So how would I achieve to let the frontend know what permissions user X has on resources that are generated with owner as an actual user and protected with UMA policies? I hope it is understandable, what my problem is. Maybe you could help me? Thank you in advance :)

[Anton Mazkovoi]

Hi Kevin,

Unfortunately, I do not know. All of our resources are owned by the resource server, so I have not observed or researched this behaviour.

Sorry I was not able to help.

Cheers,
Anton

> --
> You received this message because you are subscribed to a topic in the Google Groups "Keycloak User" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/keycloak-user/ZpEg7QACTfs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to keycloak-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/f65d3bb5-19c4-40a9-bd7b-f2f96d049ccan%40googlegroups.com.