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

[Álvaro Gómez]

Supporting resource types in scope-permissions would be great for us.
Honestly, I don't know if mixing both permissions in a single UI would make
it even more confusing. For the moment, we only need Keycloak to support
resource types in scope-permissions at the API level. We'll keep an eye on
the issue so we can upgrade to a newer version of Keycloak when it's solved
and we will try to find a workaround in the meanwhile.
Thank you very much!
Álvaro.

El mar., 23 jul. 2019 a las 14:00, Pedro Igor Silva (<psilva at redhat.com>)
escribió:

> 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
>>>>
>>>