----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
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>
>> 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)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com