[keycloak-dev] Pushing Claims from Policy Enforcer

[Bill Burke]

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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>
>


-- 
Bill Burke
Red Hat