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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

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(a)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(a)tecsisa.com&gt; 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(a)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... 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(a)tecsisa.com W: www.tecsisa.com

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(a)redhat.com>) escribió: > On Fri, May 25, 2018 at 10:59 AM, Juan José Vázquez Delgado < > juanjo.vazquez.delgado(a)tecsisa.com&gt; 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(a)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(a)tecsisa.com&gt; 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(a)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... >> >> 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(a)tecsisa.com >> >> W: www.tecsisa.com >> >