Zum Inhalt springen

Salesforce Sicherheitsanbieter im Jitterbit App Builder

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

Konfiguration

Siehe OAuth-Sicherheitsanbieter zur Konfiguration.

Beachten Sie, dass Salesforce auf die Clientkennung verweist (client_id) und geheim (client_secret) als „Consumer Key“ und „Consumer Secret“.

Standardeinstellungen

Der Salesforce Sicherheitsanbieter verwendet standardmäßig die folgenden Endpoints:

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

SAML 2.0-Träger-Assertion

Bei Verwendung des SAML 2.0 Bearer Assertion-Grants weist der Salesforce Anbieter standardmäßig die folgenden Eigenschaften zu:

  • Aussteller: Standardmäßig die Kundenkennung (client_id).
  • Publikum: https://login.salesforce.com
  • Empfänger: https://login.salesforce.com/services/oauth2/token

JWT-Trägertoken

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

  • Aussteller: Standardmäßig die Kundenkennung (client_id).

Bekannte Probleme und Einschränkungen

Aktualisierungstoken-Synchronisierung

Salesforce verwaltet nur die vorherigen 4 Aktualisierungstoken. In der Praxis bedeutet dies, dass für jeden eine andere Connected App erforderlich ist. App Builder Instanz. Andernfalls App Builder Instanz ruft ein separates Aktualisierungstoken ab, wodurch möglicherweise ein von einer anderen Instanz verwendetes Aktualisierungstoken ungültig wird.

Mehrere Salesforce Instanzen

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

Vorherige Genehmigung

Bei Verwendung der Berechtigungen SAML Bearer Assertion oder JWT Bearer Token erfordert Salesforce eine vorherige Autorisierung. In der Praxis bedeutet dies, dass sich Benutzer einmal mit der Berechtigung „Authorization Code“ authentifizieren müssen.

SAML Assertion-Quelle

Der Salesforce-Sicherheitsanbieter kann keine SAML Assertionen von einem SAML Single Sign-On (SSO)-Anbieter beziehen. Dafür gibt es zwei Gründe:

  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 Herausgeber der SAML Assertion mit dem Consumer Key des verbundenen Clients übereinstimmt. Consumer Keys sind undurchsichtige Blobs. Obwohl einige SAML SSO Identity Provider (IdPs) so konfiguriert werden können, dass sie eine SAML Assertion mit einem beliebigen Herausgeber generieren, beschreiben sie den Herausgeber möglicherweise als urn:oasis:names:tc:SAML:2.0:nameid-format:entity. Dieses Format beschreibt eine URI. Da der Consumer Key nicht als URI analysiert werden kann, App Builder lehnt die SAML Assertion ab.