Configure Server Side Identification and Authentication

How to configure the server side CGE server side identification

Configuring server side identification and authentication includes setting up both authorized Linux logged In (i.e. command-line) users, and setting up any super client authorized users that are needed for Web UI access or other purposes. The database owner needs to make decisions about the following:

  • Is it required to allow command line clients to access the dataset?
  • Is it required to grant Web-UI clients access to the dataset?
  • At what scope (single dataset or all the datasets) is it required to authorize each given user, both the Web-UI identity and the Linux identity?

The authorized_keys File

The CGE Server searches the file named authorized_keys in each of the following directories for a username that matches the username presented with a given request:

  • the database data directory
  • the CGE configuration directory (either by default: $HOME/.cge, or the value of $CGE_CONFIG_DIR_NAME which can be set using the --configDir=URL option to cge-launch)
  • $HOME/.ssh

Each username match is tested in turn until the public key associated with that match works for public-key authentication. Once a match is found, the user has successfully authenticated and becomes an authorized user for the duration of that request. Subsequent permission checks determine what that user is authorized to do.

One important decision the database owner needs to make is where to put a given user authorization. The choice of the authorized_keys file to store a given username/key combination depends on the breadth of authorization the owner of one or more databases wants to grant to the user. This breadth has three scopes:

  • authorization to use only one database
  • authorization to use all databases configured from the same configuration directory (typically all owned databases)
  • authorization to use all owned databases and, likely, to log into the Linux host using the self identity
By placing a user's authorization in the authorized_keys file in the database data directory, the user is granted the most limited scope of authorization. This is appropriate for users that need to be granted access to that specific database, or if the database owner owns multiple databases with multiple potentially overlapping lists of authorized users and wants local control over each user authorization. By placing the user's authorization in the CGE Configuration directory, the user is granted intermediate scope of authorization. This is appropriate if the database owner owns multiple databases with a core set of users who are authorized on all of the databases. Placing a user in the $HOME/.ssh/authorized_keys file can potentially permit that user to log in as the database owner, which is a serious security threat. Never put any username/key combination that is not specifically your own SSH key (for login) in the $HOME/.ssh/authorized_keys file. This file is included in the search solely to make using CGE as the owner of the database simpler.

Authorized Keys for Command Line/API Use of the CGE Database

Users who are authorized to log into the server where the CGE database resides and use the cge-cli command or one of the CGE APIs to interact with your CGE Database need to have the public SSH key corresponding to their private SSH key stored in one of the authorized_keys files. Users may communicate their public SSH keys to you using whatever means (E-mail, publicly readable files, etc.) is mutually convenient. The user's public key can be generated using the ssh-keygen command and usually resides in the user's $HOME/.ssh directory in one of the following files:
  • id_rsa.pub (RSA based public key)
  • id_dsa.pub (DSA based public key)

When adding a command line/API key to the authorized_keys file, make sure that the key is a single line comprised of three parts (separated by spaces):

  • the signing scheme used by the key (RSA or DSA)
  • the key itself
  • the username@host identifying the user

and that the username part of the username@host part matches the logged in user name of the requesting user. The host part is ignored, so it can be anything. Here is an example entry. Note that the content, which is a single line, is split up into multiple lines due to lack of space:

ssh-rsa 
AAAAB3NzaC1yc2EAAAADAQABAAABAQDOVyLTKwz/RAngMegeTST2Ow0JMwFea9qQC6R7en7A+BcsIaNt2m+9Vh/AocMfaruwpyHr26\
epsdpC8Thw4+9NIUfoUoJyKC6TMZcntF7e3RiY1yZt6uvKUIgs75zS4fqZMAtHEiuvgLHkZwypKF1vsscusSYCMkNxXUa0E38UcPVmH\
+zEGWpc9yyObl+7Ae4PuKIjw6gpOtX8W8Wz/Eb5UAwf56pCR045izZBwRe7y9anHe3+XtluFU9zU1I80aeRHg64KmMS3jCNhGIFOwmW\
O8iYmxHXyCheifxdYpCgI+jN+jQ6CqbFe4OrbkbuP/elAmFYl5BHMWi7LmYVWEYP user@nid00030
This will authorize the user user with the corresponding private SSH key to use your database.

Authorized Keys for Web-UI Users

The Web-UI uses the Super Client key of the user running the cge-cli fe command to submit requests on behalf of logged-in Web-UI clients. Normally, the user running the cge-cli fe command is the owner of the database, so examples of adding users are shown using your public SSH key as the authorizing key for Web-UI users in the authorized_keys file.

Assuming you are the user who will be running the cge-ci fe command for your database, the following command adds the user david as an authorized Web-UI user of your CGE Database:
$ $ sed -e "s/ $USER@/ david@/"< $HOME/.ssh/id_rsa.pub >> \
    authorized_keys
This replaces your username from your id_rsa.pub public key file (a similar command will work with an id_dsa.pub file as well) with david creating a user named david that you are authorized to authenticate for your CGE Database instance. Do this for all the Web-UI users you want to authorize. You will also need to make sure they are able to log into your Web-UI.