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, benutzerspezifische Autorisierung. Diese Berechtigung ist in RFC 6749 definiert.

Im Autorisierungscode-Fluss leitet der App Builder den Benutzeragenten (Browser) zum Autorisierungsserver weiter. Sobald der Benutzer erfolgreich angemeldet ist 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 veraltet.

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 für Datenquellen. 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-Tokengrant bietet eine benutzerspezifische Authentifizierung für Datenquellen. In diesem Ablauf werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstoken eingetauscht. Das OAuth 2.0 JWT-Träger-Tokengrant 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-kodierten 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. Ist 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 Bearer Assertion Die SAML 2.0 Bearer Assertion-Berechtigung erfordert ein X.509-Zertifikat mit privatem Schlüssel in einem passwortgeschützten PKCS#12 (.pfx) Container.
JWT Bearer Token Die JWT Bearer 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 ignorieren soll, wenn er Back-Channel-Anfragen an den Token-Endpunkt sendet. 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-Flow. 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 kaufmännischen 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 String-Interpolation. Ausdrücke können auf dynamische Parameter verweisen, z. B. username={{ client_id }}&password={{ client_secret }}. Dies ist nützlich, wenn man mit Drittanbieter-APIs integriert, 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 Trägerbehauptungs-Grant.

Parameter
SamlSingleSignOnProvider Name eines SAML-Sicherheitsanbieters für App Builder. Dieses Parameter gilt nur für den SAML 2.0 Trägerbehauptungs-Grant.

JWT Träger-Token

Die folgenden zusätzlichen Eigenschaften gelten für den JWT Träger-Token-Grant.

Parameter Standard
JwtClaimSet { "scope": "{{ scope }}" } Autorisierungsserver können benutzerdefinierte Ansprüche erfordern. Zum Beispiel erfordert 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 getrennt werden (erscheinen in einer eigenen Zeile).

Parameter Standard Beispiel
RequestHeaders X-Custom-Header: Value X-Another-Header: Value Benutzerdefinierte HTTP-Header, die an REST-Endpunktanfragen 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, wird App Builder automatisch versuchen, das Aktualisierungstoken zu verwenden, um ein neues Zugriffstoken nach Erhalt einer 401 Unauthorized-Antwort zu erwerben.

Autorisierungscode

Autorisierungsanfrage

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

  • redirect_uri: 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 unter 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 kleinschreibungssensible 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 Authentifizierung. Typischerweise geschieht dies 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 externe Authentifizierung verwendet werden. Beachten Sie jedoch, 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 die SAML 2.0 Trägerbehauptung eine 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 SamlSingleSignOnProvider-Parameter.