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

Mon Dec 18 22:42:14 UTC 2023

I simply wanted to +1 Eve’s suggestion to pull in more stakeholder voices if application vendors are expected to do work for any new interoperability standard, and to offer AWS’s perspective as one application provider. If other vendors give similar feedback as AWS, that’s worth taking into account.

From: Alex Babeanu <alex at 3edges.com>
Date: Monday, December 18, 2023 at 11:36 AM
To: AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
Cc: "McAdams, Darin" <darinm at amazon.com>
Subject: RE: [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.

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<mailto: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<mailto:openid-specs-authzen-bounces at lists.openid.net>> on behalf of eve--- via Openid-specs-authzen <openid-specs-authzen at lists.openid.net<mailto:openid-specs-authzen at lists.openid.net>>
Reply-To: AuthZEN Working Group List <openid-specs-authzen at lists.openid.net<mailto: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<mailto:openid-specs-authzen at lists.openid.net>>
Cc: "eve at xmlgrrl.com<mailto:eve at xmlgrrl.com>" <eve at xmlgrrl.com<mailto: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!

[cid:image001.jpg at 01DA31C0.63987A70]

Eve Maler | cell and Signal +1 425.345.6756

--
Openid-specs-authzen mailing list
Openid-specs-authzen at lists.openid.net<mailto:Openid-specs-authzen at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-authzen

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