Provedor de Segurança - Salesforce¶

O provedor de segurança Salesforce habilita a autenticação e autorização do Salesforce. Ele é fundamentalmente um provedor de segurança OAuth 2.0, suportando as seguintes concessões:

• Código de autorização
• Afirmação do portador SAML 2.0
• Token do Portador JWT

Configuração¶

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

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

Padrões¶

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

• • Endpoint de autorização*: https://login.salesforce.com/services/oauth2/authorize
• • Endpoint do token*: https://login.salesforce.com/services/oauth2/token

Asserção de Portadora SAML 2.0¶

Ao usar a concessão SAML 2.0 Bearer Assertion, o provedor do Salesforce usará as seguintes propriedades como padrão:

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

Token Portador JWT¶

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

• Emissor: O padrão é o identificador do cliente (client_id).

Problemas e Limitações Conhecidos¶

Atualizar Sincronização de Token¶

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

Várias Instâncias do Salesforce¶

É possível configurar várias instâncias do Salesforce. App Builder manterá um conjunto separado de tokens de segurança para cada instância. No entanto, o usuário terá que efetuar login em cada instância pelo menos uma vez. Se o usuário já tiver efetuado login em uma instância, ele deverá efetuar logout dessa instância antes de efetuar login na segunda. Caso contrário, o Salesforce pulará o processo de login. Em outras palavras, quando o usuário tenta efetuar login na segunda instância, o Salesforce pode efetuar login automaticamente na primeira instância.

Autorização Prévia¶

Ao usar as concessões SAML Bearer Assertion ou JWT Bearer Token, o Salesforce exige uma autorização prévia. Na prática, isso significa que os usuários devem se autenticar uma vez usando a concessão Authorization Code.

Fonte de Asserção SAML¶

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

1. O Salesforce exige uma autorização prévia (veja acima). Forçar os usuários a fazer login com OAuth antes de autenticar com SAML SSO anula o propósito.
2. O Salesforce espera que o Issuer 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) SSO SAML possam ser configurados para gerar uma asserção SAML com um Issuer arbitrário, eles podem descrever o Issuer como urn:oasis:names:tc:SAML:2.0:nameid-format:entity. Esse formato descreve um URI. Como a Consumer Key não pode ser analisada como um URI, App Builder rejeita a afirmação SAML.