[keycloak-dev] Pushing Claims from Policy Enforcer

[Pedro Igor Silva]

On Fri, Apr 13, 2018 at 10:18 AM, Bill Burke <bburke at redhat.com> wrote:

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

Team cloud is looking the client proxy and I think (someone correct me if I
wrong) we probably going to use it as a sidecar. So we won't have to worry
about C++ and Envoy.


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