1. Documentation
2. Users & Security

3. Security, Users & Permissions

3.1 Default Users & Roles

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

• 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 work.

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.

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.

3.4 User Management & Storage

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

1. Launch or go to the Settings app
2. Choose the Users tab
3. Select a user and press the Edit or Add user button
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 (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 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-insensitive.
• 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 provided (see 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 should 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.