Zum Inhalt springen

OData Sicherheitsanbieter im Jitterbit App Builder

Der OData Sicherheitsanbieter authentifiziert Anforderungen, die an eine OData Datenquelle gestellt werden. Er unterstützt die folgenden Authentifizierungsmechanismen:

  • Anonyme Authentifizierung.
  • HTTP-Basisauthentifizierung.
  • OAuth 2.0-Autorisierungscode-Flow.
  • OAuth 2.0-Client-Anmeldeinformationsfluss.
  • OAuth 2.0-Fluss für Kennwortanmeldeinformationen des Ressourcenbesitzers.
  • OAuth 2.0 JSON Web Token Bearer-Flow.
  • OAuth 2.0 SAML 2.0 Bearer Assertion-Flow.

Wichtig

Eine OData Datenquelle sollte entweder HTTP verwenden oder OAuth Sicherheitsanbieter.

Anonyme Authentifizierung

Anonyme Authentifizierung wird standardmäßig verwendet, wenn keine Anmeldeinformationen angegeben werden und kein anderer Authentifizierungstyp ausgewählt ist. Für die anonyme Authentifizierung ist keine Konfiguration erforderlich. Sie kann jedoch explizit aktiviert werden, indem die Datenquelle mit einem Sicherheitsanbieter verknüpft wird, der einen AuthenticationType von Anonymous.

Siehe Anonyme HTTP-Authentifizierung für die vollständige Konfiguration.

HTTP-Basisauthentifizierung

Umgesetzt von App Builder, HTTP Basic Authentication ist eine Form von Service-Konto, d.h. alle App Builder Benutzer authentifizieren sich mit demselben Satz von Anmeldeinformationen. Die Anmeldeinformationen (Benutzername und Passwort) werden auf Datenquellenebene definiert.

Die HTTP-Basisauthentifizierung wird auf eine von zwei Arten aktiviert:

  1. Implizit. Anmeldeinformationen werden auf Datenquellenebene definiert und die Datenquelle ist keinem Sicherheitsanbieter zugeordnet.
  2. Explizit. Anmeldeinformationen werden auf Datenquellenebene definiert und die Datenquelle ist einem Sicherheitsanbieter zugeordnet, der einen AuthenticationType von hat Basic.

Siehe HTTP-Basisauthentifizierung für die vollständige Konfiguration.

OAuth 2.0-Autorisierungscodefluss

Der OAuth 2.0-Autorisierungscode-Flow bietet Authentifizierung auf Benutzerebene. In diesem Flow werden Autorisierungscodes gegen OAuth-Zugriffstoken ausgetauscht.

Anders als bei den Authentifizierungsschemata Anonymous und HTTP Basic muss der Autorisierungscode-Flow explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter, der einen AuthenticationType von AuthorizationCode.

Darüber hinaus funktioniert der OAuth-Autorisierungscode-Flow in Verbindung mit einem OAuth-Sicherheitsanbieter. Der OAuth-Sicherheitsanbieter ist für die Autorisierung des Benutzers und den Austausch von Autorisierungscodes gegen Zugriffstoken verantwortlich.

Siehe OAuth 2.0-Autorisierungscodefluss für die vollständige Konfiguration.

OAuth 2.0 SAML 2.0-Bearer-Assertion-Flow

Der OAuth 2.0 SAML 2.0 Bearer Assertion Flow ermöglicht die Authentifizierung auf Benutzerebene. In diesem Flow werden SAML Assertionen gegen OAuth-Zugriffstoken ausgetauscht.

Im Gegensatz zu den Authentifizierungsschemata Anonymous und HTTP Basic muss der SAML 2.0 Bearer Assertion-Flow explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter, der einen AuthenticationType von Saml.

Siehe OAuth 2.0 SAML 2.0 Bearer Assertion Flow für die vollständige Konfiguration.

OAuth 2.0-Clientanmeldeinformationsfluss

Der OAuth 2.0 Client Credentials-Flow bietet eine Authentifizierung auf Clientebene, ähnlich einem Servicekonto. In diesem Flow werden die OAuth-Client-Anmeldeinformationen gegen ein OAuth-Zugriffstoken ausgetauscht.

Anders als bei den Authentifizierungsschemata Anonymous und HTTP Basic muss der Client Credentials-Flow explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter, der einen AuthenticationType von ClientCredentials.

Siehe OAuth 2.0-Clientanmeldeinformationsfluss für die vollständige Konfiguration.

OAuth 2.0-Fluss für die Kennwortanmeldeinformationen des Ressourcenbesitzers

Umgesetzt von App Builder bietet der OAuth 2.0-Flow „Ressourcenbesitzer-Passwort-Anmeldeinformationen“ eine Authentifizierung auf Clientebene, ähnlich einem Dienstkonto. In diesem Flow werden die OAuth-Ressourcenbesitzer-Anmeldeinformationen gegen ein OAuth-Zugriffstoken ausgetauscht.

Anders als bei den Authentifizierungsschemata „Anonymous“ und „HTTP Basic“ muss der OAuth-Flow „Ressourcenbesitzer-Passwort-Anmeldeinformationen“ explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter, der einen AuthenticationType von ResourceOwnerPasswordCredentials.

Siehe OAuth 2.0-Ressourcenbesitzer-Passwort-Anmeldeinformationen-Flow für die vollständige Konfiguration.

OAuth 2.0 JSON Web-Token-Bearer-Token-Fluss

Der OAuth 2.0 JSON Web Token (JWT) Bearer Token-Flow bietet Authentifizierung auf Benutzerebene. In diesem Flow werden JWTs gegen OAuth-Zugriffstoken ausgetauscht. Im Gegensatz zu den Authentifizierungsschemata Anonymous und HTTP Basic muss der JWT Bearer Token-Flow explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter, der einen AuthenticationType von Jwt.

Siehe OAuth 2.0 JSON Web Token Bearer Token Flow für die vollständige Konfiguration.