OData-Sicherheitsanbieter im Jitterbit App Builder

Der OData-Sicherheitsanbieter authentifiziert Anfragen, die an eine OData-Datenquelle gerichtet sind. Er unterstützt die folgenden Authentifizierungsmechanismen:

• Anonyme Authentifizierung.
• HTTP Basic Authentifizierung.
• OAuth 2.0 Autorisierungscode-Flow.
• OAuth 2.0 Client-Anmeldeinformationen-Flow.
• OAuth 2.0 Resource Owner Password Credentials-Flow.
• 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 bereitgestellt werden und kein anderer Authentifizierungstyp ausgewählt ist. Die anonyme Authentifizierung erfordert keine Konfiguration. Sie kann jedoch ausdrücklich aktiviert werden, indem die Datenquelle mit einem Sicherheitsanbieter verbunden wird, der einen AuthenticationType von Anonymous hat.

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

HTTP Basic Authentifizierung

Wie im App Builder implementiert, ist die HTTP Basic Authentifizierung eine Form von Dienstkonto, was bedeutet, dass alle App Builder-Benutzer mit denselben Anmeldeinformationen authentifiziert werden. Die Anmeldeinformationen (Benutzername und Passwort) werden auf der Ebene der Datenquelle definiert.

Die HTTP Basic Authentifizierung wird auf eine von zwei Arten aktiviert:

1. Implizit. Die Anmeldeinformationen werden auf der Ebene der Datenquelle definiert und die Datenquelle ist nicht mit einem Sicherheitsanbieter verbunden.
2. Explizit. Die Anmeldeinformationen werden auf der Ebene der Datenquelle definiert und die Datenquelle ist mit einem Sicherheitsanbieter verbunden, der einen AuthenticationType von Basic hat.

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

OAuth 2.0 Autorisierungscode-Flow

Die OAuth 2.0 Autorisierungscode-Flow bietet eine Authentifizierung auf Benutzerebene. In diesem Flow werden Autorisierungscodes gegen OAuth-Zugriffstoken eingetauscht.

Im Gegensatz zu den anonymen und HTTP Basic-Authentifizierungsschemata muss der Autorisierungscode-Flow ausdrücklich aktiviert werden. Dies geschieht, indem eine Datenquelle mit einem Sicherheitsanbieter verbunden wird, der einen AuthenticationType von AuthorizationCode hat.

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

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

OAuth 2.0 SAML 2.0 Träger-Assertion-Flow

Der OAuth 2.0 SAML 2.0 Träger-Assertion-Flow bietet eine Authentifizierung auf Benutzerebene. In diesem Flow werden SAML-Assertions gegen OAuth-Zugriffstoken eingetauscht.

Im Gegensatz zu den anonymen und HTTP Basic-Authentifizierungsschemata muss der SAML 2.0 Träger-Assertion-Flow ausdrücklich aktiviert werden. Dies geschieht, indem eine Datenquelle mit einem Sicherheitsanbieter verbunden wird, der einen AuthenticationType von Saml hat.

Siehe OAuth 2.0 SAML 2.0 Träger-Assertion-Flow für die vollständige Konfiguration.

OAuth 2.0 Client-Anmeldeinformationen-Flow

Der OAuth 2.0 Client-Anmeldeinformationen-Flow bietet eine Authentifizierung auf Client-Ebene, ähnlich einem Dienstkonto. In diesem Flow werden die OAuth-Client-Anmeldeinformationen gegen ein OAuth-Zugriffstoken eingetauscht.

Im Gegensatz zu den anonymen und HTTP Basic-Authentifizierungsschemata muss der Client-Anmeldeinformationen-Flow ausdrücklich aktiviert werden. Dies geschieht, indem eine Datenquelle mit einem Sicherheitsanbieter verbunden wird, der einen AuthenticationType von ClientCredentials hat.

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

OAuth 2.0 Resource Owner Passwort-Anmeldeinformationen-Flow

Als im App Builder implementiert, bietet der OAuth 2.0 Resource Owner Password Credentials-Flow eine clientseitige Authentifizierung, ähnlich einem Dienstkonto. In diesem Flow werden die OAuth-Ressourcenbesitzer-Anmeldeinformationen gegen ein OAuth-Zugriffstoken eingetauscht.

Im Gegensatz zu den anonymen und HTTP Basic-Authentifizierungsschemata muss der OAuth Resource Owner Password Credentials-Flow ausdrücklich aktiviert werden. Dies geschieht durch die Zuordnung einer Datenquelle zu einem Sicherheitsanbieter, der einen AuthenticationType von ResourceOwnerPasswordCredentials hat.

Siehe OAuth 2.0 Resource Owner Password Credentials-Flow 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 bietet eine benutzerspezifische Authentifizierung. In diesem Flow werden JWTs gegen OAuth-Zugriffstoken eingetauscht. Im Gegensatz zu den anonymen und HTTP Basic-Authentifizierungsschemata muss der JWT Bearer Token-Flow ausdrücklich aktiviert werden. Dies geschieht durch die Zuordnung einer Datenquelle zu einem Sicherheitsanbieter, der einen AuthenticationType von Jwt hat.

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