Hi Lars,
Good question. My organization is
also asking similar questions about adopting Keycloak. Let me
give my understanding as a user, then Keycloak team can
correct my misunderstandings.
Basically, Keycloak offers
coarse-grained authorizations (
realm-roles and client-app
roles) assigned to users (or
groups). So I understand Keycloak will
let you grant user Bob the 'myapp-admin' role. However, it
falls to the backend service or application to then map that
role to application-specific permissions. For example, role
'myapp-admins' can access /myapp/project1/admin page. This
resource security can be done (for Java apps) in declarative
fashion using web.xml security constraints. Alternatively,
your application code could dynamically obtain the Keycloak
user principal, check their roles, and map into your app's
permission scheme.
This understanding implies that
your application is responsible for an admin UI to map
fine-grained permissions on your app's resources to Keycloak
roles. If your app only has 'coarse-grained" resources, then
you can probably just use Keycloak roles, with no need for a
permission layer or the UI it entails.
Hope this helps,
Guy
<sorry, original response was
only to Lars, now to list as well>