Privates Jitterbit-API Gateway

Einführung

Ein privates API Gateway, das in einem privaten Netzwerk gehostet wird, übernimmt diese Sicherheitsfunktionen und Aufgaben im Zusammenhang mit der Annahme und Verarbeitung von API-Manager API ruft auf:

Verkehrsmanagement.
Autorisierung und Zugriffskontrolle.
Ratenbegrenzung.
API Payload.

Sie können ein privates API Gateway unter Linux installieren und ausführen oder führen Sie einen als Linux-basierten Docker-Container aus.

Ein privates API Gateway ist ein lokales Gateway zur Verarbeitung von APIs direkt von Ihren eigenen Servern. API-Manager Sicherheitsfunktionen werden auf der API Ebene konfiguriert oder Sicherheitsprofilebene und werden im privaten API Gateway zwischengespeichert. Auf sie wird dann während der API Laufzeit wie unten beschrieben verwiesen.

Private API Gateway-Systemarchitektur

Die Verwendung eines privaten API Gateways bietet diese zusätzlichen Vorteile gegenüber dem Cloud API Gateway:

Internes Netzwerk: Das private API Gateway und seine Agenten können ausschließlich auf ein internes Netzwerk hinter einer Firewall beschränkt werden und sind nicht vom Internet aus zugänglich.

Notiz

Wenn sich Ihre private API Gateway-Installation hinter einer Firewall in Ihrem Netzwerk befindet, müssen Sie Zulassungsliste notwendige Jitterbit-Dienste.
Payloadsicherheit: API AntwortPayloaden passieren niemals die Systeme von Jitterbit.
Kontrolle: Sie haben Kontrolle über die Hardware- und Umfeld des privaten API Gateways und stellen sicher, dass es den Standards Ihres Unternehmens entspricht.
Domänenname: Die Basis API Endpoint URL kann so konfiguriert werden, dass sie eine Subdomäne eines von Ihnen kontrollierten Domänennamens ist, statt einer Subdomäne der Harmony-Region (jitterbit.cc, jitterbit.eu, oder jitterbit.net). Eine Alternative zur Verwendung eines privaten API Gateways zur Steuerung des Domänennamens besteht darin, ein Drittpartei wie Cloudflare oder einen DNS-Proxy zu verwenden, um einen benutzerdefinierten Domänennamen an die Basis URL Route.

Dieses Diagramm zeigt die Systemarchitektur einer benutzerdefinierten API, die vor Ort mit einem privaten Agenten und einem privaten API Gateway bereitgestellt wird:

Anhang

Ein API Verbraucher ruft die API auf, die sich im privaten API -Gateway befindet.
Das private API -Gateway verweist auf die zwischengespeicherten Sicherheitsprofile (sofern zutreffend) und API Metadaten, um Authentifizierungs- und Zugriffskontrollaufgaben auszuführen. Wenn der Zugriff auf die API verweigert wird, gibt das private API Gateway eine entsprechende HTTP-Antwort und einen entsprechenden Status an den API Verbraucher zurück. Wenn der Zugriff auf die API gewährt wird, wird die API Anforderung an den Messaging-Dienst weitergeleitet, der Anforderungen für Agentengruppen weiterleitet.
Der private Agent empfängt die Anfrage vom Nachrichtendienst.
Der private Agent verweist auf die API Operation, die während der benutzerdefinierten API -Konfiguration angegeben wurde und löst die ausgeführte Operation aus.
Der Operation antwortet mit einer API Payload, die mit dem Antworttyp übereinstimmt, die während der benutzerdefinierten API -Konfiguration ausgewählt wurde.
Die Payload der API -Antwort wird vom privaten Agenten zurück an das private API Gateway geleitet, das die API Payload extrahiert und die endgültige HTTP-Antwort und den Status festlegt. Die HTTP-Antwort und der Status werden an den API Verbraucher gesendet.

Notiz

Sofern der durch den API Aufruf ausgelöste Operation nicht Temporärer Speicher verwendet, verbleibt die API Payload maximal zwei Tage lang auf dem Agenten. Die API Payload verbleibt nicht länger als das API -Gateway-Timeout von 15 Sekunden auf dem privaten API Gateway.
Laufzeitstatusinformationen und Protokolle laufender Vorgänge werden an die Transaktionsprotokolldatenbank gesendet.

Notiz

Verbraucherdaten werden nicht in der Datenbank der Transaktionsprotokolle gespeichert, es sei denn, debuggen-Modus ist während der benutzerdefinierten API -Konfiguration aktiviert.