5:11 a.m.
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-se...
{
"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-se...
{
"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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>