1:26 p.m.
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/browse/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