I dont' understand...Why do you need an plugin SPI for this? Wouldn't the developer just call into your api to create the invocation to the permission endpoint? On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Hi, > > I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903. > > This is all about allowing applications to push arbitrary claims to > Keycloak prior to evaluating permissions on the server. A simple example to > illustrate the idea: a request arrives you extract what you want from there > (parameters, headers, etc) and "push" the information from the request as > claims in order to evaluate your permissions. > > There are endless possibilities on what you can push and how. > > >From a design perspective, I was thinking about providing a SPI on the > adapter side (as simple as using ServiceLoader) to load built-in and > user-defined "claim information points". Examples of built-in > implementations would be: > > * Extract parameters > * Extract headers > * Extract path parameters > * Extract cookies > * Invoke an external "policy information point" > > What do you think ? > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat

Wouldn't a more generic hook be better. One that allowed people to add whatever they wanted to the attributes being pushed? Rather than having all this composition login within json? Not saying I'm right and you are wrong, just wondering if it would be better? On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > If you are using the API directly, yes, you don't need this SPI ... > > But when using our policy enforcer (embedded within our adapters) > developers don't actually use our API to call the permission endpoint. This > is done by the policy enforcer itself, internally. The SPI is mainly > targeted for applications using our adapters. > > The SPI serves for two purposes: > > 1) Allow developers to customize permission requests and push arbitrary > claims to the permission endpoint (extension point) > 2) Serve as the backbone for built-in "Claim Information Points", > provided by us OOTB. > > As an example, here is how a configuration should looks like: > > "claim-information-point": [ > >     "claims": { > >         "claim-a": "{request.parameter['abc']}" > >      }, > > "http-service": { > > "url": "abc" > > } > > ] > > "Claim Information Point" is pretty much the same thing as a Policy > Information Point. Each CIP Provider provides its own way to define claims > to a permission request. In the example above, you are "pushing" a > "claim-a" to your policies where the value would be a request parameter > "abc". > > Makes more sense now ? > > > On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> I dont' understand...Why do you need an plugin SPI for this? Wouldn't >> the developer just call into your api to create the invocation to the >> permission endpoint? >> >> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> > Hi, >> > >> > I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903 >> . >> > >> > This is all about allowing applications to push arbitrary claims to >> > Keycloak prior to evaluating permissions on the server. A simple >> example to >> > illustrate the idea: a request arrives you extract what you want from >> there >> > (parameters, headers, etc) and "push" the information from the request >> as >> > claims in order to evaluate your permissions. >> > >> > There are endless possibilities on what you can push and how. >> > >> > >From a design perspective, I was thinking about providing a SPI on the >> > adapter side (as simple as using ServiceLoader) to load built-in and >> > user-defined "claim information points". Examples of built-in >> > implementations would be: >> > >> > * Extract parameters >> > * Extract headers >> > * Extract path parameters >> > * Extract cookies >> > * Invoke an external "policy information point" >> > >> > What do you think ? >> > >> > Regards. >> > Pedro Igor >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> Bill Burke >> Red Hat >> > > -- Bill Burke Red Hat

