Partager via

Alla fine UN modo UTILE per attuare la federazione con Windows Live e SharePoint 2010 mediante OAuth e SAML

  • Article

Articolo originale pubblicato giovedì 1° marzo 2012

Molti in passato mi hanno parlato della possibilità di attuare la federazione di SharePoint con Windows Live. A prima vista, può sembrare una buona idea, in quanto Windows Live ha milioni di utenti che eseguono tutti l'accesso con il loro indirizzo di posta elettronica (un elemento molto utilizzato come attestazione di identità), è un grande servizio scalabile e sono disponibili varie istruzioni su come procedere direttamente o tramite il Servizio di controllo di accesso. Allora perché dovrei essere così reticente a utilizzarlo con SharePoint? Beh, chi fra voi ha provato in precedenza già lo sa: quando si attua la federazione con Windows Live, non viene mai restituito l'indirizzo di posta elettronica di un utente come attestazione. Si ottiene infatti uno speciale identificatore di Windows Live noto come PUID. Per quanto ne so, "PUID" è l'acronimo di "Practically GUID" (praticamente GUID) perché ne ha quasi lo stesso aspetto e la stessa utilità. 

Se ad esempio si ATTUA la federazione con Windows Live, in che modo è possibile aggiungere un utente a un sito? È necessario ottenerne il PUID e quindi aggiungerlo a un livello di autorizzazione o a un gruppo di SharePoint. Ma chi conosce veramente qualcuno che sappia il proprio PUID? E anche nel caso in cui magicamente si conoscesse il PUID, quanto può essere utile se si sta tentando di concedere agli utenti i diritti per raccolte siti diverse? Come si potrebbe essere individuati in un elenco di PUID o anche in un controllo Selezione utenti? Naturalmente no! Ecco perché la mia frustrazione aumenta.

In realtà pensavo che avremmo potuto prendere in considerazione una soluzione più utopica con il Servizio di controllo di accesso. Tale servizio consente subito di connettersi a diversi provider di identità, come Windows Live, Google, Yahoo e Facebook. Con Facebook viene addirittura utilizzato OAuth per l'autenticazione e viene restituito un set di attestazioni SAML. Grandioso! Allora perché non accade lo stesso con Windows Live? Quest'ultimo ora supporta OAuth, quindi sembra possibile che prima o poi qualcosa cambierà. Nel frattempo i tecnici che si occupano del Servizio di controllo di accesso ancora non sono arrivati in nostro soccorso. Ed ecco perciò che torniamo al punto focale di questo preambolo. Alla fine ho deciso di scriverne uno personalmente ed è questo lo scopo del presente post.

Vi chiederete perché dobbiamo occuparci di OAuth. Beh, a differenza del PUID che si ottiene attuando la federazione direttamente con Windows Live, il supporto di OAuth in Windows Live consente di ottenere MOLTE più informazioni relative all'utente, incluso il relativo indirizzo di posta elettronica. Fondamentalmente, è quindi necessario procedere come segue:

  1. Scrivere un provider di identità personalizzato con Windows Identity Foundation (WIF).
  2. Quando una persona viene reindirizzata al nostro servizio token di sicurezza, se non è stata ancora autenticata, viene reindirizzata di nuovo a Windows Live. A tale scopo, è necessario creare "un'applicazione" con Windows Live, ma illustrerò più avanti questa attività.
  3. Dopo essere stata autenticata, la persona viene reindirizzata ancora al servizio token di sicurezza personalizzato. A questo punto, nella stringa di query è incluso un token di esecuzione dell'accesso che può essere scambiato con un token di accesso.
  4. Il servizio token di sicurezza quindi effettua un'altra richiesta a Windows Live con il codice di esecuzione dell'accesso e richiede un token di accesso.
  5. Quando ottiene il token di accesso, invia una richiesta finale a Windows Live con tale token e richiede alcune informazioni di base relative all'utente. Più avanti fornirò i relativi dettagli.
  6. Dopo aver ricevuto da Windows Live le informazioni sull'utente, è possibile utilizzare il servizio token di sicurezza personalizzato per creare un set di attestazioni SAML per l'utente e inserirvi le informazioni relative a quest'ultimo. È quindi necessario effettuare il reindirizzamento all'applicazione che ha richiesto l'autenticazione, in modo che possa utilizzare i token SAML. In questo caso specifico, ho testato il mio servizio token di sicurezza con un'applicazione ASP.NET standard e con un'applicazione Web di SharePoint 2010.

