[Openid-specs-authzen] Initial thoughts on interop scenario planning

[Alex Babeanu]

Hi Darin,

Thanks for your input. This is interesting... I read it a bit like: "what
we're doing now is not useful because nobody will use it". Did I misread?
Additionally you propose focusing only on the side-car pattern, which is
only 1 of the patterns we identify in the Patterns doc ("PAD" in Eve's
note). You also state you'd see some value in having a common way to
express access policies... and you suggest Cedar.

I personally don't agree with your statements...
First, there's been a standard way to represent policies since 2003
(XACML). Not sure we want to revisit this here. There are also many other
ways to represent policies, and I think we purposely wanted to stay away
from this can of worms (see rego, Graphs, IDQL, ALFA,OSO,etc).

Secondly, you see things from an AWS lens, which is fine and great
input given your size and the volumes you tackle, but a lot of
organizations out there have hybrid deployments, their own data centers, or
simply don't run on AWS. And various things in between, which is why
discussing patterns is important. See for example the discussion about the
"clash" between the P*P (to quote Eve again) and OAuth* world views, which
are broader than just policy representation or just focusing on 1 pattern
(side-car).

Given these, let's see if there's a way to build some interoperability
between various vendors, one that could cater to most (or all) defined
patterns, and truly help organizations implement proper authorization.
My $0.02. And thanks again for your input!

Cheers,

./\lex.

On Fri, Dec 15, 2023 at 5:27 PM McAdams, Darin via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> (My contribution agreement was completed this morning, so I can contribute
> at last.)
>
> Eve, thank you for the write-up. I wanted to +1 the callout for more input
> from non-authz vendor partners.
>
> In this vein, I can share a brief perspective from AWS (wearing the hat of
> a web service provider). Many of the interesting proposals under discussion
> so far are not necessarily easy to align with the priorities we’re hearing
> from our customers, or that would be pragmatically implementable. To give
> an example, we would be unlikely to make a callout to an external
> authorization endpoint from within our services for various operational
> reasons. If we flip that around and consider an approach where others
> upload authorization rules to AWS, we do have several partners who do so
> already. While a standard representation of a policy might be nice-to-have
> for this audience (and we’re not adverse to that), I’m not sure if there’s
> critical mass amongst other application vendors to implement such
> standardization.
>
> One approach that I do see gaining traction is in exporting rules from
> various online services and normalizing them to a common representation for
> analysis and auditing purposes. For example, one party built a translation
> layer from AWS IAM policies into Cedar policies, which they found more
> efficient to analyze. However, I’m not sure if there’s an interop story,
> except to the degree that it would be nice if application providers
> natively exposed policies in a standard representation. But, that circles
> us back to the question of why providers would be motived to do this work.
>
> If there’s an area in need of interop, the one I’ve personally noted has
> been between open-source components. For example, solutions such as Envoy
> and Kubernetes both support authorization plugins via a sidecar. However,
> they each define different plugin mechanisms, leading authorization
> toolchains to build adapters for each one. An example is the OPA plugin for
> Envoy.  (https://www.openpolicyagent.org/docs/latest/envoy-introduction/)
>
> This raises a question of whether it’s possible to “flip the script” and
> define a standard authorization API for sidecars that the next generation
> of Envoy-like solutions would conform to. I haven’t had the time to
> deep-dive into whether sufficient commonalities exist across these
> toolchains to make such a thing practical, but it is an area where we’d
> have interest in exploring further.
>
>
>
> *From: *Openid-specs-authzen <
> openid-specs-authzen-bounces at lists.openid.net> on behalf of eve--- via
> Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
> *Reply-To: *AuthZEN Working Group List <
> openid-specs-authzen at lists.openid.net>
> *Date: *Friday, December 15, 2023 at 3:04 PM
> *To: *David Brossard via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net>
> *Cc: *"eve at xmlgrrl.com" <eve at xmlgrrl.com>
> *Subject: *[EXTERNAL] [Openid-specs-authzen] Initial thoughts on interop
> scenario planning
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> I reviewed all of the extant materials, including historical ones, and put
> together a "meta-interop-scenario" document
> <https://hackmd.io/4IaZmp2lSHaWXphriXiVOg> in HackMD. It proposes a way
> forward.
>
>
>
> I also did a very crude sketch to get some observations out of my head – I
> didn’t see a way to embed it, but it’s attached here. This diagram is
> helping me to articulate some of the questions I have about standards
> prioritization, design principles, and community engagement. For example,
> how important are the various “Clarify Access” scenarios vs. basic “Enforce
> Access” ones? Is there a way to categorize, and maybe prioritize, coverage
> of by-value inputs into policy decision requests? When SAML decided to
> solve only IdP-initiated SSO in its V1, it had a useful MVP that gave us
> runway to get to V2 and start doing SP-initiated SSO; what’s our most
> powerful MVP?
>
>
>
> The API spec doc and the PDP-PEP Use Cases doc align with a “protocol”
> view of the world, I believe, and the “PAD” (design patterns) doc adds
> real-world deployment considerations. There is some overlap; PAD includes
> both “architecture” and “model” patterns, and architecture somewhat relates
> to protocol design. Note that the “Alternate” block on the right is trying
> to hint at ways OAuth is fundamentally different, though you could see how
> to make its version of such a diagram consonant with this one.
>
>
>
> My diagram blocks are meant to be functional and descriptive and are not
> prescriptive in any way! If you think this is on the way to being helpful
> but want to revise, feel free. If it’s wrong-headed, let me know. :)
>
>
>
> Have a great weekend, all!
>
>
>
>
> Eve Maler | cell and Signal +1 425.345.6756
>
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>


-- 
[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/openid-specs-authzen/attachments/20231218/5b3d7528/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 192446 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20231218/5b3d7528/attachment-0001.jpg>