[QUERY] Migrating to new azure-messaging-eventhubs: SharedAccessSignatureTokenProvider & ConnectionStringBuilder missing

[derSchtefan]

Query/Question
After being informed by the IntelliJ plugin that the com.microsoft.azure::azure-eventhubs SDK is replaced by azure-messaging-eventhubs, we migrated, but saw that SharedAccessSignatureTokenProvider and ConnectionStringBuilder are missing. We use this in a cloud service to generate EventHub Publisher Policy bound tokens like described here (https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features#publisher-policy).

The code used to look like this:

val ttl = Duration.ofDays(tokenTimeToLive * 365L);
val authRule = this.getEventHubKey(eventHubConnectionStringConfig);

val sasToken = SharedAccessSignatureTokenProvider.generateSharedAccessSignature(
        eventHubConnectionStringConfig.getEventHubAuthorizationRuleName(), authRule.getKeys().primaryKey(), 
        URI.create("http://" + eventHubConnectionStringConfig.getEventHubUri() + "/" + eventHubConnectionStringConfig.getEventHubName()+ "/publishers/" + publisherName).toString(), ttl);

val connectionStringBuilder = new ConnectionStringBuilder().setEndpoint(eventHubConnectionStringConfig.getEventHubUri())
    .setNamespaceName(eventHubConnectionStringConfig.getEventHubNameSpace())
    .setEventHubName(eventHubConnectionStringConfig.getEventHubName() + "/publishers/" + publisherName)
    .setSharedAccessSignature(sasToken);

return connectionStringBuilder.toString();

This was quite useful and better than manually crafting the SAS token and connection string URL.
However, these two classes are gone -- are there replacement classes or mechanisms? Either in this or a management SDK?
Or do we have to manually reimplement the logic, following official Microsoft documentation?

Why is this not a Bug or a feature Request?
It is neither a bug nor a feature request because whoever removed the classes must have had a reason.

Setup (please complete the following information if applicable):

• Library/Libraries: azure-messaging-eventhubs 5.10.1

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Query Added
• Setup information Added

[joshfree]

@conniey could you follow up with @derSchtefan on their question?

[conniey]

Hey, you would want to use credential(String, String, AzureSasCredential) when constructing your client from the EventHubClientBuilder. I hope this helps.

[ramya-rao-a]

@conniey Can you make sure our migration guide covers this?

[derSchtefan]

I am sorry @conniey , but I fail to see how I can use credential(String, String, AzureSasCredential) for my purpose.

To clarify: In a cloud service, we are building a connection string that is based on a publisher policy and signed by an Authorization Rule's key.

This connection string is then given to clients. The service creating the connection string is not using it to build a connection.

As you can see in the original post we use SharedAccessSignatureTokenProvider and ConnectionStringBuilder from the old SDK which were public classes that basically handled signing and building the connection string for us.

As far as we understand there is no mechanism like this for our scenario in the new SDK. Everything in the SDK assumes that a connection is to be established with the credentials provided, there is no pure "connection string builder".

[ramya-rao-a]

Hey @derSchtefan

Apologies for the late response here.

It is neither a bug nor a feature request because whoever removed the classes must have had a reason.

You are right. The classes SharedAccessSignatureTokenProvider and ConnectionStringBuilder were removed for a reason. This was done to comply with the policy of not allowing connection strings that are hand built and not available via the Azure portal (or tooling like Azure CLI). There is along discussion in Azure/azure-sdk#1701 where we concluded with adding an exception to this rule for the SharedAccessSignature i.e. the SAS token. The assumption was that one could follow the (docs for generating a signature(token) from a policy)[https://docs.microsoft.com/en-us/azure/event-hubs/authenticate-shared-access-signature#generating-a-signaturetoken-from-a-policy] and either build a connection string or use the builder that takes the sas token.

What we missed is the case of publisher policy which requires more support than just accepting the SAS token in the client builder. We will be taking this as a feature request for the next semester.

[github-actions]

Hi @derSchtefan, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.