[keycloak-user] Patterns in Resource URI's

[Pedro Igor Silva]

On Fri, May 25, 2018 at 11:37 AM, Juan José Vázquez Delgado <
juanjo.vazquez.delgado at tecsisa.com> wrote:

> Got it. In fact, I've just seen a test that shows how to push these claims
> in the context of an UMA interchange flow [1]. I think this is the case
> you're talking about. I'll explore these solutions. Thank you so much for
> your help!.
>

Yeah, it is.


>
> BTW, it seems that something it's wrong with the Admin API documentation
> endpoint [2].
>

Thanks for the heads up.


>
> [1] https://github.com/keycloak/keycloak/blob/
> e960642399f0f135faa59ba30c3f7b5cc7f2a3c7/testsuite/
> integration-arquillian/tests/base/src/test/java/org/
> keycloak/testsuite/authz/UmaPermissionTicketPushedClaimsTest.java
> [2] https://www.keycloak.org/docs-api/4.0/rest-api/index.html
>
> El vie., 25 may. 2018 a las 16:21, Pedro Igor Silva (<psilva at redhat.com>)
> escribió:
>
>> On Fri, May 25, 2018 at 10:59 AM, Juan José Vázquez Delgado <
>> juanjo.vazquez.delgado at tecsisa.com> wrote:
>>
>>> It might work indeed, but the thing is that I'm not using the
>>> out-of-the-box policy enforcers as we don't have a JavaEE or Spring
>>> architecture. Our solution is based on Scala, Akka and Play so our plan is
>>> just to take advantage of the Rest API's and probably to tailor our own
>>> policy enforcers. In fact, we might share part of this work if this makes
>>> sense.
>>>
>>> So, I suppose that the solution you propose is still valid even though
>>> we'd probably need to re-implement the logic that extracts and provides the
>>> additional claims that should be available during the authorization
>>> process. After that, we'd provide this contextual information through the
>>> `claim_token` parameter as it's described in documentation here [1]. Is
>>> this assumption correct?. Please, excuse me if the question might be naive
>>> but I'm still learning the KC nuances. Excellent tool and work BTW.
>>>
>>> [1] https://www.keycloak.org/docs/latest/authorization_services/
>>> index.html#_service_obtaining_permissions
>>>
>>
>> It depens on how you are obtaining permissions from the token endpoint.
>> You can use `claim_token` in case you are not using UMA thus not sending
>> tickets. In this case, the resource server just need to build a JSON
>> (key-values) and Base64 encode it.
>>
>> If using UMA you can also send these claims as part of the permission
>> request (permission endpoint).
>>
>> We need to write more examples and doc around this. Will work on that
>> before going into Final.
>>
>>
>>>
>>> El vie., 25 may. 2018 a las 14:44, Pedro Igor Silva (<psilva at redhat.com>)
>>> escribió:
>>>
>>>> Hi Juan,
>>>>
>>>> Recently, we have added support for Claim Information Points [1].
>>>> Basically, these are component on the policy enforcer side that can be
>>>> configured to send additional claims to your policies. They allow you to
>>>> extract different information from the request as well from the access
>>>> token.
>>>>
>>>> Would that work for you ?
>>>>
>>>> [1] https://www.keycloak.org/docs/latest/authorization_
>>>> services/index.html#_enforcer_claim_information_point
>>>>
>>>> On Thu, May 24, 2018 at 7:51 PM, Juan José Vázquez Delgado <
>>>> juanjo.vazquez.delgado at tecsisa.com> wrote:
>>>>
>>>>> Hello everyone. I'm currently assessing KC Authz services and I
>>>>> stumbled
>>>>> across a use case that I'm not sure how to solve. I've found previous
>>>>> similar discussions but I couldn't find the answer that might apply
>>>>> directly to it. Basically, I have a web service that acts as resource
>>>>> server, following the UMA terminology, and I want to protect it using
>>>>> KC.
>>>>> This ws publishes several endpoints that follow a multi-tenant
>>>>> arrangement.
>>>>> Something like this:
>>>>>
>>>>> /{org_id}/products
>>>>> /{org_id}/product/{id}
>>>>> ...
>>>>> etc
>>>>>
>>>>> The ID Token obtained through the authentication OIDC flow carries the
>>>>> `org_id` data so I could provide this as additional claim to the token
>>>>> endpoint in order to get a proper RPT. However, I would like not to
>>>>> have to
>>>>> create a different resource per organization and uri, but just the same
>>>>> patterns as in the endpoints:
>>>>>
>>>>> /{org_id}/products
>>>>> /{org_id}/product/{id}
>>>>>
>>>>> I haven't found any information about whether it's possible to define a
>>>>> pattern also in the resource uri so that I can use it from the
>>>>> Evaluation
>>>>> API during the RPT issuance. I'm sure I'm missing something relevant
>>>>> here,
>>>>> but so far I couldn't find other solution than creating as many
>>>>> resources
>>>>> as organizations exist and that could be a maintanance burden in the
>>>>> future. Maybe it's just as simple as parsing the resource name, in JS
>>>>> or
>>>>> Drools Rules, in order to retrieve the `org_id` from the resource name.
>>>>>
>>>>> Any help would be appreciated. Thanks!.
>>>>>
>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>> --
>>>
>>> Juan José Vázquez Delgado
>>>
>>> CTO
>>>
>>> Tecsisa
>>>
>>> C/Quintanavides, 19
>>> <https://maps.google.com/?q=C/Quintanavides,+19&entry=gmail&source=g>
>>>
>>> Parque Vía Norte
>>>
>>> Edificio 4, Planta 3, Oficina H
>>>
>>> 28050 Madrid
>>>
>>> T: +34 91 182 04 70 <+34%20911%2082%2004%2070>
>>>
>>> F: +34 91 447 05 11 <+34%20914%2047%2005%2011>
>>>
>>> E: juanjo.vazquez.delgado at tecsisa.com
>>>
>>> W: www.tecsisa.com
>>>
>>