[keycloak-user] Retrieve all permissions

Mon Jul 16 10:12:45 EDT 2018

OK, great...
What was weird for me is that a resource can be rejected 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=4e9d
>>>>>>> cb80-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-b7cb33
>>>>>>>>>> e54527 is denied, while on the second it appears in the list
>>>>>>>>>> returned.
>>>>>>>>>> If you want, I can give you another export of my realm...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>