Support for OAuth Protected Resource Metadata (RFC 9728)

[adutra]

Is your feature request related to a problem? Please describe.

Quarkus 3.25 has introduced support for RFC 9728:

https://quarkus.io/guides/security-oidc-expanded-configuration#resource-metadata-properties

With that, Polaris servers could advertise the authorization server URL to interested clients.

For now, Iceberg REST clients do not leverage this possibility, but this could change in the future.

The Dremio Auth Manager has an issue to track support for this feature on its side:

dremio/iceberg-auth-manager#46

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

[singhpk234]

Thank you for the ticket @adutra for my understanding :
this would mean now a client (without OAuth) when hits the Application server lets say for loadTable would be given the following metadata :

{
  "resource": "<>/namespace/ns/table/tbl",
  "authorization_server": "<as_url>"
}

Now its up to client to obtain OAuth token by contacting the AS and obtain a token (will it always be on-behalf token, my guess is not ?) now post obtaining the token the client with the token will come back to the resource server to get Authenticated ?

wondering what are the some workflows which will be enabled by this ? is just that the burden of configuring the right Auth Server is taken away from the client

[adutra]

@singhpk234 not exactly, the catalog server must expose a new endpoint, by default /.well-known/oauth-protected-resource. This endpoint returns something like:

{
   "resource":  "https://polaris.example.com",
   "authorization_servers":   ["https://as1.example.com",  "https://as2.example.net"],
   "bearer_methods_supported": ["header"],
   "scopes_supported": ["catalog"],
   "resource_documentation": "https://polaris.apache.org/"
  }

An Iceberg REST client could interrogate this endpoint prior to invoking the config endpoint in order to understand where is the authorization server located and which scopes are required to access Polaris.

Also, Polaris could redirect the client to the metadata endpoint automatically when the client fails to authenticate properly, by including the metadata endpoint in the WWW-Authenticate header in the 401 response.

[singhpk234]

Thank you @adutra ! This helps me understand this better

the catalog server must expose a new endpoint, by default /.well-known/oauth-protected-resource

I see so the client needs to contact this endpoint to get the AS servers to know as well as which scopes they need, then lets say they need to do client credentials flow, they will do with this scope and get the OAuth and then use this for subsequent Auth ?

wondering still when is the case this flow be better than what we already have ? is it like it takes the responsibility from the client to know the AS directly and the scopes ?

[adutra]

@singhpk234 this feature wouldn't revolutionize the datalake space for sure 😄 it's just a way to require less configuration from clients as the catalog URI would be enough for the client to figure out the authorization server URI. Same for things like scope etc.

IOW it's a nice to have, not a must have!