Esempio di progettazione: distribuzione aziendale (SharePoint Server 2010)

  • Articolo

 

Si applica a: SharePoint Foundation 2010, SharePoint Server 2010

Ultima modifica dell'argomento: 2017-01-18

In questo articolo viene descritta l'implementazione pratica dei componenti di un'architettura logica necessari per ottenere una progettazione efficace. Questo articolo è concepito per essere utilizzato insieme agli esempi di progettazione seguenti:

  • Esempio di progettazione: portale aziendale con autenticazione classica

  • Esempio di progettazione: portale aziendale con autenticazione basata sulle attestazioni

Per scaricare uno di questi modelli, vedere Esempi di progettazione di SharePoint Server 2010: portale aziendale con autenticazione classica o basata sulle attestazioni (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Contenuto dell'articolo:

  • Informazioni sugli esempi di progettazione

  • Obiettivi generali di progettazione

  • Server farm

  • Utenti, aree e autenticazione

  • Servizi

  • Alternative per la creazione e modifica e per la pubblicazione

  • Siti di amministrazione

  • Pool di applicazioni

  • Applicazioni Web

  • Raccolte siti

  • Database del contenuto

  • Aree e URL

  • Criteri per le aree

I modelli di progettazione mostrano una distribuzione aziendale generica di Microsoft SharePoint Server 2010. Possono essere applicati quasi a tutti i componenti dell'architettura logica e mostrano come questi componenti sono incorporati nella progettazione generale. Nei due esempi sono illustrati gli stessi servizi e siti, ma sono basati su diversi metodi di autenticazione, come descritto di seguito:

  • Autenticazione classica: questo esempio di progettazione rappresenta un percorso per aggiornare i siti da Microsoft Office SharePoint Server 2007 a Microsoft SharePoint Server 2010 e si basa sull'autenticazione classica, in cui i metodi di autenticazione Windows vengono utilizzati per accedere ai siti. Viene utilizzata un'area diversa per ogni metodo di autenticazione. Per i siti SharePoint viene utilizzata l'autenticazione di Windows, mentre è possibile configurare un firewall o un gateway allo scopo di utilizzare l'autenticazione Forms per raccogliere le credenziali Windows inoltrate a SharePoint Server 2010. Gli account dei dipendenti dei partner vengono aggiunti alla directory aziendale.

  • Autenticazione basata sulle attestazioni: in questo esempio di progettazione viene incorporato il nuovo modello di autenticazione basata sulle attestazioni, in cui più provider di autenticazione e tipo di autenticazione sono implementati in un'unica area. L'autenticazione basata sulle attestazioni supporta l'autenticazione basata su form, quella basata su token SAML e l'autenticazione di Windows. In questo esempio di progettazione le aziende partner vengono aggiunte mediante l'autenticazione basata su token SAML per eseguire l'autenticazione direttamente in base alle directory dei partner. Sono disponibili diverse opzioni dei provider per gli account dei dipendenti dei partner.

Utilizzare l'esempio di progettazione che rappresenta meglio i requisiti specifici di autenticazione.

In questo articolo sono descritti gli obiettivi di progettazione per gli esempi ed è illustrato come raggiungere tali obiettivi mediante i componenti dell'architettura logica mostrati negli esempi.

Informazioni sugli esempi di progettazione

Gli esempi di progettazione mostrano una distribuzione aziendale per una società fittizia denominata Fabrikam, Inc. La distribuzione include due server farm: una ospita la rete Intranet aziendale e il sito Web dei partner, la seconda farm ospita invece il sito Web della società (www.fabrikam.com). Nella parte restante di questa sezione vengono descritti questi siti principali.

Intranet

L'Intranet aziendale include i siti seguenti:

  • Contenuto dell'Intranet pubblicato (ad esempio HRweb)

  • Siti per la collaborazione in team

  • Siti personali

Complessivamente, questi rappresentano i siti del contenuto e di collaborazione che i dipendenti utilizzano quotidianamente, mentre singolarmente, ognuna di queste applicazioni rappresenta un tipo diverso di contenuto che svolge le funzioni seguenti:

  • Enfatizza diverse caratteristiche di SharePoint Server 2010.

  • Ospita dati con caratteristiche differenti.

  • È soggetta a un diverso profilo di utilizzo.

  • Richiede una diversa strategia di gestione delle autorizzazioni.

Di conseguenza, le scelte di progettazione per ognuna di queste applicazioni sono volte a ottimizzare le prestazioni e la sicurezza della specifica applicazione.

La progettazione delle applicazioni di servizio raggruppa queste tre applicazioni per offrire:

  • Spostamento tra le applicazioni

  • Ricerca contenuti nell'organizzazione

  • Dati di profilo condivisi e metadati aziendali

Nel diagramma seguente vengono illustrate le tre applicazioni che costituiscono l'Intranet aziendale.

Siti Intranet

Gli URL presenti in questa figura riguardano l'esempio di progettazione con autenticazione classica.

Applicazione Web del partner

L'applicazione Web del partner ospita i siti esterni per garantire una collaborazione sicura con le società partner e i singoli partner. Questa applicazione è concepita per consentire ai dipendenti di creare facilmente siti per la collaborazione sicura. Ai partner non è consentito l'accesso ad altri tipi di contenuti ospitati nella server farm. La progettazione per le aree e le applicazioni di servizio mira a raggiungere questo obiettivo.

Nell'esempio di progettazione l'applicazione Web del partner è ospitata dalla farm che ospita il contenuto dell'Intranet.

Sito Internet della società

Il sito Internet della società rappresenta la presenza della società su Internet. Il contenuto viene messo a disposizione dei clienti mediante la configurazione dell'accesso anonimo con autorizzazioni di sola lettura. I fattori chiave alla base alle scelte di progettazione per questa applicazione includono:

  • Isolamento del contenuto: i clienti non possono accedere a contenuto diverso da quello ospitato nella server farm.

  • Gestione mirata: l'accesso autenticato viene concesso ai dipendenti che gestiscono il sito Web eseguendo attività amministrative e di creazione e modifica.

  • Creazione, modifica e pubblicazione sicure del contenuto: una raccolta siti separata è ospitata nella farm A e nell'applicazione Web del partner per la creazione e modifica. In questo modo è possibile garantire la sicurezza della collaborazione e dello sviluppo del contenuto sia con i dipendenti interni che con il personale remoto, nonché con i partner editoriali specializzati nello sviluppo del sito Web o nella creazione e modifica del contenuto. La pubblicazione del contenuto è configurata in modo che il contenuto della raccolta siti di creazione e modifica della prima farm sia pubblicato automaticamente nella raccolta siti di produzione della seconda farm. Nel diagramma seguente viene illustrato il processo di pubblicazione:

Siti pubblicati

Obiettivi generali di progettazione

Nell'esempio di progettazione è illustrata l'implementazione pratica delle caratteristiche di SharePoint Server 2010 in vari tipi di applicazioni comuni. Le implementazioni di progettazione per ogni singola applicazione sono esaminate in questo articolo. Gli obiettivi chiave della progettazione per l'esempio in questione includono:

  • Utilizzo del numero minimo di server farm per ospitare i tipi più comuni di siti Web in genere necessari a un'organizzazione, ovvero siti Intranet, Extranet e Internet.

  • Creazione di un framework per progettare un ambiente con potenziale di crescita. Le scelte di progettazione per una specifica applicazione non impediscono l'aggiunta di altre applicazioni. Ad esempio, una distribuzione iniziale può includere solo i siti del team di collaborazione o solo le tre applicazioni che compongono una rete Intranet (siti del team, siti personali e contenuto pubblicato nell'Intranet). Utilizzando una progettazione dell'architettura logica di questo tipo è possibile aggiungere applicazioni alla soluzione senza influire sulla progettazione delle applicazioni iniziali. In altri termini, la progettazione non incorpora scelte che limitano l'uso dell'ambiente.

  • Concessione dell'accesso a vari gruppi di utenti senza compromettere la sicurezza del contenuto nei diversi tipi di siti. Utenti di diverse aree della rete (sia interni che esterni) e diversi provider di autenticazione possono partecipare alla collaborazione. Gli utenti possono tuttavia accedere solo al contenuto che li riguarda. Mediante questo tipo di progettazione dell'architettura logica è possibile offrire l'accesso agli utenti in più posizioni e con obiettivi diversi. Ad esempio, la progettazione iniziale può essere intesa solo per l'accesso dei dipendenti interni. Tuttavia, in questo modo si crea l'opportunità di consentire l'accesso anche ai dipendenti remoti, ai dipendenti dei partner, alle società partner e ai clienti.

  • Verifica che la progettazione possa essere utilizzata in un ambiente Extranet. Le scelte di progettazione vengono fatte in modo da garantire che le server farm possano essere distribuite con sicurezza in una rete perimetrale.

