Configurazione di SSO per Salesforce utilizzando Microsoft AD FS come provider di identità
Consentire agli utenti di accedere da un ambiente Microsoft a un'organizzazione Salesforce utilizzando Microsoft Active Directory Federation Services (AD FS) 2.0. Microsoft AD FS svolge la funzione di provider di identità per l'autenticazione Single Sign-On.
Versioni (Edition) richieste
| Disponibile in: Lightning Experience e Salesforce Classic |
| Disponibile in: Enterprise Edition, Performance Edition, Unlimited Edition e Developer Edition |
Microsoft AD FS 2.0 supporta il protocollo SAML 2.0. Quando AD FS 2.0 è impostato come provider di identità Salesforce, gli utenti possono accedere a Salesforce utilizzando Single Sign-On (SSO).
l'endpoint Userinfo AD FS restituisce solo l'attestazione subject come da specifica degli standard OpenID, senza fornire altre attestazioni richieste tramite l'endpoint UserInfo. Se occorrono altre attestazioni nel token ID, utilizzare un token ID personalizzato.
Quando si configura AD FS 2.0 per l'utilizzo con Salesforce, è consigliabile selezionare Reindirizzamento HTTP nelle impostazioni del Single Sign-On di Salesforce in Binding della richiesta avviata dal fornitore di servizi. Questa impostazione migliora l'interoperabilità con i dispositivi basati su iOS.Prerequisiti
Per configurare AD FS 2.0 come provider di identità Salesforce, è necessario disporre di:
- Microsoft Windows Server 2008 R2 Enterprise o Datacenter Edition. Se si sta configurando un ambiente per una valutazione, è possibile scaricare una versione di prova dall'Area download Microsoft.
- Microsoft Active Directory Federation Services 2.0.
Nota Windows Server 2008 R2 include AD FS 1.0, che non supporta SAML 2.0. Per questa ragione, scaricare il pacchetto AD FS 2.0 RTW ('release to web'). - Un'organizzazione Salesforce. Per provarlo, si può utilizzare un ambiente Developer Edition.
Panoramica
SAML 2.0 definisce i ruoli per le parti interessate dall'accesso SSO. Un utente esegue l'autenticazione nel provider di identità (IdP), in questo caso AD FS 2.0. L'utente potrà quindi accedere a una risorsa di uno o più fornitori di servizi (SP) senza eseguire l'accesso a ogni fornitore. Il fornitore di servizi è in questo caso un'organizzazione Salesforce.
L'immagine illustra un accesso a Salesforce avviato dal provider di identità.
- L'utente esegue l'autenticazione nel server AD FS utilizzando l'autenticazione integrata di Windows (token Kerberos su HTTP) e richiede l'accesso a Salesforce. (1)
- AD FS restituisce un'asserzione SAML al browser dell'utente. (2)
- Il browser invia l'asserzione a Salesforce che esegue l'accesso dell'utente. (3)
Di seguito sono elencati i passaggi generali della procedura di creazione di una distribuzione di prova.
- Installare Microsoft AD FS 2.0.
- Configurare AD FS e l'ambiente Salesforce.
- Testare la configurazione.
- Cercare e risolvere eventuali problemi di implementazione.
Installazione del software
- Installare innanzitutto Windows Server 2008 R2.
Nota Il server AD FS deve essere membro di un dominio Active Directory. Se si sta creando un'installazione di prova, il server AD FS può essere il controller di dominio. Questa configurazione, tuttavia, non è consigliata per gli ambienti di produzione. - Creare un nome DNS descrittivo per AD FS, ad esempio adfs.testzone.local e fare in modo che punti al server AD FS 2.0.
- Scaricare e installare AD FS 2.0. In questo passaggio vengono installati ulteriori componenti Windows necessari, ad esempio IIS.
- In Gestione IIS, creare un certificato SSL per il nome DNS descrittivo. Se si dispone di un kit risorse IIS 6.0, è possibile utilizzare SelfSSL per creare un certificato autofirmato.
- Eseguire la procedura guidata di configurazione del server AD FS.
- Creare un servizio di federazione.
- Selezionare Server autonomo.
- Selezionare il certificato creato per il nome DNS descrittivo.
- Se si verifica un errore durante la registrazione di un nome dell'entità di servizio (SPN) da parte del programma di installazione, creare manualmente un SPN Kerberos per il nome DNS. L'SPN consente il corretto funzionamento dell'autenticazione integrata di Windows tra il browser e l'istanza di IIS di AD FS:
1 setspn -a HOST/adfs.testzone.local testzone\ADFSSVR012 setspn -a HOST/adfs testzone\ADFSSVR01Per ulteriori informazioni sugli SPN Kerberos, vedere Active Directory and Kerberos SPNs Made Easy.
Configurazione di Salesforce
Per creare una federazione tra due parti, è necessario stabilire una relazione di trust tramite lo scambio di metadati. I metadati per l'istanza AD FS 2.0 vengono immessi nella configurazione Salesforce. I metadati Salesforce vengono scaricati come file XML che può essere utilizzato da AD FS 2.0.
Configurazione di SAML 2.0
Nello snap-in MMC di AD FS 2.0, selezionare il nodo dei certificati e fare doppio clic sul certificato per la firma di token per visualizzarlo. Fare clic sulla scheda Dettagli e quindi selezionare Copia su file. Salvare il certificato in formato DER.
Nel server AD FS, cercare l'URL dei metadati della federazione nell'MMC AD FS a Servizio | Endpoint | Metadati | Tipo:Metadati federazione . Nell'esempio, l'URL è https://adfs.testzone.local/FederationMetadata/2007-06/FederationMetadata.xml.
Copiare il valore dell'attributo entityID. Nell'esempio, il valore è http://adfs.testzone.local.
In Salesforce, da Imposta, immettere Single Sign-On nella casella Ricerca veloce e selezionare Impostazioni Single Sign-On. Selezionare SAML abilitato e fare clic sull'opzione per creare una configurazione SSO SAML.
Configurare le impostazioni.
- Nome—Immettere un nome per le impostazioni SSO SAML.
- Versione SAML—Questa impostazione è impostata su 2.0.
- Emittente—Immettere il valore entityID.
- Certificato provider identità—Cercare e selezionare il certificato per la firma di token esportato in precedenza.
- Certificato di firma della richiesta—Selezionare un certificato autofirmato creato in precedenza. (Vedere la procedura per la generazione di un certificato autofirmato).
- Metodo di firma della richiesta—Impostare questa opzione su RSA-SHA-1.
- Tipo di identità SAML—Per l'accesso di un utente, è possibile confrontare il nome utente Salesforce o l'ID federazione. Se si confronta l'ID federazione, è necessario che venga specificato nel profilo di ogni utente. Per il test, selezionare l'ID federazione. Se gli utenti utilizzano l'indirizzo email come nome utente Salesforce, in una distribuzione di produzione è possibile passare all'utilizzo del nome utente.
- Posizione identità SAML—Per l'accesso dell'utente, è possibile utilizzare l'attributo NameID dell'asserzione SAML o un altro attributo. È possibile utilizzare NameID poiché AD FS popola NameID nell'asserzione SAML.
- Binding della richiesta avviata dal provider di servizi—È consigliabile scegliere Reindirizzamento HTTP.
- URL di accesso provider identità—Immettere l'URL dell'endpoint SAML di AD FS al quale Salesforce invia le richieste SAML per l'accesso avviato dal fornitore di servizi.
Nota Includere la barra alla fine dell'URL.L'URL è disponibile nell'MMC di AD FS all'indirizzo Endpoint | Emissione token | Tipo: SAML 2.0/WS-Federation . Nell'esempio, l'URL è https://adfs.testzone.local/adfs/ls/.
- URL di disconnessione personalizzato—È possibile configurare un URL a cui viene indirizzato l'utente dopo la disconnessione, ad esempio http://intranet.mycompany.com/.
- ID entità—Questa impostazione specifica la modalità con cui il provider di identità di AD FS identifica il fornitore di servizi di Salesforce. Per abilitare SSO avviato dal fornitore di servizi, immettere l'ID entità dal dominio personale configurato.
Salvare le impostazioni e scaricare il file XML dei metadati.
Configurazione di AD FS 2.0
Con i metadati di Salesforce disponibili, creare il lato AD FS della relazione di trust. Aprire lo snap-in MMC di AD FS 2.0 e aggiungere una nuova "attendibilità componente".
- Seleziona origine dati—Importare i dati su un componente da un file. Cercare il file XML scaricato da Salesforce.
- Specifica nome visualizzato—Assegnare al componente un nome visualizzato, ad esempio Salesforce Test.
- Scegli regole di autorizzazione rilascio—Consentire a tutti gli utenti di accedere al componente.
- Apri finestra di dialogo Modifica regole attestazione—Selezionare questa opzione.
Nell'editor delle regole di attestazione, fare clic sulla scheda Regole di trasformazione rilascio. Aggiungere una regola utilizzando il Modello di regola attestazione impostato su Inviare attributi LDAP come attestazioni.
- Nome regola attestazione—Per il test, impostare l'attributo User-Principal-Name come NameID e chiamare la regola Send UPN as NameID. In produzione, viene solitamente inviato l'indirizzo email dell'utente o l'ID dipendente. È importante utilizzare un attributo con un valore che non cambia nel tempo poiché qualsiasi modifica annulla la validità di SSO per l'utente.
- Attributo LDAP—Selezionare Nome entità utente.
- Tipo di attestazione in uscita—Selezionare ID nome.
Accesso avviato dal fornitore di servizi
In un accesso avviato dal provider di identità viene in genere impostato un link nella Intranet aziendale su cui gli utenti fanno clic per accedere a Salesforce. L'accesso avviato dal fornitore di servizi si verifica quando un utente fa clic su un link diretto di Salesforce.
Se è stato configurato un ID entità di dominio personale nelle impostazioni SAML di Salesforce (ad esempio, https://testinfo-developer-edition.my.salesforce.com), gli utenti possono passare agli URL del dominio. Gli utenti vengono quindi reindirizzati ad AD FS per l'autenticazione.
Quando è configurato un ID entità di Dominio personale nelle impostazioni SAML di Salesforce (ad esempio, https://testinfo-developer-edition.my.salesforce.com), gli utenti possono passare agli URL di quel dominio. Gli utenti vengono quindi reindirizzati ad AD FS per l'autenticazione.
Per garantire il funzionamento di un accesso avviato dal fornitore di servizi, impostare il parametro dell'algoritmo hash di sicurezza di AD FS su SHA-1. Salesforce utilizza SHA-1 per la firma delle richieste SAML, mentre AD FS utilizza SHA-256 per impostazione predefinita.
Il parametro SHA viene impostato nelle proprietà di trust AD FS per il componente Salesforce nella scheda Avanzate.
Se il parametro non viene impostato, viene visualizzato un messaggio nel registro eventi di AD FS.
Event ID: 378SAML request is not signed with expected signature algorithm. SAML request is signed with signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 . Expected signature algorithm is http://www.w3.org/2000/09/xmldsig#rsa-sha1Esecuzione di test
È ora possibile impostare l'ID federazione di un utente Salesforce sull'UPN dell'account utente di AD e testare l'accesso.

Per l'accesso avviato dal fornitore di servizi, se è stato configurato un ID entità del dominio personale, passare direttamente all'URL, ad esempio https://testinfo-developer-edition.my.salesforce.com.
Per l'accesso avviato dal provider di identità, utilizzare l'URL di accesso di AD FS e specificare il parametro loginToRp come ID entità SAML di Salesforce, ad esempio https://adfs.testzone.local/adfs/ls/idpinitiatedsignon.aspx?loginToRp=https://saml.salesforce.com.
In entrambi i casi, il browser segue una serie di reindirizzamenti che terminano con l'accesso all'applicazione in Salesforce. Se si verifica un errore di accesso di Salesforce, utilizzare il Validatore asserzione SAML nella pagina di configurazione di SSO di Salesforce. Vengono visualizzati i risultati dell'ultimo accesso SAML non riuscito.

Ï
Se si verifica un errore di AD FS, controllare i registri di AD FS in Server Manager\Diagnostics\Applications and Services Logs\AD FS 2.0\Admin. È anche disponibile un post del blog MSDN sulla diagnostica di AD FS 2.0.
Se è stato configurato un ID entità del dominio personale, l'accesso avviato dal fornitore di servizi può essere utilizzato per i deep link. Impostare il segnalibro di un link da Salesforce e quindi disconnettersi. Ricaricare il browser e selezionare il segnalibro. Viene eseguito il reindirizzamento al provider di identità, viene eseguita l'autenticazione e quindi il reindirizzamento al link del segnalibro.
Problemi comuni e risoluzione dei problemi
- Nell'ID federazione viene fatta distinzione tra maiuscole e minuscole.
Se l'identità federata corrisponde all'indirizzo email dell'organizzazione, inserirlo esattamente come viene inviato da AD FS. In caso contrario, Salesforce non troverà un utente corrispondente.
Non è possibile creare una regola di attestazione personalizzata per normalizzare le maiuscole e le minuscole dell'attributo LDAP prima di inviarlo poiché il linguaggio delle attestazioni ha una sola sostituzione di espressione regolare di base.
- L'asserzione è scaduta.
Le asserzioni con timestamp precedente di oltre 5 minuti vengono rifiutate.
Nota Salesforce ammette 3 minuti di differenza oraria. Per questa ragione, un'asserzione può avere superato il timestamp da 8 minuti oppure avere ancora 3 minuti di validità. Inoltre, un'asserzione scade in base a quanto specifica il periodo di validità, che può essere di meno 5 minuti.Assicurarsi che l'orologio di sistema del server AD FS sia sincronizzato con un'origine di orario Internet affidabile utilizzando il protocollo NTP (Network Time Protocol).
- Non è possibile accedere a Salesforce.
Se un errore impedisce l'accesso a Salesforce tramite SSO, è possibile eseguire l'accesso con nome utente e password. Aggiungere ?login alla parte finale dell'URL di accesso, per esempio https://login.salesforce.com/?login. Dopo aver eseguito l'accesso, è possibile disabilitare SSO se necessario durante la ricerca e la risoluzione del problema.

