8:32 a.m.
The following attempt to change the _id results in 500 Server Error:
curl -X PUT \
https://domain.com/realms/realm/authz/protection/resource_set/resource2 \
-H 'Authorization: Bearer 123' \
-H 'Content-Type: application/json' \
-H 'cache-control: no-cache' \
-d '{
"_id":"resource-2"
}'
But creating a new resource "resource-3" with the dash does resolve the
issue. Now I get access_denied.
Thanks
On Tue, 6 Nov 2018 at 14:25, Pedro Igor Silva <psilva(a)redhat.com> wrote:
I think I know what is happening.
Although we support setting the _id when creating a resource, our code
assumes that ids have the same format as when auto-generated by Keycloak.
In order to avoid unnecessary hits to the database when querying a
resource by name, we have a specific point in the code that only tries to
fetch the resource by id if it contains a "-". Otherwise, query by name.
That is why it is failing for you.
If you try to change the id value to "resource-2" you should get things
working as expected. Can you try it out?
Regards.
Pedro Igor
On Tue, Nov 6, 2018 at 10:26 AM Geoffrey Cleaves <geoff(a)opticks.io> wrote:
> The token endpoint sends an unexpected response while using grant_type
> urn:ietf:params:oauth:grant-type:uma-ticket and a ticket with permissions
> to a resource created via the resource UMA endpoint that has an explicit
> _id.
>
> When access is denied, endpoint sends a HTTP 400 and invalid_resource /
> Resource with id [resource2] does not exist. instead of sending 403. The
> same test but using a resource which has the Keycloak-assigned _id returns
> 403 as expected.
>
> I believe the key point here is that the resource has been created using
> the resource_set endpoint and had the _id set explicitly instead of
> letting
> Keycloak assign the id.
>
> Could the issue be related the fact that my Keycloak Docker install began
> as 4.3.0.Final with the database being Postgres, and then I upgraded
> Keycloak to 4.5.0.Final by downloading the latest Docker image? Could any
> DB migrations have been missed which could cause this issue?
>
> To reproduce the issue, try the following: Create resources rA and rB via
> the resource_set endpoint. When creating rB, include a explicit _id. Then,
> using an auth_token which does not have access to rB, try getting a RPT
> which includes permissions to rB. Token end point will respond with 400
> resource_not_found. But in fact the resource exists.
>
> I have opened Jira ticket: https://issues.jboss.org/browse/KEYCLOAK-8729
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>