OAuth e utente reidratato in SharePoint 2013: come fare e quali informazioni sono necessarie

Articolo originale pubblicato giovedì 16 agosto 2012

Lasciatemi dire innanzitutto che una delle cose che apprezzo di più dei blog sulle caratteristiche di SharePoint è la possibilità di utilizzare un linguaggio colloquiale, come ad esempio nel titolo, il che non sarebbe fattibile se non fosse stata creata una nuova versione di SharePoint. I messaggi di social networking di SharePoint 2013 sono a volte molto divertenti. E quello che colpisce di più è che sono intervallati da messaggi più seriosi, ad esempio riguardanti HRESULT, come è capitato al mio amico Tom l'altro giorno. È proprio vero, più le cose cambiano, più rimangono uguali.

Ma torniamo all'argomento in questione. Ho già accennato un paio di volte a OAuth in questo blog parlando delle nuove caratteristiche di SharePoint 2013. E, anche se non fornirò una descrizione dettagliata di questa caratteristica, perché abbiamo un intero team di autori che se ne occupano, vorrei esaminare un po' più a fondo alcuni dei modi in cui è possibile utilizzarla. L'esempio più significativo di un trust OAuth riguarda forse l'indice remoto di SharePoint per la ricerca, che consente a un utente in una farm di inviare una query che viene reinstradata in un'altra farm di SharePoint remota, in cui è possibile ricostruire l'identità dell'utente in modo che i risultati della ricerca vengano tagliati adeguatamente per la sicurezza. Viene inoltre utilizzato in altri scenari, come il nuovo modello di app (se l'utente dispone dei diritti per accedere al contenuto richiesto dall'app), tra applicazioni server come SharePoint e Exchange (se l'utente dispone dei diritti per il contenuto della cassetta postale) e molti altri. L'indice remoto di SharePoint è un esempio efficace perché credo che sia lo scenario migliore da utilizzare per capire il motivo per cui dobbiamo svolgere determinate attività per ottenere i risultati previsti.

Cominciamo dall'inizio. Come può FarmA riconoscere un utente di FarmB? La risposta sta nell'applicazione profilo utente. Supponiamo che un utente di FarmB chiamato Steve invii una query. La query viene reinstradata in FarmA, insieme ad alcuni attributi relativi a Steve. Per impostazione predefinita, questi attributi saranno l'indirizzo SMTP, l'indirizzo SIP, il nome dell'account e l'identificatore del nome. Quando FarmA riceve la richiesta, esegue una ricerca nella versione locale dell'applicazione profilo utente. Cercherà un profilo che corrisponde ai valori relativi a Steve che sono stati inviati. Ecco perché è importante verificare che l'applicazione profilo utente sia integra e popolata in SharePoint 2013 e perché ho scritto questo articolo di blog su questo argomento: https://blogs.msdn.com/b/sharepoint_it/archive/2012/09/20/mapping-dei-profili-degli-utenti-di-saml-con-importazione-da-active-directory-in-sharepoint-2013.aspx.

A questo punto, FarmA ha trovato il profilo utente di Steve. Come lo utilizza? La risposta è "dipende", ed ecco perché è importante pianificare questo aspetto per l'organizzazione. Da che cosa dipende? Dal tipo di autenticazione in uso, come vedremo di seguito:

