[keycloak-user] Retrieve all permissions

Pedro Igor Silva psilva at redhat.com
Tue Jul 10 15:04:00 EDT 2018


On Tue, Jul 10, 2018 at 2:02 PM, Corentin Dupont <corentin.dupont at gmail.com>
wrote:

>
>
> On Tue, Jul 10, 2018 at 5:32 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>>
>>
>> On Tue, Jul 10, 2018 at 10:31 AM, Corentin Dupont <
>> corentin.dupont at gmail.com> wrote:
>>
>>> Hi guys,
>>> I noticed a couple of strange things when retrieving all the permissions.
>>> I tried:
>>>
>>> $ curl -X POST http://localhost:8080/auth/realms/waziup/protocol/openid-
>>> connect/token
>>> <http://localhost:8080/auth/realms/waziup/protocol/openid-connect/token>
>>> -H "Authorization: Bearer $USERTOKEN" -d
>>> "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket&audi
>>> ence=api-server"
>>> | jq .access_token -r | cut -d "." -f2 | base64 -d | jq
>>>
>>> "authorization": {
>>>     "permissions": [
>>> ...
>>>
>>> But it seems that this command returns only the permissions for the
>>> resources belonging to the client, excluding resource belonging to other
>>> users?
>>>
>>
>> When obtaining all entitlenents for an user, only resources owned by the
>> resource server, by the user and shares (via ticket or via account service)
>> are processed.
>>
>
> OK, I understand. My use case is to protects an endpoint such as "GET
> /resources" that returns a bunch of resources.
> So if I understand I have to include multiple resource/scope in the same
> request (I thought a generic call would suffice).
>
> BTW, is there a possibility to use JSON in the request, instead of form
> data? i.e.
>

It is possible, but our token endpoint does not support this for other
grant types (like others do) and it is not UMA compliant. We could support
both though, but I need to start a discussion first with the team,


>
> -d {"grant_type": "urn:ietf:params:oauth:grant-type:uma-ticket",
> "audience": "api-server" ...}
>
>
>
>>
>>
>>> To get an assessment of all resources, I tried adding a scope:
>>>
>>> $ curl -X POST http://localhost:8080/auth/realms/waziup/protocol/openid-
>>> connect/token
>>> <http://localhost:8080/auth/realms/waziup/protocol/openid-connect/token>
>>> -H "Authorization: Bearer $USERTOKEN" -d
>>> "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket&audi
>>> ence=api-server&permission=#sensors:view"
>>> | jq .access_token -r | cut -d "." -f2 | base64 -d | jq
>>>
>>> "authorization": {
>>>     "permissions": [
>>>         {
>>>         "rsid": "9e24320d-ef89-440b-b6d5-d7b5a4896f60",
>>>         "rsname": "foo"
>>>
>>> This instead returns a list of resources belonging to all users.
>>> But the list seems to be wrong: it returns sensors to which I *don't*
>>> have
>>> access!
>>> If I try the request on the specific resource, it returns (rightfully)
>>> access_denied:
>>>
>>
>> I tried to do a simple test based on a previous realm configuration you
>> sent. Could not reproduce the problem.
>>
>
>>
>>>
>>> curl -X POST
>>> http://localhost:8080/auth/realms/waziup/protocol/openid-connect/token
>>> -H
>>> "Authorization: Bearer $USERTOKEN" -d
>>> "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket&audi
>>> ence=api-server&permission=
>>> 9e24320d-ef89-440b-b6d5-d7b5a4896f60#sensors:view"
>>> {"error":"access_denied","error_description":"not_authorized"}
>>>
>>> Another strange thing, if I try with a non-existent resource ID, there is
>>> no error message and it returns a list of permissions:
>>>
>>> $ curl -X POST
>>> http://localhost:8080/auth/realms/waziup/protocol/openid-connect/token
>>> -H
>>> "Authorization: Bearer $USERTOKEN" -d
>>> "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket&audi
>>> ence=api-server&permission=not-exist#sensors:view"
>>> | jq .access_token -r | cut -d "." -f2 | base64 -d | jq
>>>
>>> "authorization": {
>>>     "permissions": [
>>>         {
>>>         "rsid": "9e24320d-ef89-440b-b6d5-d7b5a4896f60",
>>>         "rsname": "foo"
>>> ...
>>>
>>
>> I think you reported ths already. Here is the PR
>> https://github.com/keycloak/keycloak/pull/5357.
>>
>
> Yes, I thought it was already in HEAD, but I see it's not merged (sorry).
>
>
>>
>>
>>> _______________________________________________
>>> 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