Proveedor de seguridad de Salesforce en Jitterbit App Builder
El proveedor de seguridad de Salesforce habilita la autenticación y autorización de Salesforce. Es fundamentalmente un proveedor de seguridad OAuth 2.0, que admite los siguientes permisos:
Configuración
Consulte el proveedor de seguridad OAuth para la configuración.
Tenga en cuenta que Salesforce se refiere al identificador del cliente (client_id) y al secreto (client_secret) como la "clave del consumidor" y el "secreto del consumidor".
Valores predeterminados
El proveedor de seguridad de Salesforce establece los siguientes puntos finales por defecto:
- Punto final de autorización:
https://login.salesforce.com/services/oauth2/authorize - Punto final de token:
https://login.salesforce.com/services/oauth2/token
Afirmación portadora SAML 2.0
Al utilizar el permiso de Afirmación Portadora SAML 2.0, el proveedor de Salesforce establecerá por defecto las siguientes propiedades:
- Emisor: Se establece por defecto en el identificador del cliente (
client_id). - Audiencia:
https://login.salesforce.com - Destinatario:
https://login.salesforce.com/services/oauth2/token
Token portador JWT
Al utilizar el permiso de Token Portador JWT, el proveedor de Salesforce establecerá por defecto las siguientes propiedades:
- Emisor: Se establece por defecto en el identificador del cliente (
client_id).
Problemas y limitaciones conocidas
Sincronización de tokens de actualización
Salesforce solo mantiene los 4 tokens de actualización anteriores. Hablando prácticamente, 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 separado, lo que podría invalidar un token de actualización utilizado por otra instancia.
Múltiples instancias de Salesforce
Es posible configurar múltiples instancias de Salesforce. App Builder mantendrá un conjunto separado de tokens de seguridad para cada instancia. Sin embargo, el usuario deberá iniciar sesión en cada instancia al menos una vez. Si el usuario ya ha iniciado sesión en una instancia, debe cerrar sesión en esa instancia 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 puede iniciar sesión automáticamente en la primera instancia.
Autorización previa
Al utilizar ya sea la Afirmación de Portador SAML o los permisos de Token de Portador JWT, Salesforce requiere una autorización previa. En la práctica, esto significa que los usuarios deben autenticarse una vez utilizando el permiso de Código de Autorización.
Fuente de afirmación SAML
El proveedor de seguridad de Salesforce no puede obtener afirmaciones SAML de un proveedor de Inicio de Sesión Único (SSO) SAML. Hay dos razones para esto:
- Salesforce requiere una autorización previa (ver arriba). Obligar a los usuarios a iniciar sesión con OAuth antes de autenticarse con SAML SSO anula el propósito.
- Salesforce espera que el Emisor de la afirmación SAML coincida con la Clave de Consumidor del Cliente Conectado. Las Claves de Consumidor son blobs opacos. Aunque algunos Proveedores de Identidad (IdPs) SAML SSO pueden configurarse para generar una afirmación SAML con un Emisor arbitrario, pueden describir el Emisor como
urn:oasis:names:tc:SAML:2.0:nameid-format:entity. Ese formato describe un URI. Dado que la Clave de Consumidor no puede ser analizada como un URI, App Builder rechaza la afirmación SAML.