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

[Bill Burke]

On 2/20/2014 12:23 PM, Stian Thorgersen wrote:
>
>
> ----- 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)


Very cool!  let me know if you don't have time to work on it and I'll 
head to that after I do refresh tokens.

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