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: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.
■ 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.
Table 3-3. Authentication Methods Supported
See “Authentication” for details about configuring authentication.Table 3-4 shows the data encryption methods supported by the data providers.
Table 3-4. Data Encryption Methods Supported
Oracle 11g only
■ 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.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.Table 3-5 shows the data provider support for SSL client authentication.
Table 3-5. SSL Client Authentication Support 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.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.
2 Click the Import... button.
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.
1
2
3
5
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.
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.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.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.The DataDirect Connect for ADO.NET data providers are marked with the AllowPartiallyTrustedCallers attribute.For more information about the effect of OS authentication on connection pooling, see “Using Reauthentication”.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.