OAuth-Sicherheitsanbieter in Jitterbit App Builder

Einführung

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

• REST

• OData

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

Darüber hinaus lässt sich ein OAuth-Sicherheitsanbieter als externer Authentifizierungsanbieter konfigurieren. Weitere Informationen finden Sie unten.

OAuth 2.0-Gewährungen

Der OAuth-Sicherheitsanbieter unterstützt die folgenden OAuth 2.0-Gewährungen:

• 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

Die OAuth 2.0 Authorization Code-Gewährung bietet delegierte Autorisierung auf Benutzerebene. Diese Gewährung 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. Die Umleitung 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 verwendet werden, um Anfragen an Webservices zu autorisieren.

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

Client Credentials

Die OAuth 2.0 Client Credentials-Gewährung bietet Authentifizierung auf Clientebene, ähnlich einem Dienstkonto. In diesem Flow werden die OAuth-Client-Anmeldedaten gegen ein OAuth-Zugriffstoken ausgetauscht. Die Client Credentials-Gewährung ist in RFC 6749 definiert.

Resource Owner Password Credentials

Die OAuth 2.0 Resource Owner Password Credentials-Gewährung ist in RFC 6749 definiert. Die Gewährung wurde jedoch inzwischen als veraltet eingestuft.

Wie ursprünglich konzipiert, bietet die OAuth 2.0 Resource Owner Password Credentials-Gewährung Autorisierung auf Benutzerebene. Der Benutzer gibt seinen Benutzernamen und sein Passwort an einen vertrauenswürdigen Client an. Der vertrauenswürdige Client tauscht die Anmeldedaten gegen ein Zugriffstoken aus.

App Builder bietet teilweise Unterstützung für die OAuth 2.0 Resource Owner Password Credentials-Gewährung. App Builder fordert den Benutzer nicht zur Eingabe seiner Anmeldedaten auf. Stattdessen wird eine einzelne Anmeldedaten verwendet, um alle Benutzer zu autorisieren. Auf diese Weise ist die Gewährung funktional gleichwertig mit einem Dienstkonto.

SAML 2.0 Bearer Assertion

Die OAuth 2.0 SAML 2.0 Bearer Assertion-Gewährung bietet Authentifizierung auf Benutzerebene für Datenquellen. In diesem Flow werden SAML-Assertions gegen OAuth-Zugriffstokens ausgetauscht. Die OAuth 2.0 SAML 2.0 Bearer Assertion-Gewährung ist in RFC 7522 definiert.

JWT Bearer Token

Die OAuth 2.0 JWT Bearer Token-Gewährung bietet Authentifizierung auf Benutzerebene für Datenquellen. In diesem Flow werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstokens ausgetauscht. Die OAuth 2.0 JWT Bearer Token-Gewährung ist in RFC 7523 definiert.

Konfiguration

Die Konfiguration variiert je nach OAuth-Gewährung. OAuth erfordert mindestens:

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

• Token-Endpunkt.

Einzelne OAuth-Gewährungen erfordern zusätzliche Konfigurationen wie nachfolgend angegeben.

Authentifizierung

Die Authentifizierungseigenschaften bestimmen die OAuth-Gewährung und Authentifizierungsschemas.

• Authentifizierungstyp: OAuth

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

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

  • Basic: Gibt an, dass das Client-Password-Schema verwendet wird. Die Anmeldedaten werden über HTTP-Basic-Authentifizierung bereitgestellt. (client_secret_basic.)

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

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

  • Post: Gibt 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 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 Ressourcenabfragen. Optionen umfassen:

  • Bearer: Bearer-Authentifizierungsschema. Standard.

  • Form: Access Token an Form-URL-codiertem Body anhängen.

  • Query: Access Token an Query-String anhängen.

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

  • User: Token werden an einzelne Benutzer ausgegeben.

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

• Token beim Abmelden löschen: Wenn aktiviert, 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: Kein Standard. Verwendet häufig eine Anwendungskennung oder die Client-ID. Konsultieren Sie die Dokumentation des Autorisierungsservers.

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

  • Subject: Standardmäßig die Client-ID (wie im Panel Credentials angegeben) gemäß 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 Gewährungen generieren Token, die gegen OAuth-Zugriffstokens ausgetauscht werden:

