5:44 a.m.
Permissions managed through the console are not really UMA. Even though
they might be associated with policies that enforce access only to the
owner.
UMA permissions are managed differently and are only created when you are
using the UMA flow, using permission tickets, etc. The /uma-policy endpoint
is an extension to the specification from where you can manage additional
policies for a resource owner resource, so you could create those
additional policies and still let the resource owner to revoke these
policies through the account service. For instance, you might want to grant
access to a specific resource to a specific group in your organization and
still let the user revoke access to this group if he wants to.
Regards.
Pedro Igor
On Sun, Nov 18, 2018 at 12:57 PM Geoffrey Cleaves <geoff(a)opticks.io> wrote:
I now see that I do get a list of *UMA permissions* when using the
Resource
Owner Password Credentials Grant Type. I has wrongly expected to see the
permissions I had created as admin via the Admin Console.
Shouldn't it be possible for the resource server's service account to view
and create UMA permissions without needing to know the end users'
credentials for the Resource Owner Password Credentials Grant Type? Or
perhaps that is the whole point of UMA...
On Sun, 18 Nov 2018 at 12:27, Geoffrey Cleaves <geoff(a)opticks.io> wrote:
> Hi,
>
> I'm sending GET requests to http://
${host}:${post}/auth/realms/${realm}/authz/protection/uma-policy
> but only get an empty array. I have a permission/policy assigned to
> hundreds of resources belonging to dozens of users and some resources
owned
> by the resource server itself. Reading the docs
> <
https://www.keycloak.org/docs/latest/authorization_services/index.html#_s...
>,
> I expect to be able to get a list of all permissions or query by name.
>
> Perhaps I am misunderstanding this:
>
> This API is protected by a bearer token that must represent a consent
> granted by the user to the resource server to manage permissions on his
> behalf. The bearer token can be a regular access token obtained from the
> token endpoint using:
>
>
> - Resource Owner Password Credentials Grant Type
> - Token Exchange, in order to exchange an access token granted to
> some client (public client) for a token where audience is the
resource
> server
>
> But I don't think so because if my token were wrong I'd get a 401 or 403
> instead of 200 with an empty array. In any case I've tried with Client
> Credentials Grant and Resource Owner Password Credentials Grant Type.
>
> [image: Screen Shot 2018-11-18 at 12.19.25.png]
> curl -D - -X GET \
> https://.../authz/protection/uma-policy \
> -H 'Authorization: Bearer eyJh' \
> -H 'Cache-Control: no-cache' \
> -H 'Postman-Token: deb09a7a-0499-430f-8164-3097e5ac145d' \
> -H 'cache-control: no-cache'
>
> HTTP/1.1 200 OK
> Server: nginx/1.11.10
> Date: Sun, 18 Nov 2018 11:23:41 GMT
> Content-Type: application/json
> Content-Length: 2
> Connection: keep-alive
> Cache-Control: no-cache
> []
>
> Any advise?
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user