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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; wrote: >>> >>>> >>>> >>>> On Wed, Jul 11, 2018 at 9:55 PM, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> 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(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Tks !! >>>>>> >>>>>> On Wed, Jul 11, 2018 at 12:29 PM, Corentin Dupont < >>>>>> corentin.dupont(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; 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... >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >