[Openid-specs-authzen] Comments on the Authzen API GW Profile
Julio Auto De Medeiros (BLOOMBERG/ 731 LEX)
jautodemedei at bloomberg.net
Wed Jan 15 15:28:23 UTC 2025
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:00To: 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 domain do this.. for gmail.com domain... do something else.
> That can be done using a simple "eq 'google.com' or endsWith '.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 .
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",
"Content-Type": "multipart/form-data"
},
"url": {
"scheme": "https",
"host": "www",
"domain": "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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250115/fb05d00b/attachment-0001.htm>
More information about the Openid-specs-authzen
mailing list