Choosing a Type of Relay Authentication
Updated: June 18, 2014
The RelayClientAuthenticationType enumeration is referenced by the security settings in all of the relay bindings. The use of this property is identical throughout all bindings. The following table lists the possible values for this enumeration.
The client is required to provide a relay access token to access the service endpoint, and access control is performed by the Microsoft Azure Access Control service. If this option is set on the service binding, all clients must acquire and present tokens to Service Bus when establishing the channel. Furthermore, all subsequent access control is delegated to Access Control. The relay access token may be a shared secret, simple Web access token, or a SAML token. This is the default value.
The client is not required to provide a relay access token. Services are not required to present access tokens at any time. Therefore, this represents an opt-out mechanism with which services can waive the Access Control protection on the endpoint and perform their own access control.
When the RelayAccessToken option is chosen, all access control management is delegated to the Access Control service. Access Control yields an access control token for the relay that indicates whether the requestor can listen on or send to the relay (or both). At the same time, it protects the actual identity of the caller. Therefore, the listening service will not be able to gather any user-specific information. Effectively, the service operates in an anonymous authentication mode, trusting the Access Control service.
The None option causes the relay to pass all incoming messages to the service. The service assumes the responsibility for performing all access control locally, and also more precise access control. The type of access control depends on business data, local credentials stores, or other criteria—but it potentially exposes the service to unwanted traffic.
The hybrid solution is to combine the RelayAccessToken option with end-to-end message security, which is an option supported by most bindings. In this combination, the client is required to provide two separate credentials: one via the TransportClientEndpointBehavior behavior, for gaining access to the service through Service Bus. The latter is specified on the regular ClientCredentials property of the channel factory, which is used to help secure the end-to-end communication path. The latter credential can be a token issued by Access Control in the scope of the solution.
You are required to use message-security for end-to-end authorization. This is because the Service Bus bindings do not support the use of standard WCF transport-credentials. For most uses, transport-credentials can only be passed point-to-point on a connection, and cannot traverse intermediaries such as Service Bus.