OAuth-Sicherheitsanbieter im Jitterbit App Builder

Einführung

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 RFC 6749.

• Client-Anmeldeinformationen RFC 6749.

• Anmeldeinformationen des Ressourcenbesitzers RFC 6749.

• SAML 2.0 Trägerbehauptung RFC 7522.

• JWT-Träger-Token RFC 7523.

Autorisierungscode

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

Im Autorisierungscode-Fluss leitet der App Builder den Benutzeragenten (Browser) an den 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 Anfrage über einen Back-Channel an den Autorisierungsserver, um den Autorisierungscode gegen ein Zugriffstoken einzutauschen. 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 credentials

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

Resource owner password credentials

Das OAuth 2.0 Resource Owner Password Credentials Grant ist in RFC 6749 definiert. Dieses Grant wurde jedoch inzwischen abgelehnt.

Ursprünglich konzipiert bietet das OAuth 2.0 Resource Owner Password Credentials Grant 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 Resource Owner Password Credentials Grant. 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 bearer assertion

Das OAuth 2.0 SAML 2.0 Bearer Assertion Grant bietet eine benutzerspezifische Authentifizierung für Datenquellen. In diesem Ablauf werden SAML-Assertions gegen OAuth-Zugriffstoken eingetauscht. Das OAuth 2.0 SAML 2.0 Bearer Assertion Grant ist in RFC 7522 definiert.

JWT bearer token

Das OAuth 2.0 JWT Bearer Token Grant bietet eine benutzerspezifische Authentifizierung für Datenquellen. In diesem Ablauf werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstoken eingetauscht. Das OAuth 2.0 JWT Bearer Token Grant ist in RFC 7523 definiert.

Configuration

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 das OAuth-Grant und die Authentifizierungsschemata.

• Authentifizierungstyp: OAuth

• OAuth Grant: Wählen Sie ein unterstütztes OAuth-Grant aus.

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

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

  • Client Secret JWT: Der Client wird mit einem JSON Web Token (JWT) authentifiziert, das mit dem Client-Geheimnis signiert ist (client_secret_jwt). (Siehe JWT-Client-Authentifizierungstypen.)

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

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

  • Private Key JWT: Der Client wird mit einem JSON Web Token (JWT) authentifiziert, das mit einem privaten Schlüssel signiert ist (private_key_jwt). (Siehe JWT-Client-Authentifizierungstypen.)

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

  • Bearer: Bearer-Authentifizierungsschema. Standard.

  • Form: Fügen Sie das Zugriffstoken zum formular-url-kodierten Körper hinzu.

  • Query: 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.

JWT-Client-Authentifizierungstypen

Die JWT-Client-Authentifizierungstypen unterstützen die folgenden Konfigurationsoptionen:

• Assertion:

  • Issuer: Kein Standard. Oft wird eine Anwendungskennung oder die Client-ID verwendet. Konsultieren Sie die Dokumentation des Autorisierungsservers.

  • Audience: Standardmäßig der Token-Endpunkt (wie im Endpoints-Panel definiert) gemäß dem Standard.

  • Subject: Standardmäßig die Client-ID (wie im Credentials-Panel angegeben) gemäß dem Standard.

• Credentials:

  • Type: Client

    Client-ID ist erforderlich. Client Secret wird ignoriert und kann weggelassen werden.

• Certificates:

  • Usage: Signing

    Ein Zertifikat wird nur vom Private Key JWT-Client-Authentifizierungstyp verwendet. Der Client Secret JWT verwendet das Client Secret als Schlüssel.

• Properties:

  • Parameter: JwtClaimSet

  • Parameter: SigningAlgorithm

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

• Issuer: Der Aussteller der SAML-Assertion.

• Audience: 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 verlangt der App Builder nicht, dass die Zielgruppe eine URI ist.

