Operating-system-based external authentication

Administrator Guide : Security : Authentication : Operating-system-based external authentication

Instead of the internal solidDB^® authentication mechanism, the user can be authenticated by services provided by operating system.

The operating-system-based external authentication is supported on Linux, UNIX, and Windows environments. On Linux and UNIX systems, solidDB^® uses services provided by Pluggable Authentication Modules (PAM) API, implementing the X/Open Single Sign-On standard. On Windows systems, external authentication is implemented on top of Security Support Provider Interface (SSPI) API.

Additionally, to use external authentication, the OpenSSL libcrypto/libeay32 must be enabled and accessible on both the server and client computers. OpenSSL libcrypto enables use of private key/public key pair for the connect message, providing strong encryption when sending the password over the network connection.

Principles of operation

When external authentication is used, the user logs in to solidDB^® by providing authentication credentials that match the credentials of an operating system user account on the solidDB^® host computer.

To create an externally authenticated user account for the database administrator, you need to enable the external authentication when creating the database. For other users, you enable external authentication using SQL statements. The authentication of each user must be specified separately. Each externally authenticated solidDB^® user must have a corresponding operating system or domain level account on the machine where solidDB^® is running.

Additional security considerations

If the user accounts are externally authenticated, the database and all of its backups must reside on encrypted or otherwise protected media; this is to ensure, for example, that malicious users cannot copy the database to another system and configure external authentication so that the login succeeds for any account.

Installing and configuring OpenSSL libcrypto for external authentication: Server

Installing and configuring OpenSSL libcrypto for external authentication: ODBC clients and solidDB^® tools

Installing and configuring OpenSSL libcrypto for external authentication: JDBC clients

Configuring your system for external authentication

Configuring external authentication on HP-UX systems

Configuring external authentication on Linux systems

Configuring external authentication on Solaris systems

Configuring external authentication on Windows systems

Creating externally authenticated accounts for database administrators

Creating externally authenticated accounts for users

Disabling external authentication

Checking authentication type of users

Example: Configuring external authentication for JDBC connections (Windows)

Authentication

Installing and configuring OpenSSl libcrypto for external authentication

To use external authentication, the OpenSSL libcrypto must be available on the solidDB^® server and client computers.

Notes

▪When you enable the use of OpenSSL libcrypto for external authentication, only the passwords are encrypted using OpenSSL libcrypto. To encrypt the solidDB^® database and log files, you need to enable the encryption separately. For more details, see Encrypting database and log files.

▪Libcrypto shared library is called libeay32.dll on Windows systems.

Installing and configuring OpenSSL libcrypto for external authentication: Server

To use external authentication, you must install the OpenSSL libcrypto on the solidDB^® server computer. If the solidDB^® server cannot access the OpenSSL libcrypto library, the login data for an externally authenticated user cannot be verified. On the server side, the use of OpenSSL libcrypto for encryption is controlled with the General.UseCryptoLib parameter.

About this task

solidDB^® does not distribute OpenSSL libraries. You must acquire the libraries from either the Operating system vendor or build the libraries yourself.

You also need to specify the library lookup path General.CryptoLibPath or let solidDB^® use the system library path variable to look up the OpenSSL libcrypto library. First libcrypto library found in the path is chosen.

You can verify the OpenSSL libcrypto version used immediately after solidDB^® startup from solmsg.out.

For details on OpenSSL, see www.openssl.org.

solidDB^® provides an OpenSSL libcrypto library for evaluation and testing purposes in the solidDB installer samples directory. This library is provided AS IS and using it for anything else than evaluation and testing is not supported.

Note Libcrypto shared library is called libeay32.dll on Windows systems.

Procedure

On the server computer:

1 Ensure that you have OpenSSL libcrypto available.

2 Set the General.UseCryptolib parameter to yes.

3 Optional: If you want that the passwords of any internally authenticated users are sent over a network connection using strong encryption, set the General.CryptoLoginRequired parameter to yes.

For example:

