Zum Inhalt springen

Salesforce-Sicherheitsanbieter im Jitterbit App Builder

Der Salesforce-Sicherheitsanbieter ermöglicht die Authentifizierung und Autorisierung von Salesforce. Es handelt sich grundsätzlich um einen OAuth 2.0-Sicherheitsanbieter, der die folgenden Berechtigungen unterstützt:

Konfiguration

Siehe den OAuth-Sicherheitsanbieter für die Konfiguration.

Beachten Sie, dass Salesforce den Client-Identifikator (client_id) und das Geheimnis (client_secret) als "Consumer Key" und "Consumer Secret" bezeichnet.

Standardwerte

Der Salesforce-Sicherheitsanbieter verwendet standardmäßig die folgenden Endpunkte:

  • Autorisierungsendpunkt: https://login.salesforce.com/services/oauth2/authorize
  • Token-Endpunkt: https://login.salesforce.com/services/oauth2/token

SAML 2.0 Bearer Assertion

Bei Verwendung der SAML 2.0 Bearer Assertion-Berechtigung wird der Salesforce-Anbieter die folgenden Eigenschaften standardmäßig festlegen:

  • Aussteller: Standardmäßig der Client-Identifikator (client_id).
  • Zielgruppe: https://login.salesforce.com
  • Empfänger: https://login.salesforce.com/services/oauth2/token

JWT Bearer Token

Bei Verwendung der JWT Bearer Token-Berechtigung wird der Salesforce-Anbieter die folgenden Eigenschaften standardmäßig festlegen:

  • Aussteller: Standardmäßig der Client-Identifikator (client_id).

Bekannte Probleme und Einschränkungen

Synchronisierung des Aktualisierungstokens

Salesforce verwaltet nur die vorherigen 4 Aktualisierungstokens. Praktisch bedeutet dies, dass für jede App Builder-Instanz eine andere verbundene App erforderlich ist. Andernfalls wird jede App Builder-Instanz ein separates Aktualisierungstoken abrufen, was möglicherweise ein von einer anderen Instanz verwendetes Aktualisierungstoken ungültig macht.

Mehrere Salesforce-Instanzen

Es ist möglich, mehrere Salesforce-Instanzen zu konfigurieren. Der App Builder verwaltet für jede Instanz ein separates Set von Sicherheitstoken. Der Benutzer muss sich jedoch mindestens einmal in jede Instanz einloggen. Wenn der Benutzer bereits in einer Instanz eingeloggt ist, muss er sich von dieser Instanz abmelden, bevor er sich in die zweite einloggt. Andernfalls überspringt Salesforce den Anmeldeprozess. Mit anderen Worten, wenn der Benutzer versucht, sich in die zweite Instanz einzuloggen, kann Salesforce ihn automatisch in die erste Instanz einloggen.

Vorherige Autorisierung

Bei der Verwendung entweder der SAML-Bearer-Assertion oder der JWT-Bearer-Token-Berechtigungen erfordert Salesforce eine vorherige Autorisierung. In der Praxis bedeutet dies, dass sich die Benutzer einmal mit der Autorisierungscode-Berechtigung authentifizieren müssen.

SAML-Assertion-Quelle

Der Salesforce-Sicherheitsanbieter kann SAML-Assertions nicht von einem SAML Single Sign-On (SSO)-Anbieter beziehen. Es gibt zwei Gründe dafür:

  1. Salesforce erfordert eine vorherige Autorisierung (siehe oben). Benutzer zu zwingen, sich zuerst mit OAuth anzumelden, bevor sie sich mit SAML SSO authentifizieren, macht keinen Sinn.
  2. Salesforce erwartet, dass der Aussteller der SAML-Assertion mit dem Consumer Key des verbundenen Clients übereinstimmt. Consumer Keys sind undurchsichtige Blobs. Obwohl einige SAML SSO-Identitätsanbieter (IdPs) so konfiguriert werden können, dass sie eine SAML-Assertion mit einem beliebigen Aussteller generieren, können sie den Aussteller als urn:oasis:names:tc:SAML:2.0:nameid-format:entity beschreiben. Dieses Format beschreibt eine URI. Da der Consumer Key nicht als URI geparst werden kann, lehnt der App Builder die SAML-Assertion ab.