Autenticazione SAML federata con SharePoint 2010 e Azure Access Control Service Parte 2
Articolo originale pubblicato sabato 7 maggio 2011
Nel primo post di questa serie (https://blogs.technet.com/b/speschka/archive/2011/05/05/federated-saml-authentication-with-sharepoint-2010-and-azure-access-control-service-part-1.aspx) ho descritto come configurare SharePoint per stabilire una relazione di trust direttamente con Azure Access Control Service (ACS) e utilizzarla per l'autenticazione federata tra ADFS, Yahoo, Google e Windows Live e quindi per l'accesso a SharePoint. Nella seconda parte utilizzerò uno scenario analogo, ma in realtà implementato quasi a ritroso rispetto alla parte 1. Imposteremo una tipica relazione di trust tra SharePoint e ADFS, configurando però ACS come provider di identità in ADFS, utilizzandolo quindi per il reindirizzamento all'account di accesso e di nuovo a SharePoint. Ritengo che molti più utenti hanno familiarità con questo tipo di trust, per lo meno tra SharePoint e ADFS, e penso che per il momento si inserisca perfettamente in uno scenario più comune utilizzato da molte società.
Come ho fatto nella parte 1, non descriverò tutti i particolari relativi all'impostazione e alla configurazione di ACS, lasciando questo compito ai team responsabili. Per la parte 2 ecco quindi la procedura per stabilire la connessione:
1. Impostare l'applicazione Web e la raccolta siti di SharePoint, configurandole con ADFS.
-
- Prima di tutto è necessario creare SPTrustedIdentityTokenIssuer, un relying party in ADFS e un'applicazione Web e una raccolta siti di SharePoint. Accertarsi di poter accedere al sito con le credenziali di ADFS. Informazioni molto dettagliate sull'esecuzione di questa operazione sono disponibili in uno dei miei post precedenti all'indirizzo https://blogs.msdn.com/b/sharepoint_it/archive/2010/11/24/configurazione-end-to-end-di-sharepoint-2010-e-adfs-v2.aspx.
2. Aprire la pagina Access Control Management
-
- Accedere al portale di gestione di Windows Azure. Fare clic sul menu Service Bus, Access Control e Caching nel riquadro sinistro. Fare clic su Access Control nella parte superiore del riquadro sinistro (sotto AppFabric), fare clic sul proprio spazio dei nomi nel riquadro destro, quindi fare clic sul pulsante Access Control Service nella parte Manage della barra multifunzione. Verrà visualizzata la pagina Access Control Management.
3. Creare una relazione di trust tra ADFS e ACS
-
- In questo passaggio configureremo ACS come provider di identità in ADFS. Per iniziare, accedere al server ADFS e aprire la console AD FS 2.0.
- Passare al nodo AD FS 2.0, Trust Relationships, Claims Provider Trusts e fare clic sul collegamento Add Claims Provider Trust nel riquadro destro.
- Fare clic sul pulsante Start per avviare la procedura guidata.
- Utilizzare l'opzione predefinita per importare i dati relativi al relying party pubblicati online. L'URL che è necessario utilizzare si trova nel portale di gestione di ACS. Tornare al browser in cui è aperto il portale e fare clic sul collegamento Application Integration nel menu Trust relationships nel riquadro sinistro.
- Copiare l'URL visualizzato per WS-Federation Metadata e incollarlo nella casella di modifica Federation metadata address (host name or URL) nella procedura guidata ADFS wizard, quindi fare clic sul pulsante Next.
- Digitare un nome visualizzato nel campo Display name e facoltativamente completare il campo Notes, quindi fare clic sul pulsante Next.
- Lasciare selezionata l'opzione predefinita che consente a tutti gli utenti di accedere al provider di identità, quindi fare clic sul pulsante Next.
- Fare clic sul pulsante Next per creare il provider di identità e lasciare selezionata la casella per aprire la finestra di dialogo Rules Editor. Il resto di questa sezione sarà molto simile a quanto ho descritto in questo post https://blogs.technet.com/b/speschka/archive/2010/11/24/configuring-adfs-trusts-for-multiple-identity-providers-with-sharepoint-2010.aspx sull'impostazione di una relazione di trust tra due server ADFS:
È necessario creare regole per passare tutte le attestazioni ottenute dal server ADFS IP. Per ogni attestazione che si desidera inviare a SharePoint, nella finestra di dialogo delle regole eseguire le operazioni seguenti:
- Fare clic su Add Rule.
- Selezionare Pass Through o Filter an Incoming Claim nell'elenco a discesa Claim Rule Template e fare clic sul pulsante Next.
- Assegnare un nome di attestazione (nel campo Claim Name). Sarà utile includere eventualmente il nome dell'attestazione da passare. Nell'elenco a discesa Incoming Claim Type selezionare il tipo di attestazione che si desidera passare, ad esempio l'indirizzo di posta elettronica. Di solito lascio selezionata l'opzione predefinita Pass through all claim values, ma in caso di regole business diverse, selezionare l'opzione appropriata e fare clic sul pulsante Finish. Se si sceglie di passare tutti i valori di attestazione, in ADFS verrà visualizzata una finestra di dialogo di avviso.
Dopo aver aggiunto le attestazioni pass-through per ogni attestazione necessaria in SharePoint, è possibile chiudere la finestra di dialogo delle regole. Per l'ultima parte della configurazione di ADFS è necessario individuare il relying party di SharePoint. Fare clic nella finestra di dialogo Edit Claim Rules. Per ogni regola attestazioni pass-through creata nel passaggio precedente è necessario aggiungere ANCHE una regola attestazioni pass-through per il relying party di SharePoint. Questa impostazione consentirà il flusso delle attestazioni da ACS ad ADFS tramite il provider di attestazioni attendibile e fino a SharePoint tramite il relying party attendibile.
La configurazione di ADFS è così completata.
4. Aggiungere ADFS come relying party in ACS
-
- Tornare al browser in cui è aperto il portale e fare clic sul collegamento Relying party applications nel menu Trust relationships nel riquadro sinistro.
- Fare clic sul collegamento Add.
- Completare la sezione Relying Party Application Settings.
- Immettere un nome visualizzato in Display name, ad esempio “Da ADFS ad ACS”.
- Utilizzare la modalità predefinita di Enter settings manually.
- Nella casella di modifica Realm immettere un'area di autenticazione inviata da ADFS con la richiesta. In ADFS è disponibile in elenco specifico di aree di autenticazione che vengono inviate in caso di reindirizzamento a un altro provider di identità, quindi NON utilizzare l'area di autenticazione utilizzata per la creazione di SPTrustedIdentityTokenIssuer in SharePoint. Consiglio invece di utilizzare https://yourFullyQualifiedAdfsServerName/adfs/services/trust.
- Come URL restituito utilizzare https:// yourFullyQualifiedAdfsServerName /adfs/ls/.
- L'impostazione nell'elenco a discesa Token format può essere SAML 2.0 o 1.1. Poiché il token viene inviato ad ADFS e non a SharePoint, e ADFS supporta i token SAML 2.0, non è necessario scorrere l'elenco fino a SAML 1.1 come lo sarebbe invece per connettersi direttamente a SharePoint.
- È possibile impostare Token lifetime (secs) su qualsiasi valore. Il valore predefinito è 10 minuti. Io l'ho impostato su 3600 che corrisponde a un'ora.
- Completare la sezione Authentication Settings.
- È possibile selezionare tutti i provider di identità, a meno che in precedenza sia stato aggiunto lo stesso server ADFS come provider di identità (operazione effettuata se è stata seguita la procedura descritta nel primo post di questa serie). In questo caso è possibile selezionare tutto eccetto il provider di identità che punta allo stesso server ADFS che verrà impostato come relying party.
- In Rule groups suggerisco, per brevità, di seguire le indicazioni relative ai gruppi di regole che ho spiegato nella parte 1 oppure, se è stata completata la parte 1, selezionare semplicemente quel gruppo di regole dall'elenco.
- In Token Signing Settings è possibile lasciare selezionata l'opzione predefinita, ovvero Use service namespace certificate (standard).
Fare clic sul pulsante Save per salvare le modifiche e creare il relying party.
A questo punto dovrebbe essere possibile accedere al sito di SharePoint tramite ADFS o ACS. Occorre tuttavia tenere presente che ADFS registrerà un cookie per ricordare il provider di identità utilizzato per ultimo. Da quel momento in avanti non verrà più richiesto il provider di identità, a meno che si utilizzi una finestra InPrivate Browsing in Internet Explorer (evidenzio questo particolare perché spesso viene dimenticato, generando confusione). Ecco come appare, ad esempio, la pagina di accesso la prima volta che si viene reindirizzati al server ADFS o se si utilizza una sessione InPrivate Browsing:
Tutto il resto funziona come descritto nella parte 1 di questa serie, inclusa la limitazione sull'utilizzo di un indirizzo di posta elettronica per Windows Live ID, quindi non pubblico di nuovo le schermate perché sono praticamente identiche. Con questa serie completa dovrebbe essere possibile integrare correttamente ADFS, ACS e tutti i provider di identità supportati da ACS nell'ambiente SharePoint 2010.
Questo è un post di blog localizzato. L'articolo originale è disponibile in Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 2