[keycloak-dev] Pushing Claims from Policy Enforcer

[Bill Burke]

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 at redhat.com> 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 at redhat.com> 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 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
>>
>
>


-- 
Bill Burke
Red Hat