- Users & Security
3. Security, Users & Permissions
- Read Security Notices — This chapter contains
a number of security notices. They are provided for your protection.
- 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
- admin (user) — Created on server
startup if no other users are found. The password is initially set to
accept any value (an empty string). The user is also assigned the
admin role. It is good practice to either disable this user
or assign it a proper password.
- admin (role) — A built-in role that
provides full access to all objects. This role should not be
modified or removed from the system. Instead, it should be
assigned to users with care. In most installations, it should be the
only role with access to modify procedures, manage plug-ins, and
similar administrative operations.
- anonymous (role) — A built-in role that
provides anonymous (i.e. public) access to system procedures and some
built-in apps. This role is required for the start and login apps to
- 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:
- HTTP Digest Auth — Uses a browser built-in login
dialog for user authentication. This method uses a challenge-response
protocol that avoids sending the password over the wire.
- HTTP Token Auth — Using an authentication token,
any HTTP call may be authenticated. This method is normally only used for
automated API access.
- system/session/authenticate Procedure —
Uses HTTP POST to call a procedure with an MD5 hash similar to HTTP
digest auth. This method uses a challenge-response scheme that avoids
sending the password over the wire.
- system/session/authenticatetoken Procedure
— Uses HTTP POST to call a procedure with an authentication token
that contains both user id and a password equivalent. This method is
normally used for "password recovery" via email or similar.
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
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
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).
- 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:
- Launch or go to the Admin app
- Choose the
- Select the appropriate user OR press the
- Edit the user form (see screenshot for admin user)
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
- User Removal – Users can be removed by
deleting the corresponding file from storage, but this is
discouraged. Instead, use the
- 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.
- 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
- 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
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:
- none — Provides no access at all. This is used to block
access to a subpath, as this permission also stops further searching down
the access control list when matched.
- internal — Provides indirect read (and execute/use)
access to an object. This allows using connections, procedures and
similar when referenced by another procedure.
- read — Provides direct read (and execute/use) access to
an object. This also allows introspection into the object properties,
source code and similar.
- search — Provides object listing and search permission.
Note that only objects with read (or internal)
permission are returned in search results.
- write — Provides write (and delete) access to an object.
This is used when modifications to data or similar must be allowed. Note
that this does not imply either read or
search access to the same objects.
- all — Provides all permissions. This can be used as a
shorthand way to provide read, search and
write permission to objects, but it also provides any custom
- ... — Any other permission name is considered a custom
permission. No automatic access control is performed for such permissions,
but they can be checked programmatically.
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:
- auto = all — Assigns the role to all users, including
anonymous, non-authenticated users. This is used to add permissions
for anonymous access.
- auto = auth — Assigns the role to all authenticated
users, regardless of their other roles. This is used to add permissions
to logged-in users.
- 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:
id = demo
type = role
name = Demo
description = Provides access to the demo app and procedures.
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:
- access.#.path — The storage path for the object. May
contain wildcard ?, * or ** characters
to match multiple objects. Only ** will match
characters (i.e. storage path separators). All path names are
- access.#.regexp — The storage path for the object, as
defined by a regular expression. This is used as an alternative to
path when more complex matching is necessary. Note that
regular expression syntax is tricky and requires proper escaping of
. characters (among others).
- access.#.permission — The access permissions provided
(see above). May contain several permissions, separated by
Permissions can be checked on all object access via the built-in procedures
or web services. Additional permissions can be checked programmatically via the
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
- Disable admin User – Make sure that the
admin user is either disabled or provided with a strong
- Use Strong Passwords – Users should be encouraged
to use strong passwords in order to avoid risks with brute-force attacks
or password guessing.
- Encrypt Connections – All external communications
should be encrypted, since information can otherwise be eavesdropped. Use
an HTTPS reverse proxy, an HTTPS servlet container, a VPN tunnel or
- Verify Access Controls – Test the access controls
for each role with a test user (having only that role). Verify that all
privileged resources are unavailable for any unprivileged role.
- Limit admin Role Access – The number of
users with the admin role should be limited, to avoid
potential abuse of the system. Create more limited roles for daily