Add support for AuthorizedIdentity credentials proxying#23546
Add support for AuthorizedIdentity credentials proxying#23546prithvip merged 3 commits intoprestodb:masterfrom
Conversation
766e3bd to
bfd988c
Compare
| import static java.util.Base64.getMimeDecoder; | ||
| import static java.util.Objects.requireNonNull; | ||
|
|
||
| public class JsonWebTokenAuthenticator |
There was a problem hiding this comment.
I am wondering if we can add the support of passing AuthorizedIdentity in the airlift code itself instead of moving the class into presto-main and adding this functionality.
There was a problem hiding this comment.
I considered this approach, but it would require airlift to understand Presto-specific concepts such as AuthorizedIdentity. There are some authenticators in airlift and some authenticators in Presto, so I think it is reasonable to move this authenticator to Presto.
presto-main/pom.xml
Outdated
| <groupId>io.jsonwebtoken</groupId> | ||
| <artifactId>jjwt-jackson</artifactId> | ||
| <scope>runtime</scope> | ||
| <scope>compile</scope> |
There was a problem hiding this comment.
you should be able to remove this line. compile is the default scope.
rschlussel
left a comment
There was a problem hiding this comment.
looks good, just small comment about removing the unneeded compile scope declaration.
ffbbed6
bfd988c to
ffbbed6
Compare
Description
This change allows for AuthorizedIdentity to be included as a claim in a JWT token. This is required for prestodb/rfcs#23, however this contribution is valuable on its own.
Motivation and Context
Today, Presto supports credentials proxying through means of a JWT token. The proxy authenticates the client, and constructs a JWT bearer token. The token is then signed and sent to the Presto coordinator in the "AUTHORIZATION" HTTP Header. The coordinator trusts the proxy if the token was signed using a shared secret (HMAC), or RSA key.
"Principal" can be proxied through a JWT token, by means of the "subject" claim. However, the AccessControl::selectAuthorizedIdentity method requires submittal of all the X509 certificates that the client presented. This is a problem in a proxy setup, because JWT credentials could only proxy the principal, and the certificates themselves would not be forwarded. To fully support proxying, this change allows for AuthorizedIdentity to be included as a claim in the same JWT token.
An alternative approach could be to forward the X509 certificates in a client-cert header, and implement IETF RFC 9440 (https://datatracker.ietf.org/doc/rfc9440/). However, this has two major drawbacks: 1) the proxy server would only be able to authenticate clients using certificate-based authentication 2) there would be issues with header size limitations. Thus, we chose to use the JWT mechanism instead.
Impact
No user-facing changes or performance impact.
Test Plan
Unit testing
Contributor checklist
Release Notes
Please follow release notes guidelines and fill in the release notes below.