CGE Security

Details about CGE security mechanisms

CGE security starts at the entry point to the request handling in the CGE server and extends outward to the web UI and the CGE CLI commands. CGE Security is comprised of the following mechanisms:

  • Server side user identification and authentication
  • User permissions and access control
  • User accountability
  • Client side user identification and authentication

Server Side User Identification and Authentication

Users on the server side of CGE are identified by user names, which are character strings that name the user. User names within CGE are not necessarily tied to any specific user known to the Linux platform on which the CGE server is running, though there are scenarios in which it is practical to configure CGE users using their Linux login usernames. This freedom from the Linux platform permits a database owner to set up a CGE instance that is web accessible (more on this later) and has a user community completely defined by the database owner without respect to ability to log into the Linux platform on which the CGE Instance is running. This is similar to other web-based frameworks that permit the owner of the framework to set up the user community without needing to be able to create user logins on the host platform.

The CGE Server handles requests in the context of a client connection. Each connection establishes a context in which one or more sequential requests may be issued. While each connection may present a sequence of requests, these connections are not persistent in the sense that they represent an open ended logged in relationship with the client. The most common scenario is a connection that presents one or two requests and handles the responses, then disconnects.

Each connection is made without context preserved from any previous connection. Because of this, each time a client connects to submit requests, the client submits the user name (identity) of the user making the request. The CGE server uses the SSH public-key authentication protocol to verify that the client submitting the user name has the authorization to present that user name.

Normally, authentication strives to verify that the user presenting an identity actually is the user who owns that identity. In the case of the CGE server, the expectation is that this level of authentication has already been done on the client side. The CGE server needs to know that it is talking to a client that is authorized to present work on behalf of the specified user.

User Permissions and Access Control

The CGE server handles work as a sequence of requests. Each request has a particular type, such as
  • Query
  • Update
  • Checkpoint
  • Shutdown
Each request type has an associated permission that determines whether a client making that request is allowed to make that request or not. Permissions can be associated with individual users or groups of users by making permission assignments in an Access Control List (ACL) located in the directory where the CGE dataset is found.

When a request arrives, the username presented by the request is authenticated and then the permissions associated with that username are looked up. If the permission associated with the incoming request type is present in the user's permission set, the request is allowed to proceed. If not, the user is notified of the request failure and the request is not allowed to proceed.

This mechanism allows the owner of a CGE database to establish coarse grained protections against unauthorized actions by otherwise authorized user.

User Accountability

When a user submits a request, the CGE Server runs that request on behalf of that user. The owner of the CGE database may want to review the operations that have been executed by a given user. To this end, from the moment a request arrives to the moment that the request completes processing and reports its result (successful or not) the username of the client making the request is recorded with each log entry written by the CGE server into its operational log. Even if the user has the permission to turn off all logging for the duration of the request, CGE server records log entries at the beginning of the request indicating that the user has turned off logging. Those log entries are tagged with the requesting user's username.

Client Side Identification and Authentication

Client side identification and authentication is responsible for assuring that a user making a request actually is the purported user. There are two different kinds of client seen by CGE:

  • logged in Linux users running CGE CLI commands and APIs as clients
  • Web-based clients
The identification and authentication for these two different kinds of clients differs, so each are explored separately.
  • Logged In Linux users as clients - A logged in Linux user has already been identified and authenticated by Linux, and the user's credentials have been established by Linux. If there were a simple trustworthy way to transmit those credentials directly to the CGE Server, this would be sufficient and the client would simply assert the user's logged in Linux identity with every request. Because requests are transmitted outside of a trusted context, however, the CGE Server authenticates the requested username using SSH public-key authentication as described above.

    Within the category of Logged In Linux users, a client may be either a normal client or a super client. The distinction is between clients that can only present a single username to the CGE server and clients that may present some larger set of usernames (constrained by the CGE server configuration) to the CGE server.

    • Normal clients - A normal logged in Linux user client presents the username of the Linux user with each request. The server side authentication of a logged in Linux user uses that user's public SSH key for public-key authentication of the user. Since Linux is a trusted repository for user identity, once the user has logged into Linux the user's identity can be trusted (by the client) at all times. The degree to which the client is trusted by the CGE Server hinges on the ability of the SSH protocol to match the requested username with a working public key.
    • Super clients - A super client is a logged in Linux user whose private SSH key matches with more than one public-key/username pair in the CGE Server configuration. Generally, the owner of the CGE Database will be a super client, allowing him or her to run the Web UI and enable user authentication, but any user can be set up by the database owner as a super client. In the case of a super client, an arbitrary username is presented with each request (generally corresponding to a user who has been authenticated using some higher level mechanism). If the username matches a public key that works with the super client user's private SSH key, the supplied username will be used by the CGE server. If not, the request will fail to authenticate at the CGE server and will not proceed.

    It is worth noting that the use of the same public key for multiple users while keeping the associated private key private to the owner of that key does not constitute SSH key sharing, since there is only one user (the super client user) who owns the key pair. In the case of key sharing, all users sharing the key have access to the same key pair. In this case, only the super client has access to the private key and the public key is used to allow the super client to authenticate as 'authorized to present' the specified username.

  • Web UI clients - The Web UI, CGE CLI front end is also capable of authenticating clients. It supports authentication using either an enterprise LDAP server or a user private authentication mode. The Web-UI also permits encryption of web transactions using SSL, to protect secrets (both authentication secrets and data secrets) in transit. When a user logs into the Web UI, the Web UI presents the logged in user name instead of the username of the Linux user who started the Web UI. For this to work, the user who starts the Web-UI needs to be the super client who has the correct private SSH key for all of the Web based users authorized to use the CGE Instance.

    Notice that Web UI clients are separated from logged in Linux clients by the keys used to log them in. A Linux user who has Web UI username/key pair on the CGE Server but no Linux username/key pair cannot use the Linux command line CGE CLI command. By the same token, if the user has no Web UI username/key pair, that user cannot use CGE through the Web UI. This allows the CGE Database owner to control both the form of access (via permissions) and the mode of access (command-line or web or both).