Re: [keycloak-user] Retrieve all permissions
by Corentin Dupont
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...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
6 years
Combine grants
by Corentin Dupont
Another question for you guys:
is it possible to combine grants?
Now to get some permissions, I need to perform 2 requests:
USERTOKEN=`curl -X POST -H "Content-Type:
application/x-www-form-urlencoded" -d
'username=cdupont&password=password&grant_type=password&client_id=api-server&client_secret=4e9dcb80-efcd-484c-b3d7-1e95a0096ac0'
"http://localhost:8080/auth/realms/waziup/protocol/openid-connect/token" |
jq .access_token -r`
curl -X POST
http://localhost:8080/auth/realms/waziup/protocol/openid-connect/token -H
"Authorization: Bearer $USERTOKEN" -d
"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket&audience=api-server&permission=ce023344-a01e-4d3c-8ba8-dc626e088dfd#sensors:view"
The first with grant_type=password and the second with
grant_type=urn:ietf:params:oauth:grant-type:uma-ticket.
However HTTP requests are expensive...
It would be nice to make only one request.
6 years
Questions about Keycloak UMA 2.0 implementation
by Francisco José Bermejo Herrera
Hello, we are testing Keycloak 4.1.0.Final for authentication and
authorization (UMA 2.0 flow).
Some assumptions:
- The Resource Server owns the resource Foo, and protects it by using
two scope-based permissions, one requiring READ scope, and the other one
requiring WRITE scope.
- User Alice has been granted READ scope for resource Foo.
- We are not using Policy Enforcers. Enforcement will be implemented at
the Resource Server.
We are modeling the following flow:
1. The Requesting Party (Alice) requests access to resource Foo in the
Resource Server. This request DOES NOT provide an RPT.
2. The Resource Server detects the absence of RPT, so it requests a
Permission Ticket to Keycloak, for the Foo resource and both READ and WRITE
scopes (providing a valid PAT).
3. Keycloak returns a valid Permission Ticket to the Resource Server.
4. The Resource Server returns the Permission Ticket (including Keycloak
token URI (http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token)
at WWW-Authorization header) with status code 401 to the Requesting Party.
5. The Requesting Party sends the Permission Ticket (for the Foo
resource and both READ and WRITE scopes) to Keycloak, in order to get a
valid RPT.
Here is where things start to get confusing. We expected that Keycloak
would reject the authorization request due to failed permission evaluation
(Alice has READ scope for resource Foo, but DOES NOT have WRITE scope).
Nevertheless, Keycloak returns a valid RPT, granting permission for
resource Foo (just for READ scope).
We are aware that this behavior is UMA 2.0 compliant
<https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.sectio...>
:
> If the value is non-null and CandidateGrantedScopes < RequestedScopes, the
> authorization server MUST subsequently issue either an RPT containing
> CandidateGrantedScopes (upgrading as appropriate; see below), or one of the
> error codes. The reason for the two options is that granting only partial
> scopes may not be useful for the client's and requesting party's purposes
> in seeking authorization for access.
But as the RFC explicitly points out, this behavior may not be useful for
the client. We think that the RFC is right, because this renders the client
unable to tell whether the authorization has been partially or completely
fulfilled. And consequently the Resource Server will request again a
Permission Ticket for the Foo resource and both READ and WRITE scopes, so
the whole flow will be repeated over and over again. If this is Keycloak
expected behavior, how can we avoid the infinite loops?
Another question is, when providing a valid RPT along with a Permission
Ticket, why Keycloak deems an RPT as upgraded = true even when the
requested resource has not been authorized? It returns the same RPT with
just jti, exp and iat updated. Since we think that the Authorization Server
must be the one stopping the UMA flow, should not Keycloak return a 403
Forbidden instead? Is this behavior configurable in any way?
Thank you in advance!
6 years
Resource unicity
by Corentin Dupont
Hi,
is there a way to configure Keycloak to ensure resource unicity, even with
different users?
In my application, resources names need to be unique, even if created with
different users...
Thanks!!!
6 years
Keycloak 3.4.3 + Apache httpd 2.4.6 load balancing proxy -> infinite redirect
by Michael Yoder
I've got an infinite redirect loop that I'm trying (and failing...) to
figure out. I'm using Keycloak 3.4.3, and in front of that I'm using
Apache httpd mod_proxy for load balancing. If I clear my cookies, or if I
fire up a new Incognito window, everything is fine. But otherwise, when I
try to log in to my application, I get an infinite redirect loop
(technically, a "302 Found", with the same Location: header each time:
http://
<host>:7192/auth/realms/<realm>/login-actions/authenticate?client_id=<client>&tab_id=...)
I've had a look at what's going over the wire with wireshark, and haven't
been particularly enlightened. I'm just using http for now, not https, but
will do that later.
Interesting parts of my keycloak config are
<subsystem xmlns="urn:jboss:domain:undertow:4.0">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener
name="default"
socket-binding="httpish"
enable-http2="true"
proxy-address-forwarding="true"
/>
...
</server>
<servlet-container name="default">
<session-cookie name="AUTH_SESSION_ID" http-only="true" />
...
</servlet-container>
In my httpd config there's
ProxyPreserveHost Off
ProxyAddHeaders On
Listen 7192
ProxyPass / balancer://auth/ stickysession=AUTH_SESSION_ID
ProxyPassReverse / balancer://auth/
<Proxy balancer://auth>
BalancerMember http://<host>:7193 retry=10 route=auth-AUTHSERVER-...
</Proxy>
(Yes I just have one BalancerMember - was attempting to isolate this issue.)
The httpd is listening on port 7192, keycloak is on port 7193.
Since everything is fine if I use an Incognito window, or if I clear my
cookies, I have to imagine that the problem is with the cookies. I looked
at what was going over the wire - in the infinitely looping case, I see two
(different) AUTH_SESSION_ID cookies and one KC_RESTART cookie. In the
"good" case, I see a (different) AUTH_SESSION_ID cookie and one KC_RESTART
cookie. The KC_RESTART cookie is nearly identical between the two except
for the "state" field. This was less helpful than I had hoped.
Any help, hints, or things to debug will be greatly appreciated. Thanks in
advance!
-Mike Yoder
6 years
how to enable releam
by vandana thota
Realm not enabled on keycloak page it showing how can I enable it
via command line ?
Thanks,
Vandana
6 years
ERROR [org.keycloak.services.resources.IdentityBrokerService]
by vandana thota
Hello
While configuring the Single sign on for the application deployed on
wildfly by using the keycloak and external Identity Provider. We came
across the below errors and warnings .
How to resolve below warnings & erros
14:10:39,362 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread
Pool -- 47) HHH000431: Unable to determine H2 database version, certain
features m work
14:11:30,567 WARN [org.keycloak.events] (default task-1)
type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=master, clientId=null,
userId=null, ipAddress=10.9.7.2,=invalidRequestMessage
14:11:30,568 ERROR [org.keycloak.services.resources.IdentityBrokerService]
(default task-1) invalidRequestMessage
14:11:51,668 WARN [org.keycloak.events] (default task-2)
type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=master, clientId=null,
userId=null, ipAddress=10.9.7.2,=invalidRequestMessage
14:11:51,669 ERROR [org.keycloak.services.resources.IdentityBrokerService]
(default task-2) invalidRequestMessage
Thanks,
Vandana
6 years
