Well, yes.. I told you it was a bit rubbish and would need some re-design to implement
more fine grained permissions. Doing that is a relatively big task and is not a high
priority for us ATM.
I'm a bit confused by this email as I proposed a simple solution that would resolve
your requirements. If an admin can only grant permissions that admin has access to all you
have to do is to create an admin that can only access roles for certain applications and
your problem should be solved. That's a simple solution that we can add soon.
----- Original Message -----
From: "Thiago Presa" <thiago.addevico(a)gmail.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Sent: Thursday, 26 March, 2015 8:10:07 PM
Subject: Re: [keycloak-user] Application Management
So I've spent the last couple of days playing with the source. :-)
The current authorization mechanism is based on Realm/RealmApp i.e.
whenever an API resource is called, check if the User has the required
Right (manage, any, view) in the resource's Realm/RealmApp.
Consider, for example, the URI
/admin/realms/{realm}/applications-by-id/{app-name}/roles/{role-name}. What
I was trying to do is to create a permission for {app-name} so that this
API call wouldn't require any Realm/RealmApp right.
The problem I see is that this API call trigger many methods (i.e.
AdminRoot#getRealmsAdmin, RealmsAdminResource#getRealmAdmin,
RealmAdminResource#getApplicationsById, and so on...), and at those methods
there is not enough information to figure out whether this is:
1- An app-specific call and thus should be authorized even without realm
authorization, or;
2- Not app-specific call and this should be properly authorized by
Realm/RealmApp.
Even in the case of (1), the information on which app should I check for
authorization is not available.
So it seems to me that this resource-loading mechanisms pressuposes an
authorization mechanism that checks only against the realm for permission,
and changing this seems daunting to me.
Do you guys have any idea on a more local change I could make to achieve
the intended behavior?
On Tue, Mar 24, 2015 at 2:33 PM, Thiago Presa <thiago.addevico(a)gmail.com>
wrote:
> OK, agreed. We thought this out of consistency, but if that's not a good
> design we surely can consider a better one.
>
> On Tue, Mar 24, 2015 at 9:44 AM, Stian Thorgersen <stian(a)redhat.com>
> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Thiago Presa" <thiago.addevico(a)gmail.com>
>> > To: stian(a)redhat.com
>> > Cc: keycloak-user(a)lists.jboss.org
>> > Sent: Tuesday, 24 March, 2015 1:41:16 PM
>> > Subject: Re: [keycloak-user] Application Management
>> >
>> > Hi there,
>> >
>> > I'm Alex's coworker and I'll be working on this too.
>> >
>> > We were just discussing your idea, and it seems to fit our requirements.
>> >
>> > As far as we have seen, keycloak already has a realm-admin concept.
>> > Whenever a realm "R" is created, it creates a R-realm application
with
>> > a bunch of default roles (manage-users, manage-roles, etc.) into the
>> > realm master.
>> >
>> > We are currently thinking if we could mimic this structure for
>> > applications. What do you think?
>>
>> It's already messy with the way I modelled it and adding the same for
>> applications would be even worse. I don't see why that's needed though
if
>> we'd add what I proposed.
>>
>> >
>> > > I had an idea a while back that is a simple way to achieve what
you're
>> > > asking for. Th> e idea would be to only allow an admin to grant
roles
>> that
>> > > the admin has access to.
>> >
>> > > Basically:> * A user with admin (super user) role can grant any
roles
>> (we
>> > > would need to add a per-> realm super user role)
>> >
>> > > * A user with the role manage-users and some roles on app1 can only
>> grant
>> > > other users > the roles on app1
>> >
>> > > * A user with the role manage-users and some roles on app2 can only
>> grant
>> > > other users > the roles on app2
>> >
>> > >
>> >
>> > > This is something we should add in either case (to prevent users
>> granting
>> > themselves more access). Would it solve your problems?
>> >
>>
>
>