[keycloak-user] Questions about scope-permissions and resource types

Pedro Igor Silva psilva at redhat.com
Tue Jul 23 08:00:02 EDT 2019


Both API and UI need a review in order to support what you are looking for
(as well as the requirement from that JIRA).

Currently, resource permissions grant access to a resource and any
associated scope where scope permissions allow you to restrict the set of
scopes that could be granted. The idea is to unify both types of permission
using a single API so you can make the process of defining permissions more
simple as well as support some scenarios that are not possible today
because of this separation (like the one you are looking for).

To be honest, I like the separation we have today and I'm still not sure if
unifying both permission types is the best way to go. Maybe just support
the resource type in scope-permissions is enough .... Wdyt ?

Regards.
Pedro Igor

On Tue, Jul 23, 2019 at 7:11 AM Álvaro Gómez <
alvaro.gomez.gimenez at tecsisa.com> wrote:

> Hi Pedro,
>
> Thanks for the response. Do you mean this is currently supported in the
> API or will it be available in future versions of Keycloak? The issue you
> linked refers to an UI functionality and we are interested in this use case
> mentioned in the issue:
>
> <<it should also cover use cases where scope permissions are set for a
> resource type and not to any resource associated with the granted scopes.>>
>
> But we don't know if that lack of functionality refers only to the UI or
> also the API.
>
> We've tested the following scenario using Keycloak#master API:
>
> * Create two scopes:
>   - read
>   - write
> * Create two resources (Both with resource-type "x"):
>   - x1 (Associated with read & write scopes)
>   - x2 (Associated with read & write scopes)
>
> Since we want to create a permission for the read scope of all resources
> of type "x" we've tried the following API requests without success:
>
> * Create a scope-permission with a resource-type:
>
>   POST
> http://localhost:8081/auth/admin/realms/***/clients/***/authz/resource-server/permission/scope
>   {
>     "type": "scope",
>     "logic": "POSITIVE",
>     "decisionStrategy": "UNANIMOUS",
>     "name": "x:read",
>     "scopes": [ "read" ],
>     "policies": [ "..." ],
>     "resourceType": "x"
>   }
>
>   This fails since "resourceType" is not available when creating
> scope-permissions.
>
> * Create a resource-permission specifying a set of scopes (Since they are
> available in the AbstractPolicyRepresentation):
>
>   POST
> http://localhost:8081/auth/admin/realms/***/clients/***/authz/resource-server/permission/resource
>   {
>     "type": "resource",
>     "logic": "POSITIVE",
>     "decisionStrategy": "UNANIMOUS",
>     "name": "x:read",
>     "scopes": [ "read" ],
>     "policies": [ "..." ],
>     "resourceType": "x"
>   }
>
>   This request is successfully executed but the scopes are ignored when
> requesting permissions for the resource "x1" (All scopes are granted
> instead of only the "read" scope):
>
>   POST http://localhost:8080/auth/realms/***/protocol/openid-connect/token
>     grant_type:urn:ietf:params:oauth:grant-type:uma-ticket
>     audience:test
>     submit_request:false
>     response_mode:permissions
>     permission:x1
>
>   Response:
>
>   [
>     {
>         "scopes": [
>             "read",
>             "write"
>         ],
>         "rsid": "e0734205-af2f-4b6d-bd5e-4eb550b2616c",
>         "rsname": "x1"
>     }
>   ]
>
>   We'd like only the "read" scope to be granted but all the Resource
> scopes are granted instead.
>   Thanks.
>
>
> El lun., 22 jul. 2019 a las 15:15, Pedro Igor Silva (<psilva at redhat.com>)
> escribió:
>
>> Hi Álvaro,
>>
>> There is no restriction for doing that. I think this issue is related:
>> https://issues.jboss.org/browse/KEYCLOAK-10663.
>>
>> Regards.
>> Pedro Igor
>>
>> On Mon, Jul 22, 2019 at 9:55 AM Álvaro Gómez <
>> alvaro.gomez.gimenez at tecsisa.com> wrote:
>>
>>> Hi,
>>>
>>> We are using UMA and scope-permissions to manage fine grained access to
>>> resources. We've
>>> noticed that we can specify a set of involved resources when defining
>>> scope-permissions (The UI
>>> only supports specifying a single resource but the API allows defining a
>>> set of resources).
>>>
>>> Referencing the involved resources in a scope-permission using a fixed
>>> list
>>> could be problematic
>>> if the size of that list is big enough. We think it would be useful to
>>> group all the resources using a
>>> resource-type and specify that resource-type in the scope-permission as
>>> one
>>> can do in a
>>> resource-permission. Is there any reason why this is not supported in a
>>> scope-permission?
>>>
>>> Having a resource type reference available in scope-permissions would be
>>> useful solving the following scenario:
>>>
>>> * Given a large amount of bank accounts, each one represented by a
>>> resource
>>> (associated with some
>>>   scopes like read, update or delete) in the Resource Server and owned by
>>> an specific user.
>>> * Users can manage their own accounts following the UMA rules (Sharing
>>> specific scopes of their
>>>   accounts with other users).
>>> * Some user with an Administrator role should be able to read ALL
>>> accounts
>>> without having them
>>>   shared with him and without needing to update any permission when a new
>>> bank account is created.
>>>
>>> We would like to "group" all accounts using a resource-type and define a
>>> single permission "can-read-bank-account"
>>> which grants access to the scope read of all bank accounts to the owner
>>> (via JS policy) and to any administrator
>>> user (using a role policy). If we protect the following endpoint:
>>>
>>> GET /accounts/3273af-544b3940-211da3
>>>
>>> , using the resource "bank-account-3273af-544b3940-211da3" and the scope
>>> "read", both the resource owner
>>> and the Administrator user must be granted when evaluating the permission
>>> "can-read-bank-account".
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>


More information about the keycloak-user mailing list