On 5/5/2014 3:33 AM, Marek Posolda wrote:
The problem is that just admin realm (or "master realm" or
whatever it
will be called) is able to retrieve list of users, applications etc.
with KC admin endpoints.
Maybe it's possible to expose endpoints for some users of realm itself
(So for example users with role "admin" of realm "myRealm" will be
able
to retrieve list of users of this realm). But this won't solve the
problem with SSO login though. If I want my administrator to have SSO
between Keycloak admin console, Liveoak admin console and Aerogear admin
console, then all these admin consoles must use same realm actually...
Yes. LIveoak, Aerogear, keycloak admin console will have to e the same
realm. The problem is that this realm has to be the "master" realm,
otherwise keycloak can't be part of SSO. Which is unworkable in a
multi-tenant server that is managing different realms for different
organizations.
So it seems that the best is if all admin users will still use the
"master realm" but there will be fine-grained authorization, which will
allow to properly isolate various admin users.
Example:
- I want my "master realm" to manage Keycloak, Liveoak and Aerogear
admin consoles.
- So "admin" user, which can do anything, will create roles
"aerogear-admin" and "liveoak-admin" and he will assign role
"aerogear-admin" to user "joe".
- Now "joe" is Aerogear administrator and he wants to grant admin rights
to more users, so he is not alone for all administration tasks. So he
must be able to create new users in "master realm" and grant them role
"aerogear-admin" and also see all other "aerogear-admin" users, but
he
shouldn't be able to see any other users from "master realm" . He
shouldn't be even able to see that "master realm" itself is also used
for liveoak administration...
Why not have a special "realm admin" role that can be assigned in each
realm to a realm user?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com