Nella parte restante di questo articolo vengono descritti i singoli componenti logici che sono presenti nell'esempio di progettazione (dall'alto verso il basso) e vengono esaminate le scelte di progettazione applicate all'esempio. Lo scopo di questo approccio è dimostrare i diversi modi in cui è possibile configurare i componenti dell'architettura logica in base all'applicazione.

Server farm

Nell'esempio di progettazione è previsto l'uso di due server farm. In questa sezione vengono descritti i requisiti di licenza che influiscono sul numero di server farm necessarie in un ambiente aziendale e vengono illustrate le topologie delle server farm mostrate nell'esempio di progettazione.

Requisiti di licenza

Per ospitare il contenuto dell'Intranet e i siti Internet, è necessario un numero minimo di due server per soddisfare i requisiti di licenza.

Sono disponibili le due licenze server seguenti per SharePoint Server 2010:

  • Microsoft SharePoint Server 2010, Server licenze: è la licenza appropriata per il contenuto intranet per la collaborazione. Questa licenza richiede l'uso delle licenze di accesso client (Client Access License, CAL). Se si creano siti per la collaborazione con i partner, è necessario accertarsi di acquistare il numero necessario di licenze CAL per i dipendenti dei partner.

  • Microsoft SharePoint Server 2010 for Internet sites: questa licenza è destinata esclusivamente ai siti Web esposti a Internet e non richiede licenze CAL. Se si creano siti per la collaborazione con i partner, non è necessario acquistare licenze CAL aggiuntive. Tuttavia, non è possibile creare siti destinati esclusivamente all'utilizzo da parte dei dipendenti.

Nota

Queste licenze non possono essere combinate nello stesso computer server o nella stessa server farm.

In base alle opzioni di licenza, la scelta di progettazione più critica consiste nel decidere quale farm deve ospitare l'applicazione Web del partner. Nell'esempio di progettazione la prima farm ospita il contenuto dell'Intranet e la seconda farm ospita il sito Internet della società. In base ai termini della licenza, ogni farm può ospitare l'applicazione Web del partner.

Con una scelta di due farm, per determinare quale farm deve ospitare un'applicazione Web del partner è possibile adottare le istruzioni generali di progettazione seguenti:

  • Natura della collaborazione: se lo scopo principale di un sito Extranet del partner è di comunicare informazioni in modo sicuro a numerosi partner, una server farm Internet è la scelta più economica. D'altra parte, se lo scopo principale è quello di collaborare con un numero limitato di dipendenti dei partner, una server farm Intranet può rappresentare una scelta più appropriata. Scegliere l'opzione che consente di ottimizzare la farm per il ruolo che deve svolgere.

  • Numero di dipendenti del partner: se si collabora con numerosi dipendenti del partner ed è fondamentale ridurre i costi al minimo, è possibile ospitare contenuto anonimo e per la collaborazione in una farm esposta a Internet mediante la licenza per i siti Internet.

Nell'esempio di progettazione l'applicazione Web del partner è destinata alla collaborazione intensiva con le società partner, incluso lo sviluppo e la gestione temporanea del sito Internet della società. Se si posiziona l'applicazione Web del partner nella prima farm, l'organizzazione può ottimizzare ognuna delle due farm per l'uso specifico (collaborazione o contenuto di sola lettura). Tuttavia, l'applicazione Web del partner può essere ospitata da entrambe le farm.

L'esempio di progettazione include Microsoft Office Web Apps. Office Web Apps richiede una licenza client Microsoft Office 2010. In altri termini, se si rende disponibile Office Web Apps ai partner, è necessario anche acquistare licenze client Office 2010 per tali partner.

Topologia delle server farm

Ogni server farm nell'esempio di progettazione è costituita da cinque server con la seguente topologia:

  • Due server Web front-end

  • Un server applicazioni

  • Due server di database, in cluster o con mirroring

Nell'esempio di progettazione viene illustrata l'architettura logica di SharePoint Server 2010 evidenziando gli aspetti seguenti:

  • Viene eseguito il mirroring di tutti i siti nei server Web front-end.

  • Il sito Amministrazione centrale viene installato in un server applicazioni per proteggerlo dall'accesso diretto degli utenti.

In realtà, il numero di computer server e la topologia della server farm non sono importanti per l'architettura logica, tranne che per incrementare la capacità e le prestazioni in base alle esigenze. L'architettura logica può essere progettata in modo indipendente dalla topologia della server farm. Il processo di pianificazione delle prestazioni e della capacità consentiranno di definire le dimensioni della server farm in relazione agli obiettivi di prestazioni e capacità. Per ulteriori informazioni, vedere Gestione di prestazioni e capacità (SharePoint Server 2010).

Adattamento di più di due farm

È possibile che sia necessario rappresentare più di due farm. I siti che sono candidati per una farm dedicata includono:

  • Siti personali: molte organizzazioni con un elevato numero di dipendenti o studenti scelgono di ospitare siti personali in una server farm dedicata.

  • Siti di creazione e modifica o di gestione temporanea: se il contenuto pubblicato è complesso o esteso, è possibile ottimizzare i processi di creazione e modifica o di gestione temporanea ospitando tali siti in una server farm dedicata con server singolo che utilizza Microsoft SharePoint Server 2010 per le licenze dei siti Internet. Ad esempio, la pubblicazione di contenuto che include metadati con tag aumenta la complessità dell'esempio di progettazione dei servizi tra la farm di creazione e modifica e la farm pubblicata, inclusa la condivisione dei servizi tra le farm e la scelta se condividere il servizio tra altri tipi di applicazioni Web in una farm multiuso.

  • Siti dei partner: i requisiti di sicurezza e isolamento possono tutelare una farm dedicata per la collaborazione con i partner. Si crea infatti un isolamento fisico tra il contenuto solo interno e il contenuto sviluppato in collaborazione con i partner esterni.

Utenti, aree e autenticazione

Quando si crea un'applicazione Web in SharePoint Server 2010, è necessario scegliere l'autenticazione basata sulle attestazioni o l'autenticazione classica. La modalità di autenticazione determina il modo in cui gli account vengono utilizzati internamente da SharePoint Server 2010. Nella tabella seguente vengono riepilogati questi due approcci.

Tipo di autenticazione

Descrizione

Suggerimenti

Autenticazione classica

Gli account utente vengono considerati da SharePoint Server 2010 come normali account di Windows Active Directory. Sono supportati i protocolli di autenticazione seguenti: Kerberos, NTLM, di base, digest e anonimo.

L'autenticazione basata su form non è supportata.

In un'area è possibile configurare solo un metodo di autenticazione.

La modalità classica è consigliata per gli ambienti di aggiornamento da Microsoft Office SharePoint Server 2007, nei quali l'autenticazione basata su form non rappresenta un requisito.

Non è necessario eseguire la migrazione utente se si aggiorna e si seleziona l'autenticazione classica.

Autenticazione basata sulle attestazioni

Gli account utente vengono considerati da SharePoint Server 2010 come identità basate sulle attestazioni. Gli account Windows vengono convertiti automaticamente in identità basate sulle attestazioni. Questa modalità supporta anche l'autenticazione basata su form e l'autenticazione con un provider di identità attendibile.

Possono essere configurati più tipi di autenticazione in un'unica area.

L'autenticazione basata su attestazioni è consigliata per le nuove distribuzioni di SharePoint Server 2010 ed è necessaria per aggiornare le soluzioni Office SharePoint Server 2007 che richiedono l'autenticazione basata su form.

