Authenticating

This section describes different ways of authenticating to the database.

Authenticating with a password

By default, users must supply a password when connecting. Some common ways to connect are described below:

  • Kognitio Console - Kognitio maintain a graphical Windows application, called Console, which can be used to connect to and browse a Kognitio system. More information can be found at http://www.kognitio.com/forums/viewforum.php?f=5

  • wxsubmit - a command line utility for connecting to a Kognitio system. The syntax is:

    wxsubmit -s SYSTEM USER [-p PASSWORD]
    

    For a full list of options, see man pages. If the -p option is omitted, an interactive prompt will appear asking for the password.

  • wxbashtools - is a set of bash function definitions designed to help bash scripts submit SQL and fetch results directly into bash variables.

    The syntax for connecting is:

    source wxbashtools;
    connect SYSTEM USER [PASSWORD]
    

    For a full list of options, see man pages. If the -p option is omitted, an interactive prompt will appear asking for the password.

Authenticating without a password

Passwordless authentication to a system is achieved with the use of a private/public keypair.

Kognitio stores a list of public keys and the user IDs that are allowed to authenticate with them in a table called IPE_AUTHORISED_KEYS. When logging on to Kognitio, if a blank password is supplied and the ODBC driver can contact an ssh-agent, the Kognitio session will be authenticated via public key cryptography. The ODBC driver attempts to connect to a running ssh-agent using the named socket in the environment variable SSH_AUTH_SOCK. Kognitio sends a random challenge, which the ssh-agent signs with all the private keys it has, the resulting signatures are then sent back to Kognitio for verification against the public keys they claim to be verifiable with, and if one succeeds, authentication is successful.

If for some reason, an ssh-agent cannot be run, then it is possible to make the ODBC driver sign the challenge itself, by identifying the location of the key in the odbc.ini file using an entry of the form: PrivateKey=private-key-pathname. In this case, authentication using SSH keys is attempted even if the password is non-blank. If the password is non-blank and the key is encrypted, the password is used as the passphrase to decrypt the key. If a passphrase is required to decrypt the key and a password is not given, then an attempt will be made to prompt for the passphrase, if this is not possible, for example it is a GUI based application, then authentication will fail This mechanism means the user should never have to type their passphrase in clear text as both the passphrase and password prompts hide what is typed.

Keys can be added to Kognitio in two ways. The first is with an SQL query inside Kognitio:

alter user USER add TYPE key KEY

Where KEY is the public key string in quotes, and TYPE is either dsa or rsa.

The second method uses a bash script on the command line

wxaddkey [opts] -s SYSTEM USER [-p PASSWORD] [KEY-FILE-NAME]

If KEY-FILE-NAME is omitted, it will search for ~/.ssh/id_dsa.pub and ~/.ssh/id_rsa.pub in that order. The wxaddkey utility is in the directory /opt/kognitio/wx2/current/bin. Run ‘wxaddkey -h’ for a full list of options.

Using the SYS user to log in as another user

A useful feature to assist with the analysis of issues associated with a particular user’s access rights is the ability of the SYS user to login as that user by using the SYS password rather than the user’s password. This establishes a session with the same privileges and access controls as the user normally receives and thus allows the SYS user to reconstruct and investigate a particular problem.

If, for security reasons, this feature is deemed undesirable in a particular environment then it can be disabled by adding the following to the [general] section of the system configuration file:

sys_pass_master=no