Tutto il codice sorgente è allegato a questo post, ma vi sono comunque alcune operazioni di configurazione da eseguire e sarà necessario ricompilare l'applicazione con il relativo ID e la chiave privata che si ottengono da Windows Live. Si tratta comunque solo di copiare e incollare, in quanto non è necessario scrivere codice per procedere. Ma ora vediamo cosa è necessario fare per poterlo utilizzare.

Creare un certificato per la firma di token

Sarà necessario creare un certificato da utilizzare per firmare i token SAML. A tale scopo, non è richiesto un certificato speciale, tranne per il fatto che si deve verificare di disporre della relativa chiave privata. Per quanto mi riguarda, nel mio dominio è installato Servizi certificati, pertanto ho solo aperto Gestione IIS e selezionato l'opzione per creare un certificato di dominio. Ho seguito la procedura guidata e ho avuto rapidamente un nuovo certificato completo della chiave privata. Per questo progetto ho creato un certificato denominato livevbtoys. 

Come spiegherò nella prossima sezione, quando le richieste arrivano inizialmente al servizio token di sicurezza, l'utente è anonimo. Per poter utilizzare tale certificato per firmare i token SAML, è quindi necessario concedere al processo IIS l'accesso alla chiave privata del certificato. Quando una richiesta anonima giunge nel processo IIS, l'identità è Servizio di rete. Per concedergli i diritti per la chiave, è necessario eseguire le operazioni seguenti:

  1. Avviare MMC.
  2. Aggiungere lo snap-in Certificati. Selezionare l'archivio Computer relativo al computer locale.
  3. Aprire l'archivio dei certificati personali e individuare il certificato creato per la firma dei token SAML. Se il certificato è stato creato come spiegato in precedenza, si troverà in tale archivio per impostazione predefinita. Se è stato creato in un altro modo, potrebbe essere necessario aggiungerlo a tale archivio.
  4. Fare clic con il pulsante destro del mouse sul certificato e scegliere l'opzione per la gestione delle chiavi private.
  5. Nell'elenco degli utenti che dispongono dei diritti per le chiavi aggiungere Servizio di rete e assegnargli i diritti di lettura.

Se queste operazioni non vengono eseguite correttamente, al momento di eseguire l'applicazione potrebbe venire visualizzato un errore di keyset non esistente. Tale errore indica semplicemente che il processo IIS non disponeva di diritti sufficienti per la chiave privata e che quindi non ha potuto utilizzarla per firmare il token SAML.

Installare l'applicazione e gli assembly necessari

Installare l'applicazione in questo caso significa in realtà creare un'applicazione ASP.NET in IIS, copiarne il codice e verificare che sia installata la versione più recente di WIF. Dopo che è configurata e funzionante in un server, è possibile aggiungere uno o più server per essere certi di disporre di una soluzione con tolleranza di errore. Illustrerò comunque solo la configurazione necessaria in un singolo server.

Non entrerò nel merito di come creare un'applicazione ASP.NET in IIS. È infatti possibile utilizzare Visual Studio, Gestione IIS e così via. 

NOTA: se si utilizza il codice fornito qui e si apre il progetto in Visual Studio, risulterà che l'host o il sito non esiste. Questo è dovuto al fatto che viene utilizzato il nome del mio server. Il modo più semplice per risolvere il problema è quello di modificare manualmente il file WindowsLiveOauthSts.sln e sostituire i valori https in esso contenuti con quelli effettivamente presenti nel proprio ambiente.

Dopo avere creato l'applicazione, vi sono ancora alcune operazioni da eseguire.

  1. Aggiungere PassiveSTS.aspx come documento predefinito in Gestione IIS per il sito Web del servizio token di sicurezza.
  2. Modificare le impostazioni di autenticazione dell'applicazione in IIS, in modo che siano disabilitati tutti i tipi di autenticazione tranne l'autenticazione anonima.
  3. Il servizio token di sicurezza deve essere eseguito su SSL, pertanto sarà necessario acquisire un certificato appropriato e aggiornare i binding nel server virtuale IIS in cui viene utilizzata l'applicazione del servizio token di sicurezza personalizzato.
  4. Ricordarsi di inserire l'identificazione digitale del certificato per la firma di token nell'attributo thumbprint dell'elemento add nella sezione trustedIssuers del file web.config della relying party (se NON si sta utilizzando SharePoint per il test). Se si utilizza la procedura guidata per l'aggiunta di un riferimento al servizio token di sicurezza in Visual Studio, l'operazione verrà eseguita automaticamente.

Queste sono tutte le operazioni di configurazione che è necessario eseguire in IIS.

