OData Sicherheitsanbieter im Jitterbit App Builder
Der OData Sicherheitsanbieter authentifiziert Anforderungen an eine OData Datenquelle. 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 die Kennwortanmeldeinformationen des Ressourcenbesitzers.
- OAuth 2.0 JSON Web Token Bearer-Flow.
- OAuth 2.0 SAML 2.0 Bearer Assertion-Flow.
Anonyme Authentifizierung
Die anonyme Authentifizierung wird standardmäßig verwendet, wenn keine Anmeldeinformationen angegeben und kein anderer Authentifizierungstyp ausgewählt ist. Die anonyme Authentifizierung erfordert keine Konfiguration. Sie kann jedoch explizit aktiviert werden, indem die Datenquelle einem Sicherheitsanbieter mit dem Authentifizierungstyp „AuthenticationType“ zugeordnet wird. Anonymous.
Siehe Anonyme HTTP-Authentifizierung für die vollständige Konfiguration.
HTTP-Basisauthentifizierung
Die von App Builder implementierte HTTP-Basisauthentifizierung ist eine Art Dienstkonto. Das bedeutet, dass sich alle App Builder-Benutzer mit denselben Anmeldeinformationen authentifizieren. Die Anmeldeinformationen (Benutzername und Kennwort) werden auf Datenquellenebene definiert.
Die HTTP-Basisauthentifizierung wird auf eine von zwei Arten aktiviert:
- Implizit. Anmeldeinformationen werden auf Datenquellenebene definiert und die Datenquelle ist keinem Sicherheitsanbieter zugeordnet.
- Explizit. Anmeldeinformationen werden auf Datenquellenebene definiert und die Datenquelle ist mit einem Sicherheitsanbieter verknüpft, der einen AuthenticationType von
Basic.
Siehe HTTP-Basisauthentifizierung für die vollständige Konfiguration.
OAuth 2.0-Autorisierungscodefluss
Der OAuth 2.0-Autorisierungscode-Flow ermöglicht die Authentifizierung auf Benutzerebene. Dabei werden Autorisierungscodes gegen OAuth-Zugriffstoken ausgetauscht.
Im Gegensatz zu den Authentifizierungsschemata „Anonymous“ und „HTTP Basic“ muss der Autorisierungscode-Flow explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter mit dem Authentifizierungstyp „AuthenticationType“ von AuthorizationCode.
Der OAuth-Autorisierungscode-Flow arbeitet außerdem mit einem OAuth-Sicherheitsanbieter zusammen. Der OAuth-Sicherheitsanbieter ist für die Benutzerautorisierung 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 mit einem 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-Anmeldedaten-Flow ermöglicht eine Authentifizierung auf Clientebene, ähnlich einem Dienstkonto. Dabei werden die OAuth-Client-Anmeldedaten gegen ein OAuth-Zugriffstoken ausgetauscht.
Im Gegensatz zu den Authentifizierungsschemata „Anonymous“ und „HTTP Basic“ muss der Client-Anmeldedaten-Flow explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter mit dem Authentifizierungstyp „AuthenticationType“ von ClientCredentials.
Siehe OAuth 2.0-Client-Anmeldeinformationen für die vollständige Konfiguration.
OAuth 2.0-Fluss für die Kennwortanmeldeinformationen des Ressourcenbesitzers
Der OAuth 2.0-Flow „Ressourcenbesitzer-Passwort-Anmeldeinformationen“ von App Builder ermöglicht eine Authentifizierung auf Clientebene, ähnlich einem Dienstkonto. In diesem Flow werden die OAuth-Ressourcenbesitzer-Anmeldeinformationen gegen ein OAuth-Zugriffstoken ausgetauscht.
Im Gegensatz zu den Authentifizierungsschemata „Anonymous“ und „HTTP Basic“ muss der OAuth-Fluss für die Kennwortanmeldeinformationen des Ressourcenbesitzers explizit aktiviert werden. Dies geschieht durch die Verknüpfung einer Datenquelle mit einem Sicherheitsanbieter mit dem AuthenticationType von ResourceOwnerPasswordCredentials.
Siehe OAuth 2.0 Ressourcenbesitzer-Passwort-Anmeldeinformationen für die vollständige Konfiguration.
OAuth 2.0 JSON Web-Token-Bearer-Token-Flow
Der OAuth 2.0 JSON Web Token (JWT) Bearer Token Flow ermöglicht die 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 mit dem Authentifizierungstyp Jwt.
Siehe OAuth 2.0 JSON Web Token Bearer Token Flow für die vollständige Konfiguration.