3 Advanced Features : Using Security

Using Security
The .NET Framework Version 2.0 introduced built-in support for secure communication between hosts using secure network streams. The .NET Framework Version 4.0 changed the existing mechanisms to add greater control. For example, you can use the following namespaces to enable SSL and TLS authentication and secret key and public key encryption in your application, or allow your application is use a lower degree of security:
For information on the security changes in the .NET Framework 4.5, refer to the Microsoft Web site:
http://msdn.microsoft.com/en-us/library/dd233103.aspx
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. For the most current information, refer to the security matrix on the Progress DataDirect Web site:
http://www.datadirect.com/products/security/documentation/securitymatrix.htm
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 that is often used in single sign-on environments. The data providers support both Windows Active Directory Kerberos and MIT Kerberos implementations for DB2, Oracle, and Sybase. For SQL Server, the data provider supports only Windows Active Directory Kerberos.
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).
Table 3-3 summarizes the authentication methods supported.
 

1
Supported for Oracle 9i R2 and higher.

See “Authentication” for details about configuring authentication.
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:
The data providers support the following data encryption methods:
Table 3-4 shows the data encryption methods supported by the data providers.

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 chapter 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.
Table 3-5 shows the data provider support for SSL client authentication.
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:
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
certmgr
The Certificates window appears.
The Certificates window, empty.
2
Click the Import... button.
3
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
5
6
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
MMC Console shows the categories available under the Certificates - Current User node.
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 the .NET Framework Versions 2.0, 3.0, 3.5, 3.5 SP1, 4.0, and 4.5.
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. Table 3-3, “Authentication Methods Supported” 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 chapter.