In Microsoft SQL Server 2005, Notification Services has a new subscription rule feature. Event-driven rules and scheduled rules can now use condition actions, which allow subscribers to define richer subscriptions using user-defined query clauses.

Because subscriptions based on condition actions allow for user-defined query clauses, the data available to the query should be limited. For this reason, you must define a database user that condition actions run under. The database user should only be allowed to query tables and views that contain input data.

The generator fires the rules that contain condition actions. However, the condition action queries are further constrained by the specified database user. You specify the database user when you define a Notification Services application.

For more information about condition actions, see Defining Condition Actions.

In addition to database permissions, some components also require additional Windows permissions:

• The account used to run the Notification Services engine must be a member of the SQLServer2005NotificationServicesUser$ComputerName Windows group. This provides access to the Notification Services binaries used to run the service. If using the NS$instanceName Windows service to run the engine, Notification Services adds the service account to the SQLServer2005NotificationServicesUser$ComputerName group when you register the instance.
  Any other components that require access to the Notification Services binaries may also require membership in the SQLServer2005NotificationServicesUser$ComputerName group. The Notification Services assemblies and resources are in the global assembly cache (GAC), and are available without membership in this group.
  
• Event providers sometimes require permissions in folders and other databases. For example, a file system watcher event provider needs read access to an XML Schema Definition (XSD) file that describes the event schema and read and modify access to the folder where event files are dropped. SQL Server event providers need access to the database tables or views that are used as event sources.
  
• Distributors need permissions to deliver notifications to the delivery service, such as a Simple Mail Transfer Protocol (SMTP) server, Short Message Service (SMS), Web server, or file system. Distributors that use the XSL transform (XSLT) content formatter also need access to the XSLT files.
  

When you deploy an instance of Notification Services, consider the following security recommendations for the Notification Services engine:

• Configure the engine to use Windows Authentication for database access.
  
• Run the engine under a low-privileged domain or local account. Do not use the Local System, Local Service, or Network Service account or any account in the Administrators group.
  However, a delivery protocol may require additional privileges for the account that the service runs under. For example, if you send notifications using the local Internet Information Services (IIS) SMTP service, the account under which the engine runs must be a member of the local Administrators group. (Administrator privileges are not a requirement when sending notifications through an SMTP service on a remote machine.)
  
• When you deploy an instance of Notification Services, make sure that each engine has only the necessary permissions.
  For single-server deployments, the engine runs all of the instance's hosted event providers, generators, and distributors. The account used by the engine should obtain the required database permissions through membership in the NSRunService database role.
  For scale-out deployments, restrict the permissions of individual engines. For example, if an engine runs only event providers, restrict the database permissions granted to the engine's account by making the account a member of the NSEventProvider database role and not granting other database or server permissions to the account. Do not use the NSRunService role unless the engine runs all of the engine components.
  

  Note:
  You configure what each engine runs by specifying the system name for each hosted event provider, generator, and distributor when you define an application.

• If the Notification Services engine components and the SQL Server Database Engine are located on separate servers, make sure that TCP/IP or named pipes is enabled for the Database Engine. To help improve Database Engine security, most network protocols are off by default.
  
• Make sure that login accounts have strong passwords. For more information about strong passwords, see "Creating Strong Passwords" in the Microsoft Windows documentation.
  
• Make sure that all code run by the engine, such as custom event providers, content formatters, and protocols, is from a trusted source. Notification Services assumes that code listed in the instance configuration and application definition, which you use to create and update the instance of Notification Services, comes from a trusted source. When defining applications, use the fully qualified assembly name to insure the correct assembly is loaded.
  
• Notification Services cannot validate protocol header fields. Therefore, if your application uses subscriber, subscriber device, or subscription information in a protocol field, either validate user input or use application-defined (not user-defined) values. For examples of malicious user data, see SQL Injection.
  
• Secure all folders containing configuration files or application data. For more information about securing files and folders, see Securing Files and Folders.
  

Typically, the Notification Services engine is an NS$instanceName Windows service that you create when you register an instance of Notification Services. However, you can host the engine in your own application instead of using the Windows service.

The engine logs in to the Database Engine and runs the instance of Notification Services. If you host the Notification Services engine, make sure to secure your source files and binaries.

For more information about hosting the engine, see Hosting the Notification Services Engine.

Subscription management interfaces allow users to subscribe to a notification application and create subscriptions. Subscription management interfaces obtain database permissions in instance and application databases through membership in the NSSubscriberAdmin database role.

When you develop a subscription management interface, consider the following security recommendations:

• Before adding, deleting, or modifying subscriber and subscription data, verify the subscriber's identity and then match that identity with a subscriber ID.
  
• Any user or application that has an account with membership in the NSSubscriberAdmin database role (or higher effective permissions) can modify subscriber and subscription data. Do not grant unnecessary permissions, and protect the user name and password used by subscription management interfaces.
  
• Do not store sensitive information in plain text, such as user names and passwords used for the application's database connections. Use the Data Protection Application Programming Interface (DPAPI) to encrypt sensitive information and then store the information in the registry.
  
• If your application must use sensitive information for user identification, such as social security numbers, you may want to provide the user with a non-sensitive user ID and then use a lookup table in the database to match the sensitive information.
  

Subscription management interfaces are often Web applications. For information about ASP.NET application security options, see Deploying a Subscription Management Interface.

Event providers submit event data to Notification Services applications. You can develop custom event providers, either hosted or non-hosted, for your applications. When you develop a custom event provider, consider the following security recommendations:

• Ensure that event providers use the NSEventProvider database role to submit events.
  
• Any user or application can submit events if it has a valid event provider name and an account with membership in the NSEventProvider database role (or one with higher effective permissions) in your application database. Do not grant unnecessary permissions, and protect the user name and password used by non-hosted event providers.
  
• Do not store sensitive information, such as user names and passwords, in plain text. Use DPAPI to encrypt sensitive information and then store the information in the registry.
  
• Secure all custom component source files and binaries.
  

Custom, hosted event providers submit events in the context of the event provider host; you do not need to provide any security credentials in your hosted event provider code to submit events. The following recommendation applies specifically to hosted event providers:

• When you create your application, you provide information about the custom hosted event provider in the application definition. Notification Services trusts all information in the application definition. Use the fully qualified assembly name to insure the correct assembly is loaded.
  

Non-hosted event providers run outside the context of your Notification Services application. The following recommendation applies specifically to non-hosted event providers:

• Non-hosted event providers are not explicitly trusted by Notification Services. You must provide security credentials in your non-hosted event provider code. The specified account must be able to log in to the instance of the Database Engine, and the associated database user account must be a member of the NSEventProvider database role in each instance and application database.
  

Custom delivery protocols run in the context of the Notification Services engine. As with all custom components, secure your source files and binaries to protect any sensitive information.

If you use Notification Services Management Objects (NMO) to configure instances of Notification Services, define applications, or develop administrative applications, make sure to secure the source and binary files. Files containing instance and application databases can contain sensitive information such as server names, user names, and passwords.

For more information about instance and application metadata and other files, see Securing Files and Folders.