API Schlüsselsicherheitsanbieter im Jitterbit App Builder

Der API Key Security Provider ermöglicht Administratoren die Sicherung App Builder REST- APIs mit „API -Schlüsseln“. Ein API Schlüssel ist ein Code, der von App Builder Der Verbraucher übergibt den API Schlüssel an App Builder beim Stellen von REST API Anfragen. Da jeder API Schlüssel einem einzelnen Benutzer zugeordnet ist, dient dies sowohl zur Authentifizierung als auch zur Autorisierung.

API Schlüssel vs. Benutzername und Passwort

Ein API Schlüssel ist einem Benutzernamen und einem Passwort insofern ähnlich, als dass er ein zwischen Client und Server geteiltes Geheimnis ist. API Schlüssel haben mehrere Schwächen mit Benutzernamen- und Passwort-Authentifizierungsschemata wie der HTTP-Basisauthentifizierung gemeinsam:

• API Schlüssel können durchsickern.
• Die Verteilung von API Schlüsseln kann schwierig zu verwalten sein.

Allerdings haben API Schlüssel gegenüber Benutzernamen und Passwörtern Vorteile:

• API Schlüssel haben eine höhere Entropie als Benutzername/Passwort-Kombinationen.
• API Schlüssel können eine Kennwortzurücksetzung überstehen.
• API Schlüssel können einfach widerrufen werden.
• API Schlüssel können rotiert werden.
• API -Schlüssel sind schneller. Passwörter müssen gehasht werden, was bewusst langsam ist.

API Schlüssel verwendet

Trotz ihrer Schwächen können API Schlüssel für bestimmte Szenarien dennoch geeignet sein, darunter:

• Service-Level-Konten
• Kommunikation von Anwendung zu Anwendung Server-zu-Server-Kommunikation
• Nur Lesezugriff
• Nicht vertrauliche Informationen

API Schlüsselmaterial

App Builder Die API Schlüssel von bestehen aus einer 128-Bit-kryptografisch zufälligen Zahl. Die Schlüssel sind base64url-kodiert.

Nachfolgend sehen Sie ein Beispiel für einen API -Schlüssel:

DLOo9sPS5slJEMHpXBFt3g

Konfiguration

Parameter

Der API Schlüssel-Sicherheitsanbieter definiert die folgenden Parameter:

HTTP- Header vs. Abfrage

Normalerweise übergibt der Client den API Schlüssel über einen benutzerdefinierten Header. Der Header muss den Namen X- API-Key haben. Dadurch wird das Risiko einer Offenlegung begrenzt. Im Gegensatz zu Abfrage werden HTTP-Header beispielsweise selten auf der Festplatte protokolliert.

Das folgende Beispiel zeigt, wie der API Schlüssel als HTTP- Header übergeben wird:

GET /App Builder/rest/v1/sales/customers HTTP/1.1
Host: example.com:443
Accept: application/json
X-API-Key: DLOo9sPS5slJEMHpXBFt3g

Einige Clients haben möglicherweise keinen Zugriff auf die HTTP-Anforderungsheader. Wenn dies der Fall ist und keine andere Problemumgehung verfügbar ist, können Sicherheitsadministratoren die Option AllowApiKeyInQueryString aktivieren. Dadurch wird App Builder um den API Schlüssel als Abfrage zu akzeptieren. Der Abfrage muss den Namen „apiKey“ haben.

Das folgende Beispiel zeigt, wie der API Schlüssel als Abfrage übergeben wird:

GET /App Builder/rest/v1/sales/customers?apiKey=DLOo9sPS5slJEMHpXBFt3g HTTP/1.1
HOST: example.com:443
Accept: application/json

Beachten Sie, dass hier ein potenzieller Konflikt besteht. Bei der Abfrage der REST- API werden Abfrage normalerweise Ressourcenfeldnamen zugeordnet. Wenn API Schlüssel als Abfrage übergeben werden können, können Ressourcen kein Feld mit dem Namen „apiKey“ haben.

HTTPS im Vergleich zu HTTP

Um Man-In-The-Middle-Angriffe zu verhindern, müssen API Schlüssel über eine sichere HTTPS-Verbindung übertragen werden. App Builder erzwingt dies, indem über HTTP übergebene API Schlüssel ignoriert werden.

In manchen Umgebungen kann die HTTPS-Verbindung jedoch vor dem Webserver beendet werden. In diesem Szenario können Sicherheitsadministratoren die Option AllowUnsafeHttpConnections aktivieren, um App Builder um API Schlüssel zu akzeptieren, die über unsichere HTTP-Verbindungen gesendet werden.