Zum Inhalt springen

OAuth-Sicherheitsanbieter im Jitterbit App Builder

Der OAuth-Sicherheitsanbieter ermöglicht die Unterstützung von OAuth 2.0. Der Sicherheitsanbieter ist verantwortlich für die Autorisierung von Webdienstanfragen. Die folgenden Datentypen unterstützen OAuth:

  • REST

  • OData

  • RDBMS (beschränkt auf unterstützte CData-Anbieter)

Darüber hinaus ist es möglich, einen OAuth-Sicherheitsanbieter als externen Authentifizierungsanbieter zu konfigurieren. Siehe unten für weitere Informationen.

OAuth 2.0 Berechtigungen

Der OAuth-Sicherheitsanbieter unterstützt die folgenden OAuth 2.0 Berechtigungen:

Autorisierungscode

Die OAuth 2.0 Autorisierungscode-Berechtigung bietet delegierte, benutzerebene Autorisierung. Diese Berechtigung ist in RFC 6749 definiert.

Im Autorisierungscode-Fluss leitet der App Builder den Benutzeragenten (Browser) an den Autorisierungsserver weiter. Sobald sich der Benutzer erfolgreich angemeldet hat und die Autorisierungsanfrage genehmigt hat, leitet der Autorisierungsserver den Benutzeragenten zurück zum App Builder. Die Weiterleitung enthält einen Autorisierungscode. Der App Builder sendet eine Back-Channel-Anfrage an den Autorisierungsserver und tauscht den Autorisierungscode gegen ein Zugriffstoken aus. Das Zugriffstoken kann dann verwendet werden, um Anfragen an Webdienste zu autorisieren.

An sich bietet OAuth Autorisierung, nicht Authentifizierung. Daher werden OAuth-Sicherheitsanbieter typischerweise nicht als externe Authentifizierungsanbieter verwendet: Sie werden verwendet, um Anfragen an einen kompatiblen Datenanbieter wie OData oder REST zu autorisieren. Wenn der OAuth-Sicherheitsanbieter jedoch einen Endpunkt veröffentlicht, der die Benutzeridentität bereitstellt, kann der OAuth-Sicherheitsanbieter als externer Authentifizierungsanbieter verwendet werden. Siehe den Benutzerinfo-Endpunkt für weitere Details.

Client-Anmeldeinformationen

Das OAuth 2.0 Client-Anmeldeinformationsgrant bietet eine clientseitige Authentifizierung, ähnlich einem Dienstkonto. In diesem Ablauf werden die OAuth-Client-Anmeldeinformationen gegen ein OAuth-Zugriffstoken eingetauscht. Das Client-Anmeldeinformationsgrant ist in RFC 6749 definiert.

Anmeldeinformationen des Ressourcenbesitzers

Das OAuth 2.0 Anmeldeinformationsgrant für Ressourcenbesitzer ist in RFC 6749 definiert. Dieses Grant wurde jedoch inzwischen abgelehnt.

Wichtig

Das Anmeldeinformationsgrant für Ressourcenbesitzer DARF NICHT verwendet werden.

Ursprünglich konzipiert bietet das OAuth 2.0 Anmeldeinformationsgrant für Ressourcenbesitzer eine benutzerspezifische Autorisierung. Der Benutzer gibt seinen Benutzernamen und sein Passwort an einen vertrauenswürdigen Client weiter. Der vertrauenswürdige Client tauscht die Anmeldeinformationen gegen ein Zugriffstoken aus.

App Builder bietet teilweise Unterstützung für das OAuth 2.0 Anmeldeinformationsgrant für Ressourcenbesitzer. App Builder fordert den Benutzer nicht zur Eingabe seiner Anmeldeinformationen auf. Stattdessen wird eine einzige Anmeldeinformation verwendet, um alle Benutzer zu autorisieren. Auf diese Weise ist das Grant funktional äquivalent zu einem Dienstkonto.

