Authentifizierung, Benutzer und Gruppen

Dieser Bereich beantwortet zwei Verwaltungsfragen: wie Personen nachweisen, wer sie sind, und wie Opfield begrenzt, was sie ändern dürfen. Der Identitätsverantwortliche pflegt Anmeldung und Wiederherstellung; Ressourcenverantwortliche legen betriebliche Gruppen fest; Sicherheitsadministratoren prüfen privilegierten Zugriff. Erfolg bedeutet, dass Personen ihren Zugang wiederherstellen können, ohne Kontrollen zu umgehen, und dass eine Rollenänderung angewendet und auditiert werden kann, ohne jede Ressource umzuschreiben.

Opfield unterstützt unabhängige Authentifizierung über OIDC, lokales Passwort und Einmalcode per E-Mail. Passkeys werden nach der Kontoerstellung registriert. Eine MFA-Richtlinie kann die Registrierung verlangen, bevor ein Benutzer eine normale Sitzung erhält. Anmeldemethoden, Multi-Faktor-Authentifizierung, der OIDC-Anbieter und die Identitätsbereitstellung werden unter Settings > Authentication konfiguriert.

Verwenden Sie Gruppen als normale Berechtigungsgrenze. Halten Sie eine kleine, auditierbare Administratorgruppe und trennen Sie Operatoren, Entwickler, Beobachter und Automatisierung. Das Sperren oder Löschen eines Benutzers entzieht den Zugriff und bewahrt die historische Zuordnung. Das Wiederherstellen eines gelöschten Benutzers lässt das Konto gesperrt, bis es ausdrücklich aktiviert wird.

Impersonation ist ein administrativer Support-Ablauf und muss im Sitzungszweck und in den Audit-Einträgen unterscheidbar bleiben. Beenden Sie die Impersonation, um die ursprüngliche Administratorsitzung wiederherzustellen; stellen Sie aus einer Impersonationssitzung keine normalen API-Tokens aus.

Opfield bietet SCIM noch nicht an. SCIM-Unterstützung ist geplant; bis sie verfügbar ist, verwenden Sie die unterstützte Administrations-API mit eingeschränkter OAuth-Automatisierung, sofern Ihr Identitätssystem externe APIs aufrufen kann, oder pflegen Sie einen dokumentierten manuellen Prozess.

Gruppeneditor mit geerbten Berechtigungen und einzeln ausgewählten Scopes

Gestaltung der Authentifizierung

Aktivieren Sie mindestens zwei Wiederherstellungswege für Administratoren, bevor Sie sich von einem externen Identitätsanbieter abhängig machen. Testen Sie OIDC-Weiterleitung und Abmeldeverhalten, E-Mail-Zustellung, Wiederherstellung des lokalen Passworts, MFA-Registrierung und Wiederherstellungscodes mit Konten außerhalb der Produktion.

OIDC weist die Identität nach, gewährt aber nicht automatisch breiten Produktzugriff. Opfield-Berechtigungen bleiben ausdrücklich. Ist der externe Anbieter nicht verfügbar, können nur unabhängig konfigurierte Methoden den Zugriff wiederherstellen.

Ihren SSO-Anbieter verbinden (OIDC)

Opfield meldet Benutzer über einen OIDC-Anbieter pro Installation an, etwa Keycloak, Authentik, Microsoft Entra ID, Okta oder Google Workspace. Das Ändern des Anbieters erfordert settings:opfield:edit und admin:system; das Umschalten von Anmeldemethoden und der Identitätsbereitstellung erfordert settings:opfield:edit.

Prüfen Sie vor dem Start, dass Public URL unter Settings > General die Adresse ist, die Benutzer öffnen, zum Beispiel https://opfield.example.com. Die Redirect-URI wird daraus gebildet.

Opfield beim Identitätsanbieter registrieren. Erstellen Sie eine OpenID-Connect-Webanwendung (einen vertraulichen Client mit Authorization Code Flow). Registrieren Sie die Redirect-URI <Public URL>/auth/callback, zum Beispiel https://opfield.example.com/auth/callback. Schema, Hostname, Port und Pfad müssen genau übereinstimmen. Notieren Sie die Issuer-URL, die Client-ID und das Client-Secret.

Den Anbieter ausfüllen. Öffnen Sie Settings > Authentication > OIDC provider:

Feld	Was einzugeben ist
Display name	Der Name auf der Anmeldeschaltfläche: Sign in with dieser Name. Lassen Sie es leer, um Sign in with SSO anzuzeigen.
Issuer URL	Der Issuer des Anbieters, zum Beispiel `https://id.example.com/application/o/opfield/`. Opfield liest daraus das Discovery-Dokument, um die Autorisierungs-, Token- und Schlüsselendpunkte zu finden.
Client ID	Die Client-Kennung aus Schritt 1.
Client secret	Das Secret aus Schritt 1. Opfield speichert es verschlüsselt und zeigt später nur seine letzten vier Zeichen. Lassen Sie es beim Bearbeiten leer, um das gespeicherte Secret zu behalten.
Redirect URI	Derselbe Callback, den Sie in Schritt 1 registriert haben: `<Public URL>/auth/callback`.
Scopes	Durch Leerzeichen getrennt; `openid` ist erforderlich. Der Standard `openid email profile` gibt Opfield die E-Mail-Adresse und den Namen des Benutzers.

Drücken Sie Save.

Festlegen, wie Konten entstehen. Unter Settings > Authentication > Identity provisioning:
- Auto-create users on OIDC sign-in erstellt ein Opfield-Konto, wenn sich ein Benutzer zum ersten Mal über den Anbieter anmeldet. Schalten Sie es aus, wenn jeder Benutzer zuerst unter Administration > Users mit der Anmeldemethode OIDC erstellt werden muss; seine erste OIDC-Anmeldung mit derselben E-Mail-Adresse übernimmt dieses Konto.
- Require verified OIDC email akzeptiert die E-Mail-Adresse nur, wenn der Anbieter email_verified: true sendet.
- Default group for new OIDC users ist die Gruppe, die automatisch erstellte Benutzer erhalten.
OIDC einschalten. Schalten Sie unter Settings > Authentication > Sign-in methods OIDC ein. Opfield lehnt es mit OIDC_NOT_CONFIGURED ab, bis der Anbieter gespeichert ist.
Die Anmeldung testen. Lassen Sie Ihre aktuelle Sitzung geöffnet. Öffnen Sie Opfield in einem privaten Fenster, wählen Sie Sign in with mit Ihrem Anzeigenamen und melden Sie sich mit einem Testkonto an. Prüfen Sie, dass der Benutzer in der erwarteten Gruppe landet, und melden Sie sich dann einmal als Administrator über den Anbieter an.
Administratoren umstellen. Setzen Sie unter Administration > Users > Configure User die Sign-in method für jeden Administrator, der den Anbieter verwenden soll, auf OIDC. Eine Änderung der Methode meldet den Benutzer überall ab; das Konto wird bei der nächsten Anmeldung mit dem Anbieter verknüpft.
Andere Methoden bei Bedarf ausschalten. Schalten Sie Email and password oder Email sign-in code unter Sign-in methods erst aus, nachdem sich ein Administrator über den Anbieter angemeldet hat.

Was Opfield vom Anbieter liest

Claim	Verwendung
`sub`	Die Identität des Benutzers beim Anbieter. Zusammen mit dem Issuer verknüpft sie das Opfield-Konto. Erforderlich.
`email`	Wird mit einem vorab erstellten Benutzer abgeglichen und wird zur E-Mail-Adresse des Kontos. Bei der ersten Anmeldung erforderlich.
`email_verified`	Wird geprüft, wenn Require verified OIDC email aktiviert ist.
`name`	Der Name des Benutzers in Opfield. Namen von OIDC-Benutzern werden vom Anbieter verwaltet und können in Opfield nicht bearbeitet werden.
`picture`	Der Avatar des Benutzers.

Opfield ordnet keine Gruppen oder Rollen des Anbieters zu. Gruppen und Scopes werden in Opfield vergeben; neue Benutzer erhalten die Standardgruppe.

Ein Benutzer, der sich über einen Anbieter angemeldet hat, bleibt mit dessen Issuer verknüpft. Ändern Sie Issuer URL auf einen anderen Anbieter, können sich solche Benutzer nicht über den neuen anmelden (OIDC_ISSUER_MISMATCH). Um einen solchen Benutzer umzustellen, wechseln Sie seine Sign-in method unter Configure User auf eine andere Methode und zurück auf OIDC; er wird bei seiner nächsten Anmeldung erneut verknüpft.

Remove im Bereich OIDC provider löscht den Anbieter nach einer Bestätigung und schaltet die OIDC-Anmeldung aus.

API: PUT /api/admin/auth-settings mit oidc (issuer, clientId, clientSecret, redirectUri, scopes, displayName), methods oder oidcProviderAction: "remove"; MCP und Assistent: update_opfield_settings mit denselben Feldern.

