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

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; >>> To: keycloak-dev(a)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)