[General]
UseCryptoLib=yes
CryptoLibPath=<solidDB installation directory>/bin/
CryptoLoginRequired=yes

What to do next

Install and configure OpenSSl libcrypto for external authentication on the client computer. The configuration procedure is different depending on whether you use the solidDB^® JDBC client or the solidDB^® ODBC client or solidDB^® tools such as solidDB^® SQL Editor (solsql).

Related tasks

Enabling encryption with OpenSSL

Installing and configuring OpenSSL libcrypto for external authentication: ODBC clients and solidDB^® tools

If you are using the solidDB^® ODBC Driver or solidDB^® data management tools (for example, solidDB^® SQL Editor (solsql)), to use external authentication, you must install the OpenSSL libcrypto on the solidDB^® client computer. If the solidDB^® client cannot access the OpenSSL libcrypto library, the login data for an externally authenticated user cannot be verified.

About this task

solidDB^® does not distribute OpenSSL libraries. You must acquire the libraries from either the Operating system vendor or build the libraries yourself.

For details on OpenSSL see www.openssl.org.

Note Libcrypto shared library is called libeay32.dll on Windows systems.

Procedure

1 To enable the use of OpenSSL for external authentication set the client-side Client.UseCryptoLib parameter to yes. You also need to specify Client.CryptoLibPath to the OpenSSL libcrypto library.

Creating externally authenticated accounts for users

Installing and configuring OpenSSL libcrypto for external authentication: JDBC clients

To use external authentication with JDBC, you enable the use of the OpenSSL libcrypto using JDBC connection properties. You must also ensure that the solidDB^® JDBC Driver has access to the solidDB^® linked library access (LLA) and OpenSSL libcrypto libraries. If the JDBC client cannot load the OpenSSL libcrypto and LLA libraries, the login data for an externally authenticated user cannot be verified.

About this task

You need both libcrypto and solidDB LLA libraries on the client computer.

solidDB^® does not distribute OpenSSL libraries. You must acquire the libraries from either the Operating system vendor or build the libraries yourself.

For details on OpenSSL, see www.openssl.org.

Note Libcrypto shared library is called libeay32.dll on Windows systems.

Procedure

1 Copy the LLA library from the computer where you have installed solidDB^® server to the client computer. The LLA library names and default installation locations are shown in the table below:

Platform	Dynamic LLA library
Windows	bin\ssolidacxx.dll
AIX	lib/libssolidacxx.so This is a symbolic link that gives you access to the actual library file bin/ssolidacxx.so.
HP-UX	lib/libssolidacxx.so This is a symbolic link that gives you access to the actual library file bin/ssolidacxx.so.
Linux	lib/libssolidacxx.so This is a symbolic link that gives you access to the actual library file bin/ssolidacxx.so
Solaris	lib/libssolidacxx.so This is a symbolic link that gives you access to the actual library file bin/ssolidacxx.so

xx is the version number of the driver library, for example, ssolidac100.so.

2 Add the location of the LLA library to the LD_LIBRARY_PATH or LIBPATH (Linux and UNIX) or PATH (Windows) environment variable.

In Linux and UNIX environments, you need to link to the symbolic link library libssolidacxx in the /lib directory. Alternatively, rename the ssolidacxx library in the /bin directory as libssolidacxx.

In Windows environments, the LLA library is located in the \bin directory.

In Linux and UNIX environments, use the following syntax:

export LD_LIBRARY_PATH=<path_to_library>:$LD_LIBRARY_PATH

For example:

export LD_LIBRARY_PATH=home/admin/UNICOM/solidDB/solidDB100.0/lib:$LD_LIBRARY_PATH

or in AIX environments:

export LIBPATH=<path to library>:$LIBPATH

For example:

export LIBPATH=home/admin/UNICOM/solidDB/solidDB100.0/lib:$LIBPATH

In Windows environments, use the following syntax:

set PATH=<path_to_library>;%PATH%

For example:

set PATH=C:\solidDB\bin;%PATH%
set PATH="<solidDB installation directory>\bin";%PATH%

