Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix OAuthCredentials (and connecting to SR via direct connections) #290

Merged
merged 11 commits into from
Jan 14, 2025

Conversation

rohitsanj
Copy link
Contributor

@rohitsanj rohitsanj commented Jan 9, 2025

Summary of Changes

Closes #126

Changes related to fixing OAuth credentials:

  • Adds a new credential option for logicalClusterId -- this is used when connecting to CCloud Kafka/SR over OAuth. See this docs page.
  • Rename identityPool to identityPoolId for clarity
  • Fix JAAS config construction by adding a semicolon at the end.

Once I fixed the above, I noticed that Kafka requests were going through fine but the SR requests were all failing with a 401. After some investigation, I found that we need to implement the httpAuthenticationHeaders method for each Credentials type. This is then used as part of the SR proxy implementation.

Implementing httpAuthenticationHeaders is simple enough for BasicCredentials (or ApiKeyAndSecret) since it's only a matter of base64 encoding the username:password string, however, for OAuthCredentials, this is likely much more complex given the breadth of configs available.

The remaining changes in the PR:

  • The SR proxy implementation now uses the cached SchemaRegistryClient instance to issue the request instead of constructing the full HTTP request ourselves.

Any additional details or context that should be provided?

I tested the OAuth credentials against Confluent Cloud by connecting to a Kafka cluster. Followed this guide to setup Okta as an OAuth provider.

Pull request checklist

Please check if your PR fulfills the following (if applicable):

  • Tests:
    • Added new
    • Updated existing
    • Deleted existing
  • Have you validated this change locally against a running instance of the Quarkus dev server?
    make quarkus-dev
  • Have you validated this change against a locally running native executable?
    make mvn-package-native && ./target/ide-sidecar-*-runner

@sonarqube-confluent

This comment has been minimized.

@sonarqube-confluent

This comment has been minimized.

@sonarqube-confluent

This comment has been minimized.

@sonarqube-confluent

This comment has been minimized.

Comment on lines -321 to +324
// CCloud requires the logical cluster ID to be set in the properties, so examine the URL
var logicalId = CCloud.SchemaRegistryIdentifier
.parse(srUri)
.map(CCloud.LsrcId.class::cast)
.map(CCloud.LsrcId::id)
.orElse(null);

// Add any properties for SR credentials (if defined)
var options = connection
.getSchemaRegistryOptions()
.withRedact(redact)
.withLogicalClusterId(logicalId);
.withRedact(redact);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Confluent Cloud logical cluster id for a schema registry will need to be provided by the user as part of the credentials config in case of OAuth credentials. We cannot infer the "logical" cluster id from the Schema Registry URI which may or may not contain the cluster id in its first part. Moreover, a given physical cluster id may host multiple logical cluster ids.

Comment on lines -244 to +228
// and getting all subjects.
srClient.getAllSubjects();
// and getting all schema types
srClient.getSchemaTypes();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getSchemaTypes is much less expensive than a getAllSubjects call. This is kind of unrelated to the PR's changes.

@rohitsanj rohitsanj changed the title Fix OAuthCredentials Fix OAuthCredentials (and connecting to SR via direct connections) Jan 13, 2025
@sonarqube-confluent

This comment has been minimized.

@rohitsanj rohitsanj marked this pull request as ready for review January 13, 2025 18:43
@rohitsanj rohitsanj requested a review from a team as a code owner January 13, 2025 18:43
Copy link
Contributor

@flippingbits flippingbits left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work, @rohitsanj! I have a few minor comments. Otherwise, your PR looks good to me!

src/generated/resources/openapi.json Outdated Show resolved Hide resolved
Comment on lines 60 to 65
@Schema(description = "Additional property that can be added in the request header to identify "
+ "the logical cluster ID to connect to. For example, this may be a Confluent Cloud " +
"Kafka or Schema Registry cluster ID.")
@JsonProperty(value = "logical_cluster_id")
@Null
String logicalClusterId,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know if the logicalClusterId is needed for clusters other than CCloud ones? If not, what about modeling this in a bit more generic way so that we can maybe support other extension_s as well without having to introduce new fields to the OAuthCredentials?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, yeah it is definitely CCloud specific, but so is the other identityPoolId field.

If not, what about modeling this in a bit more generic way so that we can maybe support other extension_s as well without having to introduce new fields to the OAuthCredentials?

Hm, would it be fine to revisit this at a later point? For now I imagine that we will have some client-side logic that will only surface these fields for direct connections to Confluent Cloud.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification! From my POV, it's fine to add these two fields now because we probably won't need to support any other custom JAAS configs in the near/mid term.

Hm, would it be fine to revisit this at a later point?

I don't think we can remove them at a later point as they'll be part of the API contract and Direct Connection form. Removing them would have an impact on existing Direction Connections of users and be a breaking change.

For now I imagine that we will have some client-side logic that will only surface these fields for direct connections to Confluent Cloud.

Maybe make it clear that these fields are only relevant for Direct Connections that target CCloud clusters by, for instance, adding the prefix ccloud_ to their names?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can remove them at a later point as they'll be part of the API contract and Direct Connection form. Removing them would have an impact on existing Direction Connections of users and be a breaking change.

Makes sense. Thanks for mentioning.

adding the prefix ccloud_ to their names?

Prefixing ccloud_ sounds good. 👍

@sonarqube-confluent

This comment has been minimized.

@sonarqube-confluent
Copy link

Failed

  • 69.30% Coverage on New Code (is less than 80.00%)

Analysis Details

4 Issues

  • Bug 0 Bugs
  • Vulnerability 0 Vulnerabilities
  • Code Smell 4 Code Smells

Coverage and Duplications

  • Coverage 69.30% Coverage (80.20% Estimated after merge)
  • Duplications No duplication information (0.60% Estimated after merge)

Project ID: ide-sidecar

View in SonarQube

@flippingbits flippingbits self-requested a review January 14, 2025 19:19
Copy link
Contributor

@flippingbits flippingbits left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update, @rohitsanj! LGTM.

@rohitsanj rohitsanj merged commit 85fca10 into main Jan 14, 2025
2 checks passed
@rohitsanj rohitsanj deleted the fix-oauth-direct branch January 14, 2025 20:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add OAuth 2.0 authN to direct connections
2 participants