Partager via

Provider di attestazioni personalizzate Azure per un progetto di SharePoint - Parte 1

  • Article

Articolo originale pubblicato sabato 11 febbraio 2012

Salve a tutti. È passato un po' di tempo da quando ho aggiunto l'ultima volta nuovo contenuto sulle attestazioni SAML. Ho deciso perciò di tornare da voi e scrivere ancora qualcosa su questo tema, mettendo in relazione i miei argomenti preferiti, ovvero SharePoint, SAML, i provider di attestazioni personalizzate, il kit CASI e Azure. Questa è la prima parte di una serie di post in cui fornirò un modello di prova, completo di codice sorgente utilizzabile liberamente, allo scopo di illustrare la creazione per SharePoint di un provider di attestazioni personalizzate che utilizzi Windows Azure come origine dati. In termini generali, l'implementazione sarà la seguente:

  • Gli utenti eseguiranno l'accesso al sito utilizzando la federazione SAML con ACS. Sul lato ACS configurerò alcuni provider di identità diversi, probabilmente Google, Yahoo e Facebook. In questo modo, gli utenti accederanno mediante il loro indirizzo di posta elettronica Google ad esempio e quindi, dopo essere stati autenticati, verranno reindirizzati nel sito.
  • Utilizzerò le code di Azure per instradare le informazioni delle attestazioni sugli utenti e inserire i dati in Azure Table Storage.
  • Utilizzerò un'applicazione WCF come interfaccia front-end per le richieste di dati in Azure Table Storage e per rilasciare nuovi elementi nella coda. Creeremo una relazione di trust tra il sito di SharePoint e questa applicazione WCF per controllare chi accede e cosa può visualizzare e fare.
  • Nel sito di SharePoint creerò un provider di attestazioni personalizzate che otterrà l'elenco dei tipi di attestazione supportati da me, nonché dalla risoluzione dei nomi e dalla ricerca in Selezione utenti. Utilizzerà inoltre il kit CASI per comunicare con Windows Azure.

Al termine, disporremo di un ambiente end-to-end con SharePoint e il cloud completamente integrati. Spero sarete soddisfatti dei risultati.

Nella Parte 2 esaminerò tutti i componenti che vengono eseguiti nel cloud, ovvero le classi di dati utilizzate per interagire con Azure Table Storage e le code, un ruolo di lavoro per la lettura degli elementi dalle code e l'inserimento di dati in Azure Table Storage e un front-end WCF che consente a un'applicazione client di creare nuovi elementi nella coda e di eseguire tutte le altre operazioni standard relative a Selezione utenti di SharePoint, ossia fornire un elenco dei tipi di attestazione supportati, ricercare i valori delle attestazioni e risolvere le attestazioni.

Nella Parte 3 creerò tutti i componenti utilizzati nella farm di SharePoint, incluso un componente personalizzato basato sul kit CASI che gestisce tutte le comunicazioni tra SharePoint e Azure. È disponibile una web part personalizzata che acquisisce le informazioni relative ai nuovi utenti e le inserisce in una coda di Azure. È infine disponibile un provider di attestazioni personalizzate che comunica con Azure Table Storage tramite WCF, grazie al componente personalizzato del kit CASI, per consentire la funzionalità Selezione utenti e controllo di digitazione.

Questo è un post di blog localizzato. L'articolo originale è disponibile in The Azure Custom Claim Provider for SharePoint Project Part 1.