OAuth-Sicherheitsanbieter im Jitterbit App Builder

Der OAuth-Sicherheitsanbieter ermöglicht die Unterstützung von 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 unten.

OAuth 2.0-Berechtigungen

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

• Autorisierungscode RFC 6749.

• Client-Anmeldeinformationen RFC 6749.

• Passwort des Ressourcenbesitzers RFC 6749.

• SAML 2.0-Bearer-Assertion RFC 7522.

• JWT-Bearer-Token RFC 7523.

Autorisierungscode

Die OAuth 2.0-Autorisierungscode-Erteilung ermöglicht eine delegierte Autorisierung auf Benutzerebene. Diese Erteilung ist in RFC 6749 definiert.

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

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

Client-Anmeldeinformationen

Die OAuth 2.0-Client-Anmeldeinformationen-Berechtigung ermöglicht eine Authentifizierung auf Clientebene, ähnlich einem Dienstkonto. Dabei werden die OAuth-Client-Anmeldeinformationen gegen ein OAuth-Zugriffstoken ausgetauscht. Die Client-Anmeldeinformationen-Berechtigung ist in RFC 6749 definiert.

Kennwortanmeldeinformationen des Ressourcenbesitzers

Die Berechtigung für OAuth 2.0-Ressourcenbesitzer-Passwort-Anmeldeinformationen ist in RFC 6749 definiert. Allerdings wurde die Erteilung inzwischen veraltet.

Wichtig

Die Berechtigung für die Kennwortanmeldeinformationen des Ressourcenbesitzers DARF NICHT verwendet werden.

Die OAuth 2.0 Resource Owner Password Credentials-Berechtigung bietet ursprünglich eine Autorisierung auf Benutzerebene. Der Benutzer übermittelt seinen Benutzernamen und sein Passwort an einen vertrauenswürdigen Client. Der vertrauenswürdige Client tauscht die Anmeldeinformationen gegen ein Zugriffstoken aus.

App Builder bietet teilweise Unterstützung für die OAuth 2.0-Berechtigung für Ressourcenbesitzerkennwörter. App Builder fordert den Benutzer nicht zur Eingabe seiner Anmeldeinformationen auf. Stattdessen werden alle Benutzer mit einer einzigen Anmeldeinformation autorisiert. Somit entspricht die Berechtigung funktional einem Dienstkonto.

SAML 2.0-Träger-Assertion

Der OAuth 2.0 SAML 2.0 Bearer Assertion Grant ermöglicht die 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-Berechtigung ermöglicht die Datenquellenauthentifizierung auf Benutzerebene. Dabei werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstoken ausgetauscht. Die OAuth 2.0 JWT Bearer Token-Berechtigung 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-Client-Authentifizierung: Bestimmt das OAuth 2.0-Client-Authentifizierungsschema RFC 6749 Abschnitt 2.3. Optionen:

  • 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 Anfragetext bereitgestellt. (client_secret_post.)

• OAuth-Ressourcenauthentifizierung: Bestimmt das Authentifizierungsschema für Ressourcenanforderungen. Mögliche Optionen:

  • Träger: Träger-Authentifizierungsschema. Standard.

  • Formular: Zugriffstoken an den URL-codierten Text des Formulars anhängen.

  • Abfrage: Zugriffstoken an Abfrage anhängen.

• Token-Besitzer: Legt fest, ob Token an einzelne Benutzer oder an das Client-System ausgegeben werden. Mögliche Optionen:

  • Benutzer: Token werden an einzelne Benutzer ausgegeben.

  • Client: Token werden an das Clientsystem ausgegeben.

• Token beim Abmelden löschen: Wenn aktiviert, löscht App Builder 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-Träger-Assertion.

• JWT-Trägertoken.

SAML 2.0-Träger-Assertion

• Aussteller: Der Aussteller der SAML -Assertion.

• Zielgruppe: Die Zielgruppenbeschränkung der SAML -Assertion. Obwohl die SAML Spezifikation vorgibt, dass die Zielgruppe eine URI ist, berücksichtigen viele Implementierungen dies nicht. Daher erfordert App Builder nicht, dass die Zielgruppe eine URI ist.

