Der API Server legt Daten auf fälschungssichere Weise verschlüsselt auf dem Client und in der Datenbank ab.
Das Zertifikat wird bei der Installation des API Servers auf dem IIS konfiguriert.
Weitere Informationen zur Konfiguration der Verschlüsselung finden Sie im One Identity Manager Konfigurationshandbuch für Webanwendungen.
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 von Entities)
-
Ermittlung der WHERE-Klausel mit internen und externen Filtern
-
Laden der Daten aus der Datenbank
-
Anreichern der Entities mit berechneten Spalten
-
Entities im delayed-logic-Modus können mit einer POST-Anfrage verändert oder mit einer DELETE-Anfrage gelöscht werden. Entities in diesem Modus sind zustandslos (stateless) und belegen auf dem Server nach der Abarbeitung einer Anfrage keine Ressourcen mehr.
Unterstützte HTTP-Methoden:
-
Interaktive Entities müssen einmalig mit einer PUT-Anfrage erzeugt werden, und erhalten danach eine eigene ID. Benutzen Sie bei nachfolgenden Anforderungen (POST oder DELETE) diese ID.
Unterstützte HTTP-Methoden:
-
PUT (erzeugen von interaktiven Entities)
-
POST (ändern von interaktiven Entities)
-
DELETE (löschen von interaktiven Entities)