[keycloak-user] Application Management

[Leonardo Loch Zanivan]

It would be nice if KeyCloak could share applications across realms in a
SaaS multi-tenant approach. Currently we need to use REST API to syncronize
app definitions.

On Thu, Mar 26, 2015 at 4:10 PM Thiago Presa <thiago.addevico at gmail.com>
wrote:

> 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 at 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 at redhat.com>
>> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>> > From: "Thiago Presa" <thiago.addevico at gmail.com>
>>> > To: stian at redhat.com
>>> > Cc: keycloak-user at 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?
>>> >
>>>
>>
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150326/9bfe9f49/attachment.html