[policy-charter] PEP-PDP Group
David Brossard
david.brossard at gmail.com
Wed Jun 28 05:04:41 UTC 2023
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/5d8a26c2/attachment-0001.html>
More information about the policy-charter
mailing list