[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 7:25:24 PM
> Subject: Re: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
> 
> 
> 
> 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.

I thought you where adding the complete OpenID connect spec ;)

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