-
Notifications
You must be signed in to change notification settings - Fork 3
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
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
// 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); |
There was a problem hiding this comment.
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.
// and getting all subjects. | ||
srClient.getAllSubjects(); | ||
// and getting all schema types | ||
srClient.getSchemaTypes(); |
There was a problem hiding this comment.
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.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this 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/main/java/io/confluent/idesidecar/restapi/application/ProxyProcessorBeanProducers.java
Outdated
Show resolved
Hide resolved
@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, |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. 👍
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this 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.
Summary of Changes
Closes #126
Changes related to fixing OAuth credentials:
logicalClusterId
-- this is used when connecting to CCloud Kafka/SR over OAuth. See this docs page.identityPool
toidentityPoolId
for clarityOnce 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 eachCredentials
type. This is then used as part of the SR proxy implementation.Implementing
httpAuthenticationHeaders
is simple enough forBasicCredentials
(orApiKeyAndSecret
) since it's only a matter of base64 encoding theusername:password
string, however, forOAuthCredentials
, this is likely much more complex given the breadth of configs available.The remaining changes in the PR:
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):