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 after installation in order to double-check on the issues outlined here.

3.1. Default Users & Roles

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

Security Notice

  • Modify admin User Password — Either disable the admin user or assign a strong password.
  • Avoid admin Role Access — The admin role should be avoided, if possible. Create new roles with more limited access privileges for daily usage.

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

After a successful authentication, a new session is initiated for the user. The sessionid HTTP cookie is sent to the web browser and no further authentication is required until the cookie expires or is invalidated. This avoids repeated authentication requests.

Session cookies are not created when accessing the storage web service, but are used if already set. Instead, the storage web service relies on HTTP Digest authentication (due to WebDAV compatibility).


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

  • Session Expiry — Both the sessionid cookie and the session itself is set to expire after 30 days.
  • 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.

Security Notice

Due to persistent cookie authentication, it is strongly recommended to always logout from user accounts with highly privileged access. Also, only secure communication channels (intranets, VPN tunnels or HTTPS) should be used.

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 almost impossible to decrypt, but a user with write permission can of course reset any user password as needed.
  • User Removal – Users can be removed by deleting the corresponding file from storage, but this is strongly discouraged. Use the Enabled checkbox in the dialog above instead.
  • Storage Location – The user objects can be found in the local plug-in, with each user stored as user/[identifier]. See the security notice below regarding the correct permissions for this path.

Security Notice

  • Protect Password Hashes — Although the actual password cannot be retrieved from a password hash, it is still possible to login 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 should be limited. Naturally, write access must also be limited.

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

The read permission should not be provided for user objects. Doing so allows other users to read the password hash or to create new authentication tokens. Both would allow login access for the user in question.

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.

Security Notice

  • Disable Role write Access — Since the role objects contain the access control lists, any user with write access to any role object can open the system for full access. Access to role/** should be very limited.

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: