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:
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.