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

[Pedro Igor Silva]

Correction ... You can also push claims using node-js-adapter
https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/fixtures/node-console/index.js#L172
.

On Wed, Mar 20, 2019 at 10:05 AM Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Wed, Mar 20, 2019 at 9:36 AM Fabio Berta <fnberta at gmail.com> 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] ?
>
> [1]
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/fixtures/node-console/index.js#L156
>
>
>> - 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#_enforcer_claim_information_point
> [2]
> https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_pushing_claims
>
>
>> 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.
>
>
>>
>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>