OAuth-Sicherheitsanbieter in Jitterbit App Builder

Einführung

Der OAuth-Sicherheitsanbieter ermöglicht Unterstützung für OAuth 2.0. Der Sicherheitsanbieter ist für die Autorisierung von Web-Service-Anfragen zuständig. Die folgenden Datenquellentypen unterstützen OAuth:

• REST

• OData

• RDBMS (begrenzt auf unterstützte CData-Anbieter)

Darüber hinaus ist es möglich, einen OAuth-Sicherheitsanbieter als externen Authentifizierungsanbieter zu konfigurieren. Weitere Informationen finden Sie unten.

OAuth 2.0-Gültigkeitsbereiche

Der OAuth-Sicherheitsanbieter unterstützt die folgenden OAuth 2.0-Gültigkeitsbereiche:

• Authorization Code RFC 6749.

• Client Credentials RFC 6749.

• Resource Owner Password Credentials RFC 6749.

• SAML 2.0 Bearer Assertion RFC 7522.

• JWT Bearer Token RFC 7523.

Authorization Code

Der OAuth 2.0 Authorization Code-Gültigkeitsbereich bietet delegierte Autorisierung auf Benutzerebene. Dieser Gültigkeitsbereich ist in RFC 6749 definiert.

Im Authorization Code-Flow leitet App Builder den User-Agent (Browser) zum Autorisierungsserver weiter. Nachdem sich der Benutzer erfolgreich angemeldet und die Autorisierungsanfrage genehmigt hat, leitet der Autorisierungsserver den User-Agent zurück zu App Builder weiter. Die Weiterleitung enthält einen Autorisierungscode. App Builder stellt eine Back-Channel-Anfrage an den Autorisierungsserver und tauscht den Autorisierungscode gegen ein Zugriffstoken aus. Das Zugriffstoken kann dann zur Autorisierung von Anfragen an Web-Services verwendet werden.

OAuth bietet an sich nur Autorisierung, nicht Authentifizierung. Daher werden OAuth-Sicherheitsanbieter typischerweise nicht als externe Authentifizierungsanbieter verwendet: Sie autorisieren Anfragen an einen kompatiblen Datenanbieter wie OData oder REST. Wenn der OAuth-Sicherheitsanbieter jedoch einen Endpunkt bereitstellt, der die Benutzeridentität angibt, kann der OAuth-Sicherheitsanbieter als externer Authentifizierungsanbieter verwendet werden. Weitere Details finden Sie unter User Info Endpoint.

Client Credentials

Der OAuth 2.0 Client Credentials-Gültigkeitsbereich bietet Authentifizierung auf Clientebene, ähnlich wie ein Dienstkonto. In diesem Flow werden die OAuth-Client-Anmeldedaten gegen ein OAuth-Zugriffstoken ausgetauscht. Der Client Credentials-Gültigkeitsbereich ist in RFC 6749 definiert.

Resource Owner Password Credentials

Der OAuth 2.0 Resource Owner Password Credentials-Gültigkeitsbereich ist in RFC 6749 definiert. Der Gültigkeitsbereich wurde jedoch inzwischen veraltet.

Wie ursprünglich konzipiert, bietet der OAuth 2.0 Resource Owner Password Credentials-Gültigkeitsbereich Autorisierung auf Benutzerebene. Der Benutzer stellt seinen Benutzernamen und sein Passwort einem vertrauenswürdigen Client zur Verfügung. Der vertrauenswürdige Client tauscht die Anmeldedaten gegen ein Zugriffstoken aus.

App Builder bietet teilweise Unterstützung für den OAuth 2.0 Resource Owner Password Credentials-Gültigkeitsbereich. App Builder fordert den Benutzer nicht zu seinen Anmeldedaten auf. Stattdessen wird ein einzelnes Anmeldedatensatz zur Autorisierung aller Benutzer verwendet. Auf diese Weise ist der Gültigkeitsbereich funktionell äquivalent zu einem Dienstkonto.

SAML 2.0 Bearer Assertion

Der OAuth 2.0 SAML 2.0 Bearer Assertion-Gültigkeitsbereich bietet Authentifizierung auf Benutzer- und Datenquellenebene. In diesem Flow werden SAML-Assertionen gegen OAuth-Zugriffstokens ausgetauscht. Der OAuth 2.0 SAML 2.0 Bearer Assertion-Gültigkeitsbereich ist in RFC 7522 definiert.

JWT Bearer Token