SAML 2.0 Trägerbehauptung

Das OAuth 2.0 SAML 2.0 Trägerbehauptungsgrant bietet eine benutzerspezifische Authentifizierung der Datenquelle. In diesem Ablauf werden SAML-Behauptungen gegen OAuth-Zugriffstoken eingetauscht. Das OAuth 2.0 SAML 2.0 Trägerbehauptungsgrant ist in RFC 7522 definiert.

JWT-Träger-Token

Das OAuth 2.0 JWT-Träger-Token-Grant bietet eine benutzerspezifische Authentifizierung der Datenquelle. In diesem Ablauf werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstoken eingetauscht. Das OAuth 2.0 JWT-Träger-Token-Grant ist in RFC 7523 definiert.

Konfiguration

Die Konfiguration variiert je nach OAuth-Grant. Mindestens erfordert OAuth:

  • Client-Identifikator (client_id) und Client-Geheimnis (client secret).

  • Token-Endpunkt.

Individuelle OAuth-Berechtigungen erfordern zusätzliche Konfigurationen, wie unten angegeben.

Authentifizierung

Die Authentifizierungseigenschaften bestimmen die OAuth-Berechtigung und die Authentifizierungsschemata.

  • Authentifizierungstyp: OAuth

  • OAuth-Berechtigung: Wählen Sie eine unterstützte OAuth-Berechtigung aus.

  • OAuth-Client-Authentifizierung: Bestimmt das Authentifizierungsschema für OAuth 2.0-Clients RFC 6749 Abschnitt 2.3. Optionen sind:

    • Keine: Gibt an, dass der Client nicht authentifiziert werden soll. (none.)

    • Basic: Gibt an, dass das Client-Passwortschema verwendet wird. Die Anmeldeinformationen werden über die HTTP Basic-Authentifizierung bereitgestellt. (client_secret_basic.)

    • Post: Gibt an, dass das Client-Passwortschema verwendet wird. Die Anmeldeinformationen werden als Formularparameter im Anfragekörper bereitgestellt. (client_secret_post.)

  • OAuth-Ressourcen-Authentifizierung: Bestimmt das Authentifizierungsschema für die Ressourcenanforderung. Optionen sind:

    • Bearer: Bearer-Authentifizierungsschema. Standard.

    • Formular: Fügen Sie das Zugriffstoken zum URL-codierten Formularinhalt hinzu.

    • Abfrage: Fügen Sie das Zugriffstoken zur Abfragezeichenfolge hinzu.

  • Tokenbesitzer: Bestimmt, ob Tokens an einzelne Benutzer oder an das Client-System ausgegeben werden. Optionen sind:

    • Benutzer: Tokens werden an einzelne Benutzer ausgegeben.

    • Client: Tokens werden an das Client-System ausgegeben.

  • Token beim Abmelden löschen: Wenn aktiviert, löscht der App Builder das gespeicherte Token, wenn der Benutzer sich abmeldet. Standard: Deaktiviert.

Token

Die folgenden Berechtigungen generieren Tokens, die gegen OAuth-Zugriffstokens eingetauscht werden:

  • SAML 2.0 Bearer Assertion.

  • JWT Bearer Token.

