Anmeldung

Jeder Zugriff auf das CMS erfordert eine Anmeldung. Welches Verfahren aktiv ist, legt die Serverkonfiguration fest (httpAuth, siehe Betrieb):

httpAuth	Verfahren
./auth/basic	Basic-Anmeldung mit Konto und Kennwort (Voreinstellung)
./auth/oidc	OpenID Connect, zusätzlich Bearer-Token und weiterhin Basic

Unabhängig davon funktionieren immer Kurzzeit-Token und, falls konfiguriert, Header-SSO.

Ohne gültige Anmeldung antwortet das CMS mit 401 bzw. 403.

Basic

Konto und Kennwort werden im Authorization-Header übertragen (Basic Authentication). Das Konto muss in cms/users existieren.

curl -u 'CMS_User_01:<kennwort>' https://cms.example.org/schema

const res = await fetch('https://cms.example.org/schema', {
    headers: { Authorization: 'Basic ' + btoa('CMS_User_01:<kennwort>') },
})

Hat das Konto noch kein Kennwort, wird das bei dieser Anmeldung verwendete gespeichert (siehe Kennwörter). Im OIDC-Modus ist das nicht möglich: Dort funktioniert Basic nur für Konten, die bereits ein Kennwort haben.

Kurzzeit-Token

GET /token liefert für das angemeldete Konto ein Token als Text. Es ist 5 Minuten gültig und kann in dieser Zeit beliebig oft als URL-Parameter token verwendet werden. Damit lassen sich z. B. Mediendateien direkt in <img>- oder <video>-Elementen einbinden, die keinen Authorization-Header senden können.

const cms = 'https://cms.example.org'
const auth = { Authorization: 'Basic ' + btoa('CMS_User_01:<kennwort>') }

const token = await fetch(`${cms}/token`, { headers: auth }).then((res) => res.text())

// Datensatz mit fertigen Datei-URLs lesen (siehe Datenschnittstelle, ?exported)
const record = await fetch(`${cms}/data/tutorial/file/<id>?exported`, { headers: auth }).then((res) => res.json())

image.src = `${cms}${record.image.path}?token=${encodeURIComponent(token)}`

Tokens werden nur im Speicher des Servers gehalten und sind nach einem Neustart ungültig.

OIDC

Mit httpAuth: "./auth/oidc" meldet sich die Pflegeanwendung über einen OpenID-Connect-Provider an, z. B. Keycloak oder den Anmeldedienst von NeuroomNet. Anwendungen können stattdessen ein Bearer-Token des Providers senden (Authorization: Bearer …).

In beiden Fällen sucht das CMS das Konto anhand des Claims email in cms/users (Feld account). Bei Microsoft ADFS wird die E-Mail-Adresse notfalls aus dem Access Token gelesen.

• Existiert kein passendes Konto und ist oidc.autoCreate gesetzt, legt das CMS das Konto ohne Rechte an.
• Die Rechte kommen immer aus dem CMS (Konto und Rollen in cms/users), nicht vom Provider. Ein Konto, das sich über OIDC anmelden kann, sieht also nichts, solange ihm im CMS keine Rechte gegeben werden.

Konfiguration (oidc in der Serverkonfiguration):

Schlüssel	Bedeutung
issuer	URL des Providers
clientId, clientSecret	Zugangsdaten des CMS beim Provider
self	eigene, von außen erreichbare URL des CMS (für die Rückleitung)
oidcResponseType	Response Type, Voreinstellung id_token
oidcResource	optionale Ressource(n) für die Anfrage
autoCreate	Konten bei der ersten Anmeldung automatisch anlegen

Abmelden: /oidcLogout, danach Weiterleitung auf /bye.

Header-SSO

Für vorgeschaltete Anmeldesysteme (z. B. F5 BIG-IP) kann das CMS einem Header vertrauen, der die E-Mail-Adresse des Kontos enthält. Damit nicht jeder diesen Header setzen kann, muss ein zweiter Header ein gemeinsames Geheimnis enthalten.

Schlüssel in headerSSO	Bedeutung
emailField	Name des Headers mit der E-Mail-Adresse (= account)
secretField	Name des Headers mit dem Geheimnis
secret	erwarteter Wert des Geheimnisses

Header-SSO ist nur aktiv, wenn emailField und secretField gesetzt sind.

Weitere Endpunkte

Endpunkt	Ergebnis
GET /user	angemeldetes Konto: account, Anmeldeverfahren (auth), Rollen und Namen der Rechte-Sammlungen
GET /version	Version des CMS und der geladenen Erweiterungen (Text)
GET /logon?ret=<url>	Nach erfolgter Anmeldung Weiterleitung auf <url>, sofern diese URL als Datensatz in der API cms/apps (Feld url) eingetragen ist. So können Anwendungen eine Anmeldung im Browser anstoßen.