Securing and Authenticating a Service Bus Connection

Applications that use the Windows Azure Service Bus are required to perform security tasks at two points. First, services exposed for use by the 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 from the Windows Azure Access Control service. Second, when permission to interact with the service has been granted by the 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 the Service Bus; it is purely a consideration of the service and its clients.)

In the first case, authentication and authorization to use a service exposed by the Service Bus are controlled by the Access Control service, and can be programmatically accessed through the Service Bus API. There are four kinds of authentication currently available:

• SharedSecret, a slightly more complex but easy-to-use form of username/password authentication.
  
  
• Saml, which can be used to interact with SAML 2.0 authentication systems.
  
  
• SimpleWebToken, which uses the OAuth Web Resource Authorization Protocol (WRAP)and Simple Web Tokens (SWT).
  
  
• Unauthenticated, which enables interaction with the service endpoint without any authentication behavior.
  
  

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 the Service Bus. For additional information about Service Bus authentication and Access Control, see Building Applications that Use Access Control Services.

Every Service Bus relay binding has a security binding element – for example, the NetTcpRelaySecurityElement performs the security functions for the NetTcpRelayBinding – that contains the following security values that you can specify either programmatically or in a configuration file.

Mode

Short for end-to-end security mode, this value defines the security across the message exchange through the Service Bus. The programmatic value depends on the specific relay binding; for example, the EndToEndSecurityMode type supports the NetTcpRelayBinding binding, and the EndToEndWebHttpSecurityMode value performs this service together with the WebHttpRelayBinding binding. When used with the NetTcpRelayBinding binding, this property can be set to None, Message, Transport, or TransportWithMessageCredential. The default is Transport, which means that the transport-specific security settings are enabled. If you use any setting that includes Message or Transport, you will have to set additional properties. In general, Mode value follows the standard WCF security programming model.

Message

Defines security on a per-message basis if you set end-to-end message security to 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.

Transport

This property is a wrapper for security properties unique to a given binding’s transport binding element. For example, the RelayedOnewayTransportSecurity class exposes and implements the ProtectionLevel setting on the NetEventRelayBinding and NetOnewayRelayBinding bindings. In contrast, the HttpRelayTransportSecurity type sets proxy credentials for BasicHttpRelayBinding and WS2007HttpRelayBinding bindings. As with the previous properties, Transport security generally follows the WCF security model.

RelayClientAuthenticationType

Controls whether clients of a service are required to present a security token issued by Access Control to the Service Bus when it sends messages. Therefore, this security property is unique to the 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 the Service Bus; otherwise they cannot register endpoints or create message buffers, each of which engages Service Bus resources. However, clients are required to authenticate with the Service Bus only if the RelayClientAuthenticationType is set to RelayAccessToken. Setting RelayClientAuthenticationType to 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.

This section describes specific processes for using authentication on the Service Bus.

In This Section