Pianificazione dell'infrastruttura necessaria per il nuovo modello di app di SharePoint 2013

  • Article

Articolo originale pubblicato martedì 4 settembre 2012

Con SharePoint 2013 viene fornito un nuovo modello applicativo, a cui facciamo riferimento eufemisticamente come "modello di app" o "modello di app per cloud". Se da un lato questo modello offre un'intera nuova gamma di opportunità dal punto di vista dello sviluppo, dall'altro prevede requisiti di infrastruttura da pianificare e allestire per supportare tali opportunità. Quando penso al modello di app, in realtà sono tre gli elementi importanti da considerare:

  1. Il modello di sviluppo, che attiene alla modalità con cui sviluppare l'applicazione, alle nuove funzionalità di cui avvalersi e così via. Questa è principalmente un'attività per sviluppatori.
  2. Il modello di sicurezza, che per queste nuove applicazioni è una combinazione interessante di diversi elementi: il nuovo concetto di entità applicazione, ovvero la modalità di definizione dei diritti per le applicazioni, il modello OAuth che definisce il contenuto a cui è possibile accedere, nonché un meccanismo per presentare a SharePoint un token che descrive l'utente, in modo del tutto analogo alle attestazioni per le applicazioni. Il modello di sicurezza e il mezzo utilizzato per creare e presentare questi token variano in modo significativo a seconda del fatto che l'applicazione sia ospitata in SharePoint o in un'altra posizione e del fatto che venga utilizzato o meno ACS (Access Control Services) come broker di trust. In questo post non verranno affrontati tutti questi aspetti, ma si tratta di un'attività sia per sviluppatori che per professionisti IT.
  3. L'infrastruttura, ovvero l'insieme degli elementi che fanno funzionare le applicazioni all'interno di un'organizzazione. Include le applicazioni di servizio, il dominio e il prefisso delle applicazioni, DNS, SSL e le configurazioni delle applicazioni Web. Si tratta principalmente di un'attività per professionisti IT e costituisce l'argomento di base di questo post, nel quale verranno trattate anche le applicazioni ospitate in SharePoint rispetto a un'applicazione ospitata esternamente in un altro sito o cloud come Windows Azure. Quando si installa un'applicazione ospitata in SharePoint, viene creato un nuovo SPWeb corrispondente. In questo modo ogni applicazione ottiene un proprio set di dati e non può sovrascrivere i dati per un'altra applicazione. Viene inoltre garantito un livello di sicurezza, in modo che chi dispone dei diritti per un'applicazione non possa avere malware che utilizzi i diritti dell'utente corrente per accedere ai dati in un altro sito della farm. Questo è un importante principio da ricordare per le applicazioni basate sul nuovo modello di app: quando sono ospitate in SharePoint, un'app corrisponde a un SPWeb.

Ora iniziamo a occuparci di questi diversi componenti dell'infrastruttura. È innanzitutto necessario verificare che nella farm sia stata creata e sia in esecuzione un'istanza delle applicazioni di servizio Gestione applicazioni e Impostazioni sottoscrizione. Il servizio Gestione applicazioni viene utilizzato per operazioni come tenere traccia delle applicazioni e delle distribuzioni, gestire le licenze e così via. Il servizio Impostazioni sottoscrizione corrisponde all'applicazione di servizio utilizzata per le distribuzioni multi-tenant e viene utilizzato anche dal modello di app per creare gli URL univoci utilizzati dalle applicazioni.

Ma come vengono creati questi URL? Tutto inizia con la configurazione delle app eseguita in Amministrazione centrale. Quando si accede ad Amministrazione centrale, risulta disponibile una nuova sezione, denominata Applicazioni. Facendo clic su di essa, viene visualizzata un'opzione Configura URL applicazione, con due valori che vengono utilizzati per creare l'URL di un'applicazione, ovvero il dominio e il prefisso dell'applicazione. Tale dominio è analogo al nome host che verrà utilizzato per tutte le applicazioni della farm. Ecco tre fattori da considerare quando si effettua la pianificazione per questo nome:

  1. Poiché viene utilizzato per l'intera farm, deve essere pianificato e concepito con la stessa attenzione utilizzata per le altre applicazioni Web. 
  2. Deve inoltre essere un nome di dominio completo. Un nome NetBIOS non funzionerà correttamente per la risoluzione dei nomi. 
  3. NON deve infine essere un dominio figlio delle applicazioni Web.