Der OAuth 2.0 JWT Bearer Token-Gültigkeitsbereich bietet Authentifizierung auf Benutzer- und Datenquellenebene. In diesem Flow werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstokens ausgetauscht. Der OAuth 2.0 JWT Bearer Token-Gültigkeitsbereich ist in RFC 7523 definiert.

Konfiguration

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

• Client-Identifizierung (client_id) und Client-Secret (client secret).

• Token-Endpunkt.

Einzelne OAuth-Grants erfordern zusätzliche Konfigurationen wie nachstehend angegeben.

Authentifizierung

Die Authentifizierungseigenschaften bestimmen den OAuth-Grant und die Authentifizierungsschemas.

• Authentifizierungstyp: OAuth

• OAuth-Grant: Wählen Sie einen unterstützten OAuth-Grant aus.

• OAuth-Client-Authentifizierung: Bestimmt das OAuth 2.0-Client-Authentifizierungsschema RFC 6749 Section 2.3. Optionen umfassen:

  • Basic: Zeigt an, dass das Client-Password-Schema verwendet wird. Die Anmeldedaten werden mithilfe der HTTP-Basic-Authentifizierung bereitgestellt. (client_secret_basic.)

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

  • None: Zeigt an, dass der Client nicht authentifiziert werden sollte. (none.)

  • Post: Zeigt an, dass das Client-Password-Schema verwendet wird. Die Anmeldedaten werden als Formularparameter im Request-Body bereitgestellt. (client_secret_post.)

  • Private Key JWT: Der Client wird mithilfe eines 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 Ressourcenanfragen. Optionen umfassen:

  • Bearer: Bearer-Authentifizierungsschema. Standard.

  • Form: Access-Token an den formularkodierten Body anhängen.

  • Query: Access-Token an die Abfragezeichenfolge anhängen.

• Token-Inhaber: Bestimmt, ob Token an einzelne Benutzer oder an das Client-System ausgestellt werden. Optionen umfassen:

  • User: Token werden an einzelne Benutzer ausgestellt.

  • Client: Token werden an das Client-System ausgestellt.

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

JWT-Client-Authentifizierungstypen

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