• Attestazioni di Windows: se si utilizzano le attestazioni di Windows, nella maggior parte dei casi tutte le informazioni necessarie si trovano nel profilo utente, che contiene il nome dell'account e le appartenenze ai gruppi di Active Directory. Vedremo in seguito che cosa intendo con "nella maggior parte dei casi". In ogni modo, se si utilizzano le attestazioni di Windows si è già a buon punto.
• Attestazioni dell'autenticazione basata su moduli: se si utilizza l'autenticazione basata su moduli, è necessario approfondire un paio di aspetti. Il primo è che bisogna trovare un modo per popolare l'applicazione profilo utente e per mantenerla aggiornata. Se l'autenticazione basata su moduli viene utilizzata con un provider LDAP e la directory corrisponde ad Active Directory di Windows, la situazione è quasi a posto. È possibile creare una connessione di profili con Active Directory e associarla al provider dell'autenticazione basata su moduli in modo simile a quanto descritto nel post di cui ho fornito il collegamento in precedenza. Nella maggior parte dei casi, tuttavia, il provider non è AD, il che significa che è necessario scrivere codice personalizzato per popolare l'applicazione profilo utente. Questo dovrebbe bastare per ottenere l'unico attributo importante per gli utenti dell'autenticazione basata su moduli, ovvero il nome dell'account. Come tutti sanno, però, nella maggior parte dei casi (come spiegherò in seguito), il resto dei dati proviene dal provider dei ruoli. L'aspetto positivo è che quando reidratiamo un utente dell'autenticazione basata su moduli, richiamiamo anche il provider dei ruoli associato, per cui è come se l'utente fosse connesso localmente. In questo modo possiamo acquisire tutte le attestazioni di ruolo per un utente dell'autenticazione basata su moduli.
• Attestazioni SAML: anche in questo caso, come nell'autenticazione basata su moduli, è necessario innanzitutto popolare l'applicazione profilo utente. Nell'ipotesi migliore, gli utenti si trovano in AD ed è sufficiente importarli direttamente seguendo le indicazioni riportate nel post di blog citato in precedenza. In caso contrario, sarà necessario trovare un modo per connettersi a una directory di origine ed eseguire l'importazione. Questa procedura è ovviamente più complicata con le attestazioni SAML, perché le directory possono essere numerose e non sempre appartengono allo stesso proprietario (ad esempio, se si hanno dei partner, è stata attuata una federazione con ACS e si utilizza Facebook o un altro provider e così via). In ogni caso, per un corretto funzionamento, sarà necessario trovare un modo per popolare l'applicazione profilo utente. Tuttavia, un secondo punto più importante è che, quando si accede come utente SAML, si ottiene una serie di attestazioni dal provider di identità. Questo processo di reidratazione dell'utente non può in alcun modo simulare l'accesso. Questa è una caratteristica di SAML: è possibile essere reindirizzati una o più volte e ricevere un qualsiasi numero di richieste di autenticazione e tipi di autenticazione (come quella a due fattori) che non possiamo controllare. Che cosa significa tutto questo? È necessario aggiungere le attestazioni tramite incremento e utilizzarle per proteggere il contenuto e autorizzare l'accesso mediante questo processo di reidratazione utente. Durante la reidratazione non si ottengono attestazioni dal provider di identità e per questo è necessario concederle localmente. È proprio questo che intendevo con "nella maggior parte dei casi", come spiegherò ora.
• Che cosa significa "nella maggior parte dei casi"? A questo punto mi auguro che sia diventato chiaro. Sia che si utilizzi Windows, l'autenticazione basata su moduli o SAML, oltre alle attestazioni ottenute dal provider di autenticazione è possibile che ne vengano aggiunte altre tramite incremento: https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx. Durante il processo di reidratazione vengono inoltre richiamati tutti i provider di attestazione personalizzati registrati, in modo che possiamo ottenere altre attestazioni per l'utente reidratato rispetto a quelle ricevute con l'accesso locale e con la chiamata ai provider.

Questo è il motivo per cui lo scenario dell'indice remoto di SharePoint mi sembra appropriato per illustrare le attività di pianificazione richieste. Come si può facilmente immaginare, all'interno di una farm è possibile concedere diritti per il contenuto in base a un gruppo di Windows, a un ruolo dell'autenticazione basata su moduli, a un'attestazione SAML o a qualsiasi attestazione aggiunta tramite incremento. Se non si dispone di queste attestazioni quando si esegue una query per richiedere contenuto, il contenuto verrà tagliato per motivi di sicurezza e non sarà possibile visualizzarlo. Per questo è importante che anche quando viene reidratata una versione si ottengano le stesse attestazioni concesse quando si esegue l'accesso localmente.

Per tutto questo lavoro, è necessaria una notevole pianificazione e mi auguro di aver identificato i principali elementi coinvolti per contribuire a semplificarla.

Questo è un post di blog localizzato. L'articolo originale è disponibile in OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know