How are your golang skills? We're going to need all this stuff in the proxy :) Don't know if you were in the meeting today... On Fri, Apr 6, 2018 at 11:37 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Yeah, it is. And the SPI provides that. That is only what we provide OOTB > so you don't need to implement boiler plate code. But yeah, you can always > use a hook to add whatever you want. > > FYI, some of these requirements (specially the OOTB config) was gathered > from a customer. > > On Fri, Apr 6, 2018 at 11:51 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> Wouldn't a more generic hook be better. One that allowed people to add >> whatever they wanted to the attributes being pushed? Rather than having >> all this composition login within json? Not saying I'm right and you are >> wrong, just wondering if it would be better? >> >> On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> If you are using the API directly, yes, you don't need this SPI ... >>> >>> But when using our policy enforcer (embedded within our adapters) >>> developers don't actually use our API to call the permission endpoint. This >>> is done by the policy enforcer itself, internally. The SPI is mainly >>> targeted for applications using our adapters. >>> >>> The SPI serves for two purposes: >>> >>> 1) Allow developers to customize permission requests and push arbitrary >>> claims to the permission endpoint (extension point) >>> 2) Serve as the backbone for built-in "Claim Information Points", >>> provided by us OOTB. >>> >>> As an example, here is how a configuration should looks like: >>> >>> "claim-information-point": [ >>> >>>     "claims": { >>> >>>         "claim-a": "{request.parameter['abc']}" >>> >>>      }, >>> >>> "http-service": { >>> >>> "url": "abc" >>> >>> } >>> >>> ] >>> >>> "Claim Information Point" is pretty much the same thing as a Policy >>> Information Point. Each CIP Provider provides its own way to define claims >>> to a permission request. In the example above, you are "pushing" a >>> "claim-a" to your policies where the value would be a request parameter >>> "abc". >>> >>> Makes more sense now ? >>> >>> >>> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> I dont' understand...Why do you need an plugin SPI for this? Wouldn't >>>> the developer just call into your api to create the invocation to the >>>> permission endpoint? >>>> >>>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> > Hi, >>>> > >>>> > I'm currently working on https://issues.jboss.org/brows >>>> e/KEYCLOAK-4903. >>>> > >>>> > This is all about allowing applications to push arbitrary claims to >>>> > Keycloak prior to evaluating permissions on the server. A simple >>>> example to >>>> > illustrate the idea: a request arrives you extract what you want >>>> from there >>>> > (parameters, headers, etc) and "push" the information from the >>>> request as >>>> > claims in order to evaluate your permissions. >>>> > >>>> > There are endless possibilities on what you can push and how. >>>> > >>>> > >From a design perspective, I was thinking about providing a SPI on >>>> the >>>> > adapter side (as simple as using ServiceLoader) to load built-in and >>>> > user-defined "claim information points". Examples of built-in >>>> > implementations would be: >>>> > >>>> > * Extract parameters >>>> > * Extract headers >>>> > * Extract path parameters >>>> > * Extract cookies >>>> > * Invoke an external "policy information point" >>>> > >>>> > What do you think ? >>>> > >>>> > Regards. >>>> > Pedro Igor >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> >>> >>> >> >> >> -- >> Bill Burke >> Red Hat >> > > -- Bill Burke Red Hat

I'm just brainstorming here and this probably should be under a different topic, but: I'm a bit concerned about putting all our eggs in the Istio basket. The first concern is it might have to be C++, although the APIs I looked at were all Golang. 2nd the Golang APIs looked like they didn't have the concept of an HTTP session.