Aggiornare e compilare il progetto del servizio token di sicurezza personalizzato

Nel file ZIP allegato è incluso un progetto di Visual Studio 2010 denominato WindowsLiveOauthSts. Dopo avere configurato IIS e aver aggiornato il file WindowsLiveOauthSts.sln come descritto in precedenza, si dovrebbe riuscire ad aprire il progetto in Visual Studio. Una delle prime operazioni da eseguire è aggiornare le costanti CLIENT_ID e CLIENT_SECRET nella classe PassiveSTS.aspx.cs. È possibile ottenerle quando si crea una nuova applicazione di Windows Live. Non spiegherò in dettaglio come procedere perché per Windows Live ci sono esperti in grado di fornire assistenza a tale proposito. Mi limiterò a indicare l'indirizzo a cui è possibile accedere per creare l'applicazione di Windows Live: https://manage.dev.live.com/Applications/Index?wa=wsignin1.0. Quando si crea l'applicazione, ricordarsi inoltre di impostare il dominio di reindirizzamento sull'indirizzo in cui il servizio token di sicurezza personalizzato è ospitato, ovvero https://myserver.foo.com.

Ora che si dispone dell'ID e della chiave privata, nell'applicazione è necessario aggiornare quanto segue:

  1. Aggiornare le costanti CLIENT_ID e CLIENT_SECRET nella classe PassiveSTS.aspx.cs.
  2. Nel file web.config aggiornare SigningCertificateName nella sezione appSettings. Non è indispensabile modificare l'impostazione IssuerName, ma è possibile farlo se lo si desidera.
  3. Aggiornare il certificato per la firma di token per il documento FederationMetadata.xml nel progetto del servizio token di sicurezza. Dopo avere selezionato il certificato desiderato, è possibile utilizzare l'applicazione test.exe inclusa in questo post per ottenere il valore stringa per il certificato. È necessario effettuarne la copia per sostituire i due valori di elemento X509Certificate in federationmetadata.xml.

È opportuno sottolineare un altro aspetto, ossia che nel file CustomSecurityTokenService.cs è possibile impostare su true una variabile denominata enableAppliesToValidation e quindi fornire un elenco degli URL che possono utilizzare tale servizio token di sicurezza personalizzato. Nel mio caso ho scelto di non applicare alcuna restrizione, pertanto la variabile è impostata su false. Se invece si desidera bloccare il servizio token di sicurezza personalizzato, apportare ora la modifica. Dopo aver effettuato tutte queste modifiche, è possibile ricompilare l'applicazione in modo che sia pronta per l'utilizzo.

Ho inoltre incluso un'applicazione ASP.NET di esempio che ho utilizzato per il testing mentre stavo compilando questa. È contenuta in un progetto denominato LiveRP. Senza entrare troppo nei dettagli, dirò solo che è disponibile per effettuare test. Ricordarsi solo di modificare l'identificazione digitale per il certificato per la firma di token del servizio token di sicurezza come descritto in precedenza.

Configurazione di SharePoint

A questo punto, tutto è configurato e dovrebbe funzionare per il servizio token di sicurezza personalizzato. L'unica operazione ancora da eseguire consiste nel creare una nuova autorità emittente SPTrustedIdentityTokenIssuer in SharePoint e nel configurare un'applicazione Web nuova o esistente per utilizzarla. Vi sono comunque alcuni aspetti da conoscere sulla configurazione di SPTrustedIdentityTokenIssuer. Riporto di seguito il codice PowerShell che ho utilizzato per creare la mia e quindi vi spiegherò tutto:

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

New-SPTrustedRootAuthority -Name "SPS Live Token Signing Certificate" -Certificate $cert

 

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/id" -IncomingClaimTypeDisplayName "WindowsLiveID" -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/full_name" -IncomingClaimTypeDisplayName "FullName" -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/first_name" -IncomingClaimTypeDisplayName "FirstName" -SameAsIncoming

$map5 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/last_name" -IncomingClaimTypeDisplayName "LastName" -SameAsIncoming

$map6 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/link" -IncomingClaimTypeDisplayName "Link" -SameAsIncoming

$map7 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/gender" -IncomingClaimTypeDisplayName "Gender" -SameAsIncoming

$map8 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/locale" -IncomingClaimTypeDisplayName "Locale" -SameAsIncoming

$map9 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/updated_time" -IncomingClaimTypeDisplayName "WindowsLiveLastUpdatedTime" -SameAsIncoming

