[keycloak-dev] management problems

[Bill Burke]

On 5/5/2014 1:56 PM, Marek Posolda wrote:
> On 5.5.2014 18:22, Bill Burke wrote:
>>
>>
>> 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
> That's something what I was thinking about as well . So members of role
> "realm admin" will be able to perform various administration tasks on
> the realm, right? For example members of role "realm admin" in realm
> "myRealm" will be able to retrieve the list of users, roles or
> applications of realm "myRealm"etc .
>
> But is this the way to go? As you already mentioned, this won't solve
> the problem of SSO between various admin consoles if I understand
> correctly.

This would solve SSO problems.  You'd create your own realm.  Add 
"ups-admin", "LiveOak admin" applications to this realm.  There would be 
a built in "security admin" application for managing access to the 
manage console solely for the realm.

> Also it seems to be a bit strange that KC admin console can
> be used by users from various realms. This will require quite big
> refactoring of existing admin console and admin endpoints.
>

Users will only be able to manage the realm they are within.  I don't 
think this would be that big of a refactor.  The auth code is in one 
place.  I just want to make sure it is the right solution which is why 
I'm asking to have a hangout to discuss.

> It seems much easier to keep all admin tasks in "master realm" and have
> very fine-grained authorization as I mentioned earlier. So for example
> member of role "aerogear-admin" will be able to create new users in
> "master realm" and assign them role "aerogear-admin" or
> "aerogear-admin-with-lower-privileges-to-perform-just-subset-of-admin-tasks"
> but he won't be able to see other users in "master realm" (for example
> members of "eap-admins") .
>

Isn't this solution kind of hacky?  Seems to me it would be a more 
disruptive change than what I suggested earlier.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com