[keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 4:54:28 PM
> Subject: Re: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
> 
> 
> 
> On 2/20/2014 11:21 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 20 February, 2014 4:06:37 PM
> >> Subject: Re: [keycloak-dev] Authz for admin console/endpoints
> >> (KEYCLOAK-292)
> >>
> >>
> >>
> >> 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.
> >
> > I don't see how what I proposed doesn't work with OAuth grants.
> >
> >>
> >> 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.
> >
> > This sounds messy to me. It means you end up with having to manage access
> > to a realm in two different realms. Also, for admin console you'd have to
> > have an option of selecting what realm to login to. Anyone that is only
> > given access to one or two realms would have to re-login to swap or
> > something.
> >
> 
> I was actually agreeing with your original post, but I don't think I
> fully understood your original post! I might understand now.  Is this
> what you mean?
> 
> * Create an application within "keycloak-admin" for each new realm
> * Under that application create all the roles mentioned in the OP.
> * Create a realm level composite role named "superuser".  When a new
> realm is created, associate all those new application roles to this
> superuser composite.
> 
> Then, when you log into the admin console, the server just checks which
> roles you have assigned to you to fill the realm selection box on the
> admin console main page.

Yes, emails can be confusing sometimes ;)

Just to be 100% sure, I'll do an example (should have done this in the first place):

* There's 3 realms: 'keycloak-admin', 'realm-a' and 'realm-b'
* Inside 'keycloak-admin' there's apps 'realm-a-management' and 'realm-b-management' (these are created/deleted as realms are created/deleted)
* Each of 'realm-a-management' and 'realm-b-mananagement' have roles 'view-realm', 'manage-realm', etc.. There's also have an app composite role 'realm-admin' that maps to all the other roles in the app (again these roles are created when a realm is created)
* The 'keycloak-admin' has a single composite role 'realms-admin' that maps to 'realm-admin' roles in both 'realm-a-management' and 'realm-b-management' (again this is updated has realms are created/deleted)

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