Closed yvesgoeleven closed 9 years ago
I think we just need to support a custom TokenProvider in configuration and instantiation of the MessagingFactory, but this gets interesting as you can no longer use MessagingFactory.CreateFromConnectionString(), so I would like to see the refactoring of the config / settings to move to connection string properties. We can either handle setting a custom TokenProvider or even just a pluggable interface for the MessagingFactory -> IMessagingFactoryFactory :)
How do we handle multiple connection strings for different namespaces?
/NServiceBus.Transports = Endpoint:sb://primary /NServiceBus.Transports/audit = Endpoint:sb://audi /NServiceBus.Transports/ns1 = Endpoint:sb://foobar
That one is already abstracted away by ICreateMessagingFactories, so should be pretty easy to do
Currently you can only set connectionstrings in the message mappings by replacing @machinename but the model you suggest is on our radar as well
We have a spike for this in our project, we still need some testing and its a separate assembly where we provide our own AdfsTokenProvider that uses the SamlTokenProvider under the covers.
I am not sure the best way to work this into NSB/Azure proper. We took a dependency on Thinktecture.IdentityModel in order to make the wstrust call to our ADFS to get the Saml Token. My guess is we don't want that dependency here.
Maybe we can just cleanup the API to make it easier to plugin a custom TokenProvider and we can publish our AdfsTokenProvider as a separate project with no NSB Dependencies?
Its a funny thing because OOB ServiceBus supports the SamlTokenProvider, the problem is the token provider takes a static saml token, so when that saml token expires you are screwed. Our AdfsTokenProvider delegates to an instance of an inner SamlTokenProvider and will attempt to get a new SamlToken and initialize a new inner SamlTokenProvider when the saml token expires. Otherwise stuff would just start failing everywhere and you would have to reinitialize the whole messagingfactory or bus.
I agree we should make this pluggable instead, would you need another plugin point than ICreateMessagingFactories to achieve this?
After a few hacks I was finally able to plugin in our custom AdfsTokenProvider with ICreateMessagingFactories. See #116, #119, #120 for my issues involved with trying to implement this. The nicer extensibility point would be ICreateTokenProviders.Create(string connectionString) so we can defer the heavy lifting to the existing infrastructure services and just swap out the token provider implementation.
This is actually really cool, we are managing our whole service bus with domain credentials and active directory groups :)
Awesome!
I'll make sure the desired entrypoints get into the next release.
This should be feasible now, given the new topology model
http://msdn.microsoft.com/en-us/library/windowsazure/jj136813.aspx