[keycloak-user] Patterns in Resource URI's

[Juan José Vázquez Delgado]

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!.

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

[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
>>
>