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