Configure Web UI Identification, Authentication and Encryption

Overview of security information when using CGE via a web UI.

After setting up the web UI users and their permissions, the web UI needs to be configured to identify and authenticate users who want to use the database through the web UI. The cge-cli fe command searches the working directory from which it is launched followed by 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) to find its configuration files. Any configuration that is put in the CGE configuration directory will be shared by any web UI that is launched using that directory. This can be convenient when running multiple web UI instances using the same configuration.

There are three major elements of this configuration:
  • The identification and authentication mechanism to be used (private or LDAP) and the form in which the credentials are presented to the CGE web UI (forms or HTTP basic).
  • The list of users and passwords to use (or, in the case of LDAP, the particulars of the LDAP server interaction)
  • SSL Encryption to protect the content of communications (including credentials) and to assure the web UI user of the authenticity of the web UI service.

Choose and Configure an Identification and Authentication Mechanism

The web UI uses the Apache Shiro Security Framework to implement Identification and authentication of users. This framework permits the user to configure one or more security realms as the basis for Authentication. An example of a realm is LDAP authentication, in which an enterprise or cluster based LDAP directory is used for authentication decisions. Another example is a simple private text based user / password list stored in the configuration (.ini) file. Which of these you choose depends on how you want to define your user base for your instance of CGE.

In addition to this, there are two different mechanisms for collecting the user's identity and authentication credentials: HTTP Basic and Forms based. In the HTTP basic approach, HTTP issues an authentication challenge to the browser or application attempting to access your web UI and the browser or application prompts the user for an identity and a password. From that, the browser generates and remembers a set of authentication credentials and attaches them to every subsequent request. This is useful for programmatic access to the web UI, but can be a bit cumbersome for user interactive use. In the Forms based approach, the user is presented with a login page on first contact with the web UI. The user fills out a username and password, and the web UI establishes a session with the user. This is very convenient for interactive use of the web UI but awkward for programmatic use, where the program will have trouble interacting with the login page. Which of these you choose depends on the mix of user interactive and programmatic access you expect your web UI to support.

CGE offers a tool, cge-cli generate shiro, that allows you to generate template configuration files for HTTP Basic with private authentication data, Forms based with private authentication data, and Forms based with LDAP authentication. To use HTTP Basic with LDAP you need to make a minor change to the Forms based with LDAP configuration.

More complex and expressive Shiro configurations are also supported by CGE, but cge-cli generate shiro does not offer tools to generate templates for them. Templates and advice may be found in the open-source Shiro community. For more information, see http://shiro.apache.org/documentation.html .

Choose the Mechanism

The first choice that needs to be made is the kind of authentication the CGE Instance web UI needs. If the user is setting up an independent instance of CGE where the user wants to fully control the security environment of the instance, or the user does not have access to an LDAP server that fully expresses the range of users the user will be interacting with, then the private approach to storing authentication data makes sense for the CGE Instance. An example of this might be some kind of moderated public access to a CGE Database, where the user does not want other users to be configured as part of the user's LDAP directory. If the user is setting up an enterprise wide CGE server, where the authentication data for all users is already stored in an enterprise LDAP server, and it is required to allow those users selective access to the CGE Instance, the LDAP approach makes the most sense. The ability to log into the web UI does not necessarily impart the ability to interact with the database. The user must also be authorized as a web UI client (i.e. have the web UI Super Client public key associated with his or her username in an authorized_keys file).

The next decision is whether to use the HTTP or Forms based login mechanism. If it is expected to have a mix of user interactive and programmatic use of the web UI, then HTTP Basic makes the most sense, even though it is a bit more cumbersome for interactive users. If only user interactive use is anticipated, then the Forms based approach makes the most sense.