Proviamo a esaminare un esempio specifico. Supponiamo che le applicazioni Web esistenti siano denominate team.contoso.com, my.contoso.com e portal.contoso.com. Come prima cosa, probabilmente non è opportuno utilizzare semplicemente "contoso.com" per il dominio dell'applicazione perché, in questo modo, è necessario creare una voce DNS con caratteri jolly per l'INTERO contoso.com che punti all'endpoint delle app (tra poco approfondiremo questo discorso). Non è nemmeno consigliabile utilizzare "apps.contoso.com" e simili perché questo è un dominio figlio dell'oggetto utilizzato per le applicazioni Web, che hanno tutte "contoso.com" come radice. Sulla base di queste regole, sarebbe preferibile utilizzare "contosoapps.com". 

Come prefisso dell'applicazione è possibile utilizzare un valore qualsiasi. Viene inserito nella prima parte dell'URL dell'applicazione, aspetto di cui parleremo più avanti.

Poco fa ho accennato all'utilizzo di una voce DNS con caratteri jolly e questo è l'argomento successivo da trattare. Quando viene installata un'applicazione ospitata in SharePoint, l'URL sarà simile a questo: https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx. Gli elementi dell'URL sono i seguenti:

  • "apps" - questo è il valore del prefisso dell'applicazione sopra menzionato che è stato immesso in Amministrazione centrale.
  • "87e90ada14c175" - questo è un valore univoco basato sulla raccolta siti e sul sito Web in cui è installata l'applicazione.
  • "contosoapps.com" - questo è il dominio dell'applicazione che è stato immesso in Amministrazione centrale.
  • "myapp" - questo è il nome dell'applicazione installata. Il resto dell'URL (pages/default.aspx) è contenuto nell'SPWeb in cui è installata l'applicazione.

Osservando l'URL e il relativo formato, è possibile comprendere il motivo per cui utilizzare una voce DNS con caratteri jolly. Dal momento che la prima parte dell'URL sarà diversa per ogni istanza di applicazione che viene installata, anche in caso di installazione della stessa applicazione in più raccolte siti, non è fattibile aggiornare continuamente DNS per tutte le singole istanze. Questo significa che, per lo scenario descritto, verrà utilizzata una voce DNS con caratteri jolly per *.contosoapps.com. Tra poco ci occuperemo dell'indirizzo IP a cui punta.

Alla voce DNS con caratteri jolly è correlata una voce SSL con caratteri jolly. Se si utilizzano le app, è chiaro che si utilizzi SSL. Il modello di app prevede il passaggio di token di accesso OAuth che descrivono l'identità dell'utente e dell'applicazione correnti. Se si passano token SAML per un utente, è opportuno crittografare il canale su cui transitano tali token per impedire qualsiasi attacco di tipo riproduzione di pacchetti (replay) che possa consentire l'accesso al contenuto a un malintenzionato pronto a intercettare il traffico di rete. L'utilizzo di SSL impedisce il verificarsi di questi scenari e, poiché gli URL per queste applicazioni saranno diversi per ogni istanza installata, per gestirli sarà inoltre necessario un certificato SSL con caratteri jolly. Nel nostro scenario si otterrà un certificato SSL con caratteri jolly per *.contosoapps.com.

OK, finora abbiamo parlato delle applicazioni di servizio necessarie, della configurazione necessaria per il dominio e il prefisso dell'applicazione, del formato degli URL e delle voci DNS e SSL necessarie. Ora, per collegare tutti questi elementi, dobbiamo parlare della modalità con cui vengono instradate le richieste delle applicazioni. In via generale, sarà necessaria un'applicazione Web di SharePoint separata solo per il routing di tali richieste. Vediamo di che si tratta. Supponiamo di nuovo che siano disponibili tre applicazioni Web definite come indicato di seguito. Utilizzano tutte SSL, pertanto per ognuna vengono utilizzati indirizzi IP univoci:

  • team.contoso.com - 192.168.1.10
  • my.contoso.com - 192.168.1.11
  • team.contoso.com - 192.168.1.10

Come spiegato in precedenza, nella farm può esistere un solo dominio delle applicazioni e non deve essere un dominio figlio. Si delineano così due problemi reali con le applicazioni sopra riportate:

  • Se si installano applicazioni in ognuna di queste app Web, come è possibile riuscire a instradare la richiesta dell'applicazione corretta all'app Web corretta? Il dominio delle applicazioni è uno, ma le app Web sono tre.
  • Se si tenta di instradare una richiesta dell'applicazione a una di queste app Web esistenti, SSL non funzionerà. Per quale motivo? Perché si sta utilizzando SSL in tutte le app Web (perché si stanno utilizzando applicazioni) e quindi hanno tutte un certificato SSL del tipo *.contoso.com. Non è pertanto possibile instradare a esse le richieste delle applicazioni, in quanto non è possibile ottenere un carattere jolly SSL che funzioni tanto con *.contoso.com che con *.contosoapps.com, che è quanto verrà invece utilizzato dalle app.

