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