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