Using Security

The .NET Framework supports secure communication between hosts using secure network streams.

For information on the latest security updates in the .NET Framework, refer to the Microsoft web site.

The DataDirect Connect for ADO.NET data providers are by default FIPS-compliant, using the standard .NET Framework security settings. In addition, the DataDirect Connect for ADO.NET data providers support the following features: authentication and data encryption.

Authentication

On most computer systems, a password is used to prove a user's identity. This password often is transmitted over the network and can possibly be intercepted by malicious hackers. Because this password is the one secret piece of information that identifies a user, anyone knowing a user's password can effectively be that user. Authentication methods protect the identity of the user.

DataDirect Connect for ADO.NET supports the following authentication methods:

• User ID/Password authentication authenticates the user to the database using a database user name and password. Encrypting the User ID and Password can provide additional authentication.
• Kerberos is a trusted third-party authentication service commonly employed in single sign-on environments. The degree of Kerberos support varies by data provider, as described below:
  • For the DB2 and Sybase data providers, both Windows Active Directory Kerberos and MIT Kerberos implementations are supported.
  • For the Oracle data provider, three Kerberos authentication methods are supported: Windows Active Directory Kerberos, MIT Kerberos, and Kerberos.NET (a fully managed third-party library). Kerberos tickets can be generated using any of these mechanisms.
  • For the SQL Server data provider, only Windows Active Directory Kerberos is supported.
• OS authentication is a trusted third-party authentication service that verifies user identities. The SQL Server data provider supports NTLM, which delivers a session security mechanism that provides for message confidentiality (encryption) and integrity (signing).

The following table summarizes the authentication methods supported.

Authentication Methods Supported

1 Supported for Oracle 9i R2 and higher.

Data Encryption Across the Network

If your database connection is not configured to use data encryption, data is sent across the network in a format that is sent across the network as a 4-byte integer. The native format is designed for fast transmission and can be decoded by interceptors given some time and effort. Because this format does not provide complete protection from interceptors, you may want to use data encryption to provide a more secure transmission of data.

For example, you may want to use data encryption in the following scenarios:

• You have offices that share confidential information over an intranet.
• You send sensitive data, such as credit card numbers, over a database connection.
• You need to comply with government or industry privacy and security requirements.

The data providers support the following data encryption methods:

• Secure Sockets Layer (SSL). SSL is an industry-standard protocol for sending encrypted data over database connections. SSL secures the integrity of your data by encrypting information and providing client/server authentication.
• Database-specific encryption:
  • DB2-specific encryption, using the DB2 encryption algorithm
  • Oracle transparent data encryption and tablespace encryption (Oracle 11g only)

The following table shows the data encryption methods supported by the data providers.

Data Encryption Methods Supported

1 Oracle 11g only

SSL Encryption

SSL works by allowing the client and server to send each other encrypted data that only they can decrypt. SSL negotiates the terms of the encryption in a sequence of events known as the SSL handshake. The handshake involves the following types of authentication:

• SSL server authentication requires the server to authenticate itself to the client.
• SSL client authentication is optional and requires the client to authenticate itself to the server after the server has authenticated itself to the client. Not all databases support client authentication.

The .NET Framework allows you to specify the version of SSL and the SSL cryptographic algorithm that is used. Refer to your Microsoft .NET documentation for more information about setting values for SSL support.

As part of the SSL negotiation, the .NET Framework may require that the targetHost be specified so that the validity of the server certificate can be verified. The certificate returned may contain a fully qualified host name, a server defined host name, or another string, depending on the way the certificate is assigned to the server. Applications can define a string to identify the server using the Host Name in Certificate connection string option.

See the "Authentication" section in each data provider section for more information.

SSL Server Authentication

Successful authentication must occur before the secure socket can be used. SSL server authentication may include proof of identity by using certificate chains and granting Certification Authorities (CA). The server and client may exchange X.509 Certificates to establish a level of trust between peers.

The certificate returned by the server can contain a fully qualified host name, a server defined host name, or an application-defined string to identify the server, depending on the way the certificate was assigned to the server.

The data provider can specify a host name using the Host Name in Certificate connection string option. By default, the data provider uses the value of the Host connection string option.

SSL Client Authentication

If the server is configured for SSL client authentication, the server asks the client to verify its identity after the server identity has been proven. Similar to SSL server authentication, the client sends one or more public certificates to the server for authentication. To send the public certificate, the data provider needs to specify the location of the X.509 Certificate store for the current user.

