Autenticazione SAML federata con SharePoint 2010 e Azure Access Control Service Parte 1

Článek
06/27/2011

Articolo originale pubblicato venerdì 6 maggio 2011

NOTA: come al solito la formattazione in questo sito non è delle migliori, quindi consiglio di scaricare il documento di Word allegato a questo post per un'esperienza di lettura migliore.

Di recente ho avuto modo di osservare Windows Azure Access Control Service (ACS) con un certo interesse, in particolare pensando alle diverse opzioni di integrazione. Si parla sempre molto dell'autenticazione basata sulle attestazioni in SharePoint 2010 e sull'integrazione di ADFS, Windows Live, Facebook e così via. ACS, noto anche come AppFabric ACS ai puristi di Azure e agli addetti al marketing, è piuttosto interessante, in quando include "connettori" predefiniti per questi provider di identità comuni. Se si imposta uno spazio dei nomi ACS, che può essere considerato come un account con connettori e impostazioni di configurazione, viene semplificata e ottimizzata la connettività per ADFS 2.0, Windows Live, Yahoo, Google e Facebook. Ho quindi pensato, come programmatore, che ci dovesse essere qualcosa di interessante ed ho quindi deciso di dare uno sguardo più approfondito da due diverse angolazioni. In questo post descriverò la prima.

Per questo scenario desideravo semplicemente stabilire una relazione di trust tra SharePoint 2010 e ACS ed essere in grado di utilizzare gli account ADFS, Windows Live, Yahoo e Google per l'autenticazione e l'accesso al mio sito di SharePoint. Non ho incluso Facebook perché il social computing non rientra nella mia sfera di interesse (questo blog è ciò che più vi si avvicina), quindi non dispongo di un account Facebook o Twitter, poiché in realtà non sono interessato a condividere frequentemente informazioni senza uno scopopreciso. NON spiegherò come si ottiene un account Windows Azure, si crea uno spazio dei nomi Access Control Service, si gestisce ACS e così via, perché il team di Windows Azure avrà sicuramente pubblicato enormi quantità di informazioni in proposito e non intendo provare a reinventarne di nuove.

Intendo invece descrivere il processo di impostazione delle diverse relazioni di trust, dei certificati e della configurazione necessari per fare in modo che tutto interagisca senza problemi. Alla fine includerò alcune schermate delle mie sessioni di accesso con identità diverse per ognuno di questi provider. Di seguito è riportata la procedura per connettersi:

Aprire la pagina Access Control Management
1. 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.
Aggiungere un provider di identità per ADFS
1. Fare clic su Identity providers nel menu Trust relationships nel riquadro sinistro.
2. Fare clic sul collegamento Add.
3. Il pulsante di opzione WS-Federation identity provider dovrebbe essere selezionato per impostazione predefinita. In caso contrario, selezionarlo. È l'opzione utilizzata per ADFS 2.0. Fare clic sul pulsante Next.
4. Completare la sezione Identity Provider Settings.
  1. Completare il campo Display name, indicando ad esempio “My ADFS Server”.
  2. Per WS-Federation metadata, se il server ADFS viene esposto a Internet sarà sufficiente indicare l'URL dell'endpoint dei metadati della federazione. Per impostazione predefinita, si trova in https://ServerAdfs.com/MetadatiFederazione/2007-06/MetadatiFederazione.xml. Se il server ADFS non viene esposto a Internet, aprire l'URL dell'endpoint nel browser locale. Passare al browser e salvare la pagina nel file system locale come file con estensione XML, quindi in Identity Provider Settings in ACS fare clic sul pulsante di opzione accanto alla casella di modifica File e utilizzare il pulsante Browse per individuare il file con estensione xml dei metadati della federazione appena salvato.

È in linea di massima tutto ciò che serve per creare il provider di identità in ACS.

3. Aggiungere un relying party per SharePoint

1. A questo punto è necessario aggiungere SharePoint come relying party di ACS, esattamente come quanto si configurano insieme SharePoint e ADFS. Iniziare facendo clic sul collegamento Relying party applications nel menu Trust relationships nel riquadro sinistro.
2. Fare clic sul collegamento Add.
3. Completare la sezione Relying Party Application Settings.
  1. Immettere un nome visualizzato in Display name, ad esempio “SharePoint 2010”.
  2. Utilizzare la modalità predefinita di Enter settings manually.
  3. Nella casella di modifica Realm immettere un'area di autenticazione e salvarla in quanto verrà utilizzata di nuovo per creare SPTrustedIdentityTokenIssuer in SharePoint. Ai fini di questo esempio, l'area di autenticazione sarà “urn:sharepoint:acs”.
  4. Come URL restituito utilizzare lo stesso formato applicato per l'impostazione di SharePoint come relying party in ADFS: https://NomeSito/_trust/.
  5. Nell'elenco a discesa Token format dovrebbe essere visualizzato SAML 1.1.
  6. È possibile impostare Token lifetime (secs) su qualsiasi valore. Il valore predefinito è 10 minuti. Io l'ho impostato su 3600 che corrisponde a un'ora.
