8:12 p.m.
Hi,
While developing a complex production-grade KeyCloak extension I've
faced the following problem. Let's say the extension provides several
custom realm resources plus the relevant parts of admin console GUI. A
user should be able to access this functionality only if he/she has
corresponding roles: one role for read-only access, another one for
full operation. The "domain-extension" example does solve the similar
problem, but in a very simplistic way: the user is only checked against
the built-in "admin" role. A real-world example would likely feature at
least two custom roles, different from the built-in ones. Implementing
this with the current KeyCloak version turned out to be a rather
complex problem. To demonstrate it, I've created the following example.
Throughout the example, two custom roles are used, "view-hello" and
"manage-hello":
https://github.com/dteleguin/custom-admin-roles
The problem could be broken down into three parts:
1. Creating roles. Imagine the instructions: "After you have installed
the extension, please go to Clients, select the master-realm client,
add view-hello and manage-hello roles, then go to Roles, select admin,
add the above roles to it. Repeat for each and every realm you've
already created, but this time also with the realm-management client
and realm-admin role. Don't forget to do the same for every new realm
you add" - this is totally unacceptable if we are speaking of high
quality software. In the example, this is fully automated (see
HelloResourceProviderFactory::postInit). Adding roles to the newly
created realms has become possible with the recent introduction of
RealmPostCreateEvent.
2. Client-side authorization. The GUI elements in the admin console
should be shown only to the users having corresponding roles. There is
the global "access" AngularJS object, instantiated by GlobalCtrl and
used everywhere in the admin console; it would be quite natural to use
the same semantics for custom roles. In the example, AngularJS
decorator mechanism is used to augment the "access" object with
additional getters, reflecting custom role grants. Unfortunately, by
some reason decorating GlobalCtrl directly doesn't work, so we have to
decorate all the controllers (as "$controller") and then select
GlobalCtrl. I'm not sure if it's a KeyCloak or AngularJS issue, since
there's not much information on the net about using decorators with
GlobalCtrl.
3. Server-side authorization, i.e. checking user roles in service
methods of realm REST resources. This is particularly cumbersome, and
imposes an ugly restriction on resource methods - all of them are
required to have @Context HttpHeaders in the argument list. Otherwise
it would be impossible to extract a JWS token and to deduce a realm to
authorize against. The only workaround I see is to move all the service
methods into a sub-resource, so that processing HttpHeaders and auth
setup could be done once, while instantiating sub-resource (like this
is done in o.k.services.resources.admin.AdminRoot). This is especially
frustrating because any custom realm resource is a sub-resource by
default, so there is no reason why it couldn't obtain a HttpHeaders
object from its parent resource upon construction.
Conclusion: a simple and natural requirement for an extension, which is
to have custom admin roles, turns into a lot of boilerplate code, most
of which is present in either form in KeyCloak. Could this
functionality be simply exposed to extensions? Ideally, this should be
a one-liner for extension authors, since the only information needed is
the name of the role(s). I could see it like this:
- an extension declares the roles. Considering possible introduction of
@KeyloakProvider annotation, this could be an annotation parameter, or
a separate annotation;
- KeyCloak takes responsibility for creating roles in both existing and
newly added realms;
- GlobalCtrl augments the "access" object with the relevant getters;
- upon creation, realm resources receive
an o.k.services.resources.admin.AdminAuth-like object, which could be
further decorated, or used as is.
What do you think?
Dmitry