SAML 2.0 Bearer Assertion

  • Aussteller: Der Aussteller der SAML-Assertion.

  • Zielgruppe: Die Einschränkung der Zielgruppe der SAML-Assertion. Obwohl die SAML-Spezifikation angibt, dass die Zielgruppe eine URI ist, beachten viele Implementierungen dies nicht. Folglich erfordert der App Builder nicht, dass die Zielgruppe eine URI ist.

  • Empfänger: Die SAML-Assertion Empfänger-URI (z. B. http://example.com/service).

JWT-Bearer-Token

Endpunkte

Typ Berechtigungen Beschreibung
Authorization Endpoint Autorisierungscode OAuth 2.0 Autorisierungsendpunkt-URL. RFC 6749
Token Endpoint Alle OAuth 2.0 Token-Endpunkt-URL. RFC 6749
User Info Endpoint Autorisierungscode Endpunkt, der die Benutzeridentität bereitstellt. Erforderlich, wenn OAuth als externen Authentifizierungsanbieter behandelt wird. Kein Teil des OAuth-Standards. Der Endpunkt muss eine JSON-Antwort zurückgeben, die die Benutzeridentität enthält.

Anmeldeinformationen

Typ Berechtigungen Beschreibung
Client Alle OAuth 2.0 Client-Identifikator (client_id) und Geheimnis (client_secret). RFC 6749
Resource Owner Anmeldeinformationen des Ressourcenbesitzers OAuth 2.0 Benutzername des Ressourcenbesitzers (username) und Passwort (password). RFC 6749

Zertifikate

Typ Berechtigungen Beschreibung
Signing SAML 2.0 Träger-Assertion Die SAML 2.0 Träger-Assertion-Berechtigung erfordert ein X.509-Zertifikat mit privatem Schlüssel in einem passwortgeschützten PKCS#12 (.pfx) Container.
JWT Träger-Token Die JWT Träger-Token-Berechtigung erfordert einen PEM-kodierten, PKCS#1 RSA privaten Schlüssel (RSA PRIVATE KEY).

Eigenschaften

Der OAuth-Sicherheitsanbieter unterstützt die folgenden zusätzlichen Parameter:

Parameter Standard
BearerSchemeIdentifier Bearer Authorization-Schema bei Verwendung der Bearer-Ressourcenauthentifizierung.
ExpiresIn Ablaufzeit des Zugriffstokens in Sekunden. Kann verwendet werden, wenn der Token-Endpunkt keine Ablaufzeit angibt und der Ressourcenserver keine 401 Unauthorized-Antwort zurückgibt, wenn das Zugriffstoken abgelaufen ist.
IgnoreTlsErrors False Gibt an, ob der App Builder TLS-Fehler beim Senden von Back-Channel-Anfragen an den Token-Endpunkt ignorieren soll. Dies sollte nur für Entwicklung und Tests verwendet werden.
Scopes Durch Leerzeichen getrennte Liste von OAuth 2.0 Zugriffstoken-Berechtigungen. RFC 6749
SingleUseAccessToken False Gibt an, ob das Zugriffstoken nur einmal verwendet werden kann.
Token Endpoint Parameters Parameter, die an den OAuth-Token-Endpunkt übergeben werden. Standardmäßig generiert der App Builder die entsprechenden Parameter basierend auf dem OAuth-Fluss. Verwenden Sie diese Einstellung nur für nicht konforme oder anderweitig nicht unterstützte OAuth-APIs. Die Parameter sollten im form URL-encoded Format (application/x-www-form-urlencoded) angegeben werden. Wenn die Parameterliste mit einem Kaufmanns-Und-Zeichen (&) beginnt, werden die Parameter in die generierten Parameter zusammengeführt. Wenn ein Parameter denselben Namen wie ein generierter Parameter hat, wird der generierte Parameter überschrieben. Wenn ein übergebener Parameter keinen Wert hat, z. B. &grant_type&username=user&password=password, wird der generierte Parameter entfernt. Andernfalls wird der übergebene Parameter zu den generierten Parametern hinzugefügt. Die Parameterliste unterstützt die Zeichenfolgeninterpolation. Ausdrücke können auf dynamische Parameter verweisen, z. B. username={{ client_id }}&password={{ client_secret }}. Dies ist nützlich, wenn Sie mit Drittanbieter-APIs integrieren, die keine standardmäßigen Parameternamen verwenden.
RefreshRequiresScopes False Gibt an, ob die Berechtigungen (scope) im Anfragekörper, der an den Token-Endpunkt gesendet wird, enthalten sein sollten, wenn das Zugriffstoken aktualisiert wird.

Autorisierungscode

Die folgenden zusätzlichen Eigenschaften gelten für den Autorisierungscode-Grant.

Parameter Standard
BackchannelAuthorization False Gibt an, ob ein Autorisierungscode über eine Backchannel-Anfrage (Server-zu-Server) erworben werden kann. Dies ist eine nicht standardisierte Erweiterung des Autorisierungscode-Grants.

SAML 2.0 Trägerbehauptung

Die folgenden zusätzlichen Eigenschaften gelten für den SAML 2.0 Bearer Assertion Grant.

Parameter
SamlSingleSignOnProvider Name eines SAML-Sicherheitsanbieters für App Builder. Dieses Parameter gilt nur für den SAML 2.0 Bearer Assertion Grant.

JWT Träger-Token

Die folgenden zusätzlichen Eigenschaften gelten für den JWT Bearer Token Grant.

Parameter Standard
JwtClaimSet { "scope": "{{ scope }}" } Autorisierungsserver können benutzerdefinierte Ansprüche erfordern. Zum Beispiel verlangt Google einen scope-Anspruch, der mit dem OAuth-scope-Parameter übereinstimmt. Das JwtClaimSet-Parameter ermöglicht es Administratoren, zusätzliche Ansprüche bereitzustellen. Der Wert hat die Form einer JSON-Vorlage. Die folgenden Werte können in die Vorlage eingesetzt werden:
  • client_id - OAuth
  • client_id-Parameter.
  • client_secret - OAuth client_secret-Parameter.
  • scope - OAuth scope-Parameter.
  • sub - JWT sub-Anspruch.
  • iss - JWT iss-Anspruch.
  • aud - JWT aud-Anspruch.
SigningAlgorithm RS256 JWT-Algorithmusparameter wie in RFC 7518 definiert. Der einzige unterstützte Algorithmus ist RS256.

Rest

Die folgenden zusätzlichen Eigenschaften gelten, wenn der OAuth-Sicherheitsanbieter zur Authentifizierung von REST-Datenquellen verwendet wird. Diese werden für OAuth-Endpunkte und andere Arten von Datenquellen, einschließlich OData und RDBMS, ignoriert.
Anforderungsheader müssen durch einen Zeilenumbruch (in einer eigenen Zeile) getrennt werden.

Parameter Standard Beispiel
RequestHeaders X-Custom-Header: Value X-Another-Header: Value Benutzerdefinierte HTTP-Header, die an REST-Endpunktanforderungen angehängt werden. Die Header müssen gemäß RFC 7230 formatiert sein. Zeilenfaltung wird nicht unterstützt.

Protokollunterstützung

Aktualisierungstoken

Wenn die Anforderung für das Zugriffstoken ein Aktualisierungstoken enthält, versucht der App Builder automatisch, das Aktualisierungstoken zu verwenden, um ein neues Zugriffstoken zu erhalten, nachdem eine 401 Unauthorized-Antwort empfangen wurde.

Autorisierungscode

Autorisierungsanforderung

Beim Erstellen einer Autorisierungsanforderung wird der App Builder die Client-ID (client_id), das Client-Geheimnis (client_secret) und die Scopes (scope) einfügen. Darüber hinaus wird der App Builder automatisch die folgenden Standardparameter anhängen:

  • redirect_uri: Der App Builder konstruiert den Parameter redirect_uri aus der aktuellen URL. Er hat die Form https://example.com/Vinyl/signin-OAuth, wobei OAuth der Name des OAuth-Sicherheitsanbieters ist.

  • state: Der Statusparameter ist eine verschlüsselte, opake Nutzlast. Er enthält ein Cross-Site Request Forgery (CSRF)-Token gemäß RFC 6749.

Weiterleitungsendpunkt

Wie in RFC 6749 definiert, stellt der Authorization Code Grant einen Weiterleitungsendpunkt zur Verfügung. Dieser Endpunkt hört auf Autorisierungsantworten an der Adresse:

  • https://example.com/Vinyl/signin-OAuth

Dabei ist https://example.com/Vinyl die absolute URL zum Stammverzeichnis der App Builder-Anwendung und OAuth der URL-kodierte, groß- und kleinschreibungssensitive Name des Sicherheitsanbieters.

Die meisten Drittanbieteranwendungen müssen vor der Autorisierung von Anfragen mit dem Weiterleitungsendpunkt konfiguriert werden.

Verwendung von OAuth für externe Authentifizierung

Wie oben erwähnt, ist OAuth ein Autorisierungsprotokoll, kein Authentifizierungsprotokoll. Einige Implementierungen von Anbietern erweitern jedoch das OAuth-Protokoll um die Authentifizierung. Dies geschieht typischerweise durch die Veröffentlichung eines Endpunkts, der den Benutzer identifiziert. App Builder bezeichnet einen solchen Endpunkt als User Info Endpoint.

App Builder kann so konfiguriert werden, dass er den User Info Endpoint abfragt, um die Identität des Benutzers abzurufen. Dadurch kann ein OAuth-Sicherheitsanbieter für die externe Authentifizierung verwendet werden. Es ist jedoch zu beachten, dass der Endpunkt die folgenden Anforderungen erfüllen muss:

  • Der Endpunkt muss von App Builder erreichbar sein.

  • Der Endpunkt muss auf eine HTTP GET-Anfrage antworten, die keinen Anfragekörper enthält.

  • Der Endpunkt muss die OAuth Basic Client-Authentifizierung (wie oben beschrieben) unterstützen.

  • Die HTTP-Antwort muss einen Statuscode von 200 haben.

  • Die HTTP-Antwort muss einen Körper mit einem Content-Type von application/json enthalten.

  • Das JSON-Dokument muss eine oberste Eigenschaft enthalten, die den Benutzer identifiziert.

Nach dem Erwerb des Zugriffstokens wird App Builder eine client-authentifizierte Anfrage an den User Info Endpoint stellen. App Builder wird den Antwortkörper als JSON analysieren und oberste Eigenschaften als Ansprüche behandeln.

Zum Beispiel, gegeben die folgende Beispielantwort:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "user_name": "arthur.dent",
    "name": "Arthur Dent",
    "email": "arthurdent@example.com"
}

