[policy-charter] PEP-PDP Group

Tue Jun 27 15:16:35 UTC 2023

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230627/caa9ddcd/attachment.html>