On Fri, Apr 13, 2018 at 8:23 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Yeah, I missed the meeting. But I have looked the slides and, yeah, we > are going to need our authz stuff there .... > > In fact, I hope to start working more with team-cloud team and see how we > can improve authorization experience for cloud native applications. The > proxy will be a great start as well how we can leverage Istio/sidecars to > enable authz. > > There is an open issue on for that proxy [1] around authorization using > Cabin. Feature wise we support the same thing but using a different model, > more integrated with Keycloak (of course) . Our use cases go beyond REST > security (which have improved a lot in Sprint 4) and also cover privacy, > with UMA. > > Hope I can get some tips from you about go when I start this :) > > [1] https://github.com/gambol99/keycloak-proxy > > On Thu, Apr 12, 2018 at 7:06 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> How are your golang skills? We're going to need all this stuff in the >> proxy :) Don't know if you were in the meeting today... >> >> On Fri, Apr 6, 2018 at 11:37 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> Yeah, it is. And the SPI provides that. That is only what we provide >>> OOTB so you don't need to implement boiler plate code. But yeah, you can >>> always use a hook to add whatever you want. >>> >>> FYI, some of these requirements (specially the OOTB config) was >>> gathered from a customer. >>> >>> On Fri, Apr 6, 2018 at 11:51 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> Wouldn't a more generic hook be better. One that allowed people to >>>> add whatever they wanted to the attributes being pushed? Rather than >>>> having all this composition login within json? Not saying I'm right and >>>> you are wrong, just wondering if it would be better? >>>> >>>> On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> If you are using the API directly, yes, you don't need this SPI ... >>>>> >>>>> But when using our policy enforcer (embedded within our adapters) >>>>> developers don't actually use our API to call the permission endpoint. This >>>>> is done by the policy enforcer itself, internally. The SPI is mainly >>>>> targeted for applications using our adapters. >>>>> >>>>> The SPI serves for two purposes: >>>>> >>>>> 1) Allow developers to customize permission requests and push >>>>> arbitrary claims to the permission endpoint (extension point) >>>>> 2) Serve as the backbone for built-in "Claim Information Points", >>>>> provided by us OOTB. >>>>> >>>>> As an example, here is how a configuration should looks like: >>>>> >>>>> "claim-information-point": [ >>>>> >>>>>     "claims": { >>>>> >>>>>         "claim-a": "{request.parameter['abc']}" >>>>> >>>>>      }, >>>>> >>>>> "http-service": { >>>>> >>>>> "url": "abc" >>>>> >>>>> } >>>>> >>>>> ] >>>>> >>>>> "Claim Information Point" is pretty much the same thing as a Policy >>>>> Information Point. Each CIP Provider provides its own way to define claims >>>>> to a permission request. In the example above, you are "pushing" a >>>>> "claim-a" to your policies where the value would be a request parameter >>>>> "abc". >>>>> >>>>> Makes more sense now ? >>>>> >>>>> >>>>> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> I dont' understand...Why do you need an plugin SPI for this? >>>>>> Wouldn't >>>>>> the developer just call into your api to create the invocation to the >>>>>> permission endpoint? >>>>>> >>>>>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > I'm currently working on https://issues.jboss.org/brows >>>>>> e/KEYCLOAK-4903. >>>>>> > >>>>>> > This is all about allowing applications to push arbitrary claims to >>>>>> > Keycloak prior to evaluating permissions on the server. A simple >>>>>> example to >>>>>> > illustrate the idea: a request arrives you extract what you want >>>>>> from there >>>>>> > (parameters, headers, etc) and "push" the information from the >>>>>> request as >>>>>> > claims in order to evaluate your permissions. >>>>>> > >>>>>> > There are endless possibilities on what you can push and how. >>>>>> > >>>>>> > >From a design perspective, I was thinking about providing a SPI >>>>>> on the >>>>>> > adapter side (as simple as using ServiceLoader) to load built-in >>>>>> and >>>>>> > user-defined "claim information points". Examples of built-in >>>>>> > implementations would be: >>>>>> > >>>>>> > * Extract parameters >>>>>> > * Extract headers >>>>>> > * Extract path parameters >>>>>> > * Extract cookies >>>>>> > * Invoke an external "policy information point" >>>>>> > >>>>>> > What do you think ? >>>>>> > >>>>>> > Regards. >>>>>> > Pedro Igor >>>>>> > _______________________________________________ >>>>>> > keycloak-dev mailing list >>>>>> > keycloak-dev(a)lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Bill Burke >>>>>> Red Hat >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> >>> >>> >> >> >> -- >> Bill Burke >> Red Hat >> > > -- Bill Burke Red Hat

Sounds like a nice addition to me. I pressume the RPT endpoint already has support for the server-side part? On 5 April 2018 at 16:41, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Hi, > > I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903. > > This is all about allowing applications to push arbitrary claims to > Keycloak prior to evaluating permissions on the server. A simple example > to > illustrate the idea: a request arrives you extract what you want from > there > (parameters, headers, etc) and "push" the information from the request as > claims in order to evaluate your permissions. > > There are endless possibilities on what you can push and how. > > >From a design perspective, I was thinking about providing a SPI on the > adapter side (as simple as using ServiceLoader) to load built-in and > user-defined "claim information points". Examples of built-in > implementations would be: > > * Extract parameters > * Extract headers > * Extract path parameters > * Extract cookies > * Invoke an external "policy information point" > > What do you think ? > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >