[keycloak-user] authorization in a hierarchical context

[Pedro Igor Silva]

On Mon, Jan 2, 2017 at 2:40 PM, Avinash Kundaliya <avinash at avinash.com.np>
wrote:

> Hello,
> I see, is it something in the UMA spec that says about resource hierarchy
> or we don't have on the server for other reasons?
> Regarding the API path, it partially matches the hierarchy but not always,
> that is why I don't want to enforce it with the URI. For example in the
> case of animals we have an /api/animal/{animal_id}
> Is there any other approach you'd suggest?
>
>
AFAIK, there is nothing in UMA spec about hierarchy of resources.

Regarding a different approach, use the path to enforce permissions to an
hierarchy was my best shot.


> Also, there is a role of a herder, who has nothing to do with the
> hierarchy but only related to the animal. Eg: a herder of cows or a herder
> of sheeps.
>
> I can add a role of herder in keycloak and probably add the animal_type to
> the user as a custom attribute, is it possible to register resource_sets
> with attributes, like animal type in case of the animal resource.
>

Resources do have a type, maybe you can use this property to set
animal_type. We don't have support for custom resource attributes though.
However that is something I think we should start supporting in Keycloak.
Maybe custom attributes could help you with the hierarchy problem too.

Would it work for you ?


>
> Is there a book/resource that you could suggest to read more about
> authorization patterns? I have already read along the keycloak guides.
>

Nothing specific as authorization is usually very specific to a domain.
However, I usually like to search for ABAC related material as they usually
provide additional information and patterns that helps to design more
flexible authorization systems. OWASP also provides some great material
around security in general.


>
> Regards,
> Avinash
>
> On Mon, Jan 2, 2017 at 10:12 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Hi,
>>
>> We don't support resource hierarchy on the server so you won`t be able to
>> model your resources as you described. And as you mentioned, I`m not sure
>> either if this is something we want/need to enable on the server.
>>
>> In theory, if your API is using a path/uri layout that allows you to
>> identify this hierarchy, I think you should be able to achieve what you
>> want. For instance, suppose you have:
>>
>> /api/farm/{farm_id}
>> /api/farm/{farm_id}/group/{group_id}
>> /api/farm/{farm_id}/group/{group_id}/animal/{animal_id}
>>
>> And every time you create one of the resources above (farms, groups or
>> animals) you associate a path such as you replace the the patterns above
>> with the identifier of the resource. That PhotoZ example does pretty much
>> the same thing, where resources are protected by using a pattern like
>> /album/{id}. But there we only use a single pattern in a path.
>>
>> I'm just not sure if our policy enforcer is capable of dealing with
>> multiple patterns in a single path. Probably not and probably a bug :)
>>
>> Regards.
>> Pedro Igor
>>
>> On Mon, Jan 2, 2017 at 1:47 PM, Avinash Kundaliya <avinash at avinash.com.np
>> > wrote:
>>
>> Hello,
>>
>> I have a question more related to the architecture of an application and
>> if/how keycloak would fit to it.
>>
>> The context is I have a hierarchy of resources (There is a Farm
>> resource, and the farm has many groups and a group has many animals). I
>> want the farm user to have access to everything below it (i.e group and
>> animals) and the group user to all the animals.
>>
>> The easiest way to do this is by doing the authorization in the resource
>> server (i.e if the token contains a farm_owner resource, and if the
>> resource is and animal owned by a group that the farm owns, then the
>> owner gets access to it). But, this somehow feels wrong, as i would like
>> to model this authorization policy (if i may call it) in the auth
>> server/keycloak.
>>
>> I have been looking at UMA recently as it somehow seems closest to what
>> I want to achieve. But, in UMA, i can only model the owner relation, but
>> not the hierarchy of it. Thus, I am not so clear on how to model such
>> relations using that as well. Probably, its not a good idea to model
>> this in the auth server.
>>
>> It would be great if there is some mechanism within keycloak to model
>> such relations or authorization structures. As of now, we do plan to use
>> keycloak for authentication and possibly, pass roles if any would make
>> sense.
>>
>> Thanks for the help in advance, and I hope I have been able to explain
>> my issue clearly.
>>
>> Regards,
>> Avinash
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>