11:59 p.m.
Hi Paul,
Indeed, there exists a workaround you're writing about. You can create
a custom REST endpoint inside Keycloak that will do exactly the
following: 1) check the user's identity, 2) check that the requested
consent belongs to the user, 3) perform actions on the consent.
To do this, you'll need to implement a RealmResourceProvider: https://w
ww.keycloak.org/docs/latest/server_development/index.html#_extensions_r
est
examples/providers/rest is a good start. The hard part is
authentication/authorization: custom REST resources are public by
default, so you'll need to take some efforts to secure your
resource.There's some sort of authorization in
examples/providers/domain-extension, but unfortunately it's currently
broken: https://issues.jboss.org/browse/KEYCLOAK-5927
I'd suggest that you rather take a look at BeerCloak (it's working and
maintained): https://github.com/dteleguin/beercloak
In BeerCloak, the user is checked for "view-beer" and "manage-beer"
roles membership; in your case, you'll need to compare the user against
the consent, but that shouldn't be difficult.
Good luck, and feel free to ask questions regarding BeerCloak,Dmitry
Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info@acutus.pro
On Tue, 2018-07-24 at 14:20 -0400, Paul Grebenc wrote:
Thank you, this is useful information.
If it is currently not possible for a normal user to view or revoke
consents on their own authority, a workaround could probably be to
set up a service associated with a client in Keycloak that does have
the authority to perform these operations, and then it will be
responsible for restricting what it allows based on the identity of
its callers.
Regards,
Paul
On Sun, Jul 22, 2018 at 10:52 PM, Dmitry Telegin <dt(a)acutus.pro>
wrote:
> Hi Paul,
>
> Here's the method responsible for consent / offline token
> revocation:
> https://github.com/keycloak/keycloak/blob/master/services/src/main/
> java/org/keycloak/services/resources/admin/UserResource.java#L480
>
> This can be further traced to
> o.k.services.resources.admin.permissions.UserPermissions::canManage
> (UserModel):
> https://github.com/keycloak/keycloak/blob/master/services/src/main/
> java/org/keycloak/services/resources/admin/permissions/UserPermissi
> ons.java#L311
>
> Long story short: currently, consents / offline tokens can be
> revoked
> only by those allowed to manage all the users in the realm (either
> via
> "admin" role membership or Realm > Users > Permissions) or by those
> allowed to manage users in a particular group (Realm > Groups >
> (group)
> > Permissions). That means, a user is not allowed to revoke his/her
> own
> consents and offline tokens. This looks like a bug to me, but let's
> see
> what the Keycloak devs say.
>
> > Also, looking through the REST API documentation, I didn't see
> > anything related to roles and authorization. Are all operations
> only
> > accessible by users with the admin role assigned?
>
> Not necessarily so; unfortunately, this topic is mostly
> undocumented,
> so the only reliable way is to look into the sources (something
> we've
> just done for consent revocation).
>
> Cheers,
> Dmitry Telegin
> CTO, Acutus s.r.o.
> Keycloak Consulting and Training
>
> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> +42 (022) 888-30-71
> E-mail: info(a)acutus.pro
>
> On Fri, 2018-07-20 at 15:47 -0400, Paul Grebenc wrote:
> > I have been doing some investigation with Keycloak 3.4.3.Final,
> and have
> > noticed something that I am wondering about.
> >
> > It is possible for me to request an offline token for a given
> user with a
> > password grant, and that consent will show up for the user under
> the user's
> > Consents tab in the admin console.
> >
> > In terms of managing any granted consents (for the purpose of
> allowing a
> > user to revoke a consent that they have granted), I have been
> able to do
> > the following:
> >
> > curl -X GET -H "Authorization: Bearer <authToken>"
> > http://localhost:8080/auth/admin/realms/master/users/<userId>/con
> sents
> > <http://localhost:8080/auth/admin/realms/master/users/38454015-6a
> b7-4880-b54c-77c5780fd2ba/consents>
> >
> >
> > This returns all current consents granted by the user. I can
> then also do
> > the following:
> >
> >
> > curl -X DELETE -H "Authorization: Bearer <authToken>"
> > http://localhost:8080/auth/admin/realms/master/users/<userId>/con
> sents/<clientId>;;;
> > <http://localhost:8080/auth/admin/realms/master/users/38454015-6a
> b7-4880-b54c-77c5780fd2ba/consents/agent-registration>
> >
> >
> > This revokes the consent granted by the specified user for the
> specified
> > client.
> >
> >
> > This is good so far, but I noticed that I was only authorized to
> perform
> > these operations as admin, and not as the user in question who
> has granted
> > these consents. Through experimentation, I was able to determine
> that if I
> > add the role "admin" to the user, that user is then authorized
> for these
> > operations.
> >
> >
> > Is this intentional? It was originally my expectation that a
> user who has
> > granted consents should be able to view or revoke their own
> consents
> > without having to have the admin role assigned.
> >
> >
> > Also, looking through the REST API documentation, I didn't see
> anything
> > related to roles and authorization. Are all operations only
> accessible by
> > users with the admin role assigned?
> >
> >
> > Regards,
> >
> > Paul
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>