Mit dem Opfield-Konto anmelden

Eine mit Opfield Cloud verbundene Installation kann Ihr Opfield-Konto als OIDC-Anbieter verwenden, statt ein eigenes SSO zu registrieren. Opfield fordert beim Konto einen Anmelde-Client an; Sie geben weder Issuer noch Client-ID noch Secret ein. Allow remote management ist nicht erforderlich.

Prüfen Sie, dass Public URL unter Settings > General gesetzt ist. Das Konto leitet Benutzer zurück an <Public URL>/auth/callback; ohne öffentliche URL wird die Anfrage mit PUBLIC_URL_REQUIRED abgelehnt.
Wählen Sie unter Settings > Authentication > OIDC provider die Option Use Opfield account. Der Bereich zeigt „Waiting for your Opfield account… Sign-in with it is set up as soon as it answers“ und eine Schaltfläche Cancel request. Ein erneutes Wählen der Schaltfläche sendet keine zweite Anfrage.
Antwortet das Konto, fügt Opfield den Anbieter „Opfield account“ hinzu und schaltet OIDC unter Sign-in methods ein. Die Installation hat einen OIDC-Anbieter, daher tritt das Opfield-Konto an die Stelle des bisherigen Anbieters. Der Bereich aktualisiert sich selbst.
Lassen Sie Personen sich damit anmelden. Benutzer werden wie bei jedem OIDC-Anbieter abgeglichen: Geben Sie einem bestehenden Benutzer unter Configure User die Sign-in method OIDC, und seine erste Anmeldung mit dem Opfield-Konto derselben E-Mail-Adresse übernimmt das Konto; neue Benutzer werden erstellt, wenn Auto-create users on OIDC sign-in aktiviert ist. Testen Sie es in einem privaten Fenster mit Sign in with Opfield account.

Cancel request zieht eine Anfrage zurück, die das Konto noch nicht beantwortet hat. Würde der Wechsel zum Opfield-Konto dazu führen, dass sich kein Administrator mehr anmelden kann, behält Opfield nur den erhaltenen Client und ändert nichts; geben Sie einem Administrator eine Methode, die aktiv bleibt, und wählen Sie dann erneut Use Opfield account. Sobald die Installation einen Client hat, stellt Use Opfield account den Anbieter sofort wieder her, zum Beispiel nachdem Sie ihn entfernt oder Ihr eigenes SSO ausprobiert haben.

Verliert jemand im Opfield-Konto den Zugriff auf die Installation, sperrt Opfield seinen Benutzer, und Administration > Users zeigt Blocked by the Opfield account. Seine nächste Anmeldung mit dem Opfield-Konto, nachdem das Konto den Zugriff wieder gewährt hat, hebt die Sperre auf; Unblock user funktioniert ebenfalls. Siehe Im Opfield-Konto entzogener Zugriff.

Das Opfield-Konto kann das Client-Secret über die Verbindung ersetzen, solange sich die Installation mit dem Anbieter „Opfield account“ anmeldet. Trennen Sie die Installation von Opfield Cloud oder trennt das Konto sie, vergisst Opfield den Client, entfernt den Anbieter „Opfield account“ und schaltet die OIDC-Anmeldung aus. Könnte sich dann kein Administrator mehr anmelden, bleibt der Anbieter bestehen, und der Bereich OIDC provider weist darauf hin: Geben Sie einem Administrator eine andere Anmeldemethode und wählen Sie dann Remove.

API: PUT /api/admin/auth-settings mit oidcProviderAction: "opfield_account" oder "cancel_opfield_account"; MCP und Assistent: update_opfield_settings mit demselben Feld. Die Einstellungen melden opfieldAccountSignIn mit available (mit Opfield Cloud verbunden), clientIssued, pendingRequest und detached. Ohne Verbindung wird die Aktion mit OPFIELD_ACCOUNT_CLIENT_MISSING abgelehnt.

Anmeldung mit Passwort und E-Mail-Code

Email and password und Email sign-in code unter Sign-in methods senden Links und Codes per E-Mail und benötigen daher ein geprüftes SMTP unter Settings > Advanced > SMTP configuration: Senden Sie dort zuerst einen Test. Ohne dieses wird das Einschalten einer der beiden Methoden mit SMTP_NOT_VERIFIED abgelehnt. Die eigene Methode eines Benutzers wird unter Administration > Users > Configure User > Sign-in method festgelegt; ein Wechsel zu Email and password sendet einen Link zum Einrichten des Passworts.

