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(a)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(a)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(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
>>>
>>
>>
>
>
> --
> Bill Burke
> Red Hat
>