• Empfänger: Die URI des SAML -Assertionsempfängers (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-Betreff-Anspruch (https://tools.ietf.org/html/rfc7523#section-3).

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

  • Wenn der Token-Besitzer Kunde ist, ist der Betreff erforderlich.

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

Endpoints

Art	Förderung	Beschreibung
Authorization Endpoint	Autorisierungscode	URL des OAuth 2.0- Endpoint. RFC 6749
Token Endpoint	Alle	OAuth 2.0-Token-Endpoint URL. RFC 6749
User Info Endpoint	Autorisierungscode	Endpoint, der die Benutzeridentität bereitstellt. Erforderlich, wenn OAuth als externer Authentifizierungsanbieter verwendet wird. Nicht Teil des OAuth-Standards. Der Endpoint muss eine JSON-Antwort zurückgeben, die die Benutzeridentität enthält.

Anmeldeinformationen

Art	Förderung	Beschreibung
Client	Alle	OAuth 2.0-Clientkennung (client_id) und geheim (client_secret). RFC 6749
Resource Owner	Kennwortanmeldeinformationen des Ressourcenbesitzers	Benutzername des OAuth 2.0-Ressourcenbesitzers (username) und Passwort (password). RFC 6749

Zertifikate

Art	Förderung	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-Container (.pfx).
	JWT-Bearer-Token	Für die Gewährung des JWT-Bearer-Tokens ist ein PEM-kodierter privater PKCS#1-RSA-Schlüssel erforderlich (RSA PRIVATE KEY).

Eigenschaften

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

Parameter	Standard
BearerSchemeIdentifier	Bearer	Authorization Schema bei der Verwendung der Bearer Ressourcenauthentifizierung.
ExpiresIn		Ablauf des Zugriffstokens in Sekunden. Kann verwendet werden, wenn der Token-Endpoint kein Ablaufdatum angibt und der Ressourcenserver kein 401 UnauthorizedAntwort, wenn das Zugriffstoken abgelaufen ist.
IgnoreTlsErrors	False	Gibt an, ob App Builder TLS-Fehler bei Backchannel-Anfragen an den Token-Endpoint ignorieren soll. Dies sollte nur für Entwicklung und Tests verwendet werden.
Scopes		Durch Leerzeichen getrennte Liste der OAuth 2.0-Zugriffstokenbereiche. RFC 6749
SingleUseAccessToken	False	Gibt an, ob das Zugriffstoken nur einmal verwendet werden kann.
Token Endpoint Parameters		Parameter, die an den OAuth-Token Endpoint übergeben werden. Standardmäßig generiert 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 Formular URL -codierten Format angegeben werden (application/x-www-form-urlencoded). Wenn die Parameterliste mit einem kaufmännischen Und-Zeichen (&), werden die Parameter in die generierten Parameter integriert. Wenn ein Parameter den gleichen Namen wie ein generierter Parameter hat, wird der generierte Parameter überschrieben. Wenn ein angegebener Parameter keinen Wert hat, z. B. &grant_type&username=user&password=password, wird der generierte Parameter entfernt. Andernfalls wird der angegebene Parameter an die generierten Parameter angehängt. Die Parameterliste unterstützt String-Interpolation. Ausdrücke können auf dynamische Parameter verweisen, z. B. username={{ client_id }}&password={{ Clientgeheimnis }}. Dies ist nützlich bei der Integration mit APIs von Drittpartei, die keine Standardparameternamen verwenden.
RefreshRequiresScopes	False	Gibt an, ob die Bereiche (scope) sollte in den Anforderungstext aufgenommen werden, der beim Aktualisieren des Zugriffstokens an den Token Endpoint gesendet wird.

Autorisierungscode

Die folgenden zusätzlichen Eigenschaften gelten für die Autorisierungscode-Erteilung.

Parameter	Standard
BackchannelAuthorization	False	Gibt an, ob ein Autorisierungscode über eine Backchannel-Anforderung (Server-zu-Server) abgerufen werden kann. Dies ist eine nicht standardmäßige Erweiterung der Autorisierungscode-Erteilung.

SAML 2.0-Träger-Assertion

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

Parameter
SamlSingleSignOnProvider	Name eines SAML -Sicherheitsanbieters des App Builder. Dieser Parameter gilt nur für die SAML 2.0 Bearer Assertion-Berechtigung.

JWT-Trägertoken

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

Parameter	Standard
JwtClaimSet	{ "scope": "{{ Umfang }}" }	Autorisierungsserver können benutzerdefinierte Ansprüche erfordern. Beispielsweise benötigt Google eine scope Anspruch, der mit dem OAuth übereinstimmt scope Parameter. Der JwtClaimSet Mit diesem Parameter können Administratoren zusätzliche Ansprüche angeben. Der Wert wird als JSON-Vorlage verwendet. Folgende Werte können in die Vorlage eingefügt werden: client_id- OAuth client_idParameter. 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.

Ausruhen

Die folgenden zusätzlichen Eigenschaften gelten, wenn der OAuth-Sicherheitsanbieter zur Authentifizierung 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 werden (erscheinen in einer eigenen Zeile).

Parameter	Standard	Beispiel
RequestHeaders		X-Custom-Header: Value X-Another-Header: Value	Benutzerdefinierte HTTP-Header, die an REST- Endpoint angehängt werden. Die Header müssen gemäß RFC 7230 formatiert sein. Zeilenumbrüche werden nicht unterstützt.

Protokollunterstützung

Aktualisierungstoken

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

Autorisierungscode

Autorisierungsanfrage

Beim Erstellen einer Autorisierungsanfrage schließt App Builder die Clientkennung (client_id), Client-Geheimnis (client_secret) und Bereiche (scope). Darüber hinaus fügt der App Builder automatisch die folgenden Standardparameter an:

• redirect_uri: App Builder erstellt 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-Erteilung 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 zum Stammverzeichnis der App Builder Anwendung und OAuth ist der URL-codierte, Groß- und Kleinschreibung berücksichtigende 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 bereits erwähnt, ist OAuth ein Autorisierungsprotokoll, kein Authentifizierungsprotokoll. Einige Anbieterimplementierungen erweitern das OAuth-Protokoll jedoch um die Authentifizierung. Dies geschieht typischerweise durch die Veröffentlichung eines Endpoint zur Benutzeridentifizierung. App Builder bezeichnet einen solchen Endpoint als „Benutzerinformations Endpoint“.

App Builder kann so konfiguriert werden, dass der Benutzerinformations-Endpoint Abfrage wird, um die Benutzeridentität 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 für App Builder erreichbar sein.

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

• Der Endpoint muss die OAuth Basic-Client-Authentifizierung berücksichtigen (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 Erhalt des Zugriffstokens sendet App Builder eine clientauthentifizierte Anfrage an den * 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 stehen zur Verfügung:

• user_name

• name

• email

Zusätzlich zur Angabe des * 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 -Assertions bei Bedarf. In diesem Fall fungiert App Builder 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 -Assertions 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 -Assertions von einem IdP beziehen

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