In diesem Kapitel finden Sie Informationen zur Abarbeitung einer Anfrage an den API Server.
Authentifizierung
Bei einer Anfrage an den API Server wird geprüft, ob in der Sitzung für das jeweilige API-Projekt die primäre und gegebenenfalls sekundäre Anmeldung erfolgt ist (siehe Authentifizierung).
HINWEIS: Diese Prüfung erfolgt nicht, wenn die API-Methode der Anfrage als AllowUnauthenticated markiert ist.
Für die Zuordnung der aktuellen Sitzung wird der vom Client übermittelte Cookie imx-session-<Name des API-Projektes> ausgewertet.
Wenn ein Cookie übermittelt wird, der aber keiner im aktuellen Prozess aktiven Sitzung zugeordnet werden kann, wird mit dem im Cookie enthaltenen Sicherheitstoken eine neue Sitzung hergestellt (siehe Sitzungsstatus und Sicherheitstoken).
Liegt keine primäre Anmeldung vor, versucht der API Server über eines der aktivierten Single-Sign-On-Authentifizierungsmodule eine Datenbankverbindung herzustellen.
Kann die Anmeldung auch dann nicht hergestellt werden, wird die Bearbeitung der Anforderung abgebrochen und der HTTP-Fehlercode 500 wird an den Client übermittelt (siehe Antwortcodes).
Autorisierung des Methodenzugriffs
Der API Server prüft, ob der aktuell angemeldete Benutzer berechtigt ist, die Methode auszuführen. Verfügt der Benutzer nicht über die benötigten Berechtigungen, wird die Bearbeitung abgebrochen und der HTTP-Fehlercode 500 wird an den Client übermittelt (siehe Antwortcodes).
Validierung der Anfrage
Der API Server ruft die an der API-Methode hinterlegten Validatoren nacheinander auf. Wenn ein Fehler zurückgemeldet wird, wird die Bearbeitung abgebrochen und der HTTP-Fehlercode 400 wird an den Client übermittelt (siehe Antwortcodes).
Abarbeitung der Anfrage (für Entity-Methoden)
- GET (Laden einer Entity)
-
Ermittlung der WHERE-Klausel mit internen und externen Filtern
-
Laden der Daten aus der Datenbank
-
Anreichern einer Entity mit berechneten Spalten
-
Eine Entity im delayed-logic-Modus kann mit einer POST-Anfrage verändert oder mit einer DELETE-Anfrage gelöscht werden. Eine Entity in diesem Modus ist zustandslos (stateless) und belegt auf dem Server nach der Abarbeitung einer Anfrage keine Ressourcen mehr.
Unterstützte HTTP-Methoden:
-
Eine interaktive Entity muss einmalig mit einer PUT-Anfrage erzeugt werden, und erhält danach eine eigene ID. Benutzen Sie bei nachfolgenden Anforderungen (POST oder DELETE) diese ID.
Unterstützte HTTP-Methoden:
-
GET (Laden einer Entity)
-
PUT (Erzeugen einer interaktiven Entity)
-
POST (Ändern einer interaktiven Entity)
-
DELETE (Löschen einer interaktiven Entity)
Die Authentifizierung von Benutzern am API Server erfolgt pro API-Projekt.
Die Ausführung einer API-Methode erfordert die vorherige Authentifizierung an einem API-Projekt. Ist die API-Methode als AllowUnauthenticated markiert (Beispiele finden Sie im SDK), ist keine Authentifizierung nötig.
Die Authentifizierung erfolgt in zwei Schritten:
-
Erforderliche primäre Authentifizierung: Standard-Authentifizierung über ein Authentifizierungsmodul
-
Optionale sekundäre Authentifizierung: Multifaktor-Authentifizierung (über OneLogin)
Weitere Informationen zur Konfiguration der Authentifizierung finden Sie im One Identity Manager Konfigurationshandbuch für Webanwendungen.
Detaillierte Informationen zum Thema
Verwandte Themen
Sie können festlegen, wie sich Benutzer an Ihrer API authentifizieren. Sie konfigurieren die Authentifizierung am API-Projekt.
Um die Authentifizierung zu konfigurieren
-
Bearbeiten Sie Ihr API-Projekt.
-
Erstellen Sie die Klasse SessionAuthDbConfig und geben Sie dabei folgende Eigenschaften an:
-
Product: Legen Sie die Anwendung fest, deren Authentifizierungsmodule Sie verwenden möchten (beispielsweise WebDesigner oder Manager).
-
SsoAuthentifiers: Legen Sie die Single-Sign-on-Authentifizierungsmodule fest, die verwendet werden sollen.
-
ExcludedAuthentifiers: Legen Sie Authentifizierungsmodule fest, die nicht verwendet werden sollen.
Die primäre Authentifizierung am API-Projekt wird mithilfe der API-Methode imx/login/<Name des API-Projektes> ermöglicht.
Senden Sie dazu eine Anfrage mit der HTTP-Methode POST mit folgendem Inhalt:
{ "Module": "RoleBasedPerson", "User": "<Benutzername>", "Password": "<Passwort>" }
TIPP: Beispiele dazu finden Sie im SDK.
Sicherheitsmechanismen
Der API Server verwendet einen Sicherheitsmechanismus, um Cross-Site-Request-Forgery-Angriffe (CSRF) zu unterbinden. Dafür wird bei der Anmeldung ein zufällig generiertes Token in einem Cookie (XSRF-TOKEN) an den Client gesendet. Der Client muss danach in jeder Anfrage an den Server den Wert dieses Tokens in einem HTTP-Header (X-XSRF-TOKEN) übermitteln. Fehlt dieser Header, wird die Anfrage mit dem Fehlercode 400 beendet.
HINWEIS: Wenn eine API-Anfrage mit einem Fehler und Hinweis auf einen falschen CSRF-Schutz-Cookie abgebrochen wird, prüfen Sie, ob Ihr Browser die vom Browser gesendeten Cookies akzeptiert.
TIPP: Sie können den Namen und den Pfad des Cookies und den Namen des HTTP-Headers über das Administrationsportal anpassen. Verwenden Sie dazu die Konfigurationsschlüssel Name des Cookies, der das vom Server ausgestellte CSRF-Schutz-Token enthält (XsrfProtectionCookieName) und Pfad für den CSRF-Schutz-Cookie (XsrfProtectionCookiePath).
Sie können zudem den CSRF-Schutz im Administrationsportal deaktivieren (Konfigurationsschlüssel CSRF-Schutz-Token global deaktivieren (XsrfProtectionDisabled)). One Identity empfiehlt jedoch, dies nicht zu tun.
Wie Sie Konfigurationsschlüssel bearbeiten, erfahren Sie im One Identity Manager Konfigurationshandbuch für Webanwendungen.
