Re: [keycloak-user] Authorisation services: resource server managing permissions

Hi Pedro, Thank you very much for quick answer, very helpful! Pedro Igor Silva <psilva(a)redhat.com&gt; schrieb am Mi., 20. März 2019 um 14:08 Uhr: > Correction ... You can also push claims using node-js-adapter > https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/fixt... > . > > On Wed, Mar 20, 2019 at 10:05 AM Pedro Igor Silva <psilva(a)redhat.com&gt; > wrote: > >> >> >> On Wed, Mar 20, 2019 at 9:36 AM Fabio Berta <fnberta(a)gmail.com&gt; wrote: >> >>> Hi >>> >>> I have a couple of questions regarding Keycloak's authorisation >>> services. >>> Premiss: >>> - I don't really need the whole user managed permissions and permission >>> sharing features that UMA gives. All permissions are given by admin >>> users. >>> - My resource server is a NodeJS application, hence I cannot use the >>> pre-made Java adapters >>> >> >> Did you had a change to look the node-js-adapter [1] ? >> > Yes, thanks! We actually used the node-js-adapter for inspiration in a lot of cases when building our own custom adapter (which only supports a small subset of the node-js-adapter and also does other things). > >> [1] >> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/fixt... >> >> >>> - I'm not sending RPT tokens to public clients at the moment, the >>> resource >>> server checks permissions by making a request to Keycloak >>> >>> Let's assume I want to protect the entity "Config". I need to restrict >>> create/delete/update rights for all configs and read rights for every >>> single instance of config. To achieve that, I created the the scopes >>> "config:read", "config:create", "config:delete" and "config:update". I >>> created the resource "config" and attached the scopes "config:create", >>> "config:delete" and "config:update". Because only users with the realm >>> role >>> "admin" should be able to create/update/delete, I created a role based >>> policy specifying the "admin" role and connected it with the resource >>> "config" and the scopes "config:create", "config:delete" and >>> "config:update" in a scope-based permission. So far everything is >>> pretty >>> straightforward and works well. >>> >>> Where it's get more complicated is the read rights for individual >>> configs. >>> What I have in mind is an interface where admins can create configs and >>> manage permissions for them without going through the keycloak admin >>> console. Whenever an admin creates a new config, the resource server >>> creates a corresponding resource (e.g. config/configId) and stores the >>> id >>> of the resource next to the config. I can do that with Protection API >>> (authz/protection/resource_set). >>> >> >> Another approach to this problem would be to push claims to your >> policies so you could avoid creating resources for every single config. >> >> For the Java-based adapter we have the concept of Claim Information >> Points [1], which basically defines a repository from where the adapter >> should obtain additional claims in order to push these claims to the server >> along with an authorization request. You can also look here [2] for more >> details about how to send these same claims directly to the token endpoint. >> >> With this approach, you would have a single "Config" resource and >> specific permissions for both write (create/delete/update) and read >> operations. For admin, you are fine as you just need a role-policy to check >> if a user is granted with the admin role. But for read, you could write a >> JS-policy [3] that matches the subject making the request with a specific >> claim that your resource server is pushing to the server, where this claim >> would contain the user ids or names, for instance. In a nutshell, you are >> basically making your policy model more flexible so the resource server is >> in charge to actually pass which users are allowed to access. The good side >> of this is that it avoids you create resources in Keycloak. The bad side is >> that your resource server is responsible to push this information, but >> maybe this is something you already have in the RS. >> >> [1] >> https://www.keycloak.org/docs/latest/authorization_services/index.html#_e... >> [2] >> https://www.keycloak.org/docs/latest/authorization_services/index.html#_s... >> >> Interesting, so this would mean that my resource server would need to keep track of which users have access to wich config. My fear would be that this logic could get complex quite fast when it has to track a mixture of groups and users permissions (I would basically be re-implementing the different policies keycloak offers I guess? Although currently only user and group are relevant for us.). We also have multiple resource servers which all talk to the same keycloak instance. If the resource server needs to keep track of all permissions, I would need to have this logic in every resource server. The beauty of having the resources in keycloak would be that the resource servers would only need to store the resourceId for every config (or any other entity) and nothing else. Or am I missing something?

Follow-up question would be, is creating resources for every single config a bad thing and would you in general advise against it? I assume the list of resources would get very big over time but I don't know if that's a problem? I guess it could be when I need to query keycloak for all resources a user has access to in order to list them. If this is list is huge, this could get costly at some point.

> >>> What I have not yet figured out is how the resource server can set >>> permissions at this point. Let's assume the admin has specified two >>> users >>> that should be able to access the new config. The resource server should >>> create a new user based policy containing the two users and connect it >>> with >>> the "config/configId" resource and the scope "config:read" in a >>> scope-based >>> permission. From the documentation it looks like the Policy API might be >>> able to handle this. But two things confuse me: >>> - It says "This API is protected by a bearer token that must represent a >>> consent granted by the user to the resource server to manage >>> permissions on >>> his behalf". I don't need to manage on the users behalf, the resource is >>> owned by the resource server and the created permission would also be >>> owned >>> by the resource server. >>> - The examples for the API somehow combine policies and permissions into >>> one? >>> I tried to use this API with a token obtained via the client credentials >>> grant but it failed to create permissions (empty response and nothing >>> got >>> created). >>> >>> I see that the Java Admin Client has the ability to manage permissions >>> but >>> I can't find documentation on the REST endpoints it uses. ( >>> https://www.keycloak.org/docs-api/5.0/rest-api/index.html doesn't >>> contain >>> anything authz related). Would the Admin API be the thing to use here or >>> can I do this with the Policy API? Or maybe my approach is fundamentally >>> flawed and I should approach this from another angle? >>> >> >> The Policy API is really for UMA protected resources. It is not an >> option in your case. >> >> To achieve your goal, you would need the Admin API. We don't have it >> documented because it is mainly used by our administration console. For >> now, you could just capture the requests that the admin console is >> performing to manage permissions and policies. The API provides a specific >> endpoint for each policy/permission type as well a specific payload. >> > I see, thanks! A related question, the admin console also uses the Admin API to create resources. If I need to create resource in my resource server, are there advantages in using the Protection API or shall I use the Admin API for this case as well?

> >> >>> >>> This message got way to long but I hope I was able to make my questions >>> clear. Grateful for any help I can get! >>> >>> Best regards, >>> Fabio Berta >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>