The Certificate Name Location connection string option specifies the pathname of the keystore file.

The following table shows the data provider support for SSL client authentication.

SSL Client Authentication Support

Importing Certificates

When X.509 Certificates must be imported to define trusted certificates or client certificates, DataDirect Connect for ADO.NET uses the certificate management capabilities of the underlying Windows platform.

Certificates can be imported in the following format:

• Cryptographic Message Syntax Standard or PKCS #7 Certificates (.P7B)
• Personal Information Exchange PKCS #12 (.PFX, .P12)
• Microsoft Serialized Certification Store (.SST)

The Certificate Management tool recognizes the purpose of each certificate, and automatically adds it to the appropriate certificate category. DataDirect Connect for ADO.NET supports Trust Root Certificate Authorities and Personal certificates.

The Certificates required for server or client authentication can be added for user accounts, a computer, and a service, depending on the context in which an application is using DataDirect Connect for ADO.NET.

Starting the Certificate Management Tool from Visual Studio

1. At the Visual Studio command prompt, type the following:

   certmgr
   

   The Certificates window appears.

   

2. Click the Import... button.

3. When the Welcome screen of the Certificate Import Wizard appears, click Next.

4. Type the file name of the certificate that you want to import, or click Browse and navigate to the file. Click OK to return to the Certificate Import Wizard.

5. Click Next. Information about the keys is displayed.

6. Click Close to exit the Certificate Import Wizard.

Running the Certificate Management Tool from the Management Console

The Certificate Management tool can also be loaded as a component of the Microsoft Management Console (MMC).

To run the Certificate Management tool, do the following steps:

1. Click Start / Run.

2. Type mmc and click OK. The MMC Console appears.

3. Select File / Add/Remove Snap-In.

4. On the Add/Remove Snap-in dialog box, click Add....

5. On the Add Standalone Snap-in dialog box, select Certificates. Then, click Add.

6. Select the account (user, service, or computer) for which the snap-in will manage certificates. Then, click Finish.

7. Click Close to close the Add Standalone Snap-in dialog box; then, click OK to close the Add/Remove Snap-in dialog box and return to the MMC Console.

8. Expand the Certificates node and select the certificate that you want to use.

   

9. When you are ready to leave the Console, select File / Exit. A message window asks if you want to save the changes to the Console.

10. Click OK to save the changes.

.NET Framework Security

DataDirect Connect for ADO.NET supports the security features defined by .NET Framework.

Note: The use of unmanaged code can affect the level of security available. If you use the MS DTC components to enlist in distributed transactions, code outside the .NET Framework is enlisted. Using the Integrated Security connection string option of the SQL Server data provider also requires the use of unmanaged code.

Code Access Permissions

The DataDirect Connect for ADO.NET data providers require the FullTrust permission to be set in order to load and run. This requirement is due to underlying classes in System.Data that demand FullTrust for inheritance. All ADO.NET data providers require these classes to implement a DataAdapter.

Security Attributes

The DataDirect Connect for ADO.NET data providers are marked with the AllowPartiallyTrustedCallers attribute.

OS Authentication and Single Sign-on

OS authentication can take advantage of the user name and password maintained by the operating system to authenticate users to the database or use another set of user credentials specified by the application. Through single sign-on, a user can be authenticated once and gain access to the resources of multiple software systems.

OS authentication uses a challenge-response authentication protocol. The server begins the authentication by sending the client a large (8-byte) random number. The client performs a predefined operation with the number and a password, and returns the result to the server. The server verifies the client has returned the correct value, and from this determines the identity of the client.

With single sign-on, the server recognizes each client, even when the client signs on with a common user ID. For example, John and Mary sign on from separate workstations using their work group’s user ID, Accounting User, and a common connection string. Because they use different workstations, their credentials are not the same. The server assigns John and Mary separate connections, creating a separate connection pool for each of them.

For more information about the effect of OS authentication on connection pooling, see Using Reauthentication.

Required Permissions

Using the DataDirect Connect for ADO.NET data providers with Kerberos requires that applications and data provider code bases are granted security permissions. The Authentication Methods Supported table identifies the data providers that support Kerberos authentication.

For more information about using Kerberos authentication with the DataDirect Connect for ADO.NET data providers, see the appropriate data provider section.