• Recipient: Die URI des Empfängers der SAML-Assertion (z. B. http://example.com/service).

JWT Bearer Token

• Issuer: JWT-Ausstelleranspruch (https://tools.ietf.org/html/rfc7523#section-3). Standardmäßig die Clientkennung (client_id).

• Subject: JWT-Subjektanspruch (https://tools.ietf.org/html/rfc7523#section-3).

  • Wenn der Token Owner User ist, standardmäßig die Identität des aktuellen Benutzers.

  • Wenn der Token Owner Client ist, ist das Subject erforderlich.

• Zielgruppe: JWT Zielanspruch (https://tools.ietf.org/html/rfc7523#section-3). Standardmäßig auf den Token-Endpunkt gesetzt.

Endpunkte

Anmeldeinformationen

Certificates

Properties

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

Autorisierungscode

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

SAML 2.0 Trägerbehauptung

Die folgenden zusätzlichen Eigenschaften gelten 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.

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).

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 zu erwerben, nachdem eine 401 Unauthorized-Antwort empfangen wurde.

Autorisierungscode

Autorisierungsanfrage

Beim Erstellen 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 ist der URL-kodierte, groß- und kleinschreibungssensible Name des Sicherheitsanbieters.

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

Reverse-Proxy

Seit App Builder 4.59 wird die OAuth-Umleitungs-URI weggelassen, wenn der Standardport verwendet wird. Dies gewährleistet die Kompatibilität mit OAuth-Anbietern, wenn App Builder hinter einem Reverse-Proxy gehostet wird.

Um dieses Problem mit App Builder 4.58 oder früher zu umgehen, konfigurieren Sie einen URL Rewrite Sicherheitsanbieter, um den expliziten Port aus der Umleitungs-URI zu entfernen:

1. Navigieren Sie zu IDE > Sicherheitsanbieter.
2. Erweitern Sie im Konfigurations-Panel das Mehr-Menü und klicken Sie auf Anbieter importieren.

3. Fügen Sie die folgende Konfiguration ein und ersetzen Sie example.com durch den Hostnamen des App Builders:

   {
     "name": "URL Rewrite",
     "type": "rewrite_url",
     "settings": {
       "MatchUrl": "https://example.com:443",
       "RewriteUrl": "https://example.com"
     }
   }
   

4. Klicken Sie auf die Schaltfläche Importieren, und klicken Sie dann auf Fortfahren, um zu bestätigen.

5. Kehren Sie zur Seite Sicherheitsanbieter zurück. Erweitern Sie im Konfigurations-Panel das Mehr-Menü und klicken Sie auf Anforderungs-Pipeline.
6. Suchen Sie den importierten URL Rewrite-Anbieter. Setzen Sie seine Priorität (zum Beispiel 10) und aktivieren Sie die Option Aktiv.

Um die Korrektur zu überprüfen, kehren Sie zur Seite Sicherheitsanbieter zurück, erweitern Sie das Mehr-Menü und klicken Sie auf Anforderung inspizieren. Der Port sollte leer sein und Standard sollte aktiviert sein.

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 Benutzerinfo-Endpunkt.

App Builder kann so konfiguriert werden, dass die User Info Endpoint abgefragt wird, um die Identität des Benutzers abzurufen. Dies ermöglicht die Verwendung eines OAuth-Sicherheitsanbieters für die externe Authentifizierung. 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.

Nachdem das Zugriffstoken erworben wurde, wird App Builder eine client-authentifizierte Anfrage an den User Info Endpoint stellen. App Builder wird den Antwortkörper als JSON analysieren und die obersten 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

Zusätzlich zur Angabe des User Info Endpoint muss der Entwickler den Anspruch, der den Benutzer identifiziert – in diesem Fall den user_name-Anspruch – dem Name Anspruchsnutzungstyp zuordnen.

SAML 2.0 Bearer Assertion

Bei Verwendung des SAML 2.0 Bearer Assertion-Flows können SAML-Assertions auf zwei Arten bezogen werden:

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

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

Jede Quelle erfordert zusätzliche Konfiguration.

SAML-Assertions nach Bedarf generieren

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

SAML-Assertions von einem IdP beziehen

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

Einschränkungen

• JWT-Client-Authentifizierungstypen können nicht mit dem JWT-Bearer-Token Grant verwendet werden. Beide verwenden ein JWT, aber jedes Token hat unterschiedliche Anforderungen. Der OAuth-Sicherheitsanbieter unterstützt die Konfiguration nur eines einzelnen JWT-Tokens.