[policy-charter] PEP-PDP Group

Wed Jun 28 02:07:34 UTC 2023

In my experience, what you call "direct request" is used for making
authorization decisions which are fully specified (subject,
action/relationship/permission, object).

An "indirect request" can be used to filter results, which is a very
adjacent scenario to authorization.

   - In OPA, this can be accomplished by issuing a partial query and
   parsing the resulting AST to construct a restriction clause for the
   resource/data service (e.g. a SQL WHERE clause)
   - In Zanzibar-inspired systems, this can be accomplished by using an
   "expand" API to return all the objects of a certain type which have a
   relationship to the subject, which (again) can be used as a restriction
   clause

Atul's document covers both scenarios (evaluation API and search API).

On Tue, Jun 27, 2023 at 11:43 AM Pieter Kasselman via policy-charter <
policy-charter at lists.openid.net> wrote:

> Hi David, the difference between the direct and indirect requests are
> interesting. The Direct request feels like a  request for a decision while
> the indirect request feels like policy retrieval (with some parameters to
> scope retrieval of policies as it relate to Alice and claims). Can you
> describe the use cases for when the direct vs when the indirect approach is
> used?
>
>
>
> *From:* policy-charter <policy-charter-bounces at lists.openid.net> *On
> Behalf Of *David Brossard via policy-charter
> *Sent:* Tuesday, June 27, 2023 4:17 PM
> *To:* Policy Charter Mail List <policy-charter at lists.openid.net>
> *Cc:* David Brossard <david.brossard at gmail.com>
> *Subject:* Re: [policy-charter] PEP-PDP Group
>
>
>
> I agree with Allan. There's another aspect to runtime authZ: it eliminates
> the need to define entitlements up front. It eliminates the need for role,
> permissions, and entitlements engineering, and consequently provisioning
> and de-provisioning.
>
>
>
> This makes me think another area of investigation for this WG is bridging
> the runtime authz world (XACML, OPA...) with the non-runtime authz world
> (OAuth scopes & claims, SCIM entitlements...) AuthZ frameworks should be
> capable of generating dynamic claims that are fed into a token. CAEP could
> be used to update/revoke/enrich such tokens.
>
>
>
> This means we need different ways to query a policy. And perhaps different
> ways to write policies. Let's assume a business authz policy:
>
>
>
>    - *Policy*: Claims processors can approve a claim in their region if
>    the amount claimed is less than the approver's limit.
>    - *Direct request*: Can Alice approve claim #123? (in the background,
>    attribute retrieval is run to figure out who Alice is and what claim 123's
>    region and amount are)
>
>
>    - Answer: Permit/Deny + obligations
>
>
>    - *Indirect request*: tell me what Alice can do on claims
>
>
>    - Answer: approve + claim amount < $500 + region = Moose Jaw.
>
>
>
>
>
> On Wed, Jun 14, 2023 at 8:15 AM Allan Foster via policy-charter <
> policy-charter at lists.openid.net> wrote:
>
>
>
> Alex,  I am not sure I fully agree with your statement!
>
>
>
> Although you might not use a PEP to protect those resources,  There is
> still a reasonable use case to treat the spec as the API and transport for
> those resources to call out to a centralized AuthZ server.
>
>
>
> I think there are at least two use cases for standardization (as we
> discussed at IDentiverse)
>
>
>
> 1.  A standardized interface between PEPs  or agents and the PDP.  This
> would allow de-weaponization of agents, and interoperability at the agent
> level….
>
> 2.  A standardization athe policy level so that IF the PDP cannot be
> centralized, the interop would be at the Policy level.  Enabling the Policy
> Management to be centralized.
>
>
>
> A SaaS might not be willing to call out to a central PDP for AuthZ (and
> all the performance problems that brings) but might well be willing to
> accept the Policy definition into its own AuthZ system
>
>
>
> I see these as complimentary.
>
>
>
> On another note, We want to ensure that whatever we do at the PEP/PDP
> level,  we allow for real time decisions.  AuthZ decisions are not
> necessarily entitlements, and the decision may well depend on environmental
> issues at the time of the request.
>
>
>
> Allan
>
>
>
>
>
>
>
> On Tuesday, Jun 13, 2023 at 11:45, Alex Babeanu <alex at 3edges.com> wrote:
>
> 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
>
>
>
>
> --
>
> [image: 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.
>
> --
> policy-charter mailing list
> policy-charter at lists.openid.net
> https://lists.openid.net/mailman/listinfo/policy-charter
>
>
>
>
> --
>
> ---
> David Brossard
> http://www.linkedin.com/in/davidbrossard
> http://twitter.com/davidjbrossard
> http://about.me/brossard
> ---
> Stay safe on the Internet: http://www.ic3.gov/preventiontips.aspx
> Prenez vos précautions sur Internet:
> http://www.securite-informatique.gouv.fr/gp_rubrique34.html
> --
> policy-charter mailing list
> policy-charter at lists.openid.net
> https://lists.openid.net/mailman/listinfo/policy-charter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230627/d29cbfb6/attachment-0001.html>