The UI and workspace security

The MAT Web server provides service access to workspaces, which the UI subscribes to. Unlike file mode, workspace mode is stateful from the point of view of the UI. It is the server, rather than the client, which loads and saves the files. However, we don't want just anybody to be able to cause the server to perform these stateful operations, so the MAT web server implements a very simple security mechanism.

The MAT Web server is NOT SECURE

The MAT Web server is not an enterprise-secure implementation, and will never be one. It does not use SSL; in workspace mode, it does not perform any sort of user authentication beyond the workspace key; it does not provide any security logging or traceability. You should assume that anyone who has access to your network can see your Web server traffic, and either observe or (in the case of workspaces) overwrite your data.

The MAT Web server doesn't support accounts, logins, or special file permissions. Instead, when the server starts, it generates and prints a workspace key. This key is a 32-character random alphanumeric sequence. When the user wants to interact with the server in workspace mode, the UI prompts the user for this key, and transmits it to the server, which compares it to the key it generated. If they match, workspace mode is enabled; if they don't, it's not. This mechanism guarantees that only the person who started the Web server, or someone that person has transmitted the workspace key to, can access the workspace via that Web server.

In addition, by default, the Web server only allows local clients to access workspaces; if you're contacting the Web server from another machine, you won't be able to open any workspaces. However, you can override this behavior by starting the server with the --allow_remote_workspace_access option.

This mechanism is simple and straightforward. There's no account management required, and the server can only be interrogated for the workspace key via its command loop, which means that unless you have console access to the Web server, you can't discover the key.


Permissions aren't issued per workspace; the Web server has exactly as much file access as the user who started the Web server. As a result, we need to provide the ability to carefully circumscribe the workspace access the clients have. So we've added the --workspace_container_directory option to the MAT Web server. This option can be used to force the Web server to search only the directories specified for workspaces. With this flag, although all changes are still made with the UID of the user who started the Web server, the accessible directories are strictly limited.

The user can provide a workspace key to the Web server rather than having one automatically generated. The MAT Web server provides a simple command-line option, --workspace_key, for this. However, if the user uses this option, the key will be visible in Unix process listings. This may be acceptable for single-user local access or for testing, but is clearly unacceptable for deploying the MAT Web server as a persisent service. To address this shortcoming, we've added the --workspace_key_file option to the MAT Web server. This file should be UTF-8 text file readable only by the user who starts MATWeb. As an added bit of security, this mechanism is the only mechanism used when the MAT Web server automatically restarts - even if the user originally used the --workspace_key option.

If the MAT Web server is being run as a persistent service, it's likely that the output of the MAT Web server will be saved to a log file using the --output_log option. The workspace key is printed to the console when the MAT Web server starts up, so the key will be visible in this file. As a precaution, then, whoever sets up the MAT Web server should ensure that the output log is readable only by the user who starts MATWeb.