Die folgenden Anspruchstypen werden verfügbar sein:

  • user_name

  • name

  • email

Neben der Angabe des User Info Endpoint muss der Entwickler den Anspruch, der den Benutzer identifiziert – in diesem Fall den user_name-Anspruch – dem Name-Anspruchsverwendungstyp zuordnen.

SAML 2.0 Trägerbehauptung

Beim Einsatz des SAML 2.0 Trägerbehauptungsflusses können SAML-Behauptungen auf eine von zwei Arten bezogen werden:

  1. Der App Builder generiert und signiert die SAML-Behauptungen nach Bedarf. In diesem Fall fungiert der App Builder als IdP.

  2. (Veraltet) Ein Drittanbieter-Identitätsanbieter (IdP) gibt während des SAML Single Sign-On (SSO)-Prozesses eine SAML-Behauptung aus. Weitere Informationen finden Sie im SAML-Anbietertyp.

Jede Quelle erfordert zusätzliche Konfiguration.

SAML-Behauptungen nach Bedarf generieren

Um eine SAML-Behauptung nach Bedarf zu generieren, konfigurieren Sie die Token-Eigenschaften wie oben beschrieben. Darüber hinaus erfordert das SAML 2.0 Trägerbehauptungsgrant ein Signing-Zertifikat mit einem privaten Schlüssel.

SAML-Behauptungen von einem IdP beziehen

Um SAML-Behauptungen von einem Drittanbieter-IdP zu beziehen, setzen Sie den Parameter SamlSingleSignOnProvider.