1. Documentation
2. Users & Security

3. Security, Users & Permissions

3.1. Default Users & Roles

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

• admin (user) — Created if no other users are detected on server startup. 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 login app to function properly.

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.
• 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 used for "password recovery" via email or similar.

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).

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

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 access to an object. This is used to allow access to connections, procedures and similar when used by another object (i.e. a procedure).
• read — Provides read (and execute) access to an object. This also allows introspection into the object properties, source code and similar. Implies internal access as well.
• search — Provides object listing and search permission. Note that only objects with read permission are returned in search results, regardless of this permission.
• 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 permission requested.
• ... — 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.

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:

• 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 case-sensitive.
• 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 literal . characters (among others).
• access.#.permission — The access permissions to match (see list above). May contain several permissions, separated by , or .

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:

• Disable admin User – Make sure that the admin user is either disabled or provided with a strong password.
• 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 be encrypted, since information can otherwise be eavesdropped. Use an HTTPS reverse proxy, an HTTPS servlet container, a VPN tunnel or similar.
• 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 usage.