[policy-charter] PEP-PDP Group

Wed Jun 28 05:49:10 UTC 2023

It's on another thread on policy-charter

https://sgnl-ai.github.io/authzapi/

On Tue, Jun 27, 2023 at 10:04 PM David Brossard <david.brossard at gmail.com>
wrote:

> Omri's email is pretty much on point. Here's my experience.
>
> At Axiomatics, we realized over time that authorization could be grouped
> into (at least) 3 buckets:
>
>    - functional: can a given user print (as a whole)? This is useful when
>    building UIs, basic entitlements, or possibly even claims inside a token
>    - transactional: can a given user do a given action on a given item?
>    E.g. can Alice view transaction #123?
>    - data-centric: this one is a variant of the transactional case but at
>    scale. Essentially, which transactions can Alice view? You want to address
>    this type of question for data filtering.
>
> The XACML core spec doesn't address the latter type which is why we came
> up with partial evaluation and an API called "reverse query". It's
> identical in spirit to what Omri states OPA contains. I'm guessing it's
> also similar to the "expand API" in Zanzibar.
>
> And then you realize reverse querying/partial evaluation is not just about
> data filtering. It can be for testing, access review, policy reports, gap
> analyses... You can ask broader to narrower questions e.g.
>
>    - What can happen?
>    - What can Alice do?
>    - What can Alice view?
>    - What can Alice view in the sales department on a Monday?
>
> You get the point.
>
> I think we need to document this type of API because it's fundamental to
> being able to deploy a successful authorization framework. While the
> traditional permit/deny API is easy to understand and implement, it's not
> enough to address filtering, access reviews, etc...
>
> Additionally, there are 2 types of policies we may want to consider:
>
>    - business policies: they reflect exactly what you want to do e.g.
>    "managers can edit documents in their department if the status is draft".
>    This is the sort of policy XACML/ALFA were born to tackle.
>    - entitlements policies: they are here to grant entitlements to users
>    e.g. "managers in the sales department can have the claim editDoc". Those
>    are not my cup of tea and should only be written when you're dealing with a
>    system that cannot handle the richness of ABAC policies
>
> @Omri Gazitt <omri at aserto.com> , can you share a link to @Atul
> Tulshibagwale <atul at sgnl.ai>'s document? Thanks!
>
> David
>
> On Tue, Jun 27, 2023 at 11:43 AM Pieter Kasselman <
> pieter.kasselman at microsoft.com> 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
>>
>
>
> --
> ---
> David Brossard
> http://www.linkedin.com/in/davidbrossard
> http://twitter.com/davidjbrossard
> http://about.me/brossard
> ---
> Stay safe on the Internet: IC3 Prevention Tips
> <https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
> 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/2716a154/attachment-0001.html>