adutra opened a new pull request, #10753: URL: https://github.com/apache/iceberg/pull/10753
As discussed in the sync meeting, here is a PR that builds on top of @jackye1995 original work here: #10621. I kept his original commit intact for reference. The main components introduced in this PR are: * `AuthManager`: manages authentication data for an owning catalog or other service. * `AuthSession`: represents a session of authentication data (typically, headers), which can be used to authenticate outgoing requests. ### Auth schemes Two existing auth schemes were retrofitted to implement the new interfaces: OAuth (see `OAuth2Manager`) and Sigv4 (see `RESTSigV4AuthManager` and `RESTSigV4Signer`). Two other auth schemes were introduced: `BasicAuthManager` and `NoopAuthManager`. The former is a simple manager that authenticates with a username and password using basic auth, and the latter is a manager that does nothing and that is used when authentication is disabled. I chose to include these components mainly to serve as examples of simple managers, but who knows if some catalogs out there could find interest in using the Basic one. ### Configuration A new `AuthProperties` class was introduced to hold new properties that are used to configure authentication. Following the idea of properly namespaced options, the new properties are all prefixed with `rest.auth.<auth-type>.` where `<auth-type>` is the name of the auth scheme. Selecting an auth scheme is done by setting the `rest.auth.type` property. Schemes can be selected by their logical name (e.g. `oauth2`, `basic`, `sigv4`, `none`) or directly by a class name implementing `AuthManager`. ### OAuth-specific components This PR doesn't change the way OAuth is used in the REST catalog, only moves the logic to the new `OAuth2Manager` class. OAuth properties weren't modified either. Imho it would be good at some point to refactor `OAuth2Util` into something more extensible, but that's out of the scope for now. ### AWS-specific components AWS SigV4 authentication was previously enabled by the `rest.sigv4-enabled` option. This property is still supported, but it is now deprecated in favor of `rest.auth.type=sigv4`. Also, `RESTSigV4Signer` used to implement Apache HTTP client's `HttpRequestInterceptor` interface, and was injected (at a rather low layer) by `HTTPClient.Builder.build()`. This has been replaced and `RESTSigV4Signer` is now created in a higher layer (catalog level). Note that this change opens up new opportunities; e.g. it is now possible to do more fine-grained operations e.g. create context- or table-specific signers. But the current implementation of `RESTSigV4AuthManager` does not take full advantage of this new flexibility for now and simply creates one single signer to sign all requests, just as it was before. Another AWS-specific component had to be adapted: `S3V4RestSignerClient` (enabled by the `s3.remote-signing-enabled` option): contrary to `RESTSigV4Signer`, `S3V4RestSignerClient` sends signing requests to the REST catalog itself, which in turn may require authentication. _This component has some shortcomings_ that are not addressed in this PR (e.g., it never closes its resources), but nevertheless, it is now delegating authentication to a (somewhat simplified) `AuthManager` instead of managing that itself. ### Implementation details Caching of sessions: responsibility for caching sessions has been transferred from `RESTSessionCatalog` and `S3V4RestSignerClient` to become an implementation detail of `AuthManager` impls. Interference with HTTP Client `CredentialsProvider`: a `CredentialsProvider` can be passed to `HTTPClient.Builder` to implement proxy authentication. This PR does not change that. Care must be taken to avoid interference between the `CredentialsProvider` and the `AuthManager` (i.e. the proxy authentication should apply only proxy auth headers to outgoing requests, but this isn't enforced and interference was already possible). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
