Ir para o conteúdo

Provedor de segurança do Salesforce no Jitterbit App Builder

O provedor de segurança do Salesforce permite a autenticação e autorização do Salesforce. Ele é fundamentalmente um provedor de segurança OAuth 2.0, suportando os seguintes tipos de concessão:

Configuração

Consulte o provedor de segurança OAuth para configuração.

Observe que o Salesforce se refere ao identificador do cliente (client_id) e ao segredo (client_secret) como "chave do consumidor" e "segredo do consumidor".

Padrões

O provedor de segurança do Salesforce define os seguintes endpoints padrão:

  • Endpoint de Autorização: https://login.salesforce.com/services/oauth2/authorize
  • Endpoint de Token: https://login.salesforce.com/services/oauth2/token

Aserção Bearer SAML 2.0

Ao usar a concessão de Aserção Bearer SAML 2.0, o provedor do Salesforce definirá as seguintes propriedades padrão:

  • Emissor: Padrão para o identificador do cliente (client_id).
  • Público: https://login.salesforce.com
  • Destinatário: https://login.salesforce.com/services/oauth2/token

Token Bearer JWT

Ao usar a concessão de Token Bearer JWT, o provedor do Salesforce definirá as seguintes propriedades padrão:

  • Emissor: Padrão para o identificador do cliente (client_id).

Problemas conhecidos e limitações

Sincronização de token de atualização

O Salesforce mantém apenas os 4 tokens de atualização anteriores. Praticamente, isso significa que um App Conectado diferente é necessário para cada instância do App Builder. Caso contrário, cada instância do App Builder recuperará um token de atualização separado, possivelmente invalidando um token de atualização usado por outra instância.

Múltiplas instâncias do Salesforce

É possível configurar múltiplas instâncias do Salesforce. O App Builder manterá um conjunto separado de tokens de segurança para cada instância. No entanto, o usuário terá que fazer login em cada instância pelo menos uma vez. Se o usuário já fez login em uma instância, ele deve sair dessa instância antes de fazer login na segunda. Caso contrário, o Salesforce pulará o processo de login. Em outras palavras, quando o usuário tentar fazer login na segunda instância, o Salesforce pode logá-lo automaticamente na primeira instância.

Autorização prévia

Ao usar a concessão de SAML Bearer Assertion ou JWT Bearer Token, o Salesforce requer uma autorização prévia. Na prática, isso significa que os usuários devem se autenticar uma vez usando a concessão de Código de Autorização.

Fonte da asserção SAML

O provedor de segurança do Salesforce não pode obter asserções SAML de um provedor de SSO (Single Sign-On) SAML. Existem duas razões para isso:

  1. O Salesforce requer uma autorização prévia (veja acima). Forçar os usuários a fazer login com OAuth antes de se autenticar com SAML SSO anula o propósito.
  2. O Salesforce espera que o Emissor da asserção SAML corresponda à Chave do Consumidor do Cliente Conectado. As Chaves do Consumidor são blobs opacos. Embora alguns Provedores de Identidade (IdPs) de SSO SAML possam ser configurados para gerar uma asserção SAML com um Emissor arbitrário, eles podem descrever o Emissor como urn:oasis:names:tc:SAML:2.0:nameid-format:entity. Esse formato descreve uma URI. Como a Chave do Consumidor não pode ser analisada como uma URI, o App Builder rejeita a asserção SAML.