Salesforce Sicherheitsanbieter im Jitterbit App Builder

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

• Autorisierungscode
• SAML 2.0-Bearer-Assertion
• JWT-Bearer-Token

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 der SAML 2.0 Bearer Assertion-Berechtigung legt der Salesforce Anbieter standardmäßig die folgenden Eigenschaften fest:

• Aussteller: Standardmäßig die Clientkennung (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 Clientkennung (client_id).

Bekannte Probleme und Einschränkungen

Aktualisierungstokensynchronisierung

Salesforce verwaltet nur die vorherigen vier Aktualisierungstoken. In der Praxis bedeutet dies, dass für jede App Builder Instanz eine andere verbundene App erforderlich ist. Andernfalls ruft jede App Builder Instanz 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 vor der Anmeldung bei der zweiten Instanz von dieser abmelden. Andernfalls überspringt Salesforce den Anmeldevorgang. Anders ausgedrückt: 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 SAML Bearer Assertion- oder JWT Bearer Token-Berechtigungen erfordert Salesforce eine vorherige Autorisierung. In der Praxis bedeutet dies, dass sich Benutzer einmalig mit der Autorisierungscode-Berechtigung 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 vor der Authentifizierung mit SAML SSO mit OAuth anzumelden, verfehlt den Zweck.
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, beschreiben sie den Aussteller 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, lehnt App Builder die SAML -Assertion ab.