I due esempi di progettazione esaminati in questo articolo rappresentano queste due opzioni. Nelle sezioni seguenti viene esaminato nello specifico come l'autenticazione viene incorporata nei due esempi di progettazione.

Esempio di progettazione basato sull'autenticazione classica

L'esempio di progettazione in cui è utilizzata l'autenticazione classica incorpora l'approccio tradizionale "un'area per tipo" incluso nella versione precedente. Per questo motivo, in questo esempio è incluso un percorso per l'aggiornamento da Office SharePoint Server 2007 a SharePoint Server 2010.

L'unica avvertenza è che l'autenticazione basata su form non è supportata nella modalità classica, poiché in questa modalità tutti gli account autenticati devono trovarsi in Servizi di dominio Active Directory (AD DS). È consigliabile che gli utenti che accedono in remoto ai siti utilizzino l'autenticazione basata su form nel firewall o nel gateway per recuperare le credenziali Windows inoltrate alla farm di SharePoint.

Nell'esempio basato sulla modalità classica sono illustrate quattro classi diverse di utenti, ognuna assegnata a un'area diversa. All'interno di ogni applicazione Web è possibile creare fino a cinque aree utilizzando uno dei nomi di area disponibili, ovvero Predefinita, Intranet, Internet, Personalizzata o Extranet.

Nella tabella seguente sono mostrate le aree, gli utenti e i tipi di autenticazione richiesti dall'esempio di progettazione basato sulla modalità classica.

Tabella che mostra le aree, gli utenti e l'autenticazione.

L'account della ricerca per indicizzazione deve poter accedere almeno a un'area mediante l'autenticazione NTLM. Se nessuna delle aree degli utenti è configurata per utilizzare l'autenticazione NTLM, è possibile configurare l'area personalizzata per tale scopo.

Esempio di progettazione con autenticazione basata sulle attestazioni

L'autenticazione basata sulle attestazioni è consigliata per tutte le nuove distribuzioni di SharePoint Server 2010 ed è necessaria per aggiornare le soluzioni Office SharePoint Server 2007 che richiedono l'autenticazione basata su form. Oltre ai metodi di autenticazione Windows standard, l'autenticazione basata sulle attestazioni consente di eseguire l'autenticazione in relazione ad altre directory, quali Windows Live ID, Active Directory Federation Services 2.0 o un provider di identità di terze parti che supporta i token SAML e il protocollo WS Federation.

Nell'esempio di progettazione con autenticazione basata sulle attestazioni, questa modalità di autenticazione viene utilizzata nella farm di collaborazione e consente l'utilizzo di più tipi di autenticazione nella stessa area. Nell'esempio di progettazione viene utilizzata l'area predefinita per tutti i tipi di autenticazione. Nella tabella seguente sono mostrate le aree, gli utenti e i tipi di autenticazione richiesti dall'esempio per la farm di collaborazione.

Tabella che mostra le aree, gli utenti e l'autenticazione.

Nell'esempio di progettazione, il sito del contenuto pubblicato nell'Intranet, i siti dei team e i siti personali sono accessibili solo ai dipendenti interni o esterni alla rete. Nell'esempio di progettazione viene implemento un solo URL (basato su SSL) che può essere utilizzato sia internamente che esternamente. Sono utilizzati gli account di Active Directory. Se necessario, è possibile utilizzare LDAP con l'autenticazione basata su form o con SAML, che richiede operazioni di configurazione aggiuntive.

Nell'esempio di progettazione, l'applicazione Web del partner rappresenta un sito Extranet accessibile dai dipendenti dei partner e dalle società partner. Per utilizzare un'autenticazione basata sulle attestazioni in questo scenario, è necessario configurare una relazione di trust con uno o più servizi token di sicurezza (STS) esterni. Per questo scopo, è possibile utilizzare uno degli approcci seguenti:

  • La farm di SharePoint può essere configurata per considerare attendibile un servizio STS esterno, ad esempio il servizio STS associato a Windows Live (per l'autenticazione di singoli partner) o quello in uso in una società partner (per l'autenticazione diretta in base alla directory del partner).

  • Il servizio STS all'interno dell'ambiente aziendale può essere configurato per considerare attendibile un servizio STS esterno. Questa relazione deve essere stabilita in modo esplicito dagli amministratori delle due organizzazioni. In questo scenario, la farm di SharePoint viene configurata per considerare attendibile solo il servizio STS in uso nel rispettivo ambiente aziendale. Questo servizio STS interno verifica il token che riceve dal servizio STS esterno e quindi genera un token che consente all'utente partner di accedere alla farm di SharePoint farm. Questo è l'approccio consigliato.

Un'alternativa all'implementazione di un ambiente basato sulle attestazioni per autenticare i partner consiste nell'utilizzare l'autenticazione basata sui form e gestire tali account mediante un archivio separato, quale un database.

Per ulteriori informazioni sull'implementazione di un ambiente con autenticazione basata sulle attestazioni, vedere il white paper seguente: Identità basata sulle attestazioni per Windows: introduzione a Active Directory Federation Services 2.0, Windows CardSpace 2.0 e Windows Identity Foundation (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Nell'esempio di progettazione con autenticazione basata sulle attestazioni la farm pubblicata è impostata per l'utilizzo dell'autenticazione classica. Un'alternativa consiste nell'utilizzare l'autenticazione basata sulle attestazioni per la farm pubblicata e nell'implementare un'area separata per gli utenti anonimi. L'elemento più importante della progettazione è costituito dall'uso di un'area separata per gli utenti anonimi in quanto consente di creare l'isolamento tra l'ambiente di sola lettura e quello di lettura-scrittura, indipendentemente dalla modalità di autenticazione implementata. Nella tabella seguente sono mostrate le aree, gli utenti e i tipi di autenticazione illustrati per la farm pubblicata.

Tabella che mostra le aree, gli utenti e l'autenticazione.

Anche in questo caso l'account della ricerca per indicizzazione deve poter accedere almeno a un'area mediante l'autenticazione NTLM. Se necessario, è possibile aggiungere l'autenticazione NTLM a un'area con autenticazione basata sulle attestazioni. Nella modalità classica se nessuna delle aree degli utenti è configurata per utilizzare l'autenticazione NTLM, è possibile configurare l'area personalizzata per tale scopo.

Aree

Per la progettazione delle aree alcune decisioni chiave relative alla progettazione e alla configurazione delle aree seguenti determinano la buona riuscita della distribuzione:

  • Area Predefinita

  • Aree per l'accesso esterno

Nelle sezioni seguenti sono descritte le decisioni incorporate nell'esempio di progettazione.

Requisiti di configurazione dell'area predefinita

L'area che richiede maggiore attenzione è quella predefinita. I requisiti seguenti per la configurazione dell'area predefinita sono imposti da SharePoint Server 2010:

  • Quando la richiesta di un utente non può essere associata a un'area vengono applicati l'autenticazione e i criteri di tale area. Di conseguenza, l'area predefinita deve essere la più sicura.

  • Poiché vengono inviati messaggi di posta elettronica amministrativi con collegamenti relativi all'area Predefinita, in cui sono inclusi messaggi di posta elettronica ai proprietari di siti che stanno raggiungendo i limiti di quota, gli utenti che ricevono questo tipo di messaggi e di avvisi devono essere in grado di accedere ai collegamenti tramite l'area Predefinita. Questo è particolarmente importante per i proprietari di siti.

  • Le raccolte siti con nome basato sull'host sono disponibili solo tramite l'area Predefinita. Per accedere alle raccolte siti con nome basato sull'host, gli utenti devono utilizzare l'area Predefinita.

Configurazione di aree per un ambiente Extranet

In un ambiente Extranet la progettazione delle aree è importante per i due motivi seguenti:

  • Le richieste degli utenti possono essere avviate da numerose reti diverse, ad esempio, nell'esempio di progettazione gli utenti avviano le richieste dalla rete interna, da Internet e dalle reti della società partner.

  • Gli utenti utilizzano contenuto in più applicazioni Web. Nell'esempio di progettazione l'Intranet è composta da tre diverse applicazioni Web. I dipendenti interni e remoti possono inoltre contribuire al contenuto Intranet e amministrarlo in tutte le applicazioni Web: nel sito Intranet, nel sito Web del partner e nel sito Internet della società.

