AAD login
Hello
Can we have an Azure Active directory login to have access to our services bus ?
We don't want to have any password / keys on our computers
Thanks
@ChoOo7, that's something that's on the roadmap. However, currently 95% of the code Service Bus Explorer is using to communicate with queues and topics is using the oldest Service Bus SDK. The remaining 5% is using the latest Service Bus SDK. For several reasons we want to migrate everything to the latest SDK and that has a higher priority for me.
However, you or anyone else is most welcome to come up with a design suggestion for AAD login. I recommend starting with that before creating a PR since this a complicated issue.
I think the easiest solution is to use AzureCliCredential or InteractiveBrowserCredential when authenticating against Azure Service Bus. The new SDK already provides an option to use TokenCredential.
public ServiceBusClient(string fullyQualifiedNamespace, TokenCredential credential);
@Rookian
However, currently 95% of the code Service Bus Explorer is using to communicate with queues and topics is using the oldest Service Bus SDK.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I really want this feature so we can stop using access keys!
Azure AD auth will be a huge win for this tool! There is some very valuable functionality such as fix/resubmit from dead letter queue which are not available in the portal. However the only way for a team to use this is they all have to have connection string with the keys which is not secure.
Is there any update on this? I just looked at the code and it seems as if the old sdk has been removed. With the new sdk it should be fairly simple to integrate this, since both the ServiceBusClient and ServiceBusAdministrationClient support passing a TokenCredential.
I can see two ways of integrating this:
-
Add a ui feature that allows one to specify whether to authenticate via active directory or not. Something like this. And if specified, a flag is passed that allows the ServiceBusClient and ServiceBusAdministrationClient to be constructed with InteractiveBrowserCredentials. This would then open a browser window where one can sign in and the rest should be handled by the sdk out of the box

-
add a magic connecting string. This is how the sqlclient handles it too. One could for example specify a connection string like this
Endpoint=sb://....servicebus.windows.net/;Authentication=Active Directory Interactive
Then provide a factory for creating a ServiceBusClient and ServiceBusAdministrationClient that can interpret the connection string and constructs the client with InteractiveBrowserCredentials. Use the factory instead of constructing the clients directly. This solution is not as elegant as the first, but I think it should be very simple to implement, as no ui changes are needed and the code only needs to be changed in a handful of places.
This would be a great benefit so that we can leverage the RBAC that we have set up on our ASB resources. Is there any update on projected release?
This would be great to have as we move over to RBAC model for service bus.
Azure AD login would be very usefull, please let us have the option to move away from connection strings with secret keys.
would be great to have this supported
Would also really like to have AD auth for this 🙏
Would be incredibly useful to have this implemented.
I would say this is an essential feature as our company moves to disable local authentication (SAS key). Until then, the Azure portal provides an AAD integrated service bus explorer that one can use.
Hello, Supporting AAD is a pretty important thing for the user who cannot use connection strings for security reasons. Please add it ;)
Pretty much stopped using Service Bus Explorer since Managed Identity is best practice for accessing Service Bus. Would love to still use it, but without Managed Identity support it’s not possible.
Hi @ErikMogensen!
What is your estimated level of effort for someone who hasn't been developing in the code base? If it's possible now (I believe you've migrated from the old SDK?) then I wouldn't mind taking a stab at this. But it would of course depend on the complexity of the issue...
@jooooel, unfortunately, the code hasn’t been migrated yet.
Also looking forward to be able to use managed identities. Many companies now move away from the sas tokens and only allow managed identity, thus removing the possibility to servicebus explorer.
@SeanFeldman is there a way to support the transition? idk how much work is left in migrating?
@SeanFeldman is there a way to support the transition? idk how much work is left in migrating?
Yes i second this, would not mind contributing to this.
is there a way to support the transition? idk how much work is left in migrating?
@Merlijnv, absolutely. The biggest work is in transitioning off the old SDK to the new multiple SDKs (ASB, EH). This is the first step towards supporting AAD.
Yes i second this, would not mind contributing to this.
@mennolaan, that's terrific! I've created a designated milestone to capture the work needed to be done to migrate SDKs. Have a look at the issues, feel free to add additional ones that are relevant for that effort.
cc @paolosalvatori, @ErikMogensen
@SeanFeldman what is the best starting point? Is there a discord or something to chat? I have time tomorrow and the day after tomorrow 😄
@Merlijnv, that's the tricky part. We're all fully dispersed with availability constraints.
If I had to do that, I'd get familiar with the codebase first and then try to see if replacing certain code paths with the newer SDKs is a go or not. We've tried that with ServiceBusHelper by introducing ServiceBusHelper2, as an experiment.
@SeanFeldman I see some other issue #527 saying that the biggest blocker for .net 5 is WindowsAzure.ServiceBus should that be my first focus?
Becides that I see also #286 talking about cross platform idk if that's something you guys are still looking into?
To check all WindowsAzure.ServiceBus, Microsoft.ServiceBus.Messaging and such should be migrated to Azure.Messaging.ServiceBus. Is that correct?
@Merlijnv, WindowsAzure.ServiceBus is the main blocker so if you got rid of it, it would be wonderful. It is a huge job though. You have to migrate to the different SDKs that support ServiceBus, Event Hubs and Relay. There are features missing so keeping backwards compatibility may not be possible. I suggest you choose one of the services to start with. I know that the latest SDK for Event Hubs management is lacking support for authorization using SAS so you have to add a login for Entra authentication for that.
We decided that cross platform will have to wait at least until WindowsAzure.ServiceBus has been removed.
@ErikMogensen Ah okay thanks for the explanation. I will prob begin with servicebus because at our project we don't use the other 2 so I have no way to test. Prob will create a way to test when I am done with servicebus and nobody else started on it. I will try and expand the servicebushelper2 with all the methods that can be used in the new sdk. Is there anything else I should know or pay attention to?
Sounds good. There is a guide at https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/servicebus/Azure.Messaging.ServiceBus/MigrationGuide_WindowsAzureServiceBus.md
Any feature that is missing in Azure.Messaging.ServiceBus and not documented as missing is interesting so please put a comment here. @paolosalvatori can notify the Service Bus Product Group about it and there is a chance that they may implement it.
There is a large PR for Event Grid, #737, that affects MainForm.cs and perhaps other central parts so please keep an eye on that one to avoid merge issues.
@Merlijnv, everything that Erik said. I can help with the ASB, assuming I have availability to do so. If you want to start a PR and ping me with some questions as you progress, we can try that.
I will try and expand the servicebushelper2 with all the methods that can be used in the new sdk.
`ServiceBusHelper2 is just a helper. Don't worry about it too much. If needs to go, it can be removed as well.
Regarding EventGrid PR - I'm looking after that one. We don't need to worry about it until it's merged into master and then whatever you'll have at that point would need to be rebased. But let's not worry about it ahead of the time.
We decided that cross platform will have to wait at least until WindowsAzure.ServiceBus has been removed.
Are you implying there's a plan to rewrite ServiceBusExplorer with Avalonia UI or Uno Platform? Because cross platform WinForms is definitely not happening.
Edit: Nevermind, I skimmed over this issue a bit too fast. There's already an issue dedicated to cross platform support: #286
@SeanFeldman Do you maybe have some time maybe next monday at 10am (that's 18.00 my time)? I need some quick walkthrough as to which code will be hit first and how everything gets called.