OAuth-Sicherheitsanbieter im Jitterbit App Builder

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

• AUSRUHEN

• OData

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

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

OAuth 2.0-Berechtigungen

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

• Autorisierungscode RFC 6749.

• Client-Anmeldeinformationen RFC 6749.

• Passwort-Anmeldeinformationen des Ressourcenbesitzers RFC 6749.

• SAML 2.0-Bearer-Assertion RFC 7522.

• JWT-Bearer-Token RFC 7523.

Autorisierungscode

Die OAuth 2.0-Autorisierungscode-Erteilung bietet delegierte Autorisierung auf Benutzerebene. Diese Erteilung ist in RFC 6749 definiert.

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

OAuth selbst bietet Autorisierung, nicht Authentifizierung. Daher werden OAuth-Sicherheitsanbieter normalerweise 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 Endpoint veröffentlicht, der die Benutzeridentität bereitstellt, kann der OAuth-Sicherheitsanbieter als externer Authentifizierungsanbieter verwendet werden. Weitere Einzelheiten finden Sie unter Benutzerinfo-Endpoint.

Client-Anmeldeinformationen

Die OAuth 2.0-Client-Anmeldeinformationen-Berechtigung bietet eine Authentifizierung auf Clientebene, ähnlich einem Servicekonto. In diesem Ablauf werden die OAuth-Client-Anmeldeinformationen gegen ein OAuth-Zugriffstoken ausgetauscht. Die Client-Anmeldeinformationen-Berechtigung ist in RFC 6749 definiert.

Kennwortanmeldeinformationen des Ressourcenbesitzers

Die OAuth 2.0 Resource Owner Password Credentials-Berechtigung ist in RFC 6749 definiert. Allerdings wurde die Erteilung inzwischen veraltet.

Wie ursprünglich konzipiert, bietet die Berechtigung „Passwort-Anmeldeinformationen des Ressourcenbesitzers“ von OAuth 2.0 Autorisierung auf Benutzerebene. 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 die Gewährung von Kennwortanmeldeinformationen für OAuth 2.0-Ressourcenbesitzer. App Builder fordert den Benutzer nicht zur Eingabe seiner Anmeldeinformationen auf. Stattdessen werden alle Benutzer mit einer einzigen Anmeldeinformation autorisiert. Auf diese Weise ist die Berechtigung funktional gleichwertig mit einem Dienstkonto.

SAML 2.0-Träger-Assertion

Der OAuth 2.0 SAML 2.0 Bearer Assertion Grant ermöglicht eine Datenquellenauthentifizierung auf Benutzerebene. In diesem Ablauf werden SAML Assertionen gegen OAuth-Zugriffstoken ausgetauscht. Der OAuth 2.0 SAML 2.0 Bearer Assertion Grant ist in RFC 7522 definiert.

JWT-Trägertoken

Die OAuth 2.0 JWT Bearer Token-Zuteilung ermöglicht eine Datenquellenauthentifizierung auf Benutzerebene. In diesem Ablauf werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstoken ausgetauscht. Die OAuth 2.0 JWT Bearer Token-Zuteilung ist in RFC 7523 definiert.

Konfiguration

Die Konfiguration variiert je nach OAuth-Berechtigung. OAuth erfordert mindestens:

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

• Token Endpoint.

Für einzelne OAuth-Berechtigungen sind zusätzliche Konfigurationen erforderlich, 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-Clientauthentifizierung: Bestimmt das OAuth 2.0-Clientauthentifizierungsschema RFC 6749 Abschnitt 2.3. Zu den Optionen gehören:

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

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

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

• OAuth-Ressourcenauthentifizierung: Bestimmt das Authentifizierungsschema für Ressourcenanforderungen. Zu den Optionen gehören:

  • Bearer: Träger-Authentifizierungsschema. Standard.

  • Formular: Zugriffstoken an den URL-codierten Formulartext anhängen.

  • Abfrage: Zugriffstoken an Abfrage anhängen.

• Token-Eigentümer: Legt fest, ob Token an einzelne Benutzer oder an das Clientsystem ausgegeben werden. Zu den Optionen gehören:

  • Benutzer: Token werden an einzelne Benutzer ausgegeben.

  • Client: Token werden an das Clientsystem ausgegeben.

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

Zeichen

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

• SAML 2.0-Bearer-Assertion.

• JWT-Trägertoken.

SAML 2.0-Träger-Assertion

• Aussteller: Der Herausgeber der SAML -Assertion.

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

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

