[Openid-specs-authzen] Comments on the Authzen API GW Profile
Ahmet Soormally
ahmet at mangomm.co.uk
Fri Jan 24 22:28:05 UTC 2025
Ahmet here from Tyk, an API Gateway vendor.
I really appreciate what you're all working on and the goals you’re
aiming to achieve - it's exciting to see how this will evolve.
When I initially read through the proposal, I shared some of the same
confusions others have raised.
A few thoughts:
Name Clarity: The term "API Gateway Profile" suggests a general-purpose
profile for API Gateways, but the current proposal is limited to
REST-ish APIs. As others mentioned, in our world, API Gateways need to
support not just REST, but also GraphQL, gRPC, SOAP, HTTP/3, WebSocket,
SSE, Kafka and more.
PDP on the Hot Path: Calling out to a Policy Decision Point (PDP) on the
hot path raises concerns for latency, security, and reliability. It
would be worth exploring the possibility of embedding the PDP instead,
which could alleviate some of these challenges.
REST API Matching: If we're limiting this to REST-style APIs, it might
be worth considering aligning the spec with OpenAPI v3 Schema. Using
operationId to uniquely identify operations could significantly simplify
the mapping process compared to relying on URL, path, method, headers, etc.
JWT Claims: In the examples provided, I saw mentions of the sub claim.
However, for medium-grained authorization with an Access Token, the
Gateway would typically look at other claims, such as client_id, to
determine what the client is authorized to do on the subject's behalf.
If the JWT is then passed along to the target microservice, it’s
typically the microservice that performs the finer-grained authorization
logic with the sub claim - unless a token exchange is performed by the
Gateway. Does your proposal support this kind of flexibility?
Response Filtering: Michael's mention of filtering responses from the
target API is a fantastic idea - definitely a +1 from me.
Looking forward to hearing more as this develops!
Best regards,
Ahmet
On 24/01/2025 18:36, Alex Babeanu via Openid-specs-authzen wrote:
> Hi there,
>
> The important part in Omri's email I think is: "It is meant to be a
> starting point for API gateway vendors and PDP vendors to be able to
> implement an interop scenario for an event we are having in March,"
>
> --> ok so this is not a spec, that wasn't clear to me. So let's not
> write it as one. It's a definition for a specific event: the March
> interop. Sure why not. But again, this is more in the line of the
> previous docs you created for past interops Omri. Again, make it an
> article, or an opinion piece on how GTwy vendors /could/ use AuthZen.
>
> --> if we want Gtwy vendors to map stuff in a specific way, we should
> just call it out in the Authzen protocol itself, and assume they're
> smart enough to figure out how to map their "stuff" (route and all)
> into it. I.e., let's not write a design spec for them. This document
> still reads like a design spec, it's something I'd give my engineers
> to work on...
>
> So it might be easier to agree on this if framed like that?
> If this is just for the interop, then yeah I don't have a pb with the
> doc, if Gtwy vendors find it helpful, good...
>
> My $0.02..
>
> cheers,
>
> ./\.
>
> On Fri, Jan 24, 2025 at 5:38 AM Michael Schwartz via
> Openid-specs-authzen <openid-specs-authzen at lists.openid.net> wrote:
>
> I disagree with just about everything you said Omri, but let's
> proceed as you say. At least we've discussed it at this point.
>
> BTW, I don't think it's "high stakes"... this Interop doesn't
> matter very much at all. I just wanted the WG to make a good
> impression, and I thought we could put forward something more
> compelling.
>
> - Mike
>
> On Fri, Jan 24, 2025 at 12:52 AM Omri Gazitt <omri at aserto.com> wrote:
>
> Michiel is correct on all counts in his response.
>
> Additional comments:
>
> _Scope_
> It seems like a few people are still confused about the
> purpose and scope of the proposal. It is meant to be a
> starting point for API gateway vendors and PDP vendors to be
> able to implement an interop scenario for an event we are
> having in March, no more, no less. I'm honestly at a loss to
> understand why the "stakes feel so high". I've already started
> sharing this with API gateway vendors, to ensure we have a
> shot of making the interop showcase.
>
> No doubt we learn a lot from doing this showcase... as we have
> with previous interops at Identiverse, EIC, Authenticate,
> which all eventually led to the AuthZEN implementer's draft.
>
> Also, I don't really understand the continuing comments about
> gRPC and graphQL. The proposal is titled "HTTP REST API
> Gateway Profile proposal". It is explicitly scoped for HTTP /
> REST (see "Scope
> <https://hackmd.io/MTJPf_vzSmubctNtHis99g#Scope>" section).
> We can have other proposals for other protocols.
>
> Note that NONE of this has gone into any OpenID document that
> looks like a "spec" as of yet - we are doing the interop
> first, learning from it, and eventually distilling the
> learnings into more formal documents.
>
> _Too opinionated_
> The proposal suggests default mappings. Everything should be
> overridable by a developer configuring a gateway's authzen
> filter. Please re-read the "purpose
> <https://hackmd.io/MTJPf_vzSmubctNtHis99g#Purpose>" section
> (also quoted below):
>
> Ideally, the filter implementation allows the developer to
> indicate which HTTP elements (method, path, headers, body)
> to map into which fields of the AuthZEN evaluation request.
>
> So why define an AuthZEN profile for API gateways? To
> provide a simple mapping as a sensible default (which a
> developer can ideally override).
>
> This in turn can accelerate the process of enabling API
> Gateways to easily become AuthZEN clients.
>
>
> <#m_-1979186327547575944_m_-3221772943351243300_Scope>
>
> Stepping back, there are three usages that the proposal is
> trying to cover.
>
> 1. PEP just puts all the HTTP fields in predictable places in
> the AuthZEN request, and PDP has code to utilize the fields it
> needs in an authorization policy. The benefits of this
> approach is that logic only needs to be written in one place,
> and a generic AuthZEN filter can be used for every endpoint
> that the gateway is proxying. (although, of course, each of
> the policies will likely be different).
>
> This is what the "default mapping" is good for. This is what
> Michiel's original proposal was trying to accomplish as well.
>
> 2. PEP allows the developer to pick what HTTP fields they want
> to put in which AuthZEN fields. /This doesn't require a
> profile or spec or anything. /There is what amounts to a
> "per-route protocol" between the API gateway and the PDP. I
> expect most/all gateways will support this usage scenario. The
> advantage is that the caller can tune the AuthZEN payload to
> something that an existing policy (already running in a PDP)
> expects. But it means code on both sides, for every route.
>
> 3. PEP calls out to the PDP to /Authorize access to routes.
> / This third scenario is more narrow (and therefore more
> opinionated with respect to "what goes where"). This is also
> the scenario that the interop in London will focus on, and
> that's why I've been trying to get it written up in the same
> proposal.
> _
> _
> _Where various HTTP fields go_
> This is of course up for discussion and is ultimately a
> judgment call, but I would suggest that for the first usage
> case, as long as the fields are found in predictable places,
> the PDP can extract them in predictable ways.
>
> For the third scenario (authorizing routes), the required
> fields actually matter. The idea is that PDPs can have a
> specific policy that is written around authorizing access to
> routes. This is why the proposal suggests using subject for
> the subject of the request (extracted from the Authorization
> header), HTTP method for action name, and the route as the
> resource.
>
> _Type names_
> I fail to understand the argument about type names working in
> various languages. Simple strings work in every language.
> There have been suggested type names in this thread that
> contain spaces - I think that's a very bad idea, because most
> languages I know use spaces to separate tokens. But in the
> end, these are strings. Making them URIs or URNs or scoped
> identifiers just makes things harder to read and harder to
> construct (on the gateway side) and parse (on the PDP side).
>
>
> In the interest of time, I will turn my attention towards
> writing up the actual interop document for the showcase in
> London (i.e. the specific application routes for the Todo
> application and the AuthZEN payloads that participating
> gateways are expected to send to participating PDPs for the
> /route authorization/ scenario.
>
>
> On Thu, Jan 23, 2025 at 1:21 PM Michiel Trimpe via
> Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
> wrote:
>
> I don't think anyone is talking about making this a
> mandatory standard. It’s a draft proposal to engage
> gateway providers that want to enable some degree of
> interoperability for authorizing gateway requests. Within
> the profile pretty much everything is also optional and
> free-form.
>
> In essence it’s just answering the question that every
> gateway provider will inevitably ask: “I have a request.
> You have subject, action, resource and context. Where
> should I put what?”
>
> So far I don't think we have much opinion there at all. We
> just say that subject is your authorization header, action
> is the method, resource is route or uri and headers is
> context. If you want to include them, include them there.
>
> Regards, Michiel
>
> P.S. The body is required for cases where sensitive query
> parameters are placed in a POST body to prevent them from
> being logged by intermediate proxies. It should indeed
> only be used in such cases though which is why it would
> also be an optional field.
> ------------------------------------------------------------------------
> *From:* Openid-specs-authzen
> <openid-specs-authzen-bounces at lists.openid.net> on behalf
> of Antonio Radesca via Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net>
> *Sent:* Thursday, January 23, 2025 9:45:46 PM
> *To:* AuthZEN Working Group List
> <openid-specs-authzen at lists.openid.net>; mike at gluu.org
> <mike at gluu.org>
> *Cc:* Antonio Radesca <antonio.radesca at nitroagility.com>
> *Subject:* Re: [Openid-specs-authzen] Comments on the
> Authzen API GW Profile
> Hi All,
> Agreed, it’s fine as an example, but I am not sure it
> works as a standard. The AuthZEN API Gateway Profile feels
> too narrow. It works for simple cases like a wrapper but
> it ignores more complex scenarios like SSE, WebSockets, or
> HTTP/3. It also seems inconsistent because it doesn’t
> include gRPC or GraphQL, which are common in API gateways.
> I think this "standard" should first be tested by multiple
> vendors and get their feedback. Making it mandatory now,
> while it’s incomplete, doesn’t seem like a good idea. IMHO
> basically it should be more agnostic to be adaptable to
> more protocols and scenarios as said.
>
> Also, since this is a security tool, requests might be
> logged in the decision logs. Logging an entire POST body
> might not only be unnecessary but could also be a security
> risk. The same applies to headers.
>
> Adding to the security concern, why should policies for
> authorization depend on a BODY DTO? What happens if an
> application uses a BFF pattern, where the DTO for mobile
> is different from the one for the frontend? Should
> policies handle these differences? And what about
> versioning for the API and the policies? Coupling DTO and
> policies doesn’t seem like a good idea. Instead if the
> body is not used in any policy, the Zero Trust Least
> Privilege Principle should apply instead, so why pass it?
>
> Finally, there is also a latency concern when passing
> unnecessary information, as it adds processing overhead
> without any clear benefit.
>
> Thank you for your time
>
> *Antonio Radesca*
>
> Co-founder / Chief Technology Officer
>
> *
> *
>
> *M:*+373 698 04 974*P:*+39 0835 170 0059 P:+44 20 3966 5620
>
> *E:*antonio.radesca at nitroagility.com *in:*antonioradesca
> <https://www.linkedin.com/in/antonioradesca/>
>
> *W:*nitroagility.com <https://www.nitroagility.com/>
> *in:*nitroagility <https://www.linkedin.com/company/20520302>
>
>
> Nitro Agility Srl - C.F./P.IVA: 01364090777 - PEC:
> nitroagility at pec.it
>
> SEDE LEGALE: VIA F. PARRI 44, 75100 MATERA (MT), ITALY
>
> SEDE OPERATIVA: VIA LUCANA 259, 75100 MATERA (MT), ITALY
>
> CODICE DESTINATARIO: M5UXCR1
>
>
>
> On Thu, Jan 23, 2025 at 8:58 PM Nicola Gallo via
> Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net> wrote:
>
> Hi All,
>
> I completely agree with @alex.babeanu at indykite.com’s
> comments. This is a great example and a helpful
> recommendation article. However, I think I wouldn’t
> feel as comfortable if it were turned into a formal
> standard or specification.
>
> Cheers,
>
> *Nicola Gallo*
>
> Co-founder / Chief Technology Officer
>
> *
> *
>
> *M:*+39 349 3305248 *P:*+39 0835 170 0059 P:+44 20
> 3966 5620
>
> *E:*nicola.gallo at nitroagility.com *in:*nicolagallo83
> <https://www.linkedin.com/in/nicolagallo83/>
>
> *W:*nitroagility.com <https://www.nitroagility.com/>
> *in:*nitroagility
> <https://www.linkedin.com/company/20520302>
>
>
> Nitro Agility Srl - C.F./P.IVA: 01364090777 - PEC:
> nitroagility at pec.it
>
> SEDE LEGALE: VIA F. PARRI 44, 75100 MATERA (MT), ITALY
>
> SEDE OPERATIVA: VIA LUCANA 259, 75100 MATERA (MT), ITALY
>
> CODICE DESTINATARIO: M5UXCR1
>
> This message may contain confidential and/or
> proprietary information, and is intended only for the
> person/entity to whom it was originally addressed. The
> content of this message may contain private views and
> opinions, which do not constitute a formal disclosure
> or commitment unless specifically stated.
>
>
>
>
> On Thu, 23 Jan 2025 at 19:02, Michael Schwartz via
> Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net> wrote:
>
> A few follow-up thoughts... I was just using Cedar
> syntax as an example for expediency, but I
> mentioned using URIs, URNs, ASNs, etc. are other
> ways to address the issue. But what I think is
> important is that we prefix the following: OpenID,
> Authzen, and API GW Profile--specifying the
> version. Not just "http" or "graphql", which I
> don't think is actually collision resistant.
>
> Just as an example in another domain, in the
> DID space, anyone can define a DID method. Certain
> DID methods started to get traction, and
> eventually will become "standardized". I think
> this is an interesting approach, because we can
> stay open minded here that we might not know best.
> So at the Interop we are showing how to profile
> Authzen, and the quick profile we are using is
> just an example of one possible profile.
>
> - Mike
>
>
> On Thu, Jan 23, 2025 at 9:51 AM Alex Babeanu
> <alex.babeanu at indykite.com> wrote:
>
> Hi all,
>
> Finally caught up with all this... Was the
> consensus that this GTWY profile was going to
> actually be helpful in bringing Gtwy vendors
> on board??
> It does really seem VERY opinionated to me:
> it's basically telling them HOW to build their
> product. It seems to me that defining a good
> AuthZEN protocol that includes the
> protocol-side things that would be required
> for their integration (Omri's the JWT Profile
> draft for example) should be sufficient. This
> here feels to me like, saying: "here's the
> OAuth spec, and oh, btw, here's how you MUST
> implement it". Not sure I like that myself...
> The AuthZEN protocol spec should be sufficient
> for all vendors to adopt in the way they see
> fit. I'm sure they have smart people that can
> figure it out, especially if the protocol
> itself makes it obvious what the expectation is...
>
> This could therefore be a recommendations
> article rather than a formal standard/spec. My
> $0.02...
>
> And sry if the decision was already made to go
> ahead in this direction, I may have missed it
> - been too busy.
>
> Regards,
>
> ./\.
>
> On Thu, Jan 23, 2025 at 7:39 AM Michiel Trimpe
> via Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net> wrote:
>
> *Collision Resistance*
> I agree that it's probably wise to include
> guidance towards ensuring collision
> resistance for implementers in the base
> AuthZEN spec. I came across a similar
> section in the OAuth RAR specification
> <https://datatracker.ietf.org/doc/html/rfc9396#name-authorization-details-types> recently
> which does a fairly good job at explaining
> this IMO (although I'm not a fan of URI's
> as namespaces.)
>
> After considering the GraphQL case I do
> agree it might be wise to give this
> profile a top-level namespace like 'http'
> instead. So then you'd get something like
> {"type": "http:route"} and {"type":
> "http:uri"} and {"action": "http:get"}
> That leaves API gateways free to model
> GraphQL calls as plain HTTP request using
> this profile or to use a (yet to be
> defined) GraphQL profile with action types
> like "graphql:query".
>
> *What goes where*
> Looking at terminology alone it seems
> logical for me to put:
> - information from/about the Uniform
> _Resource_ Identifier in the `_resource_`
> section
> - the HTTP _method/verb_ in the
> `_action_`section and
> - the _subject_ as extracted from e.g. the
> Authorization header in the `_subject_`
> section
>
> I'd personally say 'body' belongs in the
> `action` section as well since it's *what*
> your are PUTting or POSTing.
>
> Then you get a sentence like "As
> `mtrimpe`(subject) I `POST
> {"json":"string"}`(action) to
> `http://example.com/json-store`(resource)
> <http://example.com/json-store(resource)>."
>
> Only the headers are a tough one. You can
> see it as metadata about the action but
> we're also parsing the Authorization
> header to populate the subject as well.
> Given that headers are now used for so
> many purposes I'd argue that makes most
> sense to put it in the `context` section.
>
> Cheers, Michiel
>
> ------------------------------------------------------------------------
> *From:* Openid-specs-authzen
> <openid-specs-authzen-bounces at lists.openid.net>
> on behalf of Michael Schwartz via
> Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net>
> *Sent:* 23 January 2025 00:37
> *To:* AuthZEN Working Group List
> <openid-specs-authzen at lists.openid.net>
> *Cc:* Michael Schwartz <mike at gluu.org>
> *Subject:* Re: [Openid-specs-authzen]
> Comments on the Authzen API GW Profile
> Here are some more comments about Omri's
> "AuthZEN REST API Gateway Profile
> proposal" we've been so heatedly
> discussing, described here:
> https://hackmd.io/MTJPf_vzSmubctNtHis99g
>
> I know there is a time challenge around
> the interop, so I'll try to be brief. BTW,
> I very likely won't be at the meeting next
> week, so it would be great if we could
> have this conversation in the mailing list
> (or the OIDF Slack...).
>
> My first suggestion is that the "type"
> values should be collision resistant. For
> example, here are some types and what I
> might like better (just suggestions...)
> - In the Subject, *type "user"*. What
> about: "OpenID Authzen API GW Profile 0.1
> User",
> "OpenID::Authzen::API-GW::0.1::User", or
> https://openid.net/authzen/types/User"
> (today the best practice for OAuth scopes
> is to use a unique URI)
> - In the Action, *type "GET"*, to
> "OpenID::Authzen::API-GW::GET" (or one of
> the other formats above)
> - In the Resource,* "type": "route"*,
> --> "OpenID::Authzen::API-GW::0.1::Route"
> - In the Context, the type is missing...
> maybe Contexts don't have types in
> Authzen... but I would define it anyway as
> something like
> "OpenID::Authzen::API-GW::0.1::Context".
>
> While you "could" put
> information anywhere, I find the
> organization of the request in the current
> proposal very confusing. I don't
> understand why half the data about the
> request is in the resource (like the
> params), but the other half is in the
> Context (like the body). There is no clean
> explanation for that organization. I would
> like to suggest that an easy explanation
> might be to say the request itself is put
> in the resource -- url, headers, body. And
> all the information added by the API GW --
> time of day, network, etc. -- is in the
> Context.
>
> Having the Profile version in the type is
> also important. API GW plugin developers
> will write against a certain version, so
> if a PDP is expecting a different version,
> things may break.
>
> I understand that optionality is the enemy
> of interoperability. But at this phase, I
> feel like this current proposal is too
> opinionated. IMHO, we want to invite the
> API GW community to come up with more
> innovative ideas for how to add new
> subject, action, resource or context
> types. For example we need different
> actions and resources for GraphQL. So I'd
> like to see the proposal be more
> extensible, which always ends up being
> good for a spec. Maybe a vendor won't
> support every API GW Profile feature (e.g.
> a GW may not support GraphQL). Then we're
> not saying there is one "right" way...
> we're giving a way to define different
> ways, and then when adoption becomes
> clear, we can promote or demote schemas.
>
> - Mike
>
>
> On Fri, Jan 17, 2025 at 1:42 AM Omri
> Gazitt via Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net> wrote:
>
> Thank you Michael, Michiel, and Julio
> for your comments.
>
> I have been pondering this for the
> last couple of days and have come to
> the conclusion that we are trying to
> represent two separate scenarios in
> the same profile.
>
> Julio is exactly right on all counts:
>
> * the proposal I reviewed in the
> meeting is meant for
> "medium-grained authz", but I
> agree that fine-grained authz is a
> valid scenario as well
> * the question you're asking in
> "medium-grained authz" is "can
> this subject invoke the route
> represented by { HTTP method, HTTP
> route }"
> * "route" is meant to be an OpenAPI
> path template, which is widely
> implemented by many HTTP
> frameworks / API gateways. These
> pieces of software typically make
> the matched route available in the
> request or in some
> developer-accessible context
>
> In the context of this scenario, I
> also agree that the JWT is
> uninteresting, and what you really as
> the subject is a claim inside the
> JWT. So I agree with the feedback
> from George, Julio, and Michael that
> we don't want the subject to be of
> type "JWT".
>
> Julio, your memory is very good. We
> considered RFC 9493 as a way to
> represent subjects, but realized that
> we were conflating "format" (e.g.
> "JWT", "email", etc) and the "type"
> ("user", "identity", etc).
>
> Stepping back, I do think we can
> represent the two scenarios in a
> single profile.
>
> For the generic fine-grained authz
> scenario (where every field in the
> HTTP request information model is
> essentially an "attribute" that a
> policy can reason over), we want the
> API gateway to pass along most/all of
> the fields in the HTTP request
> information model, and what is placed
> in the required fields isn't all that
> important. The PDP's policy will
> likely be written around the various
> properties in the information model
> (subject, action, resource, context)
> and not the required fields.
>
> For the medium-grained authz scenario,
> what we pick for the required fields
> actually matters more, because we are
> designing an authorization protocol
> for HTTP routes.
>
> The "default" mapping for this
> scenario feels to me like the
> following (in pseudo-code):
>
> {
> "subject": {
> "type": "user",
> "id":
> "<decode_jwt(request.headers["authorization"]).sub>"
> },
> "action": {
> "name": "<request.method>"
> },
> "resource": {
> "type": "route", // or "uri" if
> "route" is not available
> "id": "<request.route>", // or
> "uri" if "route" is not available
> "properties": {
> // uri components, path
> parameters, query (or query parameters
> if they get parsed)
> },
> "context": {
> "headers": [],
> "body": ...
> }
> }
> }
>
> For the fine-grained authz scenario,
> each API request (and its
> corresponding filter) essentially has
> its own contract with the PDP. What is
> most important for this scenario is a
> predictable way of mapping the HTTP
> request information model into the
> AuthZEN information model. The PDP
> policy will lift whatever fields it
> wants out of the AuthZEN request, and
> use those fields in the policy.
>
> For example, if (as Michael suggests)
> the PDP really wants the encoded
> access token as the subject and will
> process whatever it wants to extract
> out of that, this is easy to do by
> writing a policy that extracts that
> field out of
> context.headers["Authorization"].
>
> Therefore, it stands to reason that
> the mapping sketched out above would
> work for the (more constrained)
> medium-grained authz scenario, and the
> (less constrained) fine-grained authz
> scenario.
>
> On Wed, Jan 15, 2025 at 7:28 AM Julio
> Auto De Medeiros (BLOOMBERG/ 731 LEX)
> via Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net>
> wrote:
>
> A couple of thoughts:
>
> 1. On the matter of
> "/api/v1/pets/{id}", my
> understanding was that no
> replacement/rewriting was being
> proposed. Authorizing on that
> would have the meaning of
> "principal can POST on some pet"
> (non-pet-ID-specific). The
> pet-specific authorization would
> only happen later, at the actual
> API provider. In other words, the
> API gateway would only perform
> "medium-grained" (as Omri put it)
> authorization, and the API
> provider would do fine-grained
> authorization. I also understood
> that it didn't mean that API
> gateways weren't allowed do
> fine-grained authorization, but
> more of a question of picking the
> example/use case to include in the
> profile.
>
> 2. George (IIRC) had a good point
> on the JWT subject 'type', in that
> previously the authzen spec evoked
> differences between type and
> "format". Subject types would be
> things "user", "group",
> "workload", I reckon. So, in that
> spirit, perhaps the example in the
> profile would better read: {
> "subject": {
> "type": "user",
> "id": {
> "format" : "JWT",
> "jwt": "eyJhb..."
> }
> }
> }
>
> Having that said, I'm of the
> opinion that the JWT doesn't
> belong in the subject at all, but
> rather in the context.
> Conceptually, I think the subject
> identifier is of the format
> 'email' and its value is
> 'john.doe at acmecorp.com', the JWT
> being sent in the 'context' mostly
> to allow for identity validation.
> But I understand the concern with
> giving the gateway the "burden" of
> deserializing the JWT to extract
> the subject ID.
> From:
> openid-specs-authzen at lists.openid.net
> At: 01/15/25 04:33:30 UTC-5:00
> To:
> openid-specs-authzen at lists.openid.net
> Cc: Michiel.Trimpe at VNG.NL Subject:
> Re: [Openid-specs-authzen]
> Comments on the Authzen API GW Profile
>
> Hi Michael,
>
> Please see my responses in-line.
>
> Cheers, Michiel
> ------------------------------------------------------------------------
> *From:* Openid-specs-authzen
> <openid-specs-authzen-bounces at lists.openid.net>
> on behalf of Michael Schwartz
> via Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net>
> *Sent:* 15 January 2025 02:51
> *To:* AuthZEN Working Group
> List
> <openid-specs-authzen at lists.openid.net>
> *Cc:* Michael Schwartz
> <mike at gluu.org>
> *Subject:* [Openid-specs-authzen]
> Comments on the Authzen API GW
> Profile
> Here is the feedback on the
> discussion about the API GW
> authzen profile that I also
> posted on OpenID Authzen Slack
> for the official mailing list
> record:
>
> 1. IMHO, the Resource type
> should be "HTTP_Request" not
> "path" -- there is always way
> more to an API proxy decision
> than just a path. And the path
> itself is not even enough to
> uniquely identify a resource.
> The entitlement request is to
> perform an HTTP Request with a
> certain method and
> context--not to just access a
> certain path.
>
> > I spent quite a bit of time pondering the alternatives
> and given that we are looking
> for common identifier for a
> resource in the context of
> HTTP REST request; the Uniform
> Resource Identifier (a.k.a.
> `uri`) does really seem like
> the optimal fit.
>
> 2. We can define a minimum
> required schema but allow room
> for extension. I guess what
> I'm wondering is if we can
> reduce the scope of this
> profile more.
>
> 3. A URL may include schema,
> host, port, path, query, and
> fragment. Also, I wonder if
> the host should allow for
> policies based on the domain,
> i.e. for google.com
> <http://google.com/> domain do
> this.. for gmail.com
> <http://gmail.com/> domain...
> do something else.
>
> > That can be done using a
> simple "eq 'google.com
> <http://google.com/>' or
> endsWith '.google.com
> <http://google.com/>'"
> expression right? Determining
> what's colloquially understood
> as "the domain" requires an
> up-to-date TLD list to
> disambiguate e.g. "smtp.local"
> hostnames which are perfectly
> valid as well.
>
> 4. The HTTP request includes
> url , headers, body . These
> are all things the developer
> is sending from Postman in the
> request. IMHO, Context should
> be for data that is external
> to the resource, like the time
> of day, which you don't send
> in the Postman request.
>
> > From my perspective the Subject, Action and Resource
> is the information model of
> the authorization request. In
> the Dutch standard we'll also
> recommend implementers to
> define their AuthZEN
> information model up to the
> same standard of quality as
> their domain model. That
> includes defining syntax,
> semantics, constraints and
> relations for everything in
> their domain specific AuthZEN
> information model.
> When viewed from that
> perspective the "raw JWT"
> token or "raw X509
> certificate" feel more like an
> implementation detail. That is
> why I suggested moving them to
> context.
> For headers I can also make a
> case that they're properties
> describing/annotating the
> action that you intend to take
> (e.g. Accept headers request
> specific the type of content
> you wish to GET) so that it
> would make sense to include
> them in the `action` instead.
>
> 5. It's unclear why the sample
> shows the route as
> ".../pets/{id}". The request
> would be for an exact path3.
> It may seem trivial, but we
> don't want to define any kind
> of replacement or regex syntax
> here.
>
> > Route here refers to the
> something like "path
> templates" concept as
> described in e.g.
> https://swagger.io/specification/#paths-object or
> the router concept from SPA's
> like you e.g.
> https://www.w3schools.com/react/react_router.asp
> That's what you will generally
> want to base your policies on
> if they're available.
>
> 6. For the resource id (or the
> subject id), why not make it a
> hash of the properties? That
> way it will be unique, and
> represent the totality of the
> request. It's really quick and
> easy for the API gateway to
> generate a sha-256 hash.
> > What value would that add over leaving it empty
> then? Consistent JSON hashing
> is also surprisingly difficult
> as JSON objects are specified
> to be unordered
> <https://www.rfc-editor.org/rfc/rfc7159.html#section-1> .
>
> 7. I really don't like the
> subject sent as "JWT" with the
> value as the id. At a minimum,
> you should use the fingerprint
> of the token, and not the
> token itself. Perhaps it would
> be better to send client
> claims in the subject
> properties, like client_id,
> scopes, and allow for
> extension for customers who
> have custom access token claims?
> > I agree with this for the same reason I gave on #4.
> For me it still feels
> logical to define it as the
> value of 'sub' in the JWT
> token by default and provide
> the additional JWT parameters
> in the `subject.properties` to
> disambiguate that further if
> needed. That same pattern can
> then also be applied to
> X509/mTLS since they also have
> a Subject field that is
> generally enough but sometimes
> needs additional properties to
> be provided.
> I can also think of lots of
> counter examples though. An
> API gateway that resolves
> several different
> authentication patterns to the
> same identity probably
> wouldn't too happy to be
> forced to have a subject type
> for each authentication pattern.
>
> 8 .For the resource... what
> about something like this:
>
> "type": "AuthZen::HTTP_REQUEST",
> "id":
> "31d342599750a22f90a1d6b3d765549231e6b3091530f8f813e2f754e9d62422",
> "properties": {
> "header": {
> "Accept": "application/json",
> "User-Agent":
> "AuthzenClient/1.0",
> "Host": "www.acme.com
> <http://www.acme.com/>",
> "Content-Type":
> "multipart/form-data"
> },
> "url": {
> "scheme": "https",
> "host": "www",
> "domain": "acme.com
> <http://acme.com/>",
> "port": 443,
> "path": "/protected",
> "query": "query": {
> "param1": "value"
> }
> "fragment": "TOC"
> },
> "body": {
> "form1": {
> "field1": "value1",
> "field2": "value2"
> }
> }
> }
>
>
> --------------------------------------
> Michael Schwartz
> Glue
> Founder/CEO
> mike at gluu.org
> https://www.linkedin.com/in/nynymike
>
> ------------------------------------------------------------------------
> *CONFIDENTIALITY NOTICE*
> This message may contain
> confidential or legally
> privileged information.
> If you are not the intended
> recipient, please immediately
> advise the sender by reply
> e-mail that you received this
> message, and delete this
> e-mail from your system.
> Thank you for your cooperation
>
> -- Openid-specs-authzen
> mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
>
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
>
> ------------------------------------------------------------------------
> *CONFIDENTIALITY NOTICE*
> This message may contain confidential or
> legally privileged information.
> If you are not the intended recipient,
> please immediately advise the sender by
> reply e-mail that you received this
> message, and delete this e-mail from your
> system.
> Thank you for your cooperation
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
>
>
> --
>
>
>
> Alex Babeanu
> Lead Product Manager, Access Management
>
>
>
> t. +1 604 728 8130
> e. alex.babeanu at indykite.com
> <mailto:alex.babeanu at indykite.com>
> w. www.indykite.com <http://www.indykite.com/>
>
>
>
> ------------------------------------------------------------------------
> *CONFIDENTIALITY NOTICE*
> This message may contain confidential or legally
> privileged information.
> If you are not the intended recipient, please
> immediately advise the sender by reply e-mail that
> you received this message, and delete this e-mail
> from your system.
> Thank you for your cooperation
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
>
>
> ------------------------------------------------------------------------
> *CONFIDENTIALITY NOTICE*
> This message may contain confidential or legally privileged
> information.
> If you are not the intended recipient, please immediately advise
> the sender by reply e-mail that you received this message, and
> delete this e-mail from your system.
> Thank you for your cooperation
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
>
>
> --
>
>
>
> Alex Babeanu
> Lead Product Manager, Access Management
>
>
>
> t. +1 604 728 8130
> e. alex.babeanu at indykite.com <mailto:alex.babeanu at indykite.com>
> w. www.indykite.com <http://www.indykite.com/>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250124/ebc64c60/attachment-0001.htm>
More information about the Openid-specs-authzen
mailing list