3. Security, Users & Permissions

Security Notice

  • Read Security Notices — This chapter contains a number of security notices. They are provided for your protection. Read them.
  • Understand Implications — The security implications of installing RapidContext must be properly understood. Especially for a production environment or for a server reachable from an external network (Internet).
  • Follow Advice & Precautions — Take care to follow the advice or best practices outlined in this chapter. Please revisit this chapter from time to time to validate that good security practices remain enforced.

3.1 Default Users & Roles

The default installation of RapidContext contain the following users and roles:

Security Notice

  • Modify admin User Password — Either disable the admin user or assign a strong password.
  • Limit admin Role Usage — The admin role should only be assigned to a few system owners, if possible. Create other roles instead, that provide more limited privileges needed for daily access.

3.2 User Authentication

RapidContext supports both authenticated and anonymous usage. The following protocols for user authentication are built-in and supported by default:

Security Notice

It is strongly recommended to only use user authentication over secure channels (intranets, VPN tunnels or HTTPS). Otherwise the communication is vulnerable to eavesdropping, man-in-the-middle attacks or replay attacks.

3.3 Sessions & Persistent Cookie Authentication

Client sessions are created (if missing) for each request to the app base URL (i.e. the app launcher). The sessionid HTTP cookie is sent to the web browser containing the unique identifier. Sessions are not created when accessing app file resources or APIs, but an existing session will be used if already set.

After a successful authentication (via procedure call), the active session is bound to the user. No further authentication is thereafter required until the HTTP cookie expires or is invalidated. This avoids repeated authentication requests.


A user session can be invalidated in one of the following ways:

  • Automatic Expiry — Both the sessionid cookie and the session object itself will automatically expire. Anonymous sessions expire after 30 minutes of inactivity, but authenticated sessions stay valid for 30 days after the most recent access (or a maximum of 90 days after creation).
  • User Logout — Users can logout from the user menu (top right in the standard user interface).
  • Forced Termination — The built-in procedure system/session/terminate allows the early termination of any user session (if permission allows).

Security Notice

  • Logout — Due to persistent cookie authentication, it is strongly recommended to always logout when using shared computers or privileged user accounts.
  • Disable Session Storage Access — Session identifiers must be protected in storage, as there is otherwise a risk for session hijacking.

3.4 User Management & Storage

Users are managed with the built-in Admin app. Follow the steps below in order to edit or create a user:

  1. Launch or go to the Admin app
  2. Choose the Users tab
  3. Select the appropriate user OR press the + icon
  4. Edit the user form (see screenshot for admin user)

  5. Press Save to store the changes


A few notes regarding user data storage:

  • Passwords — Passwords are stored with a one-way MD5 hash (without salt). This makes them impossible to decrypt, but still vulnerable to dictionary attacks or password guessing.
  • User Removal – Users can be removed by deleting the corresponding file from storage, but this is discouraged. Instead, use the Enabled checkbox instead.
  • Storage Location – The user objects are normally found in the local plug-in, with each user stored as user/[identifier]. The proper security precautions for this path are outlined in the security notice below.

Security Notice

  • Protect Password Hashes — Although the actual password cannot be retrieved from a password hash, it is still possible to login (or change password) using only a user name and a password hash. This is due to the workings of the HTTP Digest mechanism.
  • Disable User read Access — Due to the unsafe nature of the password hashes, all read access to the /user/** storage path or the corresponding /storage/plugin/*/user/** must be limited.
  • Disable User write Access — Anyone with write permissions to /user/** (or the file system) can reset any user password or assign users to the admin role.

3.5 Roles & Access Control

All access control is assigned via roles. Each role provides an access control list, detailing a list of storage paths and the corresponding permissions. The permission names and their meanings are the following:

Multiple roles may be assigned to each user, providing the user will the union of the role permissions. Roles can also be automatically assigned to users via the auto property:

Security Notice

  • Disable Role write Access — Since the role objects contain the access control lists, any user with write access to a role object can provide full system access to users with that role. Even read access to role/** should be limited.

3.6 Role Management & Storage

Roles are currently created and modified without any admin tools. The role objects can be found in storage as role/[identifier]. See below for an example role properties file:

# General properties
id = demo
type = role
name = Demo
description = Provides access to the demo app and procedures.

# Access array
access.0.path = app/demo
access.0.permission = read
access.1.path = procedure/Demo.**
access.1.permission = read

The configuration for the access array (the access control list) supports the following properties:

Permissions can be checked on all object access via the built-in procedures or web services. Additional permissions can be checked programmatically via the system/user/access procedure.

3.7 Security Checklist

Before installing a RapidContext server in production environment or on a server reachable from an external network (Internet), please check the following: