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

[Pedro Igor Silva]

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
>