3 Set the connection property solid_use_strong_encryption to yes.

Set the connection property solid_crypto_path to point to the directory where the OpenSSL libcrypto library is installed. Use the operating system conventions for defining the directory path.

Example: External authentication settings in Windows environments when connecting with Driver Manager

set PATH=<solidDB installation directory>\solid_client\bin;%PATH%

Properties props = new Properties(); // enable OpenSSL libcrypto encryption

props.put("solid_use_strong_encryption", "yes"); // define OpenSSL library path props.put("solid_crypto_path", "<solidDB installation directory>\solid_client\bin");

Example: External authentication settings in AIX environments when defining connection properties in the connect string

The following example enables the use of OpenSSL libcrypto by defining connection property in the connect string. The OpenSSL libcrypto library path is defined in the PATH environment variable.

export LIBPATH=home/admin/solid_client/lib:$LIBPATH

Connection c = DriverManager.getConnection

("jdbc:solid://10.11.22.314:1315//admin?T3stus3r?

solid_use_strong_encryption=yes?solid_crypto_path=home/admin/solid_client/bin");

Related tasks

Encryption

Configuring your system for external authentication

To use external authentication on Linux and UNIX systems, you need to configure your system so that solidDB^® can authenticate users using the Pluggable Authentication Modules (PAM) mechanism. On Windows systems, you should define the default domain name for the externally authenticated users. You also need to enable the use of OpenSSL libcrypto on both the server and client computers.

Configuring external authentication on AIX systems: About this task

The following procedure describes a typical way of configuring your AIX system for using external authentication with the solidDB^® server. The procedure assumes that you have installed and created the necessary Pluggable Authentication Modules (PAM) on your system.

Misconfigured PAM settings can cause an abnormal shutdown of the solidDB^® server. To address any problems with authentication, test the external authentication settings in a testing environment first.

Procedure

1 Define the solidDB^® service name with the General.PamServiceName parameter.

2 The General.PamServiceName parameter defines the solidDB^® program name that is used in the PAM configuration to define how solidDB^® users are authenticated. The factory value of General.PamServiceName is solid.

3 Edit the PAM configuration file at /etc/pam.conf. Add the following lines to the file: where

service_name defines the name of the solidDB^® service, as defined by the General.PamServiceName parameter.

module_path defines the name and path of the authentication module.

Examples

If the General.PamServiceName parameter value is solid (default) and the authentication module you have installed and created on your system is /usr/lib/security/pam_ldap, add the following lines in the /etc/pam.conf file:

solid	auth	required	pam_ldap
solid	account	required	pam_ldap
solid	password	required	pam_ldap
solid	session	required	pam_ldap

Instead of using custom-made PAM modules, you can use the pam_aix authentication module that is typically included in AIX installations.

For example:

solid	auth	required	pam_aix use_new_state
solid	account	required	pam_aix
solid	password	required	pam_aix
solid	session	required	pam_aix

However, when using the pam_aix module, the following limitations apply:

▪You must run solidDB^® as an administrator (root user). To connect to solidDB^® from a client running on an AIX system, the user does not need to have administrator rights.

▪The service name used in the /etc/pam.conf file must match the value of the General.PamServiceName parameter. If the entries do not match, the system uses the default PAM settings, which can cause an abnormal shutdown of the solidDB^® server.

Configuring external authentication on HP-UX systems

About this task

The following procedure describes a typical way of configuring your HP-UX system for using external authentication with the solidDB^® server. The procedure assumes that you have installed and created the necessary Pluggable Authentication Modules (PAM) modules on your system.

Note Misconfigured PAM settings can cause an abnormal shutdown of the solidDB^® server. To address any problems with authentication, test the external authentication settings in a testing environment first.

Procedure

1 Define the solidDB^® service name with the General.PamServiceName parameter.

The General.PamServiceName parameter defines the solidDB^® program name that is used in the PAM configuration to define how solidDB^® users are authenticated. The factory value of General.PamServiceName is solid.

2 Edit the PAM configuration file at /etc/pam.conf. Add the following lines to the file:

service_name defines the name of the solidDB^® service, as defined by the General.PamServiceName parameter.

Examples

If the General.PamServiceName parameter value is solid (default), add the following lines in the /etc/pam.conf file:

solid	auth required	libpam_hpsec.so.1
solid	auth required	libpam_ldap.so.1
solid	account required	libpam_hpsec.so.1
solid	account required	libpam_ldap.so.1
solid	password required	libpam_hpsec.so.1
solid	password required	libpam_ldap.so.1
solid	session required	libpam_hpsec.so.1
solid	session sufficient	libpam_ldap.so.1

Configuring external authentication on Linux systems

About this task

The following procedure describes a typical way of configuring your Linux system for using external authentication with the solidDB^® server. The procedure assumes that you have installed and created the necessary Pluggable Authentication Modules (PAM) modules on your system.

Procedure

1 Define the solidDB^® service name with the General.PamServiceName parameter.

2 Create a file in the /etc/pam.d/ directory. Name the file with the same service name as defined with the General.PamServiceName parameter. Add the following lines to the file:

#%PAM-1.0
auth include system-auth

Examples

If the General.PamServiceName parameter value is solid (default), create a file named solid in the /etc/pam.d directory.

Configuring external authentication on Solaris systems

About this task

The following procedure describes a typical way of configuring your Solaris system for using external authentication with the solidDB^® server. The procedure assumes that you have installed and created the necessary Pluggable Authentication Modules (PAM) modules on your system. The configuration instructions assume your system is set up to use LDAP authentication through PAM.

Procedure

1 Define the solidDB^® service name with the General.PamServiceName parameter.

2 Edit the PAM configuration file at /etc/pam.conf. Add the following lines to the file:

<service_name> account required pam_ldap.so.1
<service_name> auth required pam_dhkeys.so.1
<service_name> auth required pam_unix_cred.so.1
<service_name> auth sufficient pam_unix_auth.so.1
<service_name> auth required pam_ldap.so.1
<service_name> account required pam_ldap.so.1

where service_name defines the name of the solidDB^® service, as defined by the General.PamServiceName parameter.

Examples

If the General.PamServiceName parameter value is solid (default), add the following lines in the /etc/pam.conf file:

solid account required pam_ldap.so.1
solid auth requisite pam_authtok_get.so.1
solid auth required pam_dhkeys.so.1
solid auth required pam_unix_cred.so.1
solid auth sufficient pam_unix_auth.so.1
solid auth required pam_ldap.so.1
solid account required pam_ldap.so.1

Configuring external authentication on Windows systems

The following procedure describes typical configuration steps on a Windows system when using external authentication with the solidDB^® server. The procedure assumes that your system includes the necessary Security Support Provider Interface (SSPI) services.

On Windows systems, the operating-system-based authentication typically uses a two-part user ID that is composed of a domain and user name such as: chicago_prod\solid_admin. In this example, chicago_prod is a domain and solid_admin is the user name. To ease the use of a two-part user ID, you can use the General.DefaultDomainName parameter to specify the domain name that all solidDB^® users use by default.

When a valid domain name is defined with the General.DefaultDomainName parameter, you need to provide only the user name of the externally authenticated users when creating the login credentials. Similarly, externally authenticated users can then log on without specifying the domain name.

The solidDB^® server uses the value of the General.DefaultDomainName parameter to resolve the two-part user ID at connection time.

Defining the default domain is useful for the following reasons:

▪When the domain name is defined with the General.DefaultDomainName parameter, solidDB^® stores only the user name of the externally authenticated user in the SYS_USERS table. For example, schema names in your database then default to the one-part user name stored in the SYS_USERS table.

▪ You can change between the external and internal authentication methods. The domain name for the user accounts that were created to use internal authentication can be specified with the General.DefaultDomainName parameter without the need to modify the user name.

Note Alternatively, you can leave the General.DefaultDomainName parameter empty (default) and provide the domain name as part of the user ID of each externally authenticated user.

Defining default domain name on Windows systems

Define the default domain name with the General.DefaultDomainName parameter. The default domain name is the domain name of the computer where your solidDB^® server is installed.

The General.DefaultDomainName parameter does not have a factory value.

When the user enters the user name to authenticate to the system, solidDB^® uses the value of General.DefaultDomainName to resolve the user name as expected by the operating system.

Examples

If the domain name of the server where your solidDB^® server is running is chicago_prod, specify the following setting in the solid.ini file:

[General]
DefaultDomainName=chicago_prod

You can then create the user solid1 with the CREATE USER statement as follows:

CREATE USER solid1 IDENTIFIED EXTERNALLY

Defining Windows domain name as part of the user ID

If you do not specify the domain name with the General.DefaultDomainName parameter, you need to provide the Windows domain name as part of the user ID of each externally authenticated user.

To define the domain name as part of the user ID, use one of the following formats:

domain_name\username

username@domain_name

Note When using the CREATE USER user_name EXTERNALLY statement, the user_name string with \ or @ character must be given in double quotation marks.

Examples

If the domain name of the server where your solidDB^® server is running is chicago_prod and the user name is solid1, create the user using one of the following statements:

CREATE USER "chicago_prod\solid1" IDENTIFIED EXTERNALLY
CREATE USER "solid1@chicago_prod" IDENTIFIED EXTERNALLY

Creating externally authenticated accounts for database administrators

The external authentication method for a database administrator account must be specified when creating a database. To create a new database with external authentication, use the solidDB^® startup option -p and omit the password.

Before you begin

▪The database administrator must have a corresponding operating system or domain level account on the machine where solidDB^® is running.

▪Install and enable OpenSSL libcrypto on the server and client computers.

▪Configure the external authentication mechanism according to your operating system.

– On Linux and UNIX systems, you must have the appropriate Pluggable Authentication Module (PAM) service configured in the operating system. See Operating-system-based external authentication for details.

– On Windows systems, you must have the appropriate Security Support Provider Interface (SSPI) service configured in the operating system. Also, define the default domain name of the server where solidDB^® is running with the General.DefaultDomainName parameter. See Operating-system-based external authentication.

Procedure

Create a new solidDB^® database using the following syntax:

solid -p -U username -C catalog_name

where username must match the user name of a user that has an operating system user account.

If you do not specify a user name or a catalog name, solidDB^® prompts for them.

Example

solid -p -U soliduser1 -C DBA

What to do next

To access solidDB^® as an externally authenticated user:

1 If you are accessing solidDB^® from a client computer, ensure that OpenSSl libcrypto is enabled on the client computer.

2 Log on using the operating system or domain user account user name and password.

Note If the database administrator account uses external authentication, you cannot disable the use of OpenSSL libcrypto. If the database administrator account is externally authenticated and General.UseCryptoLib is set to no, solidDB^® server startup fails with the error External authentication requires OpenSSL libcrypto to be enabled.

Creating externally authenticated accounts for users

To enable the external authentication method for a user, use the CREATE USER or ALTER USER statements. You need to use the keyword EXTERNALLY and omit the password.

Before you begin

▪The user must have a corresponding operating system or domain level account on the machine where solidDB^® is running.

▪You must have administrator privileges to enable external authentication for a user.

▪Install and enable OpenSSL libcrypto on the server and client computers.

▪Configure the external authentication mechanism according to your operating system.

– On Linux and UNIX systems, you must have the appropriate Pluggable Authentication Module (PAM) service configured in the operating system. See Configuring your system for external authentication for details.

Creating a new user account

To create a user with external authentication, use the following syntax:

CREATE USER username IDENTIFIED EXTERNALLY

where username must match the user name of a user that has an operating system user account.

Modifying an existing user account

To change the user account of an existing user to use external authentication, use the following syntax:

ALTER USER username IDENTIFIED EXTERNALLY

where username must match the user name of a user that has an operating system user account.

Examples

CREATE USER soliduser1 IDENTIFIED EXTERNALLY
ALTER USER soliduser2 IDENTIFIED EXTERNALLY

What to do next

To access solidDB^® as an externally authenticated user:

1 If you are accessing solidDB^® from a client computer, ensure that OpenSSL libcrypto is enabled on the client computer.

2 Log on using the operating system or domain user account user name and password.

▪If the use of OpenSSL libcrypto is disabled on the solidDB^® server (General.UseLibCrypto=no), connections for externally authenticated users fail with error Error 08004: Server rejected the connection.

▪ If the use of OpenSSL libcrypto is disabled on the client computer or the client cannot load the OpenSSL libcrypto library, connections for externally authenticated users fail with error SQLAllocEnv.

Disabling external authentication

To disable the external authentication method for a user, use the ALTER USER statement, specifying the password solidDB^® uses to authenticate the user internally.

Procedure

To change the user account of an existing user to not use external authentication, use the following syntax:

ALTER USER username IDENTIFIED BY password

Example

ALTER USER soliduser1 IDENTIFIED BY Hippo123

Checking authentication type of users

You can check whether a user is authenticated internally or externally by querying the SYS_USERS system table.

Procedure

Use the following command to check the authentication type of all users:

SELECT ID, NAME, AUTHENTICATION FROM SYS_USERS;

The column AUTHENTICATION contains information about the authentication type of the user:

▪0 – internal authentication

▪1 – external authentication

Example

solsql> SELECT ID, NAME, AUTHENTICATION FROM SYS_USERS;

ID NAME      AUTHENTICATION
-- ----      --------------
1 DBA       0
2 OMEGA     1
9 PELLE     1
3 rows fetched.

Example: Configuring external authentication for JDBC connections (Windows)

This example showcases the configuration steps need for authenticating solidDB^® users using the Windows operating system provided authentication mechanism. The external authentication functionality is configured and tested by modifying a JDBC sample shipped with solidDB^®.

Before you begin

▪solidDB^® installed in the default directory: C:\Program Files\UNICOM\soliddb\ soliddb100.0. The default installation includes the linked library access (LLA) libraries and the JDBC sample.

▪LLA: bin\ssolidac70.dll

▪JDBC sample: samples\jdbc

▪Install and enable OpenSSL libcrypto on the server and client computers.

▪You can run the solidDB^® JDBC sample successfully: to compile the sample, you need a working installation of Java Development Kit (JDK) 1.7 or newer.

About this task

The example includes the following steps:

▪Configuring external authentication for the solidDB^® server, solidDB^® tools (and ODBC clients), and JDBC client

▪Creating a database with an internally authenticated DBA

▪Creating an externally authenticated user using solidDB^® SQL Editor (solsql) In the examples, the Windows domain is chicago and the user name of the externally authenticated user is testuser.

▪Compiling a sample application (samples\jdbc\sample1.java)

▪Connecting to solidDB^® server with a JDBC connection as an externally authenticated user

Procedure

1 Modify the external authentication related parameters in solid.ini.

2 Add the following lines to the solid.ini configuration file in the samples\jdbc\run directory:

[General]
UseCryptoLib=yes
CryptoLibPath=<solidDB installation directory>\bin
DefaultDomainName=<Windows_domain_name> ;for example: chicago
[Client]
UseCryptoLib=yes
CryptoLibPath="<solidDB installation directory>\bin"

If the path contains a white space, enclose the path in double quotation marks.

In this example, the solid.ini file in samples\jdbc\run functions as both the server-side and client-side configuration file.

However, the [Client] section parameters are not needed for JDBC connections. Instead, the parameter settings are needed if you want to test that you can connect to solidDB^® server with solsql as an externally authenticated user (step 5).

3 Check that the location of the OpenSSL libcrypto and LLA libraries is defined in the PATH environment variable.

To add the default installation directory of the OpenSSL libcrypto and LLA libraries to PATH, issue the following command:

set PATH="C:\Program Files\UNICOM\soliddb\soliddb100.0\bin";%PATH%

4 Start solidDB^® server and create a new database with an internally authenticated DBA with user name dba and password dba.

Use the samples\jdbc\run as the working directory.

cd <solidDB installation directory>\samples\jdbc\..\..\bin\solid -c run -Udba -Pdba -Cdba

The solidDB^® server starts, listening at tcp 2315.

5 Connect to the solidDB^® server using the DBA account.

..\..\bin\solsql -c run "tcp 2315" dba dba

soliddb SQL Editor (teletype) - Version: 7.0.0.2 Build 2012-04-20

Execute SQL statements terminated by a semicolon. Exit by giving command: exit;

solsql>

If the solsql connection fails with the error message SQLAllocEnv:

▪Check that the solsql working directory contains the solid.ini file with the Client.UseCryptoLibt and Client.CryptoLibPath parameters.

▪Check that the OpenSSL libcrypto path is defined correctly with the Client.GSKitPath parameter.

6 Create an externally authenticated user testuser using solsql.

For example, if the user name for your Windows user account is testuser, issue the following command:

solsql>CREATE USER testuser IDENTIFIED EXTERNALLY;

7 Optional: Check the authentication types of the users by querying the SYS_USERS system table.

For example:

solsql> SELECT ID, NAME, AUTHENTICATION FROM SYS_USERS;

ID NAME      AUTHENTICATION
-- ----      --------------
1 DBA       0
4 TESTUSER  1
2 rows fetched.

Value 1 in the column AUTHENTICATION means that the user is authenticated externally.

8 Optional: Restart solsql and log in as the externally authenticated user.

solsql> quit;
solidDB^® SQL Editor exiting.
<solidDB installation directory>\samples\jdbc\run>..
\..\..\bin\solsql "tcp 3315" testuser T3stus3r
soliddb SQL Editor (teletype) - Version: 100.0.0.2 Build 2014-12-20
Execute SQL statements terminated by a semicolon. Exit by giving command: exit;
solsql>

9 Modify sample1.java by adding the external authentication related JDBC properties.

Add the OpenSSL libcrypto configuration information as new properties:

props = new Properties();
props.put("StatementCache","32"); // existing property in sample1.java props.put("solid_crypto_path",
"<solidDB installation directory>\bin");
props.put("solid_use_strong_encryption", "yes");

