[policy-charter] Admin Policy Push Group
Alex Babeanu
alex at 3edges.com
Thu Jun 22 20:01:35 UTC 2023
Thanks David...!
So to follow-up on this note, I had started the doc you refer to a few days
ago, not sure if we should consolidate both into one or not, but here goes,
everybody should have commenter access to it:
https://docs.google.com/document/d/1xf5H2hLSJVa-iRTenwlAlD48dntbL8uuItDQlCIonUI/edit?usp=sharing
*Notes*:
- These patterns are a compilation of what I've seen in the field over 10
years of IAM consulting (in all verticals - including IoT- , and public,
private and higher ed too)... That said, I may be missing stuff or be
plainly wrong, please feel free to comment in those cases!
- It seems to me that these design patterns *are the main reason* we
haven't seen more adoption of external AuthZ yet, and why the skeptics are
skeptical. Even though vendors (and standards) sell "one-size-fits-all"
solutions, as you can see, it's not the case at all! in the wild !
- If we start from the top down, from use-cases, then we'll end-up with the
same pb imho. Every single use case can include several of these
patterns, so we're back to square 1. Rather, starting at a lower level, at
the pattern level, may give us a better way to scope and frame the pb and
solutions. Just my $0.02...
- Finally, given the varied possible patterns, one possibility is indeed
to exchange messages, rather than forcing a language or an API scheme on
all. We could then just focus on the formats of requests/responses (which
would include open ended ones, thanks @David). That is indeed just an idea,
but one with legs given the efforts of our friends in the SSF workgroup.
Thoughts?
./\.
On Thu, Jun 22, 2023 at 11:47 AM David Brossard <david.brossard at gmail.com>
wrote:
> HI all, Debbie,
>
> I think we might need to remove "push" from the name, I agree with Omri.
> But to Pieter's point, what's in a name?
>
> As for the scope... XACML purposely defined:
>
> - an architecture (borrowed from older standards - PAP, PEP, PDP are
> not new in XACML. PIP might be but the concept definitely isn't). It's the
> same architecture defined in NIST ABAC and Wikipedia (FWIW)
> - a policy language
> - a request/response "format" i.e. how to create a request and get a
> response. BUT the actual transportation is unspecified in the "core"
> specification. OASIS has a notion of profiles where you can tack on
> additional specs to a core spec. In the case of XACML, 3 later profiles
> define a transport for XACML requests/responses
> - The XACML SAML Profile Version 2.0
> <http://docs.oasis-open.org/xacml/xacml-saml-profile/v2.0/xacml-saml-profile-v2.0.html>:
> this old profile posited that because there was a SAML-SOAP binding already
> defined, why not piggy-back on that and use SAML to carry XACML requests
> and responses back and forth rather than define a SOAP binding of XACML.
> Not a great idea and seldom seen in the wild.
> - The JSON Profile of XACML 3.0 Version 1.0
> <http://docs.oasis-open.org/xacml/xacml-json-http/v1.0/xacml-json-http-v1.0.html>
> - this defines a JSON notation for XACML requests and responses
> rather than XML to make it more developer-friendly. It's the pre-requisite
> for the following profile
> - The REST Profile of XACML v3.0 Version 1.0
> <http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.html>
> - this defines a basic way to POST a request and get a response
> back either in XML XACML (core spec) or in JSON (the aforementioned)
>
> XACML's core didn't really focus on transport. Most vendors in the early
> days (think Axiomatics, Nexlabs, Oracle, Bitkoo) all used some kind of SOAP
> that was 99% the same (after all you were just wrapping a standard XACML
> request in a SOAP message. Other than the method name, what else would be
> different?)
>
> What might be interesting is understanding the other ways of querying for
> an authorization decision. All I've written so far is what I'd call a
> binary request/response e.g.:
>
> - Can Alice do X?
> - Yes she can.
>
> But what about open-ended requests? For instance "What can Alice do?" or
> "What can a manager do?". This is something Axiomatics, as a vendor, calls reverse
> querying
> <https://medium.com/@jonas.iggbom/authorization-for-a-list-of-resources-is-something-that-axiomatics-has-supported-for-several-years-48f8fbd1e8fa>
> (based on partial evaluation). I believe OPA calls it partial evaluation as
> well. See Torin's blog post here
> <https://blog.openpolicyagent.org/partial-evaluation-162750eaf422>.
>
> IMHO, from what I have seen, Cedar, OPA, and XACML/ALFA are 99% the same.
> Sure, there are differences. For instance XACML has obligations & advice.
> But the bottom line is: maybe we should try to standardize between these 2
> models as a starting point.
>
> And then @Alex Babeanu <alex at 3edges.com> mentions that there could be a
> different way altogether to signal authorizations via events. So that's a
> different pattern worth considering.
>
> Lastly, let's look at sibling standards? How do rich authorization
> requests <https://datatracker.ietf.org/doc/html/rfc9396> fit in?
>
> Debbie, to your point on building a list of approaches, I think Alex put a
> doc together that he'll be sharing shortly that attempts to do this. From
> the top of my mind I roughly see:
>
> - policy-driven approaches: OPA, Cedar, XACML, ALFA are all great
> examples
> - graph: 3Edges, NGAC, others?
> - ACL-based: Zanzibar, OpenFGA, others?
>
> Thanks
>
> On Tue, Jun 20, 2023 at 7:37 AM Debbie Bucci via policy-charter <
> policy-charter at lists.openid.net> wrote:
>
>> Scope seems to be all over the place … I kind of need to do my own
>> research (or perhaps it’s part of charter) to better understand what the
>> similarities and differences and /or pro cons between current
>> implementations - compared to what my own organization needs are for
>> exchanging polices generated at multiple levels -organization and
>> individual choice (which kind of implies the need of roles to me)
>> Authorization at the Org most likely not enough …Ultimately the data holder
>> is liable and will make that final decision. Certainly the “sausage
>> making” for tool of choice is out of scope but what is exchanged is most
>> important. Perhaps I am missing something.
>>
>>
>>
>> This seems to be the short list from the original thread. XACML, Open
>> Policy Agent, Amazon Verified Permissions and other implementations. Are
>> there others? Graph GL?
>>
>>
>>
>> *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: *Monday, June 19, 2023 at 5:51 PM
>> *To: *Policy Charter Mail List <policy-charter at lists.openid.net>
>> *Cc: *Omri Gazitt <omri at aserto.com>
>> *Subject: *Re: [policy-charter] Admin Policy Push Group
>>
>> @Alex I think you and I are making an assumption that communicating
>> relationships (data) changes between an administration point and a decision
>> point is just as important as communicating policy changes. But that is not
>> (yet) agreed upon.
>>
>>
>>
>> On Mon, Jun 19, 2023 at 8:29 AM Alex Babeanu via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> On the ReBAC front, and to keep it simple, no matter what language/system
>> we come up with, "relationships" should be prime citizens, and optional.
>> Note also that relationships, like any other entities, can hold properties
>> (for those of us using labelled property graphs). This should cater to all
>> cases I think, and be simple enough. Don't need it? don't use it...
>>
>>
>>
>> Also Re: Naming, does it have to be an acronym ?
>>
>>
>>
>> Cheers,
>>
>>
>>
>> ./\.
>>
>>
>>
>>
>>
>> On Mon, Jun 19, 2023 at 8:12 AM Gerry Gebel via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> @Omri - I agree with Andrew here that we should keep the scope more
>> narrowly defined.
>>
>>
>>
>> Some of what you describe (push vs. pull) will be specific to the target
>> environment and not easily generalized.
>>
>>
>> That said, a separate work stream can be started if that is appropriate
>>
>>
>> Gerry
>>
>>
>>
>> On Sun, Jun 18, 2023 at 5:05 PM Andrew Hughes via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> I prefer the most narrow scope possible. Otherwise we will never finish.
>>
>>
>>
>> Other people will work with n the other parts.
>>
>>
>>
>> On Sun, Jun 18, 2023 at 4:00 PM Omri Gazitt via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> One thing I'd like to put out there...
>>
>>
>>
>> In a world where both policy and data are important parts of a decision,
>> we should consider expanding the scope of what we believe should be pushed
>> from an administration point to a decision point. Specifically, with a
>> ReBAC model (or a hybrid policy-as-code / policy-as-data model), changes in
>> relationships between subjects and objects are as critical to communicate
>> as policy changes.
>>
>>
>>
>> If folks agree, then perhaps the name of the workstream should be
>> generalized to "PAP-PDP group".
>>
>>
>>
>> Additionally, there are two possible models to consider - Pull and Push.
>> For example, OPA defines a pull model
>> <https://www.openpolicyagent.org/docs/latest/management-bundles/> for a
>> PDP to obtain policy updates from a policy bundle service. In practice, a
>> push model seems critical for real-world scenarios.
>>
>>
>>
>> On Sun, Jun 18, 2023 at 2:54 PM Roland Baum via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> me too! :-D
>>
>> Am 15.06.23 um 20:51 schrieb Omri Gazitt via policy-charter:
>>
>> Me too
>>
>>
>>
>> On Thu, Jun 15, 2023 at 10:35 AM Atul Tulshibagwale via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> Im in
>>
>>
>>
>> On Thu, Jun 15, 2023 at 10:34 AM Vittorio Bertocci via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> Would love to be on it!
>>
>>
>>
>> On Thu, Jun 15, 2023 at 10:33 David Brossard via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> *This message originated outside your organization.*
>>
>>
>> ------------------------------
>>
>>
>>
>> Count me in too
>>
>>
>>
>> On Thu, Jun 15, 2023, 10:30 AM Shayne Miel (smiel) via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>> Please count me in for the Admin Policy Push group.
>>
>>
>>
>> Thanks!
>>
>> Shayne Miel
>>
>>
>>
>>
>>
>> *Error! Filename not specified.*
>>
>> [image: Image removed by sender.]
>>
>> *Shayne Miel*
>>
>> / Principal Engineer (he, him, his)
>>
>>
>> smiel at cisco.com
>>
>>
>> (919) 923-6230
>>
>>
>> cisco.com
>> <https://urldefense.com/v3/__https:/www.cisco.com/site/us/en/products/security/index.html__;!!PwKahg!4zuqlwDjQsKy8apRVi9ImPprXSTXVrhXnrfmIhSUtDp3STR8J62s7zvfMsE7Z_yaCzNWpdSxS1yQ-Vb0CLNdfhklKja8Kb_WYdE$>
>>
>> [image: Image removed by sender.]
>>
>>
>> ------------------------------
>>
>> *From:* policy-charter <policy-charter-bounces at lists.openid.net> on
>> behalf of Gerry Gebel via policy-charter <policy-charter at lists.openid.net
>> >
>> *Sent:* Thursday, June 15, 2023 10:53 AM
>> *To:* Policy Charter Mail List <policy-charter at lists.openid.net>
>> *Cc:* Gerry Gebel <gerry at strata.io>
>> *Subject:* [policy-charter] Admin Policy Push Group
>>
>>
>>
>> Hi all -
>>
>>
>>
>> Thanks to Andrew Hughes for leading the PEP-PDP Group and those that have
>> expressed interest in pursuing that effort.
>>
>>
>>
>> How about the Admin Policy Push work stream? Who is interested in
>> participating?
>>
>> Thanks,
>>
>> Gerry
>>
>> --
>> policy-charter mailing list
>> policy-charter at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/policy-charter
>> <https://urldefense.com/v3/__https:/lists.openid.net/mailman/listinfo/policy-charter__;!!PwKahg!4zuqlwDjQsKy8apRVi9ImPprXSTXVrhXnrfmIhSUtDp3STR8J62s7zvfMsE7Z_yaCzNWpdSxS1yQ-Vb0CLNdfhklKja8RgFFZy8$>
>>
>> --
>> 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
>>
>> --
>> policy-charter mailing list
>> policy-charter at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/policy-charter
>>
>> --
>>
>> [image: Image removed by sender.] <http://www.aserto.com/>
>>
>> *Omri Gazitt* *| *CEO
>>
>> Aserto <http://www.aserto.com/> Inc. *| *(425) 765-0079
>>
>>
>>
>> --
>> 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
>>
>> --
>>
>> Andrew Hughes
>> Director, Identity Standards
>> Ping Identity
>> Signal/Mobile: +12508889474
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*--
>> 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: Image removed by sender. 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
>>
>> --
>> 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
>
--
[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230622/bcecbb1b/attachment-0001.html>
More information about the policy-charter
mailing list