Rights and accounts

The administrator account

At first startup, the CMS automatically creates the API cms/users and an administrative account in it. Name (e.g. admin) and password are in the server configuration (webAdmin, webAdminPass, see Operations). This account has the following rights:

• Full access to all namespaces, i.e. above all unrestricted creating, changing, and deleting of all APIs.
• All records of all APIs are visible but cannot be changed or deleted.
• Full access to the API cms/users: accounts and their rights can be maintained without restriction. Only the passwords are not accessible.

Rights

The following rights can be granted. Each right is a list of patterns.

Right	Effect
namespaceAdmin	Full access to the APIs of the specified namespaces: view, create, change, remove. This does not include access to records.
namespaceUser	View APIs of the specified namespaces, likewise without rights on records. Everyone who accesses APIs of the namespace needs at least this right (see below).
apiWrite	Full access to the records of the specified APIs: view, create, change, remove.
apiRead	View records of the specified APIs.

namespaceAdmin includes namespaceUser, apiWrite includes apiRead.

An additional rule applies to records: the account that created or last changed a record may always change or delete it as well. This does not include a read right. Something similar applies to APIs, but here only for the account that created the API.

Patterns

Pattern	Meaning
tutorial	exactly the namespace tutorial (for namespace…)
tutorial/html	exactly the API html in the namespace tutorial (for api…)
tutorial/*	all APIs in the namespace tutorial
*	all namespaces or all APIs in all namespaces
^…	regular expression, see below

If a pattern starts with ^, it is evaluated as a regular expression and matched against the namespace or against namespace/api:

Pattern	Matches
^kunde-	all namespaces starting with kunde-
^kunde-[^/]*/[^/]+$	all APIs in all namespaces starting with kunde-
^kunde-[^/]*/config$	APIs named config in all namespaces starting with kunde-
^[^/]+/config$	APIs named config in all namespaces

How rights combine

• Rights are pure allow lists. There are no denials. Access is allowed as soon as any pattern matches.
• The effective rights of an account are the union of the rights on the account itself and the rights of all its roles (see below).
• Every access to an API requires a right on the namespace. Anyone who wants to read or write records needs both: namespaceUser or namespaceAdmin for the namespace and apiRead or apiWrite for the API. An account with only apiRead: ["ns/api"] receives 403.
• Listings (/schema/<ns>, /projects) likewise show an API only with both rights. An account with only namespaceAdmin can create and change APIs but only sees them in the listing with a read right on the records (e.g. apiRead: ["ns/*"]).
• Multilingual APIs: The allowed languages are in the API ns/languages (see Multilingual content). Anyone who queries or writes records with localizable fields also needs a read right on ns/languages. With ns/* this is given automatically.
• /schema only reports namespaces in which at least one API already exists. With namespaceAdmin: ["*"] it is therefore not possible to enumerate which namespaces an account could create, only which already exist.

Typical configurations

Tenant with its own namespace (the account from the quick start):

{
    "account": "CMS_User_01",
    "namespaceAdmin": ["tutorial"],
    "apiWrite": ["tutorial/*"]
}

Editorial team that maintains content but does not change APIs:

{
    "account": "redaktion@museum.example",
    "namespaceUser": ["museum"],
    "apiWrite": ["museum/*"]
}

Application that only reads content:

{
    "account": "exponat-1",
    "namespaceUser": ["museum"],
    "apiRead": ["museum/*"]
}

Roles

Rights can also be granted via roles. There are two further predefined APIs for this:

• cms/rights: named rights collections with name and the lists namespaceAdmin, namespaceUser, apiWrite, and apiRead.
• cms/roles: roles with name and a list rights containing names from cms/rights.

An account refers to roles in its field roles. Example:

// cms/rights
{ "name": "museum-redaktion", "namespaceUser": ["museum"], "apiWrite": ["museum/*"] }

// cms/roles
{ "name": "redaktion", "rights": ["museum-redaktion"] }

// cms/users
{ "account": "redaktion@museum.example", "roles": ["redaktion"] }

/user reports the names of the effective rights collections in the field rights. Extensions (plugins) can evaluate them for their own permissions.

To maintain cms/roles and cms/rights, an account needs apiWrite on these APIs. The administrator account can grant this via cms/users.

Passwords

• A new account has no password. At the first sign-in via Basic, the password used is stored.
• Passwords are never readable, not even for the administrator. They are stored hashed with argon2.
• Anyone who has apiWrite on cms/users (i.e. the administrator) can set or reset a password. In the editing application, the Reset password button serves this purpose. Via the interface:

# Set password
curl -X POST -u 'admin:<password>' -H 'Content-Type: application/json' \
  -d '{ "account": "CMS_User_01", "password": "<new password>" }' \
  https://cms.example.org/data/cms/users/actions/password

# Reset password: the account sets a new one at the next sign-in
curl -X POST -u 'admin:<password>' -H 'Content-Type: application/json' \
  -d '{ "account": "CMS_User_01" }' \
  https://cms.example.org/data/cms/users/actions/password

With authentication via OIDC, passwords play no role in the CMS.