In un ambiente Extranet verificare che vengano seguiti i principi di progettazione seguenti:

  • Configurare le aree in più applicazioni Web in modo che venga eseguito il mirroring reciproco. La configurazione dell'autenticazione e gli utenti previsti devono corrispondere. I criteri associati alle aree possono tuttavia differire tra le applicazioni Web. Assicurarsi ad esempio che l'area Intranet venga utilizzata per gli stessi dipendenti in tutte le applicazioni Web. In altri termini, non configurare l'area Intranet per i dipendenti interni in un'applicazione Web e per i dipendenti remoti in un'altra.

  • Configurare i mapping di accesso alternativo in modo corretto e accurato per ogni area e risorsa. I mapping di accesso alternativo vengono creati automaticamente quando si crea l'area. Tuttavia, è possibile configurare SharePoint Server 2010 per eseguire la ricerca per indicizzazione nel contenuto delle risorse esterne, ad esempio una condivisione di file. I collegamenti a tali risorse esterne devono essere creati manualmente per ogni area utilizzando i mapping di accesso alternativo.

Se non si esegue il mirroring tra le aree delle applicazioni Web e i collegamenti alle risorse esterne non sono appropriati, si può incorrere nei rischi seguenti:

  • I nomi dei server, i nomi DNS e gli indirizzi IP possono essere esposti all'esterno della rete interna.

  • Gli utenti potrebbero non essere in grado di accedere ai siti Web e ad altre risorse.

Servizi

L'architettura dei servizi illustrata mostra l'opzione più complessa per la distribuzione dei servizi nei tre diversi tipi di siti: Intranet, sito Web dei partner e sito Internet della società. Per il sito Web dei partner vengono distribuiti servizi dedicati e partizionati. Un'istanza separata dell'applicazione di servizio metadati gestiti viene distribuita per uso esclusivo della raccolta siti di creazione e modifica e del sito Internet pubblicato.

Un'alternativa molto più semplice consiste nel distribuire una serie di applicazioni di servizio e condividere ogni servizio tra i siti, in base alle esigenze. Questa architettura si basa sulla limitazione per motivi di sicurezza per mostrare agli utenti solo il contenuto al quale possono accedere. Nel diagramma seguente viene illustrato questo approccio più semplice.

Architettura dei servizi

La scelta di progettazione più importante per distribuire le applicazioni di servizio è costituita dalla portata della tassonomia dell'organizzazione. L'architettura dei servizi può essere semplificata condividendo i metadati gestiti, i profili utente e la ricerca tra tutte le applicazioni Web e utilizzando la limitazione per motivi di sicurezza per gestire l'accesso al contenuto. Nell'architettura semplificata descritta in questo articolo, una istanza del servizio dei metadati gestiti viene condivisa tra tutti i siti. Tuttavia, con questa configurazione tutti gli utenti hanno accesso alla tassonomia aziendale. Gli architetti della soluzione devono decidere se implementare più istanze del servizio dei metadati gestiti e stabilire quanto estendere la condivisione dei dati dei profili utente.

Sito Web del partner

Nel caso del sito Web del partner (gruppo personalizzato nella Farm 1), nell'esempio di progettazione sono richiesti almeno i servizi di ricerca e dei metadati gestiti. Se si aggiunge Office Web Apps al gruppo di servizi utilizzati dal sito Web del partner, verificare di disporre delle licenze appropriate per tutti gli utenti del sito, inclusi i partner. L'applicazione di servizio profili utente non è inclusa nell'esempio di progettazione per impedire agli utenti dei partner di consultare dati sulle persone nell'organizzazione.

Nell'architettura semplificata i partner hanno accesso all'intera tassonomia aziendale e possono consultare i dati sulle persone nell'organizzazione. Tuttavia, i risultati della ricerca sono limitati ai siti e al contenuto ai quali i partner possono accedere.

Se i siti del partner richiedono l'isolamento del contenuto tra i progetti, è consigliabile distribuire applicazioni di servizio dedicate e partizionate, come illustrato nell'esempio di progettazione. In questo modo si aumenta la complessità dell'architettura dei servizi ma è possibile garantire che i partner non abbiano accesso ai metadati associati al contenuto della rete Intranet o ad altri progetti nel sito Web del partner.

Sito Internet della società

Nell'architettura di progettazione semplificata, l'applicazione di servizio metadati gestiti viene condivisa anche con il sito Internet pubblicato. Nell'esempio di progettazione un'istanza dedicata dell'applicazione di servizio metadati gestiti viene distribuita nella farm di collaborazione per uso esclusivo della raccolta siti di creazione e modifica e della farm pubblicata.

Se la farm pubblicata è anonima e di sola lettura, non sussiste alcun rischio di esposizione dei metadati gestiti non associati al contenuto pubblicato. Gli utenti anonimi hanno accesso solo al contenuto pubblicato e non possono inoltrare valutazioni o creare altri tipi di metadati.

La condivisione dell'applicazione di servizio metadati gestiti all'interno dell'organizzazione (come illustrato nell'architettura semplificata in questo articolo) consente agli autori di utilizzare la tassonomia aziendale. Diversamente, se si distribuisce un'istanza dedicata del servizio per la creazione e modifica e per la pubblicazione (illustrato nell'esempio di progettazione) si garantisce che i metadati gestiti siano isolati.

Un'istanza dedicata dell'applicazione di servizio ricerca viene distribuita alla farm che ospita il sito Internet della società. Questa è la configurazione consigliata per un sito esposto a Internet.

Alternative per la creazione e modifica e per la pubblicazione

Per il sito Internet della società l'esempio di progettazione illustra un processo di pubblicazione che include l'utilizzo della caratteristica di distribuzione del contenuto per spostare il contenuto da una raccolta siti di creazione e modifica alla farm di pubblicazione. Un'alternativa più semplice a questo approccio consiste nel gestire creazione e modifica direttamente nella farm di pubblicazione. Questo approccio viene generalmente definito creazione e modifica in produzione.

Con questo approccio si semplifica notevolmente la soluzione in quanto si consolidano i servizi in una farm e non è più necessario distribuire il contenuto. L'esempio di progettazione include le aree aggiuntive che possono essere utilizzate dagli autori per lavorare in completa sicurezza senza incidere sugli utenti anonimi. Accertarsi di bloccare l'accesso anonimo in ingresso sulla porta associata alle aree utilizzate dagli autori. Se il sito registra un'attività di creazione e modifica inferiore a 500 scritture all'ora, è improbabile che possa verificarsi un impatto sulle prestazioni del sito pubblicato quando si gestiscono le operazioni di creazione e modifica nell'ambiente di produzione.

SharePoint Server 2010 include caratteristiche di pubblicazione che possono essere utilizzate in questo scenario per garantire che il contenuto non venga esposto a utenti anonimi finché non è pronto. Per ulteriori informazioni, vedere gli articoli seguenti:

Siti di amministrazione

Nell'esempio di progettazione il sito Amministrazione centrale per ogni server farm è ospitato in un server applicazioni per proteggere il sito dal contatto diretto con gli utenti. Se un collo di bottiglia delle prestazioni o una violazione della sicurezza incide sulla disponibilità dei server Web front-end, il sito Amministrazione resta comunque disponibile.

Gli URL con bilanciamento del carico per i siti di amministrazione non sono menzionati nell'esempio di progettazione o in questo articolo. Tra le procedure consigliate sono incluse le seguenti:

  • Se i numeri di porta vengono utilizzati negli URL amministrativi, è consigliabile utilizzare porte non standard. I numeri di porta sono inclusi negli URL per impostazione predefinita. Mentre i numeri delle porte in genere non vengono utilizzati negli URL pubblici, l'utilizzo dei numeri delle porte per i siti di amministrazione può aumentare il livello di sicurezza limitando l'accesso a tali siti alle porte non standard.

  • Creare voci DNS separate per i siti di amministrazione.

In aggiunta a queste procedure consigliate, è possibile bilanciare il carico del sito Amministrazione centrale tra più server applicazioni per garantire la ridondanza.

Pool di applicazioni

In genere vengono implementati pool di applicazioni IIS (Internet Information Services) separati per garantire l'isolamento dei processi dal contenuto. I pool di applicazioni consentono di eseguire più siti nello stesso computer server, mantenendo tuttavia i relativi processi di lavoro e identità. In questo modo è possibile limitare eventuali exploit in un sito che possono offrire l'opportunità all'autore di un attacco di introdurre codice nel server per attaccare altri siti.

In termini pratici, prendere in considerazione l'utilizzo di un pool di applicazioni dedicato per ognuno degli scenari seguenti:

  • Separazione del contenuto autenticato dal contenuto anonimo.

  • Isolamento di applicazioni che archiviano le password e interagiscono con applicazioni aziendali esterne (sebbene sia possibile utilizzare il servizio di archiviazione sicura per questo scopo).

  • Isolamento delle applicazioni in cui gli utenti dispongono di una maggiore libertà di creare e amministrare i siti nonché di collaborare al contenuto.

Nell'esempio di progettazione i pool di applicazioni vengono utilizzati come segue:

  • Ogni sito di amministrazione è ospitato in un pool di applicazioni dedicato. Questo è un requisito di Prodotti SharePoint 2010.

  • Il contenuto dell'Intranet è diviso in due diversi pool di applicazioni. Il contenuto per la collaborazione (siti personali e siti del team) è ospitato in un pool di applicazioni e il contenuto dell'Intranet pubblicato è ospitato in un altro pool di applicazioni. Questa configurazione garantisce l'isolamento dei processi dal contenuto dell'Intranet pubblicato per il quale è più probabile che vengano utilizzate le connessioni dati aziendali.

  • L'applicazione Web del partner è ospitata in un pool di applicazioni dedicato.

  • Il sito Internet della società è ospitato in un pool di applicazioni dedicato nella seconda farm. Se quest'ultima deve anche ospitare contenuto per la collaborazione con il partner, questi due tipi di contenuto (Internet e partner) vengono ospitati in due diversi pool di applicazioni.

Applicazioni Web

Un'applicazione Web è un sito Web IIS creato e utilizzato da Prodotti SharePoint 2010. Ogni applicazione Web è rappresentata da un diverso sito Web in IIS.

È in generale consigliabile utilizzare applicazioni Web dedicate per:

  • Separare il contenuto anonimo da quello autenticato. Nell'esempio di progettazione il sito Internet della società è ospitato in un'applicazione Web e in un pool di applicazioni dedicati.

  • Isolare gli utenti. Nell'esempio di progettazione il sito Web del partner è ospitato in un'applicazione Web e in un pool di applicazioni dedicati per garantire che i partner non abbiano accesso al contenuto dell'Intranet.

  • Applicare le autorizzazioni. Un'applicazione Web dedicata offre l'opportunità di applicare le autorizzazioni mediante i criteri, utilizzando la pagina Criteri per l'applicazione Web in Amministrazione centrale. È ad esempio possibile creare criteri nel sito Internet della società per negare in modo esplicito l'accesso in scrittura a uno o più gruppi di utenti. I criteri per un'applicazione Web vengono applicati indipendentemente dalle autorizzazioni configurate nei singoli siti o documenti all'interno dell'applicazione Web.

  • Ottimizzare le prestazioni dei database. Le applicazioni offrono prestazioni migliori se vengono inserite in database del contenuto con altre applicazioni con caratteristiche dei dati simili. Ad esempio, le caratteristiche dei dati di siti personali includono in genere un numero elevato di siti di dimensioni contenute. Al contrario, i siti del team comprendono in genere un numero limitato di siti di dimensioni molto grandi. Se questi due tipi di siti vengono inseriti in applicazioni Web distinte, i database risultanti saranno composti da dati con caratteristiche simili, con conseguente ottimizzazione delle prestazioni dei database. Nell'esempio di progettazione, i siti personali e quelli del team non presentano requisiti specifici di isolamento dei dati, bensì condividono lo stesso pool di applicazioni. Ciononostante, i siti personali e quelli del team vengono posizionati in applicazioni Web separate per ottimizzare le prestazioni.

  • Ottimizzare la gestibilità. Poiché la creazione di applicazioni Web separate determina la creazione di siti e database distinti, è possibile implementare limiti diversi per il sito (Cestino, scadenza e dimensioni) e negoziare contratti di servizio differenti. È ad esempio possibile concedere più tempo per ripristinare il contenuto del sito personale se non si tratta del tipo di contenuto più importante nell'organizzazione. In questo modo è possibile ripristinare il contenuto più importante prima del contenuto del sito personale. Nell'esempio di progettazione i siti personali sono posizionati in un'applicazione Web separata per consentire agli amministratori di gestire la crescita in modo più accurato rispetto alle altre applicazioni.

Raccolte siti

Le raccolte siti rappresentano il collegamento tra l'architettura logica e l'architettura delle informazioni. Gli obiettivi di progettazione per le raccolte siti nell'esempio di progettazione consistono nel soddisfare i requisiti della progettazione dell'URL e nel creare divisioni logiche di contenuto.

Per soddisfare i requisiti della progettazione dell'URL, ogni applicazione Web include una singola raccolta siti a livello della radice. I percorsi gestiti vengono utilizzati per incorporare un secondo livello di raccolte siti principali. Per ulteriori informazioni sui requisiti per gli URL e l'utilizzo dei percorsi gestiti, vedere "Aree e URL" più avanti in questo articolo. Oltre il secondo livello di raccolte siti, ogni sito è un sito secondario.

Nel diagramma seguente viene illustrata la gerarchia dei siti del team.

Siti del team

Poiché è richiesta una raccolta siti a livello della radice, le scelte di progettazione si concentrano intorno al secondo livello delle raccolte siti. Nell'esempio di progettazione sono incorporate scelte basate sulla natura dell'applicazione.

Contenuto dell'Intranet pubblicato

L'applicazione Web del contenuto dell'Intranet pubblicato si basa sul presupposto che il contenuto pubblicato verrà ospitato da più divisioni all'interno della società. Nell'esempio di progettazione il contenuto di ogni divisione viene ospitato in una raccolta siti separata. In questo modo si ottengono i vantaggi seguenti:

  • Ogni divisione può gestire il proprio contenuto e le autorizzazioni in modo indipendente.

  • Il contenuto di ogni divisione può essere archiviato in un database dedicato.

Gli svantaggi dell'utilizzo di più raccolte siti includono:

  • Le pagine master, i layout di pagina, i modelli, le web part e la struttura di spostamento non possono essere condivisi tra le raccolte siti.

  • È necessario uno sforzo maggiore per coordinare le personalizzazioni e lo spostamento tra le raccolte siti.

In base all'architettura delle informazioni e alla progettazioni dell'applicazione Intranet, il contenuto pubblicato può essere mostrato agli utenti come un'applicazione seamless. In alternativa, ogni raccolta siti può risultare come un sito Web separato.

Siti personali

I siti personali hanno caratteristiche specifiche e le procedura per la distribuzione sono semplici. Nell'esempio di progettazione l'applicazione del sito personale incorpora un sito principale con l'URL http://personale. La prima raccolta principale che viene creata utilizza il modello Host siti personali. Un percorso gestito viene incorporato utilizzando l'inclusione di caratteri jolly, che consente di gestire un numero indefinito di siti creati dagli utenti. Tutti i siti al di sotto del percorso gestito sono raccolte siti indipendenti che ereditano il modello Host siti personali. Il nome utente viene aggiunto all'URL nel formato http://personale/nomeutente. Nella figura seguente sono illustrati i siti personali.

Siti personali

Siti del team

È possibile utilizzare uno dei due approcci seguenti per progettare le raccolte siti in un'applicazione del sito del team:

  • Consentire ai team di creare raccolte siti tramite la creazione siti in modalità self-service. Il vantaggio di questo approccio è che i team possono creare facilmente un sito, in base alle esigenze, senza l'assistenza dell'amministratore. Esistono tuttavia numerosi svantaggi in questo approccio, tra cui:

    • Si perde l'opportunità di implementare una tassonomia ponderata.

    • L'applicazione può diventare difficile da gestire.

    • I siti vengono spesso abbandonati.

    • Non è possibile condividere modelli e strutture di spostamento tra i progetti o i team che possono invece condividere una raccolta siti.

  • Creare un numero definito di raccolte siti per l'organizzazione in base alle specifiche modalità operative. In questo approccio le raccolte siti vengono create da un amministratore di SharePoint. Dopo la creazione della raccolta siti, i team possono creare siti al suo interno in base alle diverse esigenze. Questo approccio offre l'opportunità di implementare una tassonomia ponderata che costituisca la base per la gestione e la crescita dei siti dei team. Vengono create inoltre più opportunità di condividere modelli e strutture di spostamento tra i progetti e i team che condividono una raccolta siti.

Il modello di progettazione incorpora il secondo approccio, che produce una gerarchia delle raccolte siti per i siti dei team simile a quella per il contenuto pubblicato dell'Intranet. La difficoltà principale per gli architetti informatici consiste nel creare un secondo livello di raccolte siti che sia appropriato all'organizzazione. Nella tabella seguente sono illustrati alcuni suggerimenti per i diversi tipi di organizzazioni.

Tipo di organizzazione Tassonomie consigliate per le raccolte siti

Sviluppo prodotti

  • Creare una raccolta siti per ogni prodotto in fase di sviluppo, consentendo ai team partecipanti di creare siti all'interno della raccolta siti.

  • Per ogni progetto di sviluppo a lungo termine, creare una raccolta siti per ogni team numeroso che contribuisce al prodotto. Creare ad esempio una raccolta siti per ognuno dei team seguenti: progettisti, ingegneri e sviluppatori di contenuti.

Ricerca

  • Creare una raccolta siti per ogni progetto di ricerca a lungo termine.

  • Creare una raccolta siti per ogni categoria di progetto di ricerca.

Istituto di istruzione superiore

  • Creare una raccolta siti per ogni dipartimento accademico.

Ufficio legislativo statale

  • Creare una raccolta siti per ogni partito politico. I rappresentanti del governo che condividono l'affiliazione a uno stesso partito possono condividere modelli e strutture di spostamento.

  • Creare una raccolta siti per ogni comitato oppure una raccolta siti per tutti i comitati.

Ufficio legale aziendale

  • Creare una raccolta siti per ogni client aziendale.

Produzione

  • Creare una raccolta siti per ogni linea di prodotti.

Applicazione Web del partner

L'applicazione Web del partner è destinata alla collaborazione con i partner esterni su progetti con ambiti o durata definiti. Da progettazione, i siti nell'applicazione Web del partner non sono concepiti per essere correlati. I requisiti per l'applicazione Web del partner includono la verifica degli aspetti seguenti:

  • I proprietari dei progetti devono poter creare facilmente i siti per la collaborazione con i partner.

  • I partner e gli altri collaboratori devono poter accedere solo al progetto a cui sono assegnati.

  • Le autorizzazioni devono essere gestite dai proprietari dei siti.

  • I risultati delle ricerche di un progetto non devono esporre contenuto di altri progetti.

  • Gli amministratori devono poter identificare ed eliminare agevolmente i siti che non vengono più utilizzati.

Per soddisfare questi requisiti, il modello di progettazione incorpora una raccolta siti per ogni progetto. In questo modo si ottengono i vantaggi seguenti:

  • Singole raccolte siti garantiscono il livello appropriato di isolamento tra i progetti.

  • È possibile implementazione la creazione di siti in modalità self-service.

Poiché l'applicazione Web del partner ospita anche le raccolte siti per lo sviluppo di contenuti per il sito Internet della società, vengono create raccolte siti separate per le attività di creazione e modifica e per la gestione temporanea.

Sito Internet della società

Il sito Internet della società incorpora una singola raccolta siti a livello della radice e tutti i siti al di sotto di essa sono siti secondari. Questa struttura semplifica gli URL per le pagine del sito. Nel diagramma seguente viene illustrata l'architettura del sito Internet della società.

Sito Internet aziendale

Database del contenuto

