On 2/20/2014 10:05 AM, Stian Thorgersen wrote:
Currently a user in the 'keycloak-admin' realm with the role
'admin' has full access to all realms. We need to support a bit more fine-grained
access control for admin console/endpoints. At the bare minimum we need to be able to have
users that can administer only some realms. Further, it would be nice to build this on-top
of roles alone and not require an ACL table or something similar.
We could start with the following permissions/roles for a realm:
* view-realm-config
* manage-realm-config
* view-users
* manage-users
* view-applications
* manage-applications
* view-clients
* manage-clients
* admin (composite role containing all the above roles)
One approach to this would be to create an application per-realm that represents that
realm (application name could be 'realm-<realm name>'). This would be
created automatically when we create a new realm, and it would have the above roles as
application roles. Users can then be granted access to individual realms by mapping the
roles for the associated application to them.
We could also have a composite realm role 'admin' that maps to the
'admin' role in all realm applications. Any user that is granted this role would
have full access to all realms.
This made me think about the concept of "resources" in Keycloak. A resource is
similar to an application except it doesn't have scope mappings, nor does it have
credentials. This could be used in the demo for the 'database-service', which
would mean we'd have roles associated with the 'database-service' rather than
using realm roles. It would also provide an installation file (and wildfly config) where
'bearer-only' is set to 'true'.
We need to think of this in terms of OAuth grants. i.e. You have one
Keycloak server that wants to export/migrate metadata from its realm(s)
to another Keycloak server. You have a service like Aerogear UPS where
you want to grant it temporary permission to define applications within
the realm.
This is why I think the best approach would be to create an application
per-realm that represents realm management. The application would just
be named "realm-management", just like we already have for "account".
This way these admin roles to mix or pollute anything user specific. We
would also create an application within the "keycloak-admin" realm with
similar role definitions.
With the above setup, we would have "keycloak-admin" users who would
have various permissions on *ALL* realms. And per realm users that have
permissions for one *specific* realm. But, there would not be a concept
of a user that has permissions on a subset of realms. It could be
access to 1 realm, or access to all realms.
Does LiveOak need the concept of one user being able to edit only a
subset of realms?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com