Der letzte Administrator behält einen Zugang

Opfield verweigert eine Änderung, nach der sich kein Systemadministrator mehr anmelden könnte. Es prüft dies, wenn Sie OIDC, Email and password oder Email sign-in code ausschalten, den OIDC-Anbieter entfernen oder einen Anbieter mit einem anderen Issuer speichern. Die Änderung wird mit LAST_ADMIN_SIGN_IN abgelehnt: „No administrator could sign in after this change.“ Ein Administrator zählt nur, wenn seine eigene Anmeldemethode aktiv bleibt, und bei OIDC nur, wenn er nicht mit einem anderen Issuer verknüpft ist. Passkeys zählen nicht. Geben Sie einem anderen Administrator oder sich selbst eine Methode, die aktiv bleibt, melden Sie sich damit an und nehmen Sie dann die Änderung vor.

Bei einer von Opfield Cloud verwalteten Installation beginnt der Anbieter als „Opfield account“ und folgt denselben Regeln; siehe Verwaltete Installationen.

Benutzer-Lebenszyklus

Erstellen oder laden Sie den Benutzer über einen freigegebenen Authentifizierungsweg ein.
Verlangen Sie MFA gemäß Richtlinie, bevor Sie sensible Scopes vergeben.
Fügen Sie den Benutzer rollenbasierten Gruppen hinzu, statt nach Möglichkeit einmalige Berechtigungen zuzuweisen.
Prüfen Sie, dass der Benutzer auf eine vorgesehene Ressource zugreifen kann und bei einer Ressource außerhalb seines Geltungsbereichs abgewiesen wird.
Prüfen Sie Sitzungen, Tokens und Gruppenmitgliedschaften, wenn sich die Rolle des Benutzers ändert.
Sperren Sie das Konto sofort, wenn der Zugriff enden muss.
Löschen Sie erst, nachdem Zuständigkeiten und Abhängigkeiten der Automatisierung übertragen wurden.

Das Sperren stoppt neue Nutzung, ohne die Zuordnung zu löschen. Die Löschung bleibt im Audit-Verlauf sichtbar. Das Wiederherstellen eines gelöschten Eintrags reaktiviert ihn nicht stillschweigend.

Einladungs-E-Mails

Eine Einladungs-E-Mail teilt einem neuen Benutzer mit, dass ein Administrator sein Opfield-Konto erstellt hat, und verlinkt auf die Anmeldeseite, mit einem Hinweis für seine Anmeldemethode: den Identitätsanbieter, einen E-Mail-Code oder die separate E-Mail, die sein Passwort festlegt. Der Versand erfordert ein geprüftes SMTP und die öffentliche URL von Opfield.

Send invitation email unter Administration > Users > Configure User im Bereich Account sendet sie manuell. Die Aktion wird einmal pro Benutzer angeboten und nur bis zu seiner ersten Anmeldung; nach dem Senden zeigt der Bereich, wann sie gesendet wurde. Sie erfordert admin:users für diesen Benutzer.
Settings > Authentication > Identity provisioning > Send an invitation email when an account is created sendet sie für jedes Konto, das in der Konsole, der API oder MCP erstellt wird. Die Einstellung ist standardmäßig aus und erfordert zum Ändern settings:opfield:edit. Schlägt der Versand fehl, wird das Konto dennoch erstellt, und die Einladung kann später manuell gesendet werden.

API: POST /api/admin/users/{id}/invitation; MCP und Assistent: manage_user mit der Operation send_invitation. Die Benutzerliste liefert für jeden Benutzer lastLoginAt und invitationSentAt.

Gestaltung von Gruppen

Trennen Sie Plattformadministration, Sicherheitsadministration, Anwendungsbetrieb, Entwicklung, reine Beobachtung und Automatisierung. Verwenden Sie ressourcenbezogene Berechtigungen für einen Ordner, eine Route, einen Node, einen Workload, eine Datenbank oder ein Pages-Projekt, statt einen ganzen Produktbereich freizugeben.

Der Gruppendialog und die zusätzlichen Berechtigungen eines Benutzers zeigen den Zugriff als Liste von Zeilen. Add Access fügt eine hinzu: eine Role, Where sie gilt (Everywhere, In a project folder, In an app environment oder Specific resources) und was sie umfasst (Covers), oder eine Zugriffsstufe auf Git-Repositories. Review N scopes öffnet die Scopes selbst; jede Abschnittsüberschrift zeigt dort, wohin die Scopes des Abschnitts reichen (Everywhere, ein Ort oder N places), und beschränkt sie auf Ordner, Apps oder Umgebungen. Siehe Tokens und OAuth-Freigaben einschränken.

