Impostazione di una relazione di trust OAuth tra farm in SharePoint 2013
Articolo originale pubblicato lunedì 23 luglio 2012
Una delle caratteristiche di SharePoint 2013 di cui si sentirà parlare spesso, e su cui potrei anche scrivere molto, è OAuth. In SharePoint 2013 OAuth consente di stabilire una relazione di trust tra due applicazioni allo scopo di definire l'identità di un'entità (utente o applicazione). In SharePoint le relazioni di trust OAuth verranno utilizzate tra SharePoint e applicazioni come Exchange e Lync, con ACS o singoli sviluppatori di applicazioni che utilizzano il nuovo modello di app cloud o anche tra due diverse farm di SharePoint per caratteristiche come l'indice remoto di SharePoint nella ricerca.
OAuth NON diventerà tuttavia un provider di autenticazione per gli utenti. Si continuerà a utilizzare New-SPTrustedIdentityTokenIssuer per creare queste relazioni di trust per i provider di identità. Per i trust OAuth abbiamo un nuovo cmdlet dal nome molto simile, New-SPTrustedSecurityTokenIssuer. Quando stabiliamo questo tipo di trust con un emittente di token di sicurezza lo chiamiamo trust S2S (Server to Server, da server a server). È consigliabile ricordare questo acronimo, perché verrà visto spesso in SharePoint 2013. In questo post parleremo di alcuni componenti richiesti per creare questo trust.
Vale innanzitutto la pena sottolineare che molte caratteristiche che richiedono un trust S2S lo stabiliranno automaticamente, ad esempio mediante attivazione. Oppure è possibile che i feature team forniscano uno script o un cmdlet di PowerShell da eseguire per creare il trust come parte dell'attivazione della caratteristica. In alcuni casi, tuttavia, non sarà necessario eseguire manualmente questa operazione, come illustreremo in questo post.
Innanzitutto è necessario decidere se utilizzare o meno SSL. In realtà, in SharePoint 2013 è necessario utilizzare SSL in molti casi. Il motivo è che il protocollo OAuth viene utilizzato in moltissimi scenari in SharePoint 2013, tramite il passaggio di un cookie con un token di accesso. Il token di accesso è simile a una chiave che apre la porta ai dati. È firmato da un certificato, quindi non può essere sottoposto a spoofing da un utente che crea un proprio token di accesso, ma è preferibile evitare di diffonderlo in testo non crittografato, perché in teoria qualcuno potrebbe acquisire il cookie e sottoporlo a un attacco di tipo replay per l'intera durata. SSL offre protezione dagli attacchi di questo tipo, allo stesso modo e per lo stesso motivo per cui questo protocollo viene utilizzato nei siti con autenticazione basata su moduli. Detto questo, esistono ancora dei motivi per cui si potrebbe scegliere di utilizzare HTTP per i siti, ad esempio negli ambienti di test o di sviluppo oppure se si utilizza esclusivamente una rete interna e non si prevedono rischi e così via. Non sta a me giudicare, il mio compito è solo quello di spiegare.
PASSAGGIO 1: Configurare il servizio token di sicurezza
Se non si utilizza SSL, è consigliabile specificare un paio di impostazioni nel servizio token di sicurezza di SharePoint. È possibile ottenere tutte le impostazioni di sicurezza di questo servizio utilizzando il cmdlet Get-SPSecurityTokenServiceConfig. È possibile stabilire una relazione di trust in due modi, con un certificato oppure utilizzando un nuovo endpoint di metadati OAuth disponibile in tutte le farm di SharePoint. L'utilizzo dell'endpoint di metadati rappresenta il modo più semplice, ma se questo endpoint non è protetto tramite SSL è necessario impostare su True la proprietà AllowMetadataOverHttp del servizio token di sicurezza di SharePoint. Se non si prevede di eseguire le app Web si SSL, è necessario impostare su True anche la proprietà AllowOAuthOverHttp. Di seguito è illustrato come impostare queste proprietà con PowerShell:
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp= $true
$c.Update()
PASSAGGIO 2: Creare il trust
Dopo aver configurato il servizio token di sicurezza come necessario, vediamo come stabilire la relazione di trust da una farm a un'altra. Come accennato in precedenza, tutte le farm di SharePoint includono un endpoint di metadati che verrà ora utilizzato per fornire le informazioni e il certificato per la firma del token di accesso. Questo endpoint di metadati si trova nel percorso /_layouts/15/metadata/json/1. Se si tenta di passare a questo endpoint in un browser verrà richiesto se si desidera salvarlo per esaminarlo. Aprendolo in Blocco note si scoprirà che si tratta di un semplice payload JSON che include l'identificatore del nome per il servizio token di sicurezza (chiamato "emittente"), oltre a una versione serializzata del certificato per la firma del token (descritto come "valore" per la chiave "x509certificate"). Esaminando ulteriormente i dati, si scoprirà che l'emittente è in realtà uguale a nomeservizio + "@" + valori dell'area di autenticazione e che corrisponde anche alla proprietà NameIdentifier del servizio token di sicurezza. Questa informazione è importante, per i motivi che illustreremo brevemente in seguito.
In questo esempio supponiamo che sia necessario che FARM_B consideri attendibili le chiamate provenienti da FARM_A, perché FARM_A utilizzerà FARM_B come indice remoto di SharePoint. Supponiamo inoltre che FARM_A includa un'applicazione Web all'indirizzo https://FARM_A. Per creare il trust dovremo eseguire il cmdlet New-SPTrustedSecurityTokenIssuer in un server di FARM_B, come indicato di seguito (illustrerò più avanti nel post perché utilizziamo la stringa che "$i = "):
$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description "descrizione FARM_A" -IsTrustBroker:$false -MetadataEndPoint "https://FARM_A/_layouts/15/metadata/json/1"
Supponiamo a questo punto di impostare un trust con una farm di soli servizi. Non vogliamo creare un'applicazione Web, una raccolta siti e un certificato SSL solo per poter creare un trust. Quindi possiamo utilizzare un altro metodo per stabilire la relazione di trust, mediante il cmdlet New-SPTrustedSecurityTokenIssuer. Nel secondo modulo è possibile fornire semplicemente il certificato per la firma del token e l'identificatore del nome. Il certificato per la firma del token si può ottenere come in SharePoint 2010: passare a un server della farm, eseguire MMC, aggiungere lo snap-in Certificati per il computer locale ed esaminare il nodo SharePoint…Certificati. Il primo certificato dell'elenco è quello che ci serve. Possiamo salvarlo nell'unità locale senza la chiave privata come file con estensione cer. Per stabilire il trust, è necessario disporre del certificato e dell'attributo NameIdentifier del servizio token di sicurezza, come descritto in precedenza. Ecco come appare il cmdlet in questo caso (si presuppone che il certificato del servizio token di sicurezza sia stato copiato in un file denominato C:\sts.cer in un server di FARM_B):
$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate "C:\sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "descrizione FARM_A" -IsTrustBroker:$false
PASSAGGIO 3: Impostare il certificato per la firma del token come attendibile
Così come per il cmdlet SPTrustedIdentityTokenIssuer, è necessario aggiungere il trust utilizzato per la firma dei token di OAuth all'elenco di autorità radice attendibili in SharePoint. Anche in questo caso, sono disponibili due opzioni. Se il trust viene creato mediante l'endpoint di metadati, è possibile stabilire il trust in questo modo:
New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint https://FARM_A/_layouts/15/metadata/json/1/rootcertificate
Altrimenti, è possibile crearlo e aggiungerlo all'elenco di autorità radice attendibili come in SharePoint 2010:
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\sts.cer")
New-SPTrustedRootAuthority -Name "Certificato CA radice per la firma di token" -Certificate $root
Per quanto riguarda i trust, a questo punto la procedura è completa. Il trust è stato stabilito ed è ora possibile utilizzarlo come base per creare nuove entità applicazioni. Il modo in cui verrà utilizzato dipende dall'applicazione stessa. Nel caso di un indice remoto di SharePoint descriverò ora come completare lo scenario.
PASSAGGIO 4: Creare un'entità app (esempio valido solo per l'indice remoto di SharePoint):
Questo processo è costituito da due passaggi: ottenere un'entità app e concedere i diritti. Ricordiamo che in questo scenario è necessario che FARM_B consideri attendibili le chiamate provenienti da FARM_A, perché eseguirà query per l'indice remoto di SharePoint. Quindi, per l'entità app è necessario ottenere un riferimento all'app Web in FARM_B, che verrà utilizzato da FARM_A. Dopo aver ottenuto questo riferimento, possiamo concedere i diritti di utilizzo a FARM_A.
Per ottenere un riferimento all'entità app, è possibile utilizzare il cmdlet come indicato di seguito:
$p = Get-SPAppPrincipal -Site https://FARM_B -NameIdentifier $i.NameId
IMPORTANTE: questa informazione è particolarmente importante, soprattutto per la versione beta di SharePoint 2013. È possibile che vengano visualizzati strani messaggi di errori in PowerShell quando si tenta di ottenere SPAppPrincipal. Ho scoperto che se la memoria disponibile nel server scende sotto il 5%, tutte le chiamate a WCF avranno esito negativo. Poiché il cmdlet di PowerShell chiama un endpoint di applicazione di servizio, ospitato come WCF, il cmdlet Get-SPAppPrincipal non viene eseguito correttamente quando la memoria disponibile è insufficiente. È possibile controllare il registro applicazioni del Visualizzatore eventi di Windows per verificare se è questa la causa del problema. A me è capitato diverse volte, quindi è possibile che succeda anche ad altri.
Come descritto in precedenza nel post, alla fine utilizziamo la variabile $i per ottenere l'attributo NameIdentifier del servizio token di sicurezza in FARM_A. Ora che abbiamo un riferimento all'entità app per l'app Web di FARM_B, possiamo concedere i diritti, in questo modo:
Set-SPAppPrincipalPermission -Site https://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl
Ecco fatto. Queste sono le opzioni e le metodologie per creare un trust OAuth tra due farm di SharePoint. Continueremo ad approfondire i vari modelli di utilizzo di OAuth e i relativi problemi di cui tenere conto nel corso del tempo in questo blog.
Questo è un post di blog localizzato. L'articolo originale è disponibile in Setting Up an oAuth Trust Between Farms in SharePoint 2013