chore(deps): deprecate arcus.security references in service-bus projects

[stijnmoreels]

• Deprecate all references to Arcus.Security types in the Service bus-related projects with a deprecation message on what to do instead.
• Remove all mentioning of the Arcus secret store in the Service bus-related documentation, and instead promote managed identity.

This is part of the excerise described in #470 where the Messaging repo becomes more lightweight and less dependent on other packages.

[netlify]

✅ Deploy Preview for arcus-messaging canceled.

Name	Link
🔨 Latest commit	9539465
🔍 Latest deploy log	https://app.netlify.com/sites/arcus-messaging/deploys/67bd72ce3897a50008695f30

[fgheysels]

I think we should not only support ManagedIdentity to connect to ServiceBus.
While we can remove the dependency to Arcus.Security, I think we should still have a way to connect to ServiceBus by specifying a clientid / clientsecret for instance. But, instead of passing in a secretname and use that secretname to retrieve the secret from KeyVault using Arcus.Security, we could pass in the secret directly.
It's then the responsibility of the client application to retrieve the secret from a secure location and use it.

[stijnmoreels]

I think we should not only support ManagedIdentity to connect to ServiceBus. While we can remove the dependency to Arcus.Security, I think we should still have a way to connect to ServiceBus by specifying a clientid / clientsecret for instance. But, instead of passing in a secretname and use that secretname to retrieve the secret from KeyVault using Arcus.Security, we could pass in the secret directly. It's then the responsibility of the client application to retrieve the secret from a secure location and use it.

That's still kinda possible as we still support the IConfiguration overload, where people can register their own source/authentication and retrieve it there.

[fgheysels]

I think we should not only support ManagedIdentity to connect to ServiceBus. While we can remove the dependency to Arcus.Security, I think we should still have a way to connect to ServiceBus by specifying a clientid / clientsecret for instance. But, instead of passing in a secretname and use that secretname to retrieve the secret from KeyVault using Arcus.Security, we could pass in the secret directly. It's then the responsibility of the client application to retrieve the secret from a secure location and use it.

That's still kinda possible as we still support the IConfiguration overload, where people can register their own source/authentication and retrieve it there.

I'd have to take a look at what you mean exactly.
My idea would just be to provide a method that allows you to specify the clientid / clientsecret itself. Arcus should not be responsible for retrieving that information. The program / component that hosts Arcus.Messaging should be responsible.

[stijnmoreels]

I'd have to take a look at what you mean exactly.
My idea would just be to provide a method that allows you to specify the clientid / clientsecret itself. Arcus should not be responsible for retrieving that information. The program / component that hosts Arcus.Messaging should be responsible.

Currently supported, even after this PR:

Host.CreateDefaultBuilder()
    .ConfigureAppConfiguration(config => config.AddAzureKeyVault(new Uri(...), new ClientSecretCredential(...))
    .ConfigureServices(services =>
    {
        services.AddServiceBusTopicMessagePump("<subscription>", (IConfiguration config) =>
        {
            return config["Topic:ConnectionString:From:IConfig:Via:KeyVault");
        });
    });

[fgheysels]

I'd have to take a look at what you mean exactly.
My idea would just be to provide a method that allows you to specify the clientid / clientsecret itself. Arcus should not be responsible for retrieving that information. The program / component that hosts Arcus.Messaging should be responsible.

Currently supported, even after this PR:

Host.CreateDefaultBuilder()
    .ConfigureAppConfiguration(config => config.AddAzureKeyVault(new Uri(...), new ClientSecretCredential(...))
    .ConfigureServices(services =>
    {
        services.AddServiceBusTopicMessagePump("<subscription>", (IConfiguration config) =>
        {
            return config["Topic:ConnectionString:From:IConfig:Via:KeyVault");
        });
    });

Yeah, but it's a pity you have to use it like that if your program that is using Arcus.Messaging is also using Arcus.Security.
In such case, I think it would be better if we can directly pass in the clientid/clientsecret.
I'l have to peek into the code to see if I can provide an example of what I mean.

[stijnmoreels]

Yeah, but it's a pity you have to use it like that if your program that is using Arcus.Messaging is also using Arcus.Security. In such case, I think it would be better if we can directly pass in the clientid/clientsecret. I'l have to peek into the code to see if I can provide an example of what I mean.

Think that is a bit the purpose, that people see that they need to migrate to something else.
Happy to discuss this separately.

[fgheysels]

I'd have to take a look at what you mean exactly.
My idea would just be to provide a method that allows you to specify the clientid / clientsecret itself. Arcus should not be responsible for retrieving that information. The program / component that hosts Arcus.Messaging should be responsible.

Currently supported, even after this PR:

Host.CreateDefaultBuilder()
    .ConfigureAppConfiguration(config => config.AddAzureKeyVault(new Uri(...), new ClientSecretCredential(...))
    .ConfigureServices(services =>
    {
        services.AddServiceBusTopicMessagePump("<subscription>", (IConfiguration config) =>
        {
            return config["Topic:ConnectionString:From:IConfig:Via:KeyVault");
        });
    });

True.
But, then you're forced to store a connectionstring (secret) in your configuration. One of the reasons we have Arcus.Security is to make a distinction between secrets and configuration.
When you want to go that route, you'll need to add your secret-store (KeyVault for instance) as a Configuration-source (which is possible, but do we want that ?). Another solution is to use KeyVault-references in your Configuration (which is also a valid way of working but then again, no explicit distinction between secrets & configuration).

I do understand that you want to remove the dependency to Arcus.Security though.
Therefore, as an alternative for teams that use Arcus.Messaging and Arcus.Security, I would provide an option to pass in the connection-string directly.
It's then the responsability of the program that uses those libraries to retrieve the connectionstring from the secret-store and pass it to Arcus.Messaging. Something like this:

string connectionstring = await secretProvider.GetRawSecretAsync(mySecretName);

services.AddServiceBusQueueMessagePump(connectionString);

[fgheysels]

I'm not a fan of having to retrieve the connctionstring from config.
Why not just pass in the connectionstring as a string ? Its the responsibility of the user to retrieve it from any location he wants.

[fgheysels]

I believe we can make the entire class obsolete ?

[stijnmoreels]

Yes, probably in time, but the scope of this PR is only to deprecate Arcus.Security references.

[stijnmoreels]

Oh, my mistake, thought that this was another extensions class, yes we can.

[stijnmoreels]

Best to discus this separately: 'What to do with projects that use Arcus.Security in combination with Arcus.Messaging.’

What I think about:

1. Arcus.Security is valid and ambitious way of separating config from secrets, but it is yet another repository to maintain, which cannot be done in the current way of working;
2. Arcus.Messaging provides still added-value and can definitely have a future and support when it becomes lightweight enough to maintain further. To do that, we need to reduce the dependencies (Arcus.Security, Arcus.Observabiltity, ApplicationInsights, AzureFunctions and Serilog come to mind).
3. Figuring out what to expose as functionality is critical, as this has to be modular enough. (The thing you proposed of having the connection string directly, would mean yet an extra extension for an already too-big extension set for registering message pumps. Also: retrieving a secret store at that point isn’t really possible in a safe way, I believe, as the pump is registered at the same time as the secret store: through the services).