• SAML 2.0 Bearer Assertion.

• JWT Bearer Token.

SAML 2.0 Bearer Assertion

• Issuer: Der SAML-Assertion-Aussteller.

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

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

JWT Bearer Token

• Issuer: JWT-Issuer-Claim (https://tools.ietf.org/html/rfc7523#section-3). Standardmäßig die Clientkennung (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 das 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 die Autorisierungscode-Gewährung.

SAML 2.0 Bearer Assertion

Die folgenden zusätzlichen Eigenschaften gelten für die SAML 2.0 Bearer Assertion-Gewährung.

JWT Bearer Token

Die folgenden zusätzlichen Eigenschaften gelten für die JWT Bearer Token-Gewährung.

Rest

Übersetzung

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

Protokollunterstützung

Refresh-Token

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

Autorisierungscode

Autorisierungsanfrage

Beim Erstellen einer Autorisierungsanfrage fügt App Builder die Client-ID (client_id), das Client-Geheimnis (client_secret) und die Bereiche (scope) ein. Darüber hinaus fügt App Builder automatisch die folgenden Standardparameter 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 Nutzlast. Er enthält ein Cross-Site Request Forgery (CSRF)-Token gemäß RFC 6749.

Umleitungsendpunkt

Wie in RFC 6749 definiert, stellt die Authorization Code-Gewährung einen Umleitungsendpunkt bereit. Dieser Endpunkt lauscht 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 das Groß-/Kleinschreibung-sensitive Schema des Sicherheitsanbieters. Alle Sonderzeichen müssen URL-codiert sein.

Die meisten Drittanwendungen müssen vor der Autorisierung von Anfragen mit dem Umleitungsendpunkt 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-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 dem Redirect-URI zu entfernen:

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

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 Importieren und dann auf Fortfahren, um zu bestätigen.

5. Kehren Sie zur Seite Sicherheitsanbieter zurück. Erweitern Sie im Bereich Konfiguration das Menü Mehr und klicken Sie auf Request Pipeline.
6. Suchen Sie den importierten URL Rewrite-Anbieter. Legen Sie seine Priorität fest (z. B. 10) und aktivieren Sie die Option Aktiviert.

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

OAuth für externe Authentifizierung verwenden

Wie oben erwähnt, ist OAuth ein Autorisierungsprotokoll und kein Authentifizierungsprotokoll. Einige Herstellerimplementierungen erweitern das OAuth-Protokoll jedoch um Authentifizierung. Typischerweise erfolgt 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 der User Info Endpoint abgefragt wird, 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 Anfragebody enthält.

• Der Endpunkt muss OAuth-Basic-Clientauthentifizierung 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 Eigenschaft auf oberster Ebene enthalten, die den Benutzer identifiziert.

Nach dem Abrufen des Zugriffstokens stellt App Builder eine clientauthentifizierte Anfrage an den User Info Endpoint. App Builder analysiert den Antwortkörper als JSON und behandelt Eigenschaften auf oberster Ebene als Claims.

Beispielsweise wird bei der folgenden 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, der den Benutzer identifiziert – in diesem Fall den user_name-Claim – dem Claim-Verwendungstyp Name zuordnen.

SAML 2.0 Bearer Assertion

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

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

2. (Veraltet) Ein Identitätsanbieter (IdP) eines Drittanbieters stellt eine SAML-Assertion während des SAML-Single-Sign-On-Prozesses (SSO) aus. Weitere Informationen finden Sie unter SAML-Anbietertyp.

Jede Quelle erfordert zusätzliche Konfiguration.

SAML-Assertions bei Bedarf generieren

Um eine SAML-Assertion bei Bedarf zu generieren, konfigurieren Sie die Token-Eigenschaften wie oben beschrieben. Zusätzlich 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, legen Sie den Parameter SamlSingleSignOnProvider fest.

Einschränkungen

• JWT-Clientauthentifizierungstypen 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 nur die Konfiguration eines einzelnen JWT-Tokens.