La soluzione è quella di creare una quarta applicazione Web. È possibile crearla senza un nome di intestazione host e assegnarle l'indirizzo IP condiviso 192.168.1.13. In DNS la voce con caratteri jolly per *.contosoapps.com punterà a 192.168.1.13. L'applicazione Web delle app resta pertanto in attesa su tale indirizzo IP e il modulo http di SharePoint responsabile del routing recupererà la richiesta per l'applicazione. Utilizzerà quindi l'applicazione di servizio Gestione applicazioni per determinare quale applicazione Web stia effettivamente ospitando tale applicazione e reinstraderà a essa la richiesta. Quest'ultima viene quindi servita da tale applicazione Web, dalla raccolta siti e dall'SPWeb in cui si trova l'app. Tutte le impostazioni di sicurezza e autenticazione verranno perciò applicate correttamente.

La configurazione della farm ora è simile alla seguente:

  •  Configurazione delle app
    • Dominio delle app - contosoapps.com
    • Prefisso delle app - apps
  • Applicazioni Web

    • team.contoso.com

      • Indirizzo IP: 192.168.1.10
      • Certificato SSL: *.contoso.com

    • my.contoso.com

      • Indirizzo IP: 192.168.1.11
      • Certificato SSL: *.contoso.com

    • portal.contoso.com

      • Indirizzo IP: 192.168.1.12
      • Certificato SSL: *.contoso.com

    • Nessuna intestazione host oppure è possibile utilizzare contosoapps e simili. Non ha importanza, in quanto il routing non avviene in base all'intestazione host, ma all'indirizzo IP. Se PERÒ si stanno utilizzando intestazioni host e tutte le applicazioni Web utilizzano lo stesso indirizzo IP, questa applicazione Web listener non deve avere alcun valore di intestazione host! Altrimenti IIS non recupererà le richieste di app per alcuna applicazione Web.

      • Indirizzo IP: 192.168.1.13
      • Certificato SSL: *.contosoapps.com
  • DNS
    • team.contoso.com - 192.168.1.10
    • my.contoso.com - 192.168.1.11
    • team.contoso.com - 192.168.1.10
    • *.contosoapps.com - 192.168.1.13

Ora che abbiamo affrontato tutti gli aspetti della configurazione dell'infrastruttura delle app, vi sono altri due fattori di cui tenere conto durante la pianificazione dell'implementazione delle nuove app per SharePoint 2013:

  • Le app di SharePoint non funzionano nelle applicazioni Web che utilizzano SAML. Se si utilizza l'autenticazione SAML, non sarà possibile utilizzare app di SharePoint in tali applicazioni Web. È probabile che tale problema venga risolto in un Service Pack futuro o con qualche altro tipo di patch, ma si tratta di una limitazione per SharePoint 2013 RTM.
  • Le app di SharePoint non supportano più aree (AAM). Tutte le richieste vengono servite all'esterno dell'area predefinita. Se si utilizza AAM per supportare più aree, probabilmente non sarà possibile utilizzare app di SharePoint. Tutte le app vengono servite al di fuori dell'area predefinita. Se pertanto in teoria l'area predefinita fosse esposta in modo da essere raggiungibile da chiunque e si utilizzasse esattamente lo stesso meccanismo di autenticazione in ogni area (con alcune possibili limitazioni che sarebbe troppo lungo approfondire ora in questa sede), potrebbe funzionare. Se però si utilizzano aree, significa di solito che a) non si desidera che tutti gli endpoint siano esposti a chiunque o che b) SI DESIDERA utilizzare metodi di autenticazione diversi. Anche questa situazione può cambiare in futuro, ma per il momento accade questo in SharePoint 2013 RTM.

 

Un'altra importante nota finale: la configurazione può sembrare impegnativa ed effettivamente lo è. Tenere comunque presente che, se si utilizza Office 365, tutte queste attività verranno eseguite automaticamente e che quindi sarà facile installare e utilizzare le applicazioni. Questo è un aspetto da valutare per la scelta delle diverse opzioni.

Concludendo, le app di SharePoint rappresentano una parte importante di SharePoint 2013, ma richiedono a monte alcune attività di pianificazione e progettazione per approntare l'infrastruttura necessaria a supportarle.

 

Questo è un post di blog localizzato. L'articolo originale è disponibile in Planning the Infrastructure Required for the new App Model in SharePoint 2013.