$map10 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/account" -IncomingClaimTypeDisplayName "AccountName" -SameAsIncoming

$map11 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/accesstoken" -IncomingClaimTypeDisplayName "WindowsLiveAccessToken" -SameAsIncoming

$realm = "https://spslive.vbtoys.com/_trust/"

$ap = New-SPTrustedIdentityTokenIssuer -Name "SpsLive" -Description "Window Live oAuth Identity Provider for SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4,$map5,$map6,$map7,$map8,$map9,$map10,$map11 -SignInUrl "https://spr200.vbtoys.com/WindowsLiveOauthSts/PassiveSTS.aspx" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

Ecco gli aspetti da notare:

  1. Come spiegato in precedenza, ho creato un certificato denominato livevbtoys.cer per la firma dei token, quindi l'ho aggiunto al mio elenco SPTrustedRootAuthority e l'ho associato alla mia autorità emittente di token.
  2. Ho creato mapping per tutte le attestazioni restituite dal servizio token di sicurezza personalizzato. Come è possibile vedere, il risultato è DECISAMENTE MIGLIORE rispetto all'attuazione diretta della federazione con Windows Live. Un altro elemento da porre in evidenza è che includo qui come attestazione il token di accesso che ho ottenuto da Windows Live. Mentre funziona con Facebook, non l'ho testato e quindi non posso affermare con certezza se Windows Live mi consentirà o meno di riutilizzarlo. Ma forse questo sarà l'argomento di un prossimo post.
  3. Il valore $realm è estremamente importante. Deve puntare al sito radice dell'applicazione Web e includere la directory /_trust/. Se l'operazione non viene eseguita correttamente, SharePoint genererà 500 errori quando si verrà reindirizzati dopo l'autenticazione.
  4. Per la creazione dell'autorità emittente di token, il parametro –SignInUrl corrisponde all'URL assoluto della pagina PassiveSTS.aspx per il servizio token di sicurezza personalizzato.

Ecco fatto. Dopo questa preparazione, si utilizzeranno ancora la selezione utenti e i provider di attestazioni predefiniti, quindi non si disporrà di funzionalità di ricerca, come si può prevedere. È possibile concedere diritti agli utenti con gli indirizzi di posta elettronica utilizzati per eseguire l'accesso a Windows Live. Si potrebbe anzi estendere questo esempio e utilizzare anche il provider di attestazioni di Azure di cui ho scritto nel blog all'indirizzo seguente:  https://blogs.msdn.com/b/sharepoint_it/archive/2012/03/07/provider-di-attestazioni-personalizzate-azure-per-un-progetto-di-sharepoint-parte-1.aspx. Questo significa che si utilizzerà il servizio token di sicurezza per consentire l'autenticazione in Windows Live e ottenere alcune attestazioni SAML reali e che quindi si utilizzeranno il progetto del provider di attestazioni personalizzate di Azure per aggiungere tali utenti autenticati nell'archivio directory di Azure e la selezione utenti per selezionarli.

Le immagini valgono più delle parole. Ecco perciò la schermata che verrà visualizzata quando si esegue il primo accesso al sito di SharePoint e si esegue l'autenticazione in Windows Live:

Quando si esegue per la prima volta l'accesso, verrà richiesto se si accetta di condividere le proprie informazioni con l'applicazione del servizio token di sicurezza personalizzato. Nessun problema. Si tratta della procedura standard per le autorizzazioni OAuth. Di seguito è riportata la schermata che verrà visualizzata. I dati sono quelli che richiedo nel servizio token di sicurezza, ma voi potreste richiedere dati completamente diversi. È necessario solo fare riferimento a Windows Live OAuth SDK per vedere cosa modificare e come procedere:

Dopo aver accettato, si viene reindirizzati al sito di SharePoint. In questo esempio sto utilizzando la web part SharePoint Claims di cui ho scritto nel blog all'indirizzo seguente: https://blogs.technet.com/b/speschka/archive/2010/02/13/figuring-out-what-claims-you-have-in-sharepoint-2010.aspx. È possibile vedere tutte le attestazioni che ho ottenuto da Windows Live tramite OAuth e di cui ora dispongo come attestazioni SAML grazie al servizio token di sicurezza personalizzato, nonché il fatto che ho avuto accesso con il mio indirizzo di posta elettronica di Windows Live che ho creato per questo progetto (dal controllo di accesso nell'angolo in alto a destra):

 

Questo è un post di blog localizzato. L'articolo originale è disponibile in Finally A USEFUL Way to Federate With Windows Live and SharePoint 2010 Using OAuth and SAML.