• Assertion:

  • Issuer: Keine Vorgabe. Verwendet häufig einen Anwendungsidentifizieren oder die Client-ID. Konsultieren Sie die Dokumentation des Autorisierungsservers.

  • Audience: Wird standardmäßig auf den Token-Endpunkt gesetzt (wie im Panel Endpoints definiert) gemäß dem Standard.

  • Subject: Wird standardmäßig auf die Client-ID gesetzt (wie im Panel Credentials 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 Client-Authentifizierungstyp Private Key JWT verwendet. Client Secret JWT verwendet das Client-Secret als Schlüssel.

• Properties:

  • Parameter: JwtClaimSet

  • Parameter: SigningAlgorithm

Token

Die folgenden Grants generieren Token, die gegen OAuth-Zugriffstoken ausgetauscht werden:

• SAML 2.0 Bearer Assertion.

• JWT Bearer Token.

SAML 2.0 Bearer Assertion

• Issuer: Der SAML-Assertion-Aussteller.

• Audience: Die SAML-Assertion-Zielgruppenbeschränkung. Obwohl die SAML-Spezifikation angibt, dass die Audience ein URI ist, beachten viele Implementierungen dies nicht. Daher setzt App Builder nicht voraus, dass die Audience ein URI ist.

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

JWT Bearer Token

• Issuer: JWT-Issuer-Claim (https://tools.ietf.org/html/rfc7523#section-3). Wird standardmäßig auf die Client-Identifizierung gesetzt (client_id).

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

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

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

• Audience: JWT Audience Claim (https://tools.ietf.org/html/rfc7523#section-3). Standardmäßig der Token Endpoint.

Endpoints

Credentials

Certificates

Properties

Der OAuth Security Provider unterstützt die folgenden zusätzlichen Parameter:

Autorisierungscode

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

SAML 2.0 Bearer Assertion

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

JWT Bearer Token

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

Rest

Die folgenden zusätzlichen Eigenschaften gelten bei Verwendung des OAuth-Sicherheitsanbieters zur Authentifizierung von REST-Datenquellen. Diese werden für OAuth-Endpunkte und andere Arten von Datenquellen ignoriert, einschließlich OData und RDBMS.
Request Headers müssen durch einen Zeilenumbruch getrennt werden (jeweils auf einer eigenen Zeile).

Protokollunterstützung

Refresh-Tokens

Wenn die Zugriffstokenanfrage ein Refresh-Token enthält, versucht App Builder automatisch, das Refresh-Token zu verwenden, um ein neues Zugrifftoken nach Erhalt einer 401 Unauthorized-Antwort zu erwerben.

Autorisierungscode

Autorisierungsanfrage

Bei der Erstellung einer Autorisierungsanfrage bezieht App Builder die Client-ID (client_id), das Client-Geheimnis (client_secret) und die Scopes (scope) ein. Darüber hinaus fügt App Builder automatisch die folgenden Standard-Parameter an:

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

• state: Der State-Parameter ist eine verschlüsselte, undurchsichtige Payload. Sie enthält ein CSRF-Token (Cross-Site Request Forgery) gemäß RFC 6749.

Weiterleitungsendpunkt

Wie in RFC 6749 definiert, stellt die Authorization Code Gewährung einen Weiterleitungsendpunkt bereit. Dieser Endpunkt überwacht Autorisierungsantworten unter der Adresse:

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

Wobei https://example.com/Vinyl die absolute URL zum App Builder-Anwendungsstammverzeichnis und OAuth das Groß-/Kleinschreibung-sensitive Schema des Sicherheitsanbieters ist. Alle Sonderzeichen müssen URL-codiert werden.

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

Reverse Proxy

Seit App Builder 4.59 lässt der OAuth-Redirect-URI die Portnummer weg, wenn der Standardport verwendet wird. Dies gewährleistet die Kompatibilität mit OAuth-Providern, 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 dem Redirect-URI zu entfernen:

1. Navigieren Sie zu IDE > Security Providers.
2. Erweitern Sie im Panel Security Providers das Menü More und klicken Sie auf Import Provider.

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

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

4. Klicken Sie auf die Schaltfläche Import und dann auf Proceed zur Bestätigung.

5. Kehren Sie zur Seite Security zurück. Erweitern Sie im Panel Security Providers das Menü More und klicken Sie auf Request Pipeline.
6. Suchen Sie den importierten URL Rewrite-Anbieter. Legen Sie seine Priority fest (z. B. 10) und aktivieren Sie die Option Enabled.

Um die Fehlerbehebung zu überprüfen, kehren Sie zur Seite Security zurück, erweitern Sie das Menü More des Panels Configuration, und klicken Sie auf Inspect Request. Der Port sollte leer sein und Default sollte aktiviert sein.

Verwendung von OAuth für externe Authentifizierung

Wie oben erwähnt, ist OAuth ein Autorisierungsprotokoll und kein Authentifizierungsprotokoll. Allerdings erweitern einige Anbieterimplementierungen das OAuth-Protokoll um Authentifizierung. Typischerweise wird dies durch Veröffentlichung eines Endpunkts erreicht, der den Benutzer identifiziert. App Builder bezeichnet einen solchen Endpunkt als User Info Endpoint.

App Builder lässt sich so konfigurieren, dass es den User Info Endpoint abfragt, um die Identität des Benutzers abzurufen. Dies ermöglicht die Verwendung eines OAuth-Sicherheitsanbieters für 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 Request Body enthält.

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

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

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

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

Nach dem Abrufen des Zugriffstokens stellt App Builder eine Client-authentifizierte Anfrage an den User Info Endpoint. App Builder analysiert den Antwort-Body als JSON und behandelt Top-Level-Eigenschaften als Claims.

Beispielsweise wird für die folgende Beispielantwort:

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

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

folgende Claim-Typen verfügbar sein:

• user_name

• name

• email

Zusätzlich zur Angabe des User Info Endpoint muss der Entwickler den Claim abbilden, der den Benutzer identifiziert – in diesem Fall der user_name Claim – zum Name Claim-Verwendungstyp.

SAML 2.0 Bearer Assertion

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

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

2. (Veraltet) Ein Identity Provider (IdP) eines Drittanbieters stellt eine SAML-Assertion während des SAML Single Sign-On (SSO) Prozesses aus. Siehe SAML-Anbietertyp für weitere Informationen.

Jede Quelle erfordert zusätzliche Konfiguration.

SAML-Assertions bedarfsgesteuert generieren

Um eine SAML-Assertion bedarfsgesteuert zu generieren, konfigurieren Sie die Token-Eigenschaften wie oben beschrieben. Darüber hinaus erfordert der 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 IdP eines Drittanbieters zu beziehen, setzen Sie den Parameter SamlSingleSignOnProvider.

Beschrä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.