[keycloak-user] Retrieve all permissions

Mon Jul 16 10:13:15 EDT 2018

Sorry typo

On Mon, Jul 16, 2018 at 4:12 PM, Corentin Dupont <corentin.dupont at gmail.com>
wrote:

>
> OK, great...
> What was weird for me is that a resource can be accepted one way, and
> rejected the other... With the same scope.
>
>
> On Mon, Jul 16, 2018 at 2:03 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> I was expecting to run some tests today .... But now I see what is
>> happening.
>>
>> The behavior is correct. If you are asking permissions for "MyScope"
>> only, your policies should be able to evaluate whether or not permissions
>> should be granted to the scope itself, regardless of the resource. In fact,
>> that is what you are asking in your authorization request. We allow
>> permissions granted only yo scopes.
>>
>> On Sun, Jul 15, 2018 at 5:31 PM, Corentin Dupont <
>> corentin.dupont at gmail.com> wrote:
>>
>>> I think I understood the problem.
>>> This Javascript policy will yield different result if a permission
>>> request is made on the resource+scope, or with just scope.
>>>
>>> var permission = $evaluation.getPermission();
>>> if(permission.getResource()) {
>>>    $evaluation.deny();
>>> } else {
>>>    $evaluation.grant();
>>> }
>>>
>>> A permission request on "MyResource#MyScope" will yield a 403 Forbidden.
>>> However, a request on "#MyScope" will return the resource (among
>>> others).
>>>
>>> I noticed that the policy is evaluated twice: once with the resource,
>>> once without. Is that correct?
>>>
>>> On Fri, Jul 13, 2018 at 4:58 PM, Corentin Dupont <
>>> corentin.dupont at gmail.com> wrote:
>>>
>>>> Hi Pedro,
>>>> so finally did you manage to reproduce the bug?
>>>> Cheers
>>>>
>>>> On Thu, Jul 12, 2018 at 9:52 AM, Corentin Dupont <
>>>> corentin.dupont at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 11, 2018 at 9:55 PM, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> The configuration you sent has a resource "Sensors". Is this the
>>>>>> resource I need to use to get permissions ? I mean the resource I need to
>>>>>> use to get a DENY.
>>>>>>
>>>>>
>>>>> In my example I used the resource "Sensor2-ea0541de1ab7132a1d45b
>>>>> 85f9b2139f7", but "Sensors" will also work.
>>>>> BTW, I see that the export I gave you doesn't have the resource "
>>>>> Sensor2-ea0541de1ab7132a1d45b85f9b2139f7", is it normal?
>>>>> This resource was created using the API.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Also, I noted that "Admin Users" which is used by permission "View
>>>>>> Sensor" has no user defined,
>>>>>>
>>>>>
>>>>> I think this is due to this problem that I reported:
>>>>> https://issues.jboss.org/browse/KEYCLOAK-7786?filter=-2
>>>>> It seems that users are not exported with the policy. I do have users
>>>>> in the policy "Admin Users".
>>>>> Do you have the same issue if you export the realm?
>>>>> I used:
>>>>> docker-compose run --entrypoint "/opt/jboss/docker-entrypoint.sh -b
>>>>> 0.0.0.0 -Dkeycloak.migration.action=export
>>>>> -Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=/opt/
>>>>> jboss/keycloak/standalone/data/" keycloak
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> but "View Sensor" permission is set as "Affirmative". In this case,
>>>>>> there is a policy "Unregistered users" that do grant access to user
>>>>>> "guest", because the user is granted with the role. So access is granted to
>>>>>> resource "Sensors".
>>>>>>
>>>>>> Wdyt ?
>>>>>>
>>>>>
>>>>> I'm still experimenting. I have an API like this:
>>>>> GET /sensors
>>>>> POST /sensors
>>>>> GET /sensors/<Sensor-xxxxx>
>>>>> ...
>>>>>
>>>>> At first I used a resource "Sensors" to represent "/sensors", and
>>>>> resources created with name "Sensor-xxxx" for each specific resources.
>>>>> But now I see that this is not enough. When performing GET /sensors, I
>>>>> need to filter the sensors list by matching it with the permission list
>>>>> retrieved with "#sensors:view".
>>>>>
>>>>> Anyway, you can modify any of the policies to obtain a "DENY", that
>>>>> should reproduce the problem :)
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 11, 2018 at 1:12 PM, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Tks !!
>>>>>>>
>>>>>>> On Wed, Jul 11, 2018 at 12:29 PM, Corentin Dupont <
>>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>>
>>>>>>>> PS. I used the account "guest":
>>>>>>>> USERTOKEN=`curl -X POST  -H "Content-Type:
>>>>>>>> application/x-www-form-urlencoded" -d
>>>>>>>> 'username=guest&password=guest&grant_type=password&client_id
>>>>>>>> =api-server&client_secret=4e9dcb80-efcd-484c-b3d7-1e95a0096ac0&scope=offline_access'
>>>>>>>> "http://localhost:8080/auth/realms/waziup/protocol/openid-co
>>>>>>>> nnect/token" | jq .access_token -r`
>>>>>>>>
>>>>>>>> On Wed, Jul 11, 2018 at 5:15 PM, Corentin Dupont <
>>>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Here is the realm.
>>>>>>>>> You should be able to reproduce the bug with the commands I gave
>>>>>>>>> (hopefully).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jul 11, 2018 at 3:08 PM, Pedro Igor Silva <
>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Please, share it ... I have that previous export you sent me
>>>>>>>>>> already, maybe you can just give me the steps to set up things like:
>>>>>>>>>>
>>>>>>>>>> * Create resource X where user Y is owner
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 11, 2018 at 5:57 AM, Corentin Dupont <
>>>>>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Pedro,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I retried this morning, I still have the problem:
>>>>>>>>>>>
>>>>>>>>>>> $ curl -X POST http://localhost:8080/auth/rea
>>>>>>>>>>> lms/waziup/protocol/openid-connect/token -H "Authorization:
>>>>>>>>>>> Bearer $USERTOKEN" -d "grant_type=urn:ietf:params:oa
>>>>>>>>>>> uth:grant-type:uma-ticket&audience=api-server&permission=baa
>>>>>>>>>>> b7620-7d36-4efd-8810-b7cb33e54527#sensors:view"
>>>>>>>>>>> {"error":"access_denied","error_description":"not_authorized"}
>>>>>>>>>>>
>>>>>>>>>>> $ curl -X POST http://localhost:8080/auth/rea
>>>>>>>>>>> lms/waziup/protocol/openid-connect/token -H "Authorization:
>>>>>>>>>>> Bearer $USERTOKEN" -d "grant_type=urn:ietf:params:oa
>>>>>>>>>>> uth:grant-type:uma-ticket&audience=api-server&permission=#sensors:view"
>>>>>>>>>>> | jq .access_token -r | cut -d "." -f2 | base64 -d | jq
>>>>>>>>>>> ".authorization.permissions[] | select(.rsid ==
>>>>>>>>>>> \"baab7620-7d36-4efd-8810-b7cb33e54527\")"
>>>>>>>>>>> {
>>>>>>>>>>>   "scopes": [
>>>>>>>>>>>     "sensors:view"
>>>>>>>>>>>   ],
>>>>>>>>>>>   "rsid": "baab7620-7d36-4efd-8810-b7cb33e54527",
>>>>>>>>>>>   "rsname": "Sensor2-ea0541de1ab7132a1d45b85f9b2139f7"
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> On the first request, the resource
>>>>>>>>>>> baab7620-7d36-4efd-8810-b7cb33e54527 is denied, while on the
>>>>>>>>>>> second it appears in the list returned.
>>>>>>>>>>> If you want, I can give you another export of my realm...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>