Proveedor de Seguridad: Salesforce

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

• Código de autorización
• Afirmación de portador SAML 2.0
• Token portador JWT

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 "clave del consumidor" y "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

Actualizar Sincronización de Token

Salesforce solo mantiene los 4 tokens de actualización anteriores. En términos prácticos, esto significa que se requiere una aplicación conectada diferente para cada uno. App Builder instancia. De lo contrario, cada App Builder la instancia recuperará un token de actualización independiente, lo que posiblemente invalidará un 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 el usuario ya ha iniciado sesión en una instancia, deberá 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 las concesiones SAML Bearer Assertion o JWT Bearer Token, Salesforce requiere una autorización previa. En la práctica, esto significa que los usuarios deben autenticarse una vez mediante la concesión de código de autorización.

Fuente de la Afirmación SAML

El proveedor de seguridad de Salesforce no puede obtener aserciones SAML de un proveedor de inicio de sesión único (SSO) SAML. Existen dos motivos para esto:

1. Salesforce requiere una autorización previa (ver arriba). Obligar a los usuarios a iniciar sesión con OAuth antes de autenticarse con SAML SSO es contraproducente.
2. 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 (IdP) de SSO SAML se pueden configurar para generar una afirmació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 afirmación SAML.