Halten Sie die Administratorgruppe klein und pflegen Sie einen dokumentierten Notfallzugang (Break Glass). Testen Sie Berechtigungsänderungen mit einer echten Sitzung ohne Administratorrechte; eine Administratoransicht kann nicht nachweisen, dass Ablehnungsgrenzen funktionieren.

Impersonation und Support

Verwenden Sie Impersonation nur für eine begrenzte Support-Untersuchung. Die Sitzung muss sichtbar gekennzeichnet und auditierbar bleiben. Ändern Sie während der Impersonation eines anderen Benutzers keine Zugangsdaten, erstellen Sie keine dauerhaften Administrator-Tokens und erledigen Sie keine fremde Arbeit. Beenden Sie die Impersonation, bevor Sie zur normalen Administration zurückkehren.

Bereitstellung vor SCIM

Die SCIM-Bereitstellung ist noch nicht verfügbar, und ein Veröffentlichungstermin wird nicht garantiert. Bis sie veröffentlicht wird, führen Sie eine Checkliste für Eintritt, Wechsel und Austritt und gleichen Sie Benutzer und Gruppen manuell oder über unterstützte Automatisierung mit REST API und OAuth ab. Geben Sie dem Automatisierungs-Client nur die Benutzer- und Gruppen-Scopes, die er benötigt, machen Sie Anfragen idempotent und prüfen Sie nach jeder Zugriffsänderung eine erwartete Berechtigung und eine erwartete Ablehnung.

Wiederherstellung und Vermeidung von Aussperrung

Behandeln Sie die Identitätskonfiguration als Produktionsabhängigkeit. Erstellen und testen Sie vor der Änderung der einzigen funktionierenden Anmeldemethode einen zweiten Administratorzugang in einem separaten Browserprofil. Bewahren Sie Wiederherstellungscodes außerhalb von Opfield auf, prüfen Sie, dass E-Mails zur Wiederherstellung des lokalen Passworts das vorgesehene Postfach erreichen, und halten Sie fest, welches Team für die OIDC-Anwendung und ihr Client-Secret zuständig ist. Deaktivieren Sie die vorherige Methode erst, wenn sich eine neue Sitzung über den Ersatzweg anmelden, MFA abschließen und eine Seite nur für Administratoren erreichen kann.

Sind Administratoren ausgesperrt, stellen Sie die ausgefallene externe Abhängigkeit wieder her oder verwenden Sie die zuvor getestete unabhängige Methode. Vermeiden Sie es, Benutzer-, Sitzungs- oder Gruppenzeilen direkt in PostgreSQL zu bearbeiten: Das Umgehen der Anwendung kann den Zustand von Passwort, MFA, Sitzungen und Audit inkonsistent machen. Prüfen Sie nach der Rückkehr des Zugriffs jüngste Authentifizierungsereignisse, aktive Sitzungen, Gruppenmitgliedschaften und den Status der Wiederherstellungscodes, bevor Sie den Vorfall als abgeschlossen betrachten.

Prüfliste

Melden Sie sich mit einem Konto außerhalb der Produktion über jede aktivierte Methode an.
Bestätigen Sie, dass die MFA-Registrierung erzwungen wird, bevor eine normale privilegierte Sitzung ausgestellt wird.
Prüfen Sie, dass ein gesperrter Benutzer weder eine neue Sitzung erstellen noch ein bestehendes Token verwenden kann.
Prüfen Sie, dass ein wiederhergestellter Benutzer gesperrt bleibt, bis er ausdrücklich aktiviert wird.
Testen Sie für jede betriebliche Gruppe eine erlaubte und eine abgewiesene Ressourcenaktion.
Bestätigen Sie, dass die Impersonation sichtbar gekennzeichnet ist und der Audit-Akteur zuordenbar bleibt.
Gleichen Sie inaktive Benutzer, ungenutzte Gruppen, veraltete Sitzungen und offene Einladungen regelmäßig ab.

Die Authentifizierung weist nach, wer der Aufrufer ist; Gruppen und Scopes entscheiden, was dieser Aufrufer tun darf. Eine erfolgreiche OIDC-Anmeldung darf niemals als Beleg dafür verwendet werden, dass der Benutzer breite Befugnisse in Opfield erhalten sollte.