[keycloak-dev] management problems

[Stian Thorgersen]

+1 To a Hangout - today would be good for me

There was a public holiday in the UK yesterday, hence I was out for a bike ride with the kids instead of thinking about realms ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 5 May, 2014 11:46:54 PM
> Subject: Re: [keycloak-dev] management problems
> 
> 
> 
> 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
>