JWT-Trägertoken

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

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

  • Wenn der Token-Eigentümer Benutzer ist, wird standardmäßig die Identität des aktuellen Benutzers verwendet.

  • Wenn der Token-Eigentümer Kunde ist, ist der Betreff erforderlich.

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

Endpoints

Qualifikationen

Zertifikate

Eigenschaften

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

Autorisierungscode

Die folgenden zusätzlichen Eigenschaften gelten für die Gewährung des Autorisierungscodes.

SAML 2.0-Träger-Assertion

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

JWT-Trägertoken

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

Ausruhen

Die folgenden zusätzlichen Eigenschaften gelten, wenn der OAuth-Sicherheitsanbieter zum Authentifizieren von REST-Datenquellen verwendet wird. Diese werden für OAuth-Endpoints und andere Datenquellentypen, einschließlich OData und RDBMS, ignoriert.
Anforderungsheader müssen durch einen Wagenrücklauf getrennt sein (in einer eigenen Zeile erscheinen).

Protokollunterstützung

Aktualisierungstoken

Wenn die Zugriffstokenanforderung ein Aktualisierungstoken enthält, App Builder versucht automatisch, mit dem Aktualisierungstoken ein neues Zugriffstoken zu erhalten, nachdem ein 401 Unauthorized Antwort.

Autorisierungscode

Autorisierungsanfrage

Beim Erstellen einer Autorisierungsanfrage App Builder enthält die Clientkennung (client_id), geheimer Clientschlüssel (client_secret) und Bereiche (scope). Zusätzlich, App Builder fügt automatisch die folgenden Standardparameter an:

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

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

Endpoint

Wie in RFC 6749 definiert, stellt die Autorisierungscode-Zuweisung einen Endpoint bereit. Dieser Endpoint wartet auf Autorisierungsantworten an der Adresse:

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

Wo https://example.com/AppBuilder ist die absolute URL zur App Builder Stammverzeichnis der Anwendung und OAuth ist der URL-codierte, Groß-/Kleinschreibung beachtende Name des Sicherheitsanbieters.

Die meisten Anwendungen von Drittpartei müssen mit dem Endpoint konfiguriert werden, bevor Anfragen autorisiert werden können.

Verwenden von OAuth zur externen Authentifizierung

Wie oben erwähnt, ist OAuth ein Autorisierungsprotokoll und kein Authentifizierungsprotokoll. Einige Anbieterimplementierungen erweitern das OAuth-Protokoll jedoch um die Authentifizierung. Normalerweise geschieht dies durch die Veröffentlichung eines Endpoint, der den Benutzer identifiziert. App Builder bezeichnet einen solchen Endpoint als User Info Endpoint.

App Builder kann so konfiguriert werden, dass der Benutzerinfo-Endpoint Abfrage wird, um die Identität des Benutzers abzurufen. Dadurch kann ein OAuth-Sicherheitsanbieter für die externe Authentifizierung verwendet werden. Beachten Sie jedoch, dass der Endpoint die folgenden Anforderungen erfüllen muss:

• Der Endpoint muss erreichbar sein durch App Builder.

• Der Endpoint muss auf ein HTTP antworten GET Anfrage, die keinen Anfragetext enthält.

• Der Endpoint muss die OAuth Basic-Client-Authentifizierung akzeptieren (wie oben beschrieben).

• Die HTTP-Antwort muss eine 200 Statuscode.

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

• Das JSON-Dokument muss eine Eigenschaft der obersten Ebene enthalten, die den Benutzer identifiziert.

Nach dem Erhalt des Zugriffstokens App Builder sendet eine clientauthentifizierte Anfrage an den User Info Endpoint. App Builder analysiert den Antworttext als JSON und behandelt Eigenschaften der obersten Ebene als Ansprüche.

Nehmen wir beispielsweise die folgende Beispielantwort:

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

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

Folgende Anspruchsarten werden verfügbar sein:

• user_name

• name

• email

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

SAML 2.0-Träger-Assertion

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

1. App Builder generiert und signiert die SAML Assertionen auf Anfrage. In diesem Fall App Builder fungiert als IdP.

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

Jede Quelle erfordert eine zusätzliche Konfiguration.

Generieren Sie SAML Assertionen bei Bedarf

Um bei Bedarf eine SAML -Assertion zu generieren, konfigurieren Sie die Token-Eigenschaften wie oben beschrieben. Darüber hinaus erfordert die Gewährung der SAML 2.0 Bearer Assertion ein Signatur-Zertifikat mit einem privaten Schlüssel.

SAML Quellenbehauptungen von einem IdP

Um SAML Assertionen von einem Drittpartei IdP zu beziehen, legen Sie den Parameter SamlSingleSignOnProvider fest.