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:
• Microsoft.ServiceBus.TransportClientCredentialType.SharedSecret, a slightly more complex but easy-to-use form of username/password authentication.
• Microsoft.ServiceBus.TransportClientCredentialType.Saml, which can be used to interact with SAML 2.0 authentication systems.
• Microsoft.ServiceBus.TransportClientCredentialType.SimpleWebToken, which uses the OAuth Web Resource Authorization Protocol (WRAP)and Simple Web Tokens (SWT).
• Microsoft.ServiceBus.TransportClientCredentialType.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
Microsoft.ServiceBus.Configuration.NetTcpRelaySecurityElement performs the security functions for the Microsoft.ServiceBus.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 Microsoft.ServiceBus.EndToEndSecurityMode
type supports the Microsoft.ServiceBus.NetTcpRelayBinding binding, and the
Microsoft.ServiceBus.EndToEndWebHttpSecurityMode value performs this service together with the Microsoft.ServiceBus.WebHttpRelayBinding binding. When used with the Microsoft.ServiceBus.NetTcpRelayBinding binding, this property can be set to Microsoft.ServiceBus.EndToEndSecurityMode.None,
Microsoft.ServiceBus.EndToEndSecurityMode.Message,
Microsoft.ServiceBus.EndToEndSecurityMode.Transport, or
Microsoft.ServiceBus.EndToEndSecurityMode.TransportWithMessageCre dential. 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 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
Microsoft.ServiceBus.EndToEndSecurityMode.Message or
Microsoft.ServiceBus.EndToEndSecurityMode.TransportWithMessageCre dential. 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
Microsoft.ServiceBus.RelayedOnewayTransportSecurity class exposes and implements the
Microsoft.ServiceBus.RelayedOnewayTransportSecurity.ProtectionLevel
setting on the Microsoft.ServiceBus.NetEventRelayBinding and
Microsoft.ServiceBus.NetOnewayRelayBinding bindings. In contrast, the
Microsoft.ServiceBus.HttpRelayTransportSecurity type sets proxy credentials for Microsoft.ServiceBus.BasicHttpRelayBinding and
Microsoft.ServiceBus.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
Microsoft.ServiceBus.RelayClientAuthenticationType is set to
Microsoft.ServiceBus.RelayClientAuthenticationType.RelayAccessToken. Setting Microsoft.ServiceBus.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
Microsoft.ServiceBus.RelayClientAuthenticationType.RelayAccessToken.
In addition, every binding contains the Scheme property, which defines the scheme used to encode information. For HTTP-based bindings (such as
Microsoft.ServiceBus.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
How to: Set Security and Authentication on a Service Bus Application Setting Security on a REST-based Service Bus Application
Choosing Authentication for a Service Bus Application Choosing a Type of Relay Authentication
How to: Modify the Service Bus Connectivity Settings Creating a Service Bus URI