OAuth-Sicherheitsanbieter im Jitterbit App Builder
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, benutzerebene Autorisierung. Diese Berechtigung ist in RFC 6749 definiert.
Im Autorisierungscode-Fluss leitet der App Builder den Benutzeragenten (Browser) an den Autorisierungsserver weiter. Sobald sich der Benutzer erfolgreich angemeldet hat 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 Back-Channel-Anfrage an den Autorisierungsserver und tauscht den Autorisierungscode gegen ein Zugriffstoken aus. 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-Anmeldeinformationen
Das OAuth 2.0 Client-Anmeldeinformationsgrant bietet eine clientseitige Authentifizierung, ähnlich einem Dienstkonto. In diesem Ablauf werden die OAuth-Client-Anmeldeinformationen gegen ein OAuth-Zugriffstoken eingetauscht. Das Client-Anmeldeinformationsgrant ist in RFC 6749 definiert.
Anmeldeinformationen des Ressourcenbesitzers
Das OAuth 2.0 Anmeldeinformationsgrant für Ressourcenbesitzer ist in RFC 6749 definiert. Dieses Grant wurde jedoch inzwischen abgelehnt.
Wichtig
Das Anmeldeinformationsgrant für Ressourcenbesitzer DARF NICHT verwendet werden.
Ursprünglich konzipiert bietet das OAuth 2.0 Anmeldeinformationsgrant für Ressourcenbesitzer 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 Anmeldeinformationsgrant für Ressourcenbesitzer. 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 Trägerbehauptung
Das OAuth 2.0 SAML 2.0 Trägerbehauptungsgrant bietet eine benutzerspezifische Authentifizierung der Datenquelle. In diesem Ablauf werden SAML-Behauptungen gegen OAuth-Zugriffstoken eingetauscht. Das OAuth 2.0 SAML 2.0 Trägerbehauptungsgrant ist in RFC 7522 definiert.
JWT-Träger-Token
Das OAuth 2.0 JWT-Träger-Token-Grant bietet eine benutzerspezifische Authentifizierung der Datenquelle. In diesem Ablauf werden JSON Web Tokens (JWTs) gegen OAuth-Zugriffstoken eingetauscht. Das OAuth 2.0 JWT-Träger-Token-Grant ist in RFC 7523 definiert.
Konfiguration
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 die OAuth-Berechtigung und die Authentifizierungsschemata.
-
Authentifizierungstyp: OAuth
-
OAuth-Berechtigung: Wählen Sie eine unterstützte OAuth-Berechtigung aus.
-
OAuth-Client-Authentifizierung: Bestimmt das Authentifizierungsschema für OAuth 2.0-Clients RFC 6749 Abschnitt 2.3. Optionen sind:
-
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 Anfragekörper bereitgestellt. (
client_secret_post
.)
-
-
OAuth-Ressourcen-Authentifizierung: Bestimmt das Authentifizierungsschema für die Ressourcenanforderung. Optionen sind:
-
Bearer: Bearer-Authentifizierungsschema. Standard.
-
Formular: Fügen Sie das Zugriffstoken zum URL-codierten Formularinhalt hinzu.
-
Abfrage: 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.
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
-
Aussteller: Der Aussteller der SAML-Assertion.
-
Zielgruppe: 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 erfordert der App Builder nicht, dass die Zielgruppe eine URI ist.
-
Empfänger: Die SAML-Assertion Empfänger-URI (z. B.
http://example.com/service
).
JWT-Bearer-Token
-
Aussteller: JWT-Ausstelleranspruch (https://tools.ietf.org/html/rfc7523#section-3). Standardmäßig der Client-Identifikator (
client_id
). -
Subjekt: JWT-Subjektanspruch (https://tools.ietf.org/html/rfc7523#section-3).
-
Wenn der Token-Besitzer Benutzer ist, standardmäßig die Identität des aktuellen Benutzers.
-
Wenn der Token-Besitzer Client ist, ist das Subjekt erforderlich.
-
-
Zielgruppe: JWT-Zielgruppenanspruch (https://tools.ietf.org/html/rfc7523#section-3). Standardmäßig der Token-Endpunkt.
Endpunkte
Typ | Berechtigungen | Beschreibung |
---|---|---|
Authorization Endpoint |
Autorisierungscode | OAuth 2.0 Autorisierungsendpunkt-URL. RFC 6749 |
Token Endpoint |
Alle | OAuth 2.0 Token-Endpunkt-URL. RFC 6749 |
User Info Endpoint |
Autorisierungscode | Endpunkt, der die Benutzeridentität bereitstellt. Erforderlich, wenn OAuth als externen Authentifizierungsanbieter behandelt wird. Kein Teil des OAuth-Standards. Der Endpunkt muss eine JSON-Antwort zurückgeben, die die Benutzeridentität enthält. |
Anmeldeinformationen
Typ | Berechtigungen | Beschreibung |
---|---|---|
Client |
Alle | OAuth 2.0 Client-Identifikator (client_id ) und Geheimnis (client_secret ). RFC 6749 |
Resource Owner |
Anmeldeinformationen des Ressourcenbesitzers | OAuth 2.0 Benutzername des Ressourcenbesitzers (username ) und Passwort (password ). RFC 6749 |
Zertifikate
Typ | Berechtigungen | Beschreibung |
---|---|---|
Signing |
SAML 2.0 Träger-Assertion | Die SAML 2.0 Träger-Assertion-Berechtigung erfordert ein X.509-Zertifikat mit privatem Schlüssel in einem passwortgeschützten PKCS#12 (.pfx) Container. |
JWT Träger-Token | Die JWT Träger-Token-Berechtigung erfordert einen PEM-kodierten, PKCS#1 RSA privaten Schlüssel (RSA PRIVATE KEY ). |
Eigenschaften
Der OAuth-Sicherheitsanbieter unterstützt die folgenden zusätzlichen Parameter:
Parameter | Standard | |
---|---|---|
BearerSchemeIdentifier |
Bearer |
Authorization -Schema bei Verwendung der Bearer -Ressourcenauthentifizierung. |
ExpiresIn |
Ablaufzeit des Zugriffstokens in Sekunden. Kann verwendet werden, wenn der Token-Endpunkt keine Ablaufzeit angibt und der Ressourcenserver keine 401 Unauthorized -Antwort zurückgibt, wenn das Zugriffstoken abgelaufen ist. |
|
IgnoreTlsErrors |
False |
Gibt an, ob der App Builder TLS-Fehler beim Senden von Back-Channel-Anfragen an den Token-Endpunkt ignorieren soll. Dies sollte nur für Entwicklung und Tests verwendet werden. |
Scopes |
Durch Leerzeichen getrennte Liste von OAuth 2.0 Zugriffstoken-Berechtigungen. RFC 6749 | |
SingleUseAccessToken |
False |
Gibt an, ob das Zugriffstoken nur einmal verwendet werden kann. |
Token Endpoint Parameters |
Parameter, die an den OAuth-Token-Endpunkt übergeben werden. Standardmäßig generiert der App Builder die entsprechenden Parameter basierend auf dem OAuth-Fluss. Verwenden Sie diese Einstellung nur für nicht konforme oder anderweitig nicht unterstützte OAuth-APIs. Die Parameter sollten im form URL-encoded Format (application/x-www-form-urlencoded ) angegeben werden. Wenn die Parameterliste mit einem Kaufmanns-Und-Zeichen (& ) beginnt, werden die Parameter in die generierten Parameter zusammengeführt. Wenn ein Parameter denselben Namen wie ein generierter Parameter hat, wird der generierte Parameter überschrieben. Wenn ein übergebener Parameter keinen Wert hat, z. B. &grant_type&username=user&password=password , wird der generierte Parameter entfernt. Andernfalls wird der übergebene Parameter zu den generierten Parametern hinzugefügt. Die Parameterliste unterstützt die Zeichenfolgeninterpolation. Ausdrücke können auf dynamische Parameter verweisen, z. B. username={{ client_id }}&password={{ client_secret }} . Dies ist nützlich, wenn Sie mit Drittanbieter-APIs integrieren, die keine standardmäßigen Parameternamen verwenden. |
|
RefreshRequiresScopes |
False |
Gibt an, ob die Berechtigungen (scope ) im Anfragekörper, der an den Token-Endpunkt gesendet wird, enthalten sein sollten, wenn das Zugriffstoken aktualisiert wird. |
Autorisierungscode
Die folgenden zusätzlichen Eigenschaften gelten für den Autorisierungscode-Grant.
Parameter | Standard | |
---|---|---|
BackchannelAuthorization |
False |
Gibt an, ob ein Autorisierungscode über eine Backchannel-Anfrage (Server-zu-Server) erworben werden kann. Dies ist eine nicht standardisierte Erweiterung des Autorisierungscode-Grants. |
SAML 2.0 Trägerbehauptung
Die folgenden zusätzlichen Eigenschaften gelten für den SAML 2.0 Bearer Assertion Grant.
Parameter | |
---|---|
SamlSingleSignOnProvider |
Name eines SAML-Sicherheitsanbieters für App Builder. Dieses Parameter gilt nur für den SAML 2.0 Bearer Assertion Grant. |
JWT Träger-Token
Die folgenden zusätzlichen Eigenschaften gelten für den JWT Bearer Token Grant.
Parameter | Standard | |
---|---|---|
JwtClaimSet |
{ "scope": "{{ scope }}" } |
Autorisierungsserver können benutzerdefinierte Ansprüche erfordern. Zum Beispiel verlangt Google einen scope -Anspruch, der mit dem OAuth-scope -Parameter übereinstimmt. Das JwtClaimSet -Parameter ermöglicht es Administratoren, zusätzliche Ansprüche bereitzustellen. Der Wert hat die Form einer JSON-Vorlage. Die folgenden Werte können in die Vorlage eingesetzt werden:
|
SigningAlgorithm |
RS256 |
JWT-Algorithmusparameter wie in RFC 7518 definiert. Der einzige unterstützte Algorithmus ist RS256 . |
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 (in einer eigenen Zeile) getrennt werden.
Parameter | Standard | Beispiel | |
---|---|---|---|
RequestHeaders |
X-Custom-Header: Value X-Another-Header: Value |
Benutzerdefinierte HTTP-Header, die an REST-Endpunktanforderungen angehängt werden. Die Header müssen gemäß RFC 7230 formatiert sein. Zeilenfaltung wird nicht unterstützt. |
Protokollunterstützung
Aktualisierungstoken
Wenn die Anforderung für das Zugriffstoken ein Aktualisierungstoken enthält, versucht der App Builder automatisch, das Aktualisierungstoken zu verwenden, um ein neues Zugriffstoken zu erhalten, nachdem eine 401 Unauthorized
-Antwort empfangen wurde.
Autorisierungscode
Autorisierungsanforderung
Beim Erstellen einer Autorisierungsanforderung wird der App Builder die Client-ID (client_id
), das Client-Geheimnis (client_secret
) und die Scopes (scope
) einfügen. Darüber hinaus wird der App Builder automatisch die folgenden Standardparameter anhängen:
-
redirect_uri
: Der App Builder konstruiert den Parameterredirect_uri
aus der aktuellen URL. Er hat die Formhttps://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 an 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 der URL-kodierte, groß- und kleinschreibungssensitive Name des Sicherheitsanbieters.
Die meisten Drittanbieteranwendungen müssen vor der Autorisierung von Anfragen mit dem Weiterleitungsendpunkt konfiguriert werden.
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 die Authentifizierung. Dies geschieht typischerweise 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 er den User Info Endpoint abfragt, um die Identität des Benutzers abzurufen. Dadurch kann ein OAuth-Sicherheitsanbieter für die externe Authentifizierung verwendet werden. Es ist jedoch zu beachten, 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
vonapplication/json
enthalten. -
Das JSON-Dokument muss eine oberste Eigenschaft enthalten, die den Benutzer identifiziert.
Nach dem Erwerb des Zugriffstokens wird App Builder eine client-authentifizierte Anfrage an den User Info Endpoint stellen. App Builder wird den Antwortkörper als JSON analysieren und oberste 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
Neben der Angabe des User Info Endpoint muss der Entwickler den Anspruch, der den Benutzer identifiziert – in diesem Fall den user_name
-Anspruch – dem Name-Anspruchsverwendungstyp zuordnen.
SAML 2.0 Trägerbehauptung
Beim Einsatz des SAML 2.0 Trägerbehauptungsflusses können SAML-Behauptungen auf eine von zwei Arten bezogen werden:
-
Der App Builder generiert und signiert die SAML-Behauptungen nach Bedarf. In diesem Fall fungiert der App Builder als IdP.
-
(Veraltet) Ein Drittanbieter-Identitätsanbieter (IdP) gibt während des SAML Single Sign-On (SSO)-Prozesses eine SAML-Behauptung aus. Weitere Informationen finden Sie im SAML-Anbietertyp.
Jede Quelle erfordert zusätzliche Konfiguration.
SAML-Behauptungen nach Bedarf generieren
Um eine SAML-Behauptung nach Bedarf zu generieren, konfigurieren Sie die Token-Eigenschaften wie oben beschrieben. Darüber hinaus erfordert das SAML 2.0 Trägerbehauptungsgrant ein Signing-Zertifikat mit einem privaten Schlüssel.
SAML-Behauptungen von einem IdP beziehen
Um SAML-Behauptungen von einem Drittanbieter-IdP zu beziehen, setzen Sie den Parameter SamlSingleSignOnProvider.