Rechte und Konten

Das Administrator-Konto

Beim ersten Start legt das CMS automatisch die API cms/users an und darin ein administratives Konto. Name (z. B. admin) und Kennwort stehen in der Serverkonfiguration (webAdmin, webAdminPass, siehe Betrieb). Dieses Konto hat folgende Rechte:

• Vollzugriff auf alle Namensräume, also vor allem uneingeschränktes Anlegen, Ändern und Löschen sämtlicher APIs.
• Alle Datensätze aller APIs sind sichtbar, können aber nicht verändert oder gelöscht werden.
• Vollzugriff auf die API cms/users: Konten und deren Rechte können uneingeschränkt gepflegt werden. Nur auf die Kennwörter besteht kein Zugriff.

Rechte

Folgende Rechte können vergeben werden. Jedes Recht ist eine Liste von Mustern.

Recht	Wirkung
namespaceAdmin	Vollzugriff auf die APIs der angegebenen Namensräume: anzeigen, anlegen, verändern, entfernen. Ein Zugriff auf Datensätze ist damit nicht verbunden.
namespaceUser	APIs der angegebenen Namensräume anzeigen, ebenfalls ohne Rechte auf Datensätze. Mindestens dieses Recht braucht jeder, der auf APIs des Namensraums zugreift (siehe unten).
apiWrite	Vollzugriff auf die Datensätze der angegebenen APIs: anzeigen, anlegen, verändern, entfernen.
apiRead	Datensätze der angegebenen APIs anzeigen.

namespaceAdmin schließt namespaceUser ein, apiWrite schließt apiRead ein.

Für Datensätze gilt eine zusätzliche Regel: Das Konto, das einen Datensatz angelegt oder zuletzt verändert hat, darf ihn immer auch verändern oder löschen. Ein Leserecht ist damit nicht verbunden. Ähnliches gilt für APIs, hier aber nur für das Konto, das die API angelegt hat.

Muster

Muster	Bedeutung
tutorial	genau der Namensraum tutorial (bei namespace…)
tutorial/html	genau die API html im Namensraum tutorial (bei api…)
tutorial/*	alle APIs im Namensraum tutorial
*	alle Namensräume bzw. alle APIs in allen Namensräumen
^…	regulärer Ausdruck, siehe unten

Beginnt ein Muster mit ^, wird es als regulärer Ausdruck ausgewertet und gegen den Namensraum bzw. gegen namensraum/api geprüft:

Muster	Passt auf
^kunde-	alle Namensräume, die mit kunde- beginnen
^kunde-[^/]*/[^/]+$	alle APIs in allen Namensräumen, die mit kunde- beginnen
^kunde-[^/]*/config$	APIs mit dem Namen config in allen Namensräumen, die mit kunde- beginnen
^[^/]+/config$	APIs mit dem Namen config in allen Namensräumen

Wie Rechte zusammenwirken

• Rechte sind reine Erlaubnislisten. Verbote gibt es nicht. Ein Zugriff ist erlaubt, sobald irgendein Muster passt.
• Die wirksamen Rechte eines Kontos sind die Vereinigung der Rechte am Konto selbst und der Rechte aller seiner Rollen (siehe unten).
• Jeder Zugriff auf eine API braucht ein Recht auf den Namensraum. Wer Datensätze lesen oder schreiben will, braucht beides: namespaceUser oder namespaceAdmin für den Namensraum und apiRead oder apiWrite für die API. Ein Konto mit nur apiRead: ["ns/api"] erhält 403.
• Auflistungen (/schema/<ns>, /projects) zeigen eine API ebenfalls nur bei beiden Rechten. Ein Konto mit nur namespaceAdmin kann APIs anlegen und ändern, sieht sie in der Auflistung aber erst mit einem Leserecht auf die Datensätze (z. B. apiRead: ["ns/*"]).
• Mehrsprachige APIs: Die erlaubten Sprachen stehen in der API ns/languages (siehe Mehrsprachigkeit). Wer Datensätze mit lokalisierbaren Feldern abfragt oder schreibt, braucht auch Leserecht auf ns/languages. Mit ns/* ist das automatisch gegeben.
• /schema meldet nur Namensräume, in denen bereits mindestens eine API existiert. Bei namespaceAdmin: ["*"] lässt sich deshalb nicht aufzählen, welche Namensräume ein Konto anlegen dürfte, nur welche bereits existieren.

Typische Konfigurationen

Mandant mit eigenem Namensraum (das Konto aus dem Schnelleinstieg):

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

Redaktion, die Inhalte pflegt, aber keine APIs ändert:

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

Anwendung, die Inhalte nur liest:

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

Rollen

Rechte lassen sich auch über Rollen vergeben. Dafür gibt es zwei weitere vordefinierte APIs:

• cms/rights: benannte Rechte-Sammlungen mit name sowie den Listen namespaceAdmin, namespaceUser, apiWrite und apiRead.
• cms/roles: Rollen mit name und einer Liste rights, die Namen aus cms/rights enthält.

Ein Konto verweist in seinem Feld roles auf Rollen. Beispiel:

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

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

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

Die Namen der wirksamen Rechte-Sammlungen meldet /user im Feld rights. Erweiterungen (Plugins) können sie für eigene Berechtigungen auswerten.

Zum Pflegen von cms/roles und cms/rights braucht ein Konto apiWrite auf diese APIs. Das Administrator-Konto kann es über cms/users vergeben.

Kennwörter

• Ein neues Konto hat kein Kennwort. Bei der ersten Anmeldung per Basic wird das verwendete Kennwort gespeichert.
• Kennwörter sind nie lesbar, auch nicht für den Administrator. Sie werden mit argon2 gehasht gespeichert.
• Wer apiWrite auf cms/users hat (also der Administrator), kann ein Kennwort setzen oder zurücksetzen. In der Pflegeanwendung dient dazu die Schaltfläche Reset password. Über die Schnittstelle:

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

# Kennwort zurücksetzen: Das Konto legt bei der nächsten Anmeldung ein neues fest
curl -X POST -u 'admin:<kennwort>' -H 'Content-Type: application/json' \
  -d '{ "account": "CMS_User_01" }' \
  https://cms.example.org/data/cms/users/actions/password

Bei Anmeldung über OIDC spielen Kennwörter im CMS keine Rolle.