4:47 p.m.
Hi,
I am working on a keycloak setup trying to replicate the photoz example. The
'test' realm is configured as follows:
* UMA enabled
* has a client 'photoz' with Authorization enabled
* 2 authorization scopes: album:view & album:modify
* each scope has a scope-based 'only owner' permission associated (Javascript)
* 2 users: alice and bob
Alice creates a new album resouce with the following request:
POST /auth/realms/test/authz/protection/resource_set
{"name": "Amazing sunsets", "owner": "alice",
"ownerManagedAccess": "true",
"uri": "/albums/100", "type": "album",
"resource_scopes": ["album:view",
"album:modify"]}
Simulating Bob accessing album "Amazing sunsets" using the authorization
evaluation tab, returns permission denied for both scopes (view & modify) as
expected.
Now, Alice shares "Amazing sunsets" via the account management interface but
limits the scope to 'view' by sharing 'album:view' only.
Back to evaluating Bob's access:
* Scope album:view on "Amazing sunsets" is granted (yay!).
* Scope album:modify on "Amazing sunsets" also is granted ??
Why would Bob get full access if Alice only shared album:view ? The evaluation
output even states that the granted album:view access was the reason why
access to album:modify is granted too (see attached screenshot for details).
Does anybody have a suggestion what I am missing here ?
Thanks,
Marek
5:54 p.m.
I've had a similar problem, it might be related to this:
https://issues.jboss.org/browse/KEYCLOAK-9093
On 1/15/19, 7:53 AM, "keycloak-user-bounces(a)lists.jboss.org on behalf of Marek
Lindner" <keycloak-user-bounces(a)lists.jboss.org on behalf of
mareklindner(a)neomailbox.ch> wrote:
Hi,
I am working on a keycloak setup trying to replicate the photoz example. The
'test' realm is configured as follows:
* UMA enabled
* has a client 'photoz' with Authorization enabled
* 2 authorization scopes: album:view & album:modify
* each scope has a scope-based 'only owner' permission associated
(Javascript)
* 2 users: alice and bob
Alice creates a new album resouce with the following request:
POST /auth/realms/test/authz/protection/resource_set
{"name": "Amazing sunsets", "owner": "alice",
"ownerManagedAccess": "true",
"uri": "/albums/100", "type": "album",
"resource_scopes": ["album:view",
"album:modify"]}
Simulating Bob accessing album "Amazing sunsets" using the authorization
evaluation tab, returns permission denied for both scopes (view & modify) as
expected.
Now, Alice shares "Amazing sunsets" via the account management interface but
limits the scope to 'view' by sharing 'album:view' only.
Back to evaluating Bob's access:
* Scope album:view on "Amazing sunsets" is granted (yay!).
* Scope album:modify on "Amazing sunsets" also is granted ??
Why would Bob get full access if Alice only shared album:view ? The evaluation
output even states that the granted album:view access was the reason why
access to album:modify is granted too (see attached screenshot for details).
Does anybody have a suggestion what I am missing here ?
Thanks,
Marek
3:19 a.m.
On Wednesday, 16 January 2019 00:54:43 HKT Lamina, Marco wrote:
I've had a similar problem, it might be related to this:
https://issues.jboss.org/browse/KEYCLOAK-9093
It may be related but I am not 100% sure yet.
What do your policies & permissions look like ? If you compare your evaluation
screenshot and mine you can see that my keycloak has a policy installed which
forbids non-owners to access the resource. That DENY policy is overruled due
to some unrelated scope.
In your case there seems to be no DENY at all. Could be you have an 'allow
everybody' policy in place. Keycloak comes with such default policies you may
want to look into.
Cheers,
Marek
12:25 p.m.
Hi Marek,
Which version of Keycloak are you using?
I tried to reproduce the problem using upstream and the evaluation tool
looks correct by reporting only album:view. The same goes if obtaining an
RPT from the token endpoint.
On Wed, Jan 16, 2019 at 12:21 AM Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
On Wednesday, 16 January 2019 00:54:43 HKT Lamina, Marco wrote:
> I've had a similar problem, it might be related to this:
>
> https://issues.jboss.org/browse/KEYCLOAK-9093
It may be related but I am not 100% sure yet.
What do your policies & permissions look like ? If you compare your
evaluation
screenshot and mine you can see that my keycloak has a policy installed
which
forbids non-owners to access the resource. That DENY policy is overruled
due
to some unrelated scope.
In your case there seems to be no DENY at all. Could be you have an 'allow
everybody' policy in place. Keycloak comes with such default policies you
may
want to look into.
Cheers,
Marek
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
12:29 p.m.
Hi Pedro,
Which version of Keycloak are you using?
I am using 4.8.2 Final (see attached screenshot).
I tried to reproduce the problem using upstream and the evaluation
tool
looks correct by reporting only album:view. The same goes if obtaining an
RPT from the token endpoint.
Can you share a screenshot of your evaluation tool result ? Does it correctly
DENY access ?
I can also share my server config json if this helps.
Thanks,
Marek
12:38 p.m.
Here it is.
On Wed, Jan 16, 2019 at 9:30 AM Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
Hi Pedro,
> Which version of Keycloak are you using?
I am using 4.8.2 Final (see attached screenshot).
> I tried to reproduce the problem using upstream and the evaluation tool
> looks correct by reporting only album:view. The same goes if obtaining an
> RPT from the token endpoint.
Can you share a screenshot of your evaluation tool result ? Does it
correctly
DENY access ?
I can also share my server config json if this helps.
Thanks,
Marek
12:40 p.m.
Basically, I imported the "photoz" realm from that quickstart and removed
everything except the scopes and policies. Then I followed your steps to
reproduce the issue.
On Wed, Jan 16, 2019 at 9:38 AM Pedro Igor Silva <psilva(a)redhat.com> wrote:
Here it is.
On Wed, Jan 16, 2019 at 9:30 AM Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
> Hi Pedro,
>
> > Which version of Keycloak are you using?
>
> I am using 4.8.2 Final (see attached screenshot).
>
>
> > I tried to reproduce the problem using upstream and the evaluation tool
> > looks correct by reporting only album:view. The same goes if obtaining
> an
> > RPT from the token endpoint.
>
> Can you share a screenshot of your evaluation tool result ? Does it
> correctly
> DENY access ?
>
> I can also share my server config json if this helps.
>
> Thanks,
> Marek
>
>
12:51 p.m.
On Wednesday, 16 January 2019 19:38:45 HKT Pedro Igor Silva wrote:
Here it is.
Thanks! The difference between your evaluation test and mine appears to be
that you tested the shared scope.
To summarize:
a) Alice does allow Bob to perform album:view.
b) Alice does not allow Bob to perform album:modify.
When Bob tries to access album:view I'd expect PERMIT whereas when
album:modify is attempted DENY should be the result. Do we agree ?
I attached screenshots for both evaluation attempts. Both (view and modify)
yield PERMIT. That should not be the case or am I missing something ?
Regards,
Marek
12:58 p.m.
Now I see. The result is giving a false-positive but the set of granted
permissions should be correct.
To check that, could you click "Show Authorization Data" link on the top of
the result page and see how the permissions look like in the generated
token? You should see:
"authorization": {
"permissions": [
{
"scopes": [
"album:view"
],
"rsid": "7e1ae12b-e733-4090-9f84-8242f9192288",
"rsname": "Amazing sunsets"
}
]
},
On Wed, Jan 16, 2019 at 9:51 AM Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
On Wednesday, 16 January 2019 19:38:45 HKT Pedro Igor Silva wrote:
> Here it is.
Thanks! The difference between your evaluation test and mine appears to be
that you tested the shared scope.
To summarize:
a) Alice does allow Bob to perform album:view.
b) Alice does not allow Bob to perform album:modify.
When Bob tries to access album:view I'd expect PERMIT whereas when
album:modify is attempted DENY should be the result. Do we agree ?
I attached screenshots for both evaluation attempts. Both (view and
modify)
yield PERMIT. That should not be the case or am I missing something ?
Regards,
Marek
1:01 p.m.
On Wednesday, 16 January 2019 19:58:30 HKT Pedro Igor Silva wrote:
Now I see. The result is giving a false-positive but the set of
granted
permissions should be correct.
To check that, could you click "Show Authorization Data" link on the top of
the result page and see how the permissions look like in the generated
token? You should see:
"authorization": {
"permissions": [
{
"scopes": [
"album:view"
],
"rsid": "7e1ae12b-e733-4090-9f84-8242f9192288",
"rsname": "Amazing sunsets"
}
]
},
Bob's album:view:
"authorization": {
"permissions": [
{
"scopes": [
"album:view"
],
"rsid": "2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b",
"rsname": "Amazing sunsets"
}
]
}
Bob's album:modify (false-positive):
"authorization": {
"permissions": [
{
"scopes": [
"album:view"
],
"rsid": "2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b",
"rsname": "Amazing sunsets"
}
]
}
Regards,
Marek
1:13 p.m.
Thanks. I think we are on the same page then. Created
https://issues.jboss.org/browse/KEYCLOAK-9337.
Please, for now, ignore that result and consider the set of the actual
granted permissions.
Regards.
Pedro Igor
On Wed, Jan 16, 2019 at 10:02 AM Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
On Wednesday, 16 January 2019 19:58:30 HKT Pedro Igor Silva wrote:
> Now I see. The result is giving a false-positive but the set of granted
> permissions should be correct.
>
> To check that, could you click "Show Authorization Data" link on the top
of
> the result page and see how the permissions look like in the generated
> token? You should see:
>
> "authorization": {
> "permissions": [
> {
> "scopes": [
> "album:view"
> ],
> "rsid": "7e1ae12b-e733-4090-9f84-8242f9192288",
> "rsname": "Amazing sunsets"
> }
> ]
> },
Bob's album:view:
"authorization": {
"permissions": [
{
"scopes": [
"album:view"
],
"rsid": "2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b",
"rsname": "Amazing sunsets"
}
]
}
Bob's album:modify (false-positive):
"authorization": {
"permissions": [
{
"scopes": [
"album:view"
],
"rsid": "2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b",
"rsname": "Amazing sunsets"
}
]
}
Regards,
Marek
1:31 p.m.
On Wednesday, 16 January 2019 20:13:56 HKT Pedro Igor Silva wrote:
Thanks. I think we are on the same page then. Created
https://issues.jboss.org/browse/KEYCLOAK-9337.
Please, for now, ignore that result and consider the set of the actual
granted permissions.
Thanks for opening that bug. However, let me point out that this issue is not
limited to the evaluation tool. The UMA policy API evaluation is affected too.
Here the call for checking permissions:
POST /auth/realms/test/protocol/openid-connect/token
grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
&permission=2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b#album:modify
&audience=photoz&response_mode=decision
returns: {"result":true}
Haven't tested RPT tickets but it is somewhat reasonable to assume those
are affected too. Looks like the policy logic is fine with any scope shared
to grant permission for all scopes.
Regards,
Marek
1:37 p.m.
Now you are talking about https://github.com/keycloak/keycloak/pull/5833.
Which is related to the "decision" response mode returning a
false-positive. However, both RPT and "permissions" response mode returns
the correct permissions.
On Wed, Jan 16, 2019 at 10:31 AM Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
On Wednesday, 16 January 2019 20:13:56 HKT Pedro Igor Silva wrote:
> Thanks. I think we are on the same page then. Created
> https://issues.jboss.org/browse/KEYCLOAK-9337.
>
> Please, for now, ignore that result and consider the set of the actual
> granted permissions.
Thanks for opening that bug. However, let me point out that this issue is
not
limited to the evaluation tool. The UMA policy API evaluation is affected
too.
Here the call for checking permissions:
POST /auth/realms/test/protocol/openid-connect/token
grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
&permission=2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b#album:modify
&audience=photoz&response_mode=decision
returns: {"result":true}
Haven't tested RPT tickets but it is somewhat reasonable to assume those
are affected too. Looks like the policy logic is fine with any scope shared
to grant permission for all scopes.
Regards,
Marek
1:38 p.m.
Due to the bugs you and Marco are discussing, you should not use
response_mode=decision but instead need to examine the scopes that are
returned in the token.
On Wed, 16 Jan 2019 at 13:36, Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
On Wednesday, 16 January 2019 20:13:56 HKT Pedro Igor Silva wrote:
> Thanks. I think we are on the same page then. Created
> https://issues.jboss.org/browse/KEYCLOAK-9337.
>
> Please, for now, ignore that result and consider the set of the actual
> granted permissions.
Thanks for opening that bug. However, let me point out that this issue is
not
limited to the evaluation tool. The UMA policy API evaluation is affected
too.
Here the call for checking permissions:
POST /auth/realms/test/protocol/openid-connect/token
grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
&permission=2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b#album:modify
&audience=photoz&response_mode=decision
returns: {"result":true}
Haven't tested RPT tickets but it is somewhat reasonable to assume those
are affected too. Looks like the policy logic is fine with any scope shared
to grant permission for all scopes.
Regards,
Marek
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Regards,
Geoffrey Cleaves
1:40 p.m.
+1. Or just use the "permissions" response mode while that PR is not merged.
On Wed, Jan 16, 2019 at 10:38 AM Geoffrey Cleaves <geoff(a)opticks.io> wrote:
Due to the bugs you and Marco are discussing, you should not use
response_mode=decision but instead need to examine the scopes that are
returned in the token.
On Wed, 16 Jan 2019 at 13:36, Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
> On Wednesday, 16 January 2019 20:13:56 HKT Pedro Igor Silva wrote:
> > Thanks. I think we are on the same page then. Created
> > https://issues.jboss.org/browse/KEYCLOAK-9337.
> >
> > Please, for now, ignore that result and consider the set of the actual
> > granted permissions.
>
> Thanks for opening that bug. However, let me point out that this issue is
> not
> limited to the evaluation tool. The UMA policy API evaluation is affected
> too.
> Here the call for checking permissions:
>
> POST /auth/realms/test/protocol/openid-connect/token
> grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
> &permission=2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b#album:modify
> &audience=photoz&response_mode=decision
>
> returns: {"result":true}
>
> Haven't tested RPT tickets but it is somewhat reasonable to assume those
> are affected too. Looks like the policy logic is fine with any scope
> shared
> to grant permission for all scopes.
>
> Regards,
> Marek
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Regards,
Geoffrey Cleaves
3:41 p.m.
The "response_mode" request parameter that you can set to authorization
requests you send to token endpoint. If the value is "permissions" you will
get a JSON array with the granted permissions as a response.
On Wed, Jan 16, 2019 at 12:30 PM Marek Lindner <mareklindner(a)neomailbox.ch>
wrote:
On Wednesday, 16 January 2019 20:40:43 HKT Pedro Igor Silva wrote:
> +1. Or just use the "permissions" response mode while that PR is not
merged.
What's the permission response mode you are referring to ?
Regards,
Marek
2200
days inactive
2201
days old
16 comments
4 participants
participants (4)
-
Geoffrey Cleaves -
Lamina, Marco -
Marek Lindner -
Pedro Igor Silva