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-Identifier (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-Identifier (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-Identifier (client_id).

Bekannte Probleme und Einschränkungen

Synchronisierung des Refresh-Tokens

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

Mehrere Salesforce-Instanzen

Es ist möglich, mehrere Salesforce-Instanzen zu konfigurieren. Der App Builder verwaltet einen separaten Satz von Sicherheitstoken für jede Instanz. 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 Anmeldevorgang. 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 des SAML Bearer Assertion oder JWT Bearer Token Grants erfordert Salesforce eine vorherige Autorisierung. In der Praxis bedeutet dies, dass sich die Benutzer einmal mit dem Authorization Code Grant authentifizieren müssen.

SAML-Assertionsquelle

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.