Proveedor de seguridad de Salesforce en Jitterbit App Builder

El proveedor de seguridad de Salesforce permite la autenticación y autorización de Salesforce. Es fundamentalmente un proveedor de seguridad OAuth 2.0 que admite las siguientes concesiones:

Configuración

Consulte el proveedor de seguridad OAuth para la configuración.

Tenga en cuenta que Salesforce hace referencia al identificador del cliente (client_id) y secreto (client_secret) como la "clave del consumidor" y el "secreto del consumidor".

Valores predeterminados

El proveedor de seguridad de Salesforce establece de forma predeterminada los siguientes extremos:

- Extremo de autorización*: https://login.salesforce.com/services/oauth2/authorize
- Extremo del token*: https://login.salesforce.com/services/oauth2/token

Aserción de portador SAML 2.0

Al utilizar la concesión de aserción de portador SAML 2.0, el proveedor de Salesforce establecerá de forma predeterminada las siguientes propiedades:

Emisor: Por defecto es el identificador del cliente (client_id).
Audiencia: https://login.salesforce.com- Destinatario: https://login.salesforce.com/services/oauth2/token

Token portador JWT

Al utilizar la concesión de token de portador JWT, el proveedor de Salesforce establecerá de forma predeterminada las siguientes propiedades:

Emisor: Por defecto es el identificador del cliente (client_id).

Problemas y limitaciones conocidos

Sincronización del token de actualización

Salesforce solo mantiene los 4 tokens de actualización anteriores. En la práctica, esto significa que se requiere una aplicación conectada diferente para cada instancia de App Builder. De lo contrario, cada instancia de App Builder recuperará un token de actualización independiente, lo que podría invalidar el token de actualización utilizado por otra instancia.

Varias instancias de Salesforce

Es posible configurar varias instancias de Salesforce. App Builder mantendrá un conjunto independiente de tokens de seguridad para cada instancia. Sin embargo, el usuario deberá iniciar sesión en cada instancia al menos una vez. Si ya ha iniciado sesión en una instancia, deberá cerrarla antes de iniciar sesión en la segunda. De lo contrario, Salesforce omitirá el proceso de inicio de sesión. En otras palabras, cuando el usuario intente iniciar sesión en la segunda instancia, Salesforce podría iniciar sesión automáticamente en la primera.

Autorización previa

Al utilizar las autorizaciones de aserción de portador SAML o token de portador JWT, Salesforce requiere una autorización previa. En la práctica, esto significa que los usuarios deben autenticarse una vez mediante la autorización de código.

Fuente de aserción SAML

El proveedor de seguridad de Salesforce no puede obtener aserciones SAML de un proveedor de inicio de sesión único (SSO) SAML. Esto se debe a dos razones:

Salesforce requiere autorización previa (ver arriba). Obligar a los usuarios a iniciar sesión con OAuth antes de autenticarse con SAML SSO es contraproducente.
Salesforce espera que el emisor de la aserción SAML coincida con la clave de consumidor del cliente conectado. Las claves de consumidor son blobs opacos. Si bien algunos proveedores de identidad (IdP) de SSO SAML pueden configurarse para generar una aserción SAML con un emisor arbitrario, pueden describir al emisor como urn:oasis:names:tc:SAML:2.0:nameid-format:entity Ese formato describe una URI. Dado que la clave de consumidor no se puede analizar como una URI, App Builder rechaza la aserción SAML.