[policy-charter] PEP-PDP Group

Tue Jun 13 20:18:42 UTC 2023

Hi there,

may be this is a good chance to share a (very basic) API description of 
a PDP I recently made for a ReBAC approach.

Link: https://gist.github.com/tr33/2fbd45a07524e9aa0867d103aa11eb79

Its not much into generalized, but tries to cover the basic aspects of 
request/response scheme between PEP/PDP.
It's also pretty ReBAC-oriented, as one can see from the two "update" 
and "delete" interfaces.

The intent was to design a useful but simple communication scheme 
between PEP (application) and PDP decisions - independent from the 
(ReBAC oriented) backend used by the PDP (which is OPA, in this case).
Related entities like "Identity" or  "Policy" are yet not covered by the 
scheme, but could be addressed in further versions.

Anyway, hope that helps to get some impressions and good ideas.

feedback welcome!

roland

Am 13.06.23 um 20:45 schrieb Alex Babeanu via policy-charter:
> This is a good discussion, that said a PEP is actually *not* mandated 
> in all cases. For example you would *not* use a PEP to secure GraphQL 
> APIs nor COTS software.
>
> I'm going to share soon a doc, to all contribute on, that lists common 
> authorization design patterns. I think it would be a good basis for 
> discussion, and at least to scope what we're trying to do...
>
> Thanks,
> ./\lex.
>
> On Tue, Jun 13, 2023 at 11:30 AM Allan Foster via policy-charter 
> <policy-charter at lists.openid.net> wrote:
>
>     So I am thinking we also want to set some scope of what we want to
>     cover?
>
>     Off the top of my head….   I can put some more context around
>     these if they aren’t clear
>
>     The Transport layer
>
>     The Envelope Layer
>
>     The request/response transaction layer
>
>     How meta-data is handled?  (both request and response)
>
>     Extension mechanisms
>
>     Exception mechanism
>
>     Allan
>
>     *From: *policy-charter <policy-charter-bounces at lists.openid.net>
>     on behalf of Omri Gazitt via policy-charter
>     <policy-charter at lists.openid.net>
>     *Date: *Tuesday, June 13, 2023 at 10:54
>     *To: *Policy Charter Mail List <policy-charter at lists.openid.net>
>     *Cc: *Omri Gazitt <omri at aserto.com>
>     *Subject: *Re: [policy-charter] PEP-PDP Group
>
>     I agree with David that looking at existing systems is a good
>     place to start. If the idea is that PDPs can add a "standard" API
>     that PEPs can call, then it would be good if the API supports the
>     existing message exchange patterns (and doesn't mandate things
>     that aren't supported).
>
>     Here are three examples, to get us started:
>
>       * OPA is interesting in the sense that its primary REST API is
>         very document-oriented - you have a set of rules that are
>         defined in a JSON-style hierarchy and you issue a GET or POST
>         on that resource in the hierarchy to evaluate the rule that is
>         rooted there. This seems like a special case. OPA does have a
>         generic query
>         <https://www.openpolicyagent.org/docs/latest/rest-api/#execute-an-ad-hoc-query>
>         API, which allows you to pass input and evaluate a rego query
>         based on the loaded policy document and the input.
>       * Auth0 FGA (one of the zanzibar implementations) has a check
>         <https://www.openpolicyagent.org/docs/latest/rest-api/#execute-an-ad-hoc-query> API
>         that takes a JSON payload containing a user key, relation
>         name, and object key, and returns an allowed decision (true or
>         false). Most zanzibar implementations seem to do something
>         similar - e.g. SpiceDB has a check
>         <https://www.postman.com/authzed/workspace/spicedb/documentation/21043612-9786e5f3-2014-4b31-86c1-39335236c0e2?entity=request-c58c40ff-9fc7-4c3e-9cca-f017160ba5b8>
>         API that takes a resource, permission, and subject.
>       * Topaz (Aserto's OSS authorizer) has a query
>         <https://aserto.readme.io/reference/authorizerquery-1> API
>         that takes an identity and policy (rule/decisions to
>         evaluate), and optionally a resource context and additional
>         input, and returns what OPA would return. It also has a
>         simpler is <https://aserto.readme.io/reference/authorizeris-1>
>         API that evaluates a policy (rule/decisions) with an identity
>         and resource context.
>
>     On Tue, Jun 13, 2023 at 1:54 AM Roland Baum via policy-charter
>     <policy-charter at lists.openid.net> wrote:
>
>         I'm in as well :-D
>
>
>
>         Roland Baum
>         umbrella.associates GmbH
>
>
>         -- 
>         policy-charter mailing list
>         policy-charter at lists.openid.net
>         https://lists.openid.net/mailman/listinfo/policy-charter
>
>     -- 
>     policy-charter mailing list
>     policy-charter at lists.openid.net
>     https://lists.openid.net/mailman/listinfo/policy-charter
>
>
>
> -- 
> This is Alexandre Babeanu's card. Their email is alex at 3edges.com. 
> Their phone number is +1 604 728 8130. 
> <https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments 
> hereto, is for the sole use of the intended recipient(s) and may 
> contain confidential and/or proprietary information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230613/650bce36/attachment.html>