È possibile utilizzare i due approcci seguenti per incorporare i database del contenuto nella progettazione (l'esempio di progettazione incorpora entrambi gli approcci):

  • Stabilire le dimensioni di destinazione per i database del contenuto con valori di soglia degli avvisi per le dimensioni appropriati. Creare un nuovo database quando si raggiungono i valori di soglia degli avvisi per le dimensioni. Se si utilizza questo approccio, le raccolte siti vengono aggiunte automaticamente al database o ai database disponibili esclusivamente in base alle dimensioni di destinazione. Questo è l'approccio utilizzato più frequentemente.

  • Associare raccolte siti a database del contenuto specifici. Questo approccio consente di inserire una o più raccolte siti in un database dedicato che può essere gestito in modo indipendente dagli altri.

Se si desidera sceglie di associare le raccolte siti a database del contenuto specifici, è possibile eseguire le operazioni seguenti:

  • Utilizzare Windows PowerShell per creare una raccolta siti in un database specifico.

  • Dedicare un database a una singola raccolta siti applicando le impostazioni di capacità del database seguenti:

    • Numero di siti consentiti prima della generazione di un avviso = 1

    • Numero massimo di siti che è possibile creare nel database = 1

  • Aggiungere un gruppo di raccolte siti a un database dedicato completando i passaggi seguenti:

    1. Nell'applicazione Web creare il database e impostarne lo stato su Pronto.

    2. Impostare lo stato di tutti gli altri database su Offline. Mentre i database del contenuto sono offline, non è possibile creare nuove raccolte siti. Le raccolte siti esistenti nei database offline sono tuttavia accessibili per le operazioni sia di lettura che di scrittura.

    3. Creare le raccolte siti. Verranno aggiunte automaticamente al database.

    4. Reimpostare lo stato di tutti gli altri database su Pronto.

Contenuto dell'Intranet pubblicato

Per il contenuto dell'Intranet pubblicato l'esempio di progettazione incorpora un singolo database per semplificare la gestione. Aggiungere database in base alle dimensioni di destinazione, se necessario.

Siti personali

Nel caso dei siti personali, per ottenere efficienza a livello di scalabilità, nell'esempio di progettazione vengono gestiti i database fino alle dimensioni di destinazione massime. Vengono configurate le impostazioni seguenti per raggiungere questo obiettivo:

  • Dimensioni massime spazio di archiviazione del sito: questa impostazione, che può essere configurata nella pagina Modelli quote di Amministrazione centrale, limita le dimensioni di un sito personale.

  • Cestino secondario: questa impostazione, che può essere configurata nella pagina Impostazioni generali applicazione Web, determina quanto spazio aggiuntivo viene allocato al cestino secondario.

  • Numero massimo di siti che è possibile creare nel database: questa impostazione viene configurata quando si crea un database. Calcolare le dimensioni totali consentite dei siti utilizzando i numeri specificati per i precedenti due valori. Determinare quindi, in base all'obiettivo in termini di dimensioni per ogni database, quanti siti possono essere inclusi nel database.

Nell'esempio di progettazione sono descritte le impostazioni di esempio seguenti delle dimensioni, basate sulla dimensione del database di destinazione di 200 GB e sulla dimensione del sito personale di destinazione di 1 GB:

  • Limite dimensioni per sito = 1 GB

  • Dimensioni di destinazione del database = 175 GB

  • Percentuale riservata per il cestino secondario = 15%

  • Numero massimo di siti = 180

  • Avviso numero siti = 150

Quando si raggiunge il livello di avviso per il numero di siti, creare un nuovo database. Dopo aver creato il nuovo database, i nuovi siti personali vengono aggiunti alternativamente al nuovo database e a quello esistente fino a raggiungere il numero massimo di siti per uno dei database.

Siti del team

Anche nel caso dei siti dei team, per ottenere efficienza a livello di scalabilità, nell'esempio di progettazione vengono gestiti i database fino alle dimensioni di destinazione massime. I genere siti dei team per la maggior parte delle organizzazioni sono molto più grandi dei siti personali. Nell'esempio di progettazione sono incluse impostazioni dei database basate su un limite di 30 GB per le raccolte siti. Scegliere un limite appropriato ai siti dei team nell'organizzazione.

Un altro approccio per le organizzazioni che hanno team con significative esigenze di archiviazione consiste nel dedicare un singolo database a ogni raccolta siti principale del team.

Sito Web del partner

Analogamente ai siti personali, per ottenere efficienza a livello di scalabilità nel sito Web del partner, nell'esempio di progettazione vengono gestiti i database fino alle dimensioni di destinazione massime. Nell'esempio di progettazione il sito Web del partner ospita però anche la raccolta siti di creazione e modifica per il sito Internet della società. Di conseguenza, la progettazione del database incorpora entrambi gli approcci:

  • La raccolta siti di creazione e modifica viene ospitata in un database dedicato.

  • Le impostazioni del database e delle dimensioni vengono configurate per gestire tutti gli altri siti e database.

Poiché il sito Web del partner è ospitato in un'applicazione Web dedicata, è possibile creare limiti delle dimensioni che siano più appropriati ai tipi di siti creati. Nell'esempio di progettazione sono descritte le seguenti impostazioni di esempio delle dimensioni:

  • Dimensioni di destinazione del database = 200 GB

  • Quota di archiviazione per sito = 5 GB

  • Numero massimo di siti = 40

  • Raccolta siti di creazione e modifica ospitata in un database dedicato

Sito Internet della società

Utilizzando una singola raccolta siti nella progettazione del sito Internet della società, si utilizza un singolo database per questa applicazione Web.

Aree e URL

Nell'esempio di progettazione viene illustrato come coordinare gli URL tra più applicazioni in una distribuzione aziendale.

Obiettivi della progettazione

Gli obiettivi seguenti influenzano le scelte di progettazione per gli URL:

  • Le convenzioni degli URL non limitano le aree attraverso le quali è possibile accedere al contenuto.

  • Le porte HTTP e HTTPS standard (80 e 443) possono essere utilizzate in tutte le applicazioni dell'esempio di progettazione.

  • I numeri di porta non sono inclusi negli URL. In effetti, i numeri di porta non vengono quasi mai utilizzati negli ambienti di produzione.

Principi della progettazione

Per raggiungere questi obiettivi di progettazione vengono applicati i principi seguenti:

  • Le raccolte siti con nome basato sull'host non vengono utilizzate. Tali raccolte siti sono diverse dalle intestazioni host IIS e non supportano la caratteristica di mapping di accesso alternativo. Tale caratteristica è necessaria per accedere allo stesso contenuto mediante più URL di dominio. Di conseguenza, se si utilizzano raccolte siti con nome basato sull'host, tali siti sono disponibili solo tramite l'area predefinita.

  • Ogni applicazione incorpora una singola raccolta siti radice. Questo è un requisito necessario per l'utilizzo dei mapping di accesso alternativo. Se sono necessarie più raccolta siti radice in un'applicazione Web e si prevede di utilizzare solo l'area predefinita per l'accesso utente, le raccolte siti con nome basato sull'host rappresentano un'opzione valida.

  • Per le applicazioni che includono più raccolte siti principali, in cui ogni raccolta siti rappresenta un team o un progetto principale (ad esempio i siti del team), l'esempio di progettazione incorpora i percorsi gestiti, che garantiscono un controllo maggiore sugli URL per questi tipi di siti.

Svantaggi della progettazione

Il raggiungimento degli obiettivi di progettazione comporta degli svantaggi, tra cui:

  • Gli URL sono più lunghi.

  • Le raccolte siti con nome basato sull'host non vengono utilizzate.

Progettazione di URL con bilanciamento del carico

Quando si crea un'applicazione Web, è necessario scegliere un URL con bilanciamento del carico da assegnare all'applicazione, nonché creare un URL con bilanciamento del carico per ogni area creata in un'applicazione Web. L'URL con bilanciamento del carico include il protocollo, lo schema, il nome host e la porta, se utilizzata, e deve essere univoco tra tutte le applicazioni Web e le aree. Di conseguenza, ogni applicazione e ogni area all'interno delle singole applicazioni richiede un URL univoco per tutto l'esempio di progettazione.

Intranet

Ognuna delle tre applicazioni Web che compongono l'Intranet richiede un URL univoco. Nell'esempio di progettazione il gruppo di destinazione del contenuto dell'Intranet è costituito dai dipendenti interni e da quelli remoti. Nell'esempio di progettazione con autenticazione basata sulle attestazioni i dipendenti utilizzano gli stessi URL per ognuna di queste applicazioni, indipendentemente dal fatto che si trovino nel sito o in remoto. Sebbene questo approccio aggiunga un livello di sicurezza alla progettazione di SharePoint (tutto il traffico è basato su SSL), richiede anche la distribuzione del traffico interno attraverso il firewall o il gateway insieme al traffico remoto oppure l'impostazione di un ambiente DNS diviso per risolvere le richieste interne generate nella rete interna.

Per l'esempio di progettazione con autenticazione classica gli URL sono diversi per i dipendenti interni e per quelli remoti. Nella tabella seguente vengono mostrati gli URL che gli utenti interni e quelli remoti devono utilizzare per accedere a ogni applicazione nell'esempio di progettazione con autenticazione classica.

Applicazione URL dipendente interno URL dipendente remoto

Contenuto dell'Intranet pubblicato

http://fabrikam

https://intranet.fabrikam.com

Siti del team

http://team

https://team.fabrikam.com

Siti personali

http://personale

https://personale.fabrikam.com

Sito Web del partner

Nell'esempio di progettazione al sito Web del partner accedono dipendenti interni, dipendenti remoti e dipendenti dei partner. Nell'esempio di progettazione con autenticazione basata sulle attestazioni ognuno di questi utenti immette lo stesso URL, indipendentemente dal metodo di autenticazione. Nell'esempio di progettazione con autenticazione classica ogni diverso tipo di utenti immette un URL diverso. Sebbene sia i dipendenti remoti che i dipendenti del partner accedano al sito Web del partner utilizzando SSL (HTTPS), ogni gruppo deve disporre di un URL diverso per ottenere i vantaggi legati all'utilizzo di aree separate, ovvero metodi di autenticazione e criteri delle aree diversi. Nella tabella seguente vengono mostrati gli URL che i dipendenti interni, quelli remoti e i partner utilizzano per accedere al sito Web del partner, come mostrato nell'esempio di progettazione con autenticazione classica.

Area URL

URL dipendente interno

http://partnerweb

URL dipendente remoto

https://sitoWebpartnerremoto.fabrikam.com

URL partner

https://sitoWebpartner.fabrikam.com

Sito Internet della società

Il sito Internet della società è un sito pubblico al quale può accedere qualsiasi utente utilizzando l'URL predefinito, http://www.fabrikam.com. Vengono applicati i criteri dell'area Internet, ovvero accesso anonimo e protezione da scrittura.

Per supportare tuttavia le attività di amministrazione e di creazione e modifica nel sito pubblico, l'esempio di progettazione incorpora gli URL per i dipendenti interni e per quelli remoti. È possibile utilizzare i criteri per queste aree al fine di garantire l'accesso appropriato ai gruppi di sicurezza di destinazione per le attività di creazione e modifica e di manutenzione. Sia l'esempio di progettazione con autenticazione classica che quello con autenticazione basata sulle attestazioni utilizzano lo stesso approccio per questa farm. Nella tabella seguente vengono mostrati gli URL per ogni area.

Area URL

URL dipendente interno

http://sitofabrikam

URL dipendente remoto

https://sitofabrikam.fabrikam.com

URL cliente

http://www.fabrikam.com

Utilizzo di inclusioni esplicite e di caratteri jolly per i percorsi URL

Mediante la definizione di percorsi gestiti è possibile specificare le parti dello spazio dei nomi URL di un'applicazione Web da utilizzare per una raccolta siti. È possibile specificare che una raccolta siti o più raccolte siti esistano in corrispondenza di un percorso distinto sotto il sito radice. Senza percorsi gestiti, tutti i siti creati sotto la raccolta siti principale fanno parte di tale raccolta.

È possibile creare i due tipi di percorsi gestiti seguenti:

  • Inclusione esplicita: raccolta siti con l'URL specifico assegnato. Un'inclusione esplicita viene assegnata a un'unica raccolta siti. È possibile creare più inclusioni esplicite in una raccolta siti radice. Un esempio di URL per una raccolta siti creata tramite questo metodo è http://fabrikam/risorseumane. Per ogni percorso esplicito aggiunto si verifica un impatto sulle prestazioni, pertanto è consigliabile non creare più di 20 raccolte siti con un'inclusione esplicita.

  • Inclusione di caratteri jolly: percorso aggiunto all'URL. Tale percorso indica che tutti i siti specificati direttamente dopo il nome del percorso sono raccolte siti univoche. Questa opzione in genere viene utilizzata per le raccolte siti che supportano la creazione di siti in modalità self-service, ad esempio i siti personali. Un esempio di URL per una raccolta siti creata tramite questo metodo è http://personale/privato/utente1.

Nell'esempio di progettazione è mostrato l'utilizzo di entrambi i tipi, come descritto nelle sezioni seguenti.

Inclusioni esplicite: contenuto dell'Intranet pubblicato

Nell'esempio di progettazione le esclusioni esplicite vengono utilizzate nell'applicazione Web del contenuto dell'Intranet pubblicato.

Contenuto dell'Intranet pubblicato

Nell'ambito dell'applicazione Web del contenuto dell'Intranet pubblicato viene utilizzata un'inclusione esplicita per ogni sito secondario, ad esempio per Risorse umane, Strutture e Acquisti. Ognuna di queste raccolte siti può essere associata a un diverso database del contenuto, se necessario. L'uso delle inclusioni esplicite in questo esempio si basa sul presupposto che nell'applicazione Web non vengano creati altri tipi di siti, tra cui le inclusioni di caratteri jolly.

È consigliabile non superare il limite di 20 siti creati mediante un'inclusione esplicita. Se nell'organizzazione è necessario un numero di raccolte siti maggiore, è consigliabile utilizzare un'inclusione di caratteri jolly o le raccolte siti con nome basato sull'host.

Nel modello di progettazione con autenticazione classica l'utilizzo delle inclusioni esplicite determina la visualizzazione degli URL nella tabella seguente.

Dipendente interno (area Intranet) Dipendente remoto (area predefinita)

http://fabrikam

https://intranet.fabrikam.com

http://fabrikam/risorseumane

https://intranet.fabrikam.com/risorseumane

http://fabrikam/strutture

https://intranet.fabrikam.com/strutture

http://fabrikam/acquisti

https://intranet.fabrikam.com/acquisti

In questo esempio la raccolta siti radice, http://fabrikam, rappresenta l'home page predefinita per l'Intranet. Questo sito è destinato a ospitare il contenuto per gli utenti.

Inclusioni di caratteri jolly: siti del team, siti personali e applicazione Web del partner

I siti del team, i siti personali e l'applicazione Web del partner incorporano l'utilizzo di un'inclusione di caratteri jolly. Questo tipo di inclusioni è ideale per le applicazioni che consentono agli utenti di creare raccolte siti personali e per le applicazioni Web che includono numerose raccolte siti. Un'inclusione di caratteri jolly indica che l'elemento dopo il carattere jolly è un sito radice di una raccolta siti.

Siti del team

Nell'ambito dell'applicazione siti del team l'inclusione di caratteri jolly viene utilizzata per ogni raccolta siti del team. È consigliabile limitare il numero di siti del team principali entro una soglia gestibile. Inoltre la tassonomia per i siti del team deve essere logica per le modalità operative dell'azienda.

Nel modello di progettazione con autenticazione classica l'utilizzo delle inclusioni di caratteri jolly determina la visualizzazione degli URL nella tabella seguente.

Dipendente interno (area Intranet) Dipendente remoto (area predefinita)

http://team/siti/Team1

https://team.fabrikam.com/siti/Team1

http://team/siti/Team2

https://team.fabrikam.com/siti/Team2

http://team/siti/Team3

https://team.fabrikam.com/siti/Team3

In questo esempio la raccolta siti radice, http://team, non deve necessariamente ospitare il contenuto per gli utenti.

Siti personali

Nei siti personali è supportata la creazione siti in modalità self-service. Quando un utente che sta esplorando l'Intranet fa clic per la prima volta su Sito personale, viene creato automaticamente un sito personale per l'utente. Nell'esempio di progettazione i siti personali presentano un'inclusione di caratteri jolly denominata /privato (http://personale/privato). Il nome utente viene aggiunto automaticamente all'URL.

Nel modello di progettazione con autenticazione classica gli URL assumono il formato mostrato nella tabella seguente.

Dipendente interno (area Intranet) Dipendente remoto (area predefinita)

http://personale/privato/utente1

https://personale.fabrikam.com/privato/utente1

http://personale/privato/utente2

https://personale.fabrikam.com/privato/utente2

http://personale/privato/utente3

https://personale.fabrikam.com/privato/utente3

Applicazione Web del partner

L'applicazione Web del partner è progettata per consentire ai dipendenti di creare agevolmente siti sicuri per la collaborazione con partner esterni. Per supportare questo obiettivo è consentita la creazione siti in modalità self-service.

Nel modello di progettazione con autenticazione classica l'applicazione Web del partner presenta un'inclusione di caratteri jolly denominata /siti (http://applicazioneWebpartner/siti). Di conseguenza gli URL hanno il formato mostrato nella tabella seguente.

Dipendente interno (area Intranet) Dipendente remoto (area predefinita)

http://applicazioneWebpartner/siti/progetto1

https://applicazioneWebpartnerremoto.fabrikam.com/siti/progetto1

http://applicazioneWebpartner/siti/progetto2

https://applicazioneWebpartnerremoto.fabrikam.com/siti/progetto2

http://applicazioneWebpartner/siti/progetto3

https://applicazioneWebpartnerremoto.fabrikam.com/siti/progetto3

I collaboratori del partner possono accedere ai siti Web del partner utilizzando gli URL elencati nella tabella seguente.

Partner (area Extranet)

https://applicazioneWebpartner.fabrikam.com/siti/progetto1

https://applicazioneWebpartner.fabrikam.com/siti/progetto2

https://applicazioneWebpartner/fabrikam.com/progetto3

L'eccezione per l'applicazione Web del partner, come illustrato negli esempi di progettazione, è rappresentata dalla raccolta dedicata alla creazione e modifica del contenuto per il sito Internet della società. Per questa raccolta siti viene utilizzata un'inclusione esplicita. Questo è un esempio in cui vengono utilizzate sia le inclusioni esplicite che le inclusioni di caratteri jolly nella stessa applicazione Web.

Criteri per le aree

È possibile creare criteri per un'applicazione Web allo scopo di applicare le autorizzazioni a livello dell'applicazione Web. I criteri possono essere definiti per l'applicazione Web in generale o solo per un'area specifica. I criteri applicano autorizzazioni a tutto il contenuto dell'applicazione Web o dell'area. Le autorizzazioni applicate tramite criteri sostituiscono tutte le altre impostazioni di sicurezza configurate per i siti e il contenuto. È possibile configurare criteri basati sugli utenti o sui gruppi di utenti, ma non sui gruppi di SharePoint. Se si aggiungono o si modificano criteri di un'area, è necessario ripetere la ricerca per indicizzazione dei siti per individuare le nuove autorizzazioni.

I criteri non vengono utilizzati nell'esempio di progettazione con autenticazione basata sulle attestazioni per la farm di collaborazione in cui sono abilitati più tipi di autenticazione in un'unica area. I criteri vengono implementati nell'esempio di progettazione con autenticazione classica e nella farm pubblicata dell'esempio di progettazione con autenticazione basata sulle attestazioni in cui è richiesta l'autenticazione di Windows. Se si utilizzano criteri nella farm pubblicata si aggiunge un ulteriore livello di sicurezza tra gli utenti anonimi e gli utenti che hanno accesso ai siti gestiti.

Gli esempi di progettazione mostrano esempi di vari criteri per ottenere gli scopi seguenti:

  • Negare l'accesso in scrittura al contenuto pubblicato.

  • Verificare che gli autori e i tester dispongano del tipo di accesso appropriato al contenuto pubblicato.