Extend Dev Services for Keycloak in Keycloak Authorization

[sberyozkin]

Description

Right now, when Dev Services for Keycloak creates the default realm and client and users (when no custom realm is imported), this default realm has no keycloak authorization permissions for the default alice and bob users - this causes the confusion when starting quickstarts/security-keycloak-authorization in a dev mode.

Implementation ideas

Start introducing Dev Services for Keycloak authorization - it will simply catch the build item produced by Dev Services for KC and add the correct permissions for the default users

[quarkus-bot]

/cc @pedroigor, @stuartwdouglas

[sberyozkin]

Hi @pedroigor @stuartwdouglas - this is a basic prototype - note it is really better be created directly in Keycloak by importing the realm or directly in Keycloak - at the devservices level it does not make sense to start mirroring a somewhat complex keycloak authorization permissions - ex, keycloak-authorization does a path specific enforcement;

All this PR tries to achieve is to support a straightforward default case where it just works OOB immediately, something Daniel Oh was keen to demonstrate - which may be worth it as creating these permissions is somewhat involved even in the Keycloak UI. So KC DevServices has default alice (as admin and user) and bob (as user) users - so it will be possible, for a start, add resource permissions for them at the configured paths set in the devservices config.

Note I'm doing it all in keycloak-authorization deployment but it is not really good - as this extra configuration is decoupled from the KC devservices one and so changing it won't restart the container - keycloak-authorization is a quarkus-oidc instance so it can't have its own container.

So I'll likely push it down to quarkus-oidc/deployment - and document that some properties will be effective if Keycloak Authorization is enabled

[pedroigor]

@sberyozkin Can we hold this one a bit? The reason is that make this happen is a bit too complex due to how you configure resources/scopes/permissions/policies.

Secondly, we are planning some changes next year in authz and this area is one we should focus more to improve. For instance, have a more easy/clear spec to configure things.

[michalvavrik]

@sberyozkin do you plan on resuming your #21276 effort? I can have a look into this, as I've already planned for longer time to get more familiar with Dev Services.

@pedroigor changes in authz and this are are done, so this issue can be worked on, correc? (+ [very] optionally feel free to point out where to look for important changes)

[sberyozkin]

After thinking more about it, it appears to me that too much effort is required for a very minor gain, specifically, the whole idea of Dev Services for Keycloak creating a default realm with Alice and Bob allocated some roles is that it can be tested immediately against the endpoints with @RolesAllowed annotations, where users can tweak those annotations to have user and admin roles - and while this is not what will be used in prod, at least RBAC with @RolesAllowed can be tested.

With Keycloak Authorization, it can't work at the default realm level, because it does not depend on @RolesAllowed but on path specific policies, which in case of dev services, would require something like

quarkus.keycloak.devservices.authorization.paths.user=/api/users/me
quarkus.keycloak.devservices.authorization.paths.admin=/api/admin

But it is not how these policies are configured in prod, and it would require users typing those mappings, which would defeat the purpose of the easy to start testing.

I was thinking for a minute that maybe it would be great if DevUI could offer a way to configure Keycloak Authorization - but it would be complex to achieve and Keycloak itself has it all supported, it is all only a single click away from Dev UI - users click on Keycloak Admin