Particular / NServiceBus.Azure

Transports and storage for Windows Azure
https://docs.particular.net/nservicebus/azure/
Other
10 stars 15 forks source link

Support for ASB/ACS/ADFS integrated security #104

Closed yvesgoeleven closed 9 years ago

yvesgoeleven commented 10 years ago

http://msdn.microsoft.com/en-us/library/windowsazure/jj136813.aspx

abombss commented 10 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

yvesgoeleven commented 10 years ago

That one is already abstracted away by ICreateMessagingFactories, so should be pretty easy to do

yvesgoeleven commented 10 years ago

Currently you can only set connectionstrings in the message mappings by replacing @machinename but the model you suggest is on our radar as well

abombss commented 10 years ago

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.

yvesgoeleven commented 10 years ago

I agree we should make this pluggable instead, would you need another plugin point than ICreateMessagingFactories to achieve this?

abombss commented 10 years ago

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 :)

yvesgoeleven commented 10 years ago

Awesome!

I'll make sure the desired entrypoints get into the next release.

yvesgoeleven commented 9 years ago

This should be feasible now, given the new topology model