10 Compile sample1.java.

<solidDB installation directory>\samples\jdbc>javac sample1.java

11 Execute the sample application. The application will prompt you to provide the solidDB^® JDBC connect string, including the user name and password of the externally authenticated user.

Issue the following command:

java -classpath ..\..\jdbc\SolidDriver2.0.jar;. sample1

For example:

<solidDB installation directory>\samples\jdb
c>java -classpath ..\..\jdbc\SolidDriver2.0.jar;. sample1

JDBC sample application starts...
Application tries to register the driver.
Driver succesfully registered.

Now sample application needs a connect string in format:

jdbc:solid://<host>:<port>/<user name>/<password>
Please enter the connect string (default:jdbc:solid://localhost:2315/dba/dba)>

For example, provide the following connect string:

jdbc:solid://localhost:2315/testuser/T3stus3r

If the login details are correct, the application will continue as follows:

Attempting to connect :jdbc:solid://localhost:2315:testuser/T3stus3r
SolidDriver succesfully connected.
Query executed and result set obtained. Obtaining metadata information.

Metadata information for columns is as follows:

Column i:1 TABLE_SCHEMA,12,WVARCHAR

Column i:2 TABLE_NAME,12,WVARCHAR

...

Row 89 : _SYSTEM SYS_SYNC_REPLICA_PROPERTIES BASE TABLE

Row 90 : _SYSTEM SYS_BACKGROUNDJOB_INFO BASE TABLE

Result set dumped. Sample application finishes.

In some environments, you might need to provide the OpenSSL libcrypto and LLA library path with -Djava.library.path when starting the application.

For example:

java -Djava.library.path=..\..\bin -classpath ..\..\jdbc\SolidDriver2.0.jar;. sample1

Related concepts

Troubleshooting encryption and authentication