4. Completare la sezione Authentication Settings.
  1. Selezionare tutte le caselle di controllo in Identity providers. Dovrebbe essere visualizzato il provider di identità ADFS creato nel passaggio precedente.
  2. In Rule groups lasciare selezionato il valore predefinito, ovvero Create new rule group.
5. In Token Signing Settings è possibile lasciare selezionata l'opzione predefinita, ovvero Use service namespace certificate (standard).
6. Fare clic sul pulsante Save per salvare le modifiche e creare il relying party

4. Creare le regole per il relying party

1. Supponendo che in precedenza non sia già stato creato un set di regole in ACS, ne creeremo uno nuovo. In caso fosse già presente un gruppo che si desidera riutilizzare, nel passaggio precedente era necessario selezionare semplicemente il gruppo o i gruppi da utilizzare con il relying party, anziché l'opzione predefinita Create new rule group. Poiché tuttavia stiamo creando un nuovo gruppo, fare clic sul collegamento Rule groups nel menu Trust relationships nel riquadro sinistro.
2. Dovrebbe essere visualizzato un gruppo di regole denominato “Default Rule Group per il nome del relying party specificato”. Fare clic sul collegamento relativo al nome del gruppo di regole.
3. In effetti, la cosa più semplice a questo punto è fare semplicemente clic sul collegamento Generate. Verrà creato automaticamente un set di regole che fondamentalmente enumera tutte le attestazioni inviate da ogni provider di identità e quindi verrà creata per ognuno una regola che passa tale valore di attestazione con lo stesso tipo al relying party.
4. Nella pagina Generate Rules selezionare la casella accanto a ogni provider di identità e fare clic sul pulsante Generate. Verranno create le regole che ho descritto in precedenza. Al termine si verrà reindirizzati alla pagina Edit Rule Group in cui saranno elencate tutte le regole. In molti casi ciò sarebbe sufficiente, ma qui siamo in presenza di un'anomalia che è necessario considerare. In SharePoint utilizzeremo l'indirizzo di posta elettronica come attestazione di identità. È piuttosto curioso che tutti i provider di identità inviino l'indirizzo di posta elettronica (e dispongano di regole che definiscono questo comportamento) tranne Windows Live. Di conseguenza, per questo esempio simulerò questa parte di Windows Live, ovvero utilizzerò la sola attestazione fornita (nameidentifier) e creerò una regola che la utilizzi, ma come attestazione di posta elettronica. Questo è solo un espediente per fare in modo che questo ambiente dimostrativo venga eseguito con il minor numero possibile di parti in movimento, che già sono molte. Ora aggiungeremo questa regola finale.
5. Fare clic sul collegamento Add.
6. Nell'elenco a discesa Identity Provider selezionare Windows Live I.
7. Nella sezione Input claim type fare clic sul pulsante di opzione accanto a Select type. Windows Live ID supporta un solo tipo di attestazione (nameidentifier) che è già selezionato.
8. Scorrere la sezione Output claim type e fare clic sul pulsante di opzione accanto a Select type.
9. Nell'elenco a discesa individuare https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress e selezionarlo.
10. Immettere una descrizione, se lo si desidera, quindi fare clic sul pulsante Save per salvare le modifiche e creare la regola.
11. Si verrà reindirizzati alla pagina Edit Rule Group. Fare quindi clic sul pulsante Save per salvare tutte le modifiche. La configurazione di ACS è così completata, ma il browser dovrà rimanere aperto perché è necessario ottenere alcune informazioni aggiuntive quando si creano e si configurano gli altri componenti.

5. Creare un relying party per ACS in ADFS

1. Mentre ADFS è un provider di identità per ACS, ACS è un relying party per ADFS. Ciò significa che è necessario configurare un relying party in ADFS, in modo che quando ACS reindirizza una richiesta di autenticazione ad ADFS venga stabilita una relazione di trust per consentire ad ADFS di rispondere. Accedere al server ADFS e aprire la console AD FS 2.0 Management.
2. Passare al nodo AD FS 2.0, Trust Relationships, Relying Party Trusts e fare clic sul collegamento Add Relying Party Trust nel riquadro destro.
3. Fare clic sul pulsante Start per avviare la procedura guidata.
4. 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.
5. 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.
6. Digitare un nome visualizzato nel campo Display name e facoltativamente completare il campo Notes, quindi fare clic sul pulsante Next.
7. Lasciare selezionata l'opzione predefinita che consente a tutti gli utenti di accedere al relying party, quindi fare clic sul pulsante Next.
8. Fare clic sul pulsante Next per creare il relying party.
9. Dopo aver creato il relying party, aprire Rules Editor in ADFS per creare nuove regole per passare i valori di attestazione ad ACS.
10. Con la scheda Issuance Transform Rules selezionata, fare clic sul pulsante Add Rule.
11. Lasciare selezionato il modello predefinito Send LDAP Attributes as Claims e fare clic sul pulsante Next.
12. Completare il resto dei dettagli relativi alla regola:
  1. Digitare un nome per la regola attestazioni.
  2. Nell'elenco a discesa Attribute store selezionare Active Director.
  3. Nella sezione Mapping of LDAP attributes mappare
    1. LDAP attribute E-Mail-Addresses a Outgoing Claim Type E-Mail Address
    2. LDAP attribute Token-Groups – Unqualified Names a Outgoing Claim Type Role
  4. Fare clic sul pulsante Finish per salvare la regola. A questo punto la configurazione di ADFS è completata.

6. Configurare la relazione di trust di SharePoint con ACS

1. Questo processo in più passaggi inizia con la richiesta di un certificato per la firma di token da ACS. Poiché il certificato è incluso nel file FederationMetadata.xml, possiamo recuperarlo e salvarlo localmente sul server di SharePoint, dove apriremo un browser e la pagina Access Control Management, come ho spiegato in precedenza.
2. Fare clic sul collegamento Application Integration nel menu Trust relationships nel riquadro sinistro, copiare l'URL visualizzato per WS-Federation Metadata e incollarlo nel browser. Il file ACS FederationMetadata.xml verrà visualizzato nel browser.
3. Individuare la sezione con un aspetto simile al seguente (è la seconda sezione principale dall'inizio della pagina):

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

Copiare i dati dell'elemento X509Certificate e incollarli nel Blocco note. Salvare il file con estensione CER (con codifica ANSI). Ai fini di questo post, supponiamo che il file verrà denominato C:\AcsTokenSigning.cer. Si tratta del certificato per la firma di token per ACS.

1. Aggiungere il certificato per la firma di token di ACS all'elenco delle autorità radice attendibili di SharePoint. È possibile eseguire questa operazione seguendo le istruzioni descritte in https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx oppure è possibile aggiungere il certificato con PowerShell come indicato di seguito:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")

New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert

1. Il passaggio successivo consiste nel creare un nuovo SPTrustedIdentityTokenIssuer, che ho descritto in diverse posizioni. È possibile utilizzare ad esempio https://blogs.msdn.com/b/sharepoint_it/archive/2010/11/24/configurazione-end-to-end-di-sharepoint-2010-e-adfs-v2.aspx come punto di partenza (è sufficiente scorrere il testo fino alle informazioni riportate dopo la sezione AFTER setting up ADFS). Alcuni aspetti da ricordare:
  1. Sia name che nameidentifier sono tipi di attestazioni riservati in SharePoint, quindi anche se nameidentifier è la sola attestazione comune tra i provider di identità standard in ACS, non è un'opzione disponibile per l'attestazione di identità. Consiglio invece di utilizzare per ora solo l'indirizzo di posta elettronica e di aggiungere le regole appropriate in ACS, come descritto.
  2. Il parametro SignInUrl per New-SPTrustedIdentityTokenIssuer deve puntare all'istanza di ACS, ad esempio, https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation. Per individuarla, osservare il relying party impostato in ADFS per ACS. Aprire la finestra di dialogo delle proprietà del relying party, fare clic sulla scheda Endpoints e utilizzare l'URL visualizzato per WS-Federation Passive Endpoint for the POST binding (dovrebbe essere il solo).
2. L'ultimo passaggio prevede la creazione dell'applicazione Web, la relativa configurazione per l'utilizzo dell'autenticazione basata sulle attestazioni e la creazione di SPTrustedIdentityTokenIssuer per ACS. Si creerà infine una raccolta siti nell'applicazione Web e si procedereà all'esecuzione dei test.

A questo punto dovrebbe essere possibile visitare il sito e verificarne il funzionamento. Tenere presente che è necessario configurare l'amministratore della raccolta siti utilizzando uno degli indirizzi di posta elettronica che verrà restituito da uno dei provider di identità, in modo da poter accedere al sito. Dopo avere effettuato l'accesso, sarà possibile aggiungere, come al solito, gli indirizzi di posta elettronica o le attestazioni relative ai ruoli dei provider ai gruppi di SharePoint.

La sola limitazione da ricordare, per ora, riguarda Windows Live ID. Come ho detto in questo post, per Windows Live non è in realtà disponibile un indirizzo di posta elettronica valido, quindi è necessario aggiungere ciò che viene definito il PUID del gruppo di SharePoint. Ai fini dei test, il modo più semplice per ottenerlo è di effettuare l'accesso con il Windows Live ID, quindi raggiungere la pagina di SharePoint in cui è indicato che si è connessi come “foo” e in cui viene negato l'accesso. A quel punto è possibile copiare il PUID, accedere come utente admin, aggiungere il PUID al gruppo di SharePoint e procedere. Non ho verificato che tipo di opzioni di directory sono disponibili per il Windows Live ID, anche se è probabile che non ve ne siano. Questo è tuttavia solo l'inizio, quindi possiamo continuare in base a questo modello di prova. Riporto quindi di seguito alcune schermate che mostrano l'accesso al mio sito utilizzando ognuno dei provider di identità impostati:

Pagina di accesso

ADFS

Google

Yahoo

Windows Live ID

Questo è un post di blog localizzato. L'articolo originale è disponibile in Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

Sdílet prostřednictvím

Autenticazione SAML federata con SharePoint 2010 e Azure Access Control Service Parte 1

Další materiály