Database authentication
Instructions to Make a Key
To connect to a database server to run queries, you must authenticate your connection. For interactive utilities, like the Deephaven console, you do so through a username/password dialog box. For automated batch queries, you must use a private key file. Best practices dictate that system batch jobs are run as a role user.
If you are writing your own batch queries (or interactive utilities), you need to provide a method for authenticating your client before any database connection is made. The database components all use the WAuthenticationClientManager.DEFAULT
instance, so authenticating should be performed using one of the following methods:
- Setting the
WAuthenticationClientManager.defaultPrivateKeyFile
property, which will automatically authenticate using the selected private key. For a batch query, this is the preferred choice. - Calling
WAuthenticationManager.DEFAULT.challengeResponse(String privateKeyFile)
, with a private key file that has had its public key entered into the file specified byauthentication.server.authorizedkeys.file
(default isdsakeys.txt
). - Implementing a method to get the password from the user. You should not have users store passwords in a file. If the password is typed in, you should make it obscured (for example, by using
java.io.Console.readPassword
).
To generate a keypair using generate-iris-keys
, the workflow is as follows:
$ sudo -u irisadmin /usr/illumon/latest/bin/generate-iris-keys <user>
Generating DSA parameters, 512 bit long prime
This could take some time
.+.+.....+...+......+...........+....+.....................+...+.......+.+..+.+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*
...+....+..........................+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*
Generating DSA key, 512 bits
Writing public key
read DSA key
writing DSA key
Converting to DER
read DSA key
writing DSA key
Converting Public Key to Base64
Converting to Base64
Signature creation
Signature check
Verified OK
$ sudo -u irisadmin sh -c "cat pub-<user>.base64.txt >> <auth_keys_file>"
$ sudo -u irisadmin mv priv-<user>.base64.txt <someplace safe>
Note
It is best practice to store authorized public keys into source control. The private keys should be protected using file permissions, as if they were a password.
The authentication server must be restarted for the new configuration to take place. Alternatively, the configuration can be reloaded without a restart via:
sudo -u irisadmin /usr/illumon/latest/bin/iris auth_server_reload_tool
How to Connect to a DB Server
To connect to a database server to run queries, you must authenticate your connection. For interactive utilities, like the Deephaven console, you do so through a username/password dialog box. For automated batch queries, you must use a private key file. You should generate your own private key that allows you to authenticate to the database for batch jobs like back tests, without having to enter a password, and then provide the public key to the system administrator. Move this file to the machine that you use to run batch jobs. When you run a batch job, make sure to add the JVM property:
WAuthenticationClientManager.defaultPrivateKeyFile=<path/to/private/key/file>
- For example, you could use the following property on Windows:
WAuthenticationClientManager.defaultPrivateKeyFile=C:\\Users\\<username>\\priv-<user>.base64.txt
- Or the following property on Linux:
WAuthenticationClientManager.defaultPrivateKeyFile=/Users/<username>/priv-{user}.base64.txt
You can set this property from any prop file that you include, or if you prefer, you can also set it from the IntelliJ VM Options by prefacing it with –D
. You can do this for an individual configuration, by selecting the configuration and adding -DWAuthenticationClientManager.defaultPrivateKeyFile=<path/to/private/key/file>
to that configuration's VM Options string.
You can alternatively update the default options for applications to include this property ("Run" menu -> "Edit Configurations" -> "Defaults" -> "Application", "VM Options" field), which will take effect for new configurations (but not your existing configurations).
You should treat this file like a password; other users should not be allowed to read it:
chmod 600 <path/to/private/key/file>
This will allow only the owner to read the file, which can be verified via:
ls -l <path/to/private/key/file>
Permissions should read rw- --- ---.