[keycloak-user] Authorization on resources that belong to different "groups"

[Pedro Igor Silva]

On Fri, Mar 31, 2017 at 4:01 PM, Gabriel Trisca <gtrisca at cignifi.com> wrote:

> Hi Pedro,
>
> Thanks for your reply.
>
> Adding the country to the URI would that mean that I have to create all of
> the resources again for every new country that I add, correct?
>

> Is there any way to avoid duplicating resources where the only thing that
> changes in the URI is the {country}?
>

If what you mean is that you would need to create those resource instances
(e.g.: country 1, country 2, etc) in Keycloak. Yes. Because you want to
protect individual countries, right ?

Maybe a different approach to your API is use a patter like this:

/api/{country}/report
/api/{country}/status
/api/{country}/history

Actually, isn't above more meaningful than use /api/status|report|history ?


>
> Thanks!
>
> On Fri, Mar 31, 2017 at 10:17 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> What about using patterns in your paths. Something like:
>>
>>     /api/report/{country}
>>
>>
>> On Thu, Mar 30, 2017 at 6:59 PM, Gabriel Trisca <gtrisca at cignifi.com>
>> wrote:
>>
>>> HI there,
>>>
>>> We've integrated Keycloak auth and authz to an existing REST service
>>> which
>>> serves endpoints like this:
>>>
>>> GET /api/report?country={country}
>>> GET /api/status?country={country}
>>> GET /api/history?country={country}
>>>
>>> As far as I understand, the only way to protect these resources is to
>>> create "global" resources (/api/report, /api/status etc.), but then we
>>> can't validate if the current user is authorized to make requests for a
>>> given "country":
>>>
>>> The other alternative would be to include the country name in the URI,
>>> but
>>> this would lead to duplication of resource definitions:
>>>
>>> /api/report/country1
>>> /api/report/country2
>>> /api/status/country1
>>> /api/status/country2
>>> ...
>>>
>>> We considered including a list of the countries the user has access to as
>>> an attribute in the access_token but that would require manually
>>> maintaining said attribute
>>>
>>> Is there another way that would accommodate this kind of authentication
>>> requirements?
>>>
>>> Thanks in advance!
>>>
>>> --
>>> *Gabriel Trisca, Software Developer*
>>> Cignifi | 101 Main Street, 14th Floor, Cambridge, MA 02142  USA
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>
>
> --
> *Gabriel Trisca, Software Developer*
> Cignifi | 101 Main Street, 14th Floor, Cambridge, MA 02142  USA
> P: +1 857-209-2685 <(857)%20209-2685> • M: +1 301-433-2221
> <(301)%20433-2221> | www.cignifi.com
>