Securing and Authenticating a Service Bus Connection
Updated: September 4, 2014
This section describes specific processes for using authentication on Microsoft Azure Service Bus.
Applications that use Service Bus are required to perform security tasks at two points. First, services exposed for use by Service Bus are resources. Therefore, access to them -- whether for configuration and registration purposes or for invoking service functionality -- requires authentication and authorization using tokens. Second, when permission to interact with the service has been granted by Service Bus, the service has its own security considerations that are associated with the authentication, authorization, encryption, and signatures required by the message exchange itself. This second set of security issues has nothing to do with the functionality of Service Bus; it is purely a consideration of the service and its clients.
In the first case, the authentication and authorization to use a service exposed by Service Bus are controlled either by a Shared Access Signature (SAS) token or by a token issued by the Access Control Service, and can be programmatically accessed through the Service Bus API. There are four types of authentication currently available:
CreateSharedAccessSignatureTokenProvider, which is used to define a SAS token provider credential.
Microsoft.ServiceBus.TokenProvider.CreateSharedSecretTokenProvider, a slightly more complex but easy-to-use form of username/password authentication.
Microsoft.ServiceBus.TokenProvider.CreateSamlTokenProvider, which can be used to interact with SAML 2.0 authentication systems.
Microsoft.ServiceBus.TokenProvider.CreateSimpleWebTokenProvider, which uses the OAuth Web Resource Authorization Protocol (WRAP)and Simple Web Tokens (SWT).
In the second case, the originating service itself typically applies some end-to-end security that specifies message-level security (such as message encryption) and transport-level security (such as Windows or NTLM). End-to-end conversation security follows the Windows Communication Foundation (WCF) programming model, and is discussed more fully in the Securing Services topic in the WCF documentation. Therefore, although the following topics contain a general discussion of end-to-end security, they focus mainly on the features unique to a service configured to use Service Bus.
Every Service Bus relay binding has a security binding element – for example, the NetTcpRelaySecurityElement class performs the security functions for the NetTcpRelayBinding – that contains the following security values that you can specify either programmatically or in a configuration file.
- Short for end-to-end security mode, this value defines the security across the message exchange through Service Bus. The programmatic value depends on the specific relay binding; for example, the Microsoft.ServiceBus.EndToEndSecurityMode class supports the NetTcpRelayBinding binding, and the Microsoft.ServiceBus.EndToEndWebHttpSecurityMode value performs this service together with the WebHttpRelayBinding binding. When used with the NetTcpRelayBinding binding, this property can be set to Microsoft.ServiceBus.EndToEndSecurityMode.None, Microsoft.ServiceBus.EndToEndSecurityMode.Message, Microsoft.ServiceBus.EndToEndSecurityMode.Transport, or Microsoft.ServiceBus.EndToEndSecurityMode.TransportWithMessageCredential. The default is Microsoft.ServiceBus.EndToEndSecurityMode.Transport, which means that the transport-specific security settings are enabled. If you use any setting that includes Microsoft.ServiceBus.EndToEndSecurityMode.Message or Microsoft.ServiceBus.EndToEndSecurityMode.Transport, you must set additional properties. In general, the Mode value follows the standard WCF security programming model.
- Defines security on a per-message basis if you set end-to-end message security to Microsoft.ServiceBus.EndToEndSecurityMode.Message or TransportWithMessageCredential. Setting one of those values for the Mode property requires that this property also be set to specify the type of credentials that are used, and also to the algorithm that is used to help secure the credentials. As with Mode, the message security setting follows the WCF programming model.
- This property is a wrapper for security properties unique to a given binding’s transport binding element. For example, the Microsoft.ServiceBus.RelayedOnewayTransportSecurity class exposes and implements the Microsoft.ServiceBus.RelayedOnewayTransportSecurity.ProtectionLevel setting on the NetEventRelayBinding and NetOnewayRelayBinding bindings. In contrast, the Microsoft.ServiceBus.HttpRelayTransportSecurity type sets proxy credentials for the BasicHttpRelayBinding and WS2007HttpRelayBinding bindings. As with the previous properties, Transport security generally follows the WCF security model.
- Controls whether clients of a service are required to present a security token issued by Access Control to Service Bus when it sends messages. Therefore, this security property is unique to Service Bus, and is the focus of topics in this section of the documentation. Services are always required to authenticate with Access Control and present an authorization token to Service Bus; otherwise, they cannot register endpoints, which engages Service Bus resources. However, clients are required to authenticate with Service Bus only if the RelayClientAuthenticationType is set to RelayAccessToken. Setting RelayClientAuthenticationType to Microsoft.ServiceBus.RelayClientAuthenticationType.None waives the requirement of a token. If you are providing your own authentication or if you do not need authentication, you may want to opt out of authentication on the client (sender) in the Service Bus leg of the communication. The default value is RelayAccessToken.
In addition, every binding contains the Scheme property, which defines the scheme used to encode information. For HTTP-based bindings (such as BasicHttpRelayBinding, the default scheme is HTTPS, which includes its own security protocols.
In This Section