Service Broker Security Overview

Service Broker messages may carry valuable business information. Therefore, it is important to ensure that their integrity is preserved, that messages are received from authenticated services, and that messages are sent to designated services. The Service Broker infrastructure ensures that only authorized databases send and receive the messages and that the message integrity is preserved.

Service Broker provides security at two levels:

• Dialog Dialog security encrypts the messages, verifies the identities of participants, provides remote authorization, and performs message integrity checking. Therefore, dialog security helps protect data against inspection or modification in transit. Service Broker provides two types of dialog security: full security and anonymous security. Full security prevents the initiating service from sending messages to an untrusted database and protects the target service from receiving messages from an untrusted database. Service Broker encrypts messages transmitted over the network when the conversation uses full security. Anonymous security protects the initiating service against sending messages to an untrusted database. Service Broker encrypts messages transmitted over the network when the conversation uses anonymous security. Anonymous security identifies the target service to the initiating service, but it does not identify the initiating service to the target service. Full security requires the initiator to have a certificate and remote service binding with ANONYMOUS = OFF.

• Transport Transport security prevents unauthorized databases from sending Service Broker messages to databases in the local instance. When transport security is enabled, authorization is required to connect to the Service Broker endpoint. Whether the network connection uses transport security depends on the AUTHENTICATION option for the broker endpoint and whether both databases contain a certificate for master.dbo.

Applications that send messages between SQL Server instances may use transport security, dialog security, or both. By default, all dialog conversations use dialog security. When you begin a dialog, you can explicitly allow the dialog to proceed without dialog security by including the ENCRYPTION = OFF clause on the BEGIN DIALOG CONVERSATION statement. However, if a remote service binding exists for the service that the conversation targets, the dialog uses security even when ENCRYPTION = OFF. For a dialog that uses security, Service Broker encrypts all messages sent outside a SQL Server instance. Messages that remain within a SQL Server instance are never encrypted.

Service Broker remote security, where more than one SQL Server instance participates in the dialog, is based on certificates. SQL Server uses certificates to verify the identity of a remote database and to identify the local database principal for the operation. You can create certificates by using the CREATE CERTIFICATE T-SQL statement. Service Broker uses the remote service bindings in the database that begins the conversation to determine the security for the conversation. Service Broker therefore uses the service name and, optionally, the contract name to determine the security for the service.

In addition to Service Broker dialog and transport security, SQL Server permissions are required to run Service Broker statements such as SEND, RECEIVE, CONNECT, and so on. The GRANT statement can be used to allow permissions on a Service Broker contract, message type, remote binding, route, or service.