Zum Inhalt springen

Salesforce-Sicherheitsanbieter in Jitterbit App Builder

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

Konfiguration

Siehe den OAuth-Sicherheitsanbieter für die Konfiguration.

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

Standardwerte

Der Salesforce-Sicherheitsanbieter setzt die folgenden Endpunkte als Standard:

  • Authorization Endpoint: https://login.salesforce.com/services/oauth2/authorize
  • Token Endpoint: https://login.salesforce.com/services/oauth2/token

SAML 2.0 Bearer Assertion

Bei Verwendung der SAML 2.0 Bearer Assertion-Gewährung setzt der Salesforce-Anbieter die folgenden Eigenschaften als Standard:

  • Issuer: Wird standardmäßig auf die Client-Kennung (client_id) gesetzt.
  • Audience: https://login.salesforce.com
  • Recipient: https://login.salesforce.com/services/oauth2/token

JWT Bearer Token

Bei Verwendung der JWT Bearer Token-Gewährung setzt der Salesforce-Anbieter die folgenden Eigenschaften als Standard:

  • Issuer: Wird standardmäßig auf die Client-Kennung (client_id) gesetzt.

Bekannte Probleme und Einschränkungen

Refresh-Token-Synchronisierung

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

Mehrere Salesforce-Instanzen

Es ist möglich, mehrere Salesforce-Instanzen zu konfigurieren. App Builder verwaltet für jede Instanz einen separaten Satz von Sicherheits-Tokens. Der Benutzer muss sich jedoch mindestens einmal bei jeder Instanz anmelden. Hat sich der Benutzer bereits bei einer Instanz angemeldet, muss er sich von dieser Instanz abmelden, bevor er sich bei der zweiten anmeldet. Andernfalls überspringt Salesforce den Anmeldeprozess. Mit anderen Worten: Wenn der Benutzer versucht, sich bei der zweiten Instanz anzumelden, kann Salesforce ihn automatisch bei der ersten Instanz anmelden.

Vorherige Autorisierung

Bei Verwendung der SAML Bearer Assertion- oder JWT Bearer Token-Gewährung erfordert Salesforce eine vorherige Autorisierung. In der Praxis bedeutet dies, dass sich Benutzer mindestens einmal mit der Authorization Code-Gewährung 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 mit OAuth anzumelden, bevor sie sich mit SAML SSO authentifizieren, verfehlt den Zweck.
  2. Salesforce erwartet, dass der Issuer der SAML-Assertion dem Consumer Key des verbundenen Clients entspricht. 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 Issuer generieren, können sie den Issuer als urn:oasis:names:tc:SAML:2.0:nameid-format:entity beschreiben. Dieses Format beschreibt einen URI. Da der Consumer Key nicht als URI analysiert werden kann, lehnt App Builder die SAML-Assertion ab.

Fehlerbehebung

Weitere Informationen zur Fehlerbehebung finden Sie in den folgenden Abschnitten im App Builder-Fehlerbehebungsleitfaden: