[keycloak-dev] Pushing Claims from Policy Enforcer

[Pedro Igor Silva]

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
>