[keycloak-user] Patterns in Resource URI's

Juan José Vázquez Delgado juanjo.vazquez.delgado at tecsisa.com
Fri May 25 09:59:35 EDT 2018


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

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

Parque Vía Norte

Edificio 4, Planta 3, Oficina H

28050 Madrid

T: +34 91 182 04 70

F: +34 91 447 05 11

E: juanjo.vazquez.delgado at tecsisa.com

W: www.tecsisa.com


More information about the keycloak-user mailing list