Partager via

Exemple de conception : déploiement en entreprise (SharePoint Server 2010)

  • Article

 

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

Dernière rubrique modifiée : 2017-01-18

Cet article décrit une implémentation concrète des composants d’une architecture logique permettant d’obtenir une conception exploitable. Cet article doit être utilisé avec les modèles de conception suivants :

  • Exemple de conception : portail d’entreprise avec authentification classique

  • Exemple de conception : portail d’entreprise avec authentification basée sur les revendications

Pour télécharger ces modèles, voir Exemples de conception SharePoint Server 2010 : portail d’entreprise avec authentification classique ou authentification basée sur les revendications (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x40C) (éventuellement en anglais).

Dans cet article :

  • À propos des exemples de conception

  • Objectifs globaux de conception

  • Batteries de serveurs

  • Utilisateurs, zones et authentification

  • Services

  • Autres options de création et de publication

  • Sites d’administration

  • Pools d’applications

  • Applications Web

  • Collections de sites

  • Bases de données de contenu

  • Zones et URL

  • Stratégies de zone

Les exemples de conception illustrent un déploiement générique en entreprise de Microsoft SharePoint Server 2010. Ils appliquent la plupart des composants d’une architecture logique et montrent la manière dont ils sont incorporés dans la conception globale. Les deux exemples illustrent les mêmes services et sites, mais utilisent deux méthodes d’authentification distinctes :

  • Authentification classique : cet exemple de conception représente un chemin de mise à niveau des sites de Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010. Il intègre l’authentification classique ; autrement dit les méthodes d’authentification Windows sont utilisées pour accéder au site. Une zone distincte est utilisée pour chaque méthode d’authentification. Alors que l’authentification Windows est utilisée pour les sites SharePoint, un produit de pare-feu ou de passerelle peut être configuré pour utiliser l’authentification par formulaires afin de collecter les informations d’identification Windows qui sont transmises à SharePoint Server 2010. Des comptes d’employés partenaires sont ajoutés à l’annuaire d’entreprise.

  • Authentification basée sur les revendications : cet exemple de conception intègre le nouveau modèle d’authentification basé sur les revendications. Plusieurs fournisseurs d’authentification et types d’authentification sont implémentés dans une zone unique. L’authentification basée sur les revendications prend en charge l’authentification basée sur les formulaires, l’authentification basée sur les jetons SAML et l’authentification Windows. Cet exemple de conception ajoute des entreprises partenaires en utilisant l’authentification basée sur les jetons SAML pour l’authentification directe par rapport à des annuaires de partenaires. Différentes options de fournisseur sont disponibles pour les comptes d’employés partenaires.

Utilisez le modèle de conception représentant le mieux vos besoins en matière d’authentification.

Cet article décrit les objectifs de conception des exemples et explique comment atteindre ces objectifs en utilisant les composants de l’architecture logique illustrés dans les exemples.

À propos des exemples de conception

Les exemples de conception illustrent un déploiement en entreprise pour une entreprise fictive nommée Fabrikam, Inc. Le déploiement comprend deux batteries de serveurs. L’une d’elles héberge l’intranet de l’entreprise et le site Web partenaire. L’autre héberge le site Web de l’entreprise (www.fabrikam.com). Le reste de cette section décrit ces sites de niveau supérieur.

Intranet

L’intranet de l’entreprise inclut les sites suivants :

  • Contenu intranet publié (comme HRweb)

  • Sites de collaboration des équipes

  • Sites Mon site

Réunis, ces sites forment les sites de contenu et de collaboration que les employés utiliseront quotidiennement. Individuellement, chacune de ces applications représente un contenu distinct. Chaque type de contenu :

  • met l’accent sur différentes fonctionnalités de SharePoint Server 2010 ;

  • héberge des données aux caractéristiques différentes ;

  • est soumis à un profil d’utilisation différent ;

  • requiert une stratégie de gestion des autorisations différentes.

Par conséquent, les choix de conception au niveau de chacune de ces applications visent à optimiser les performances et la sécurité de chaque application.

La conception des applications de service réunit ces trois applications afin de fournir :

  • la navigation à travers les applications ;

  • la recherche à l’échelle de l’entreprise ;

  • des données de profil et des métadonnées d’entreprise partagées.

Le diagramme qui suit illustre les trois applications constituant l’intranet de l’entreprise.

Sites intranet

Les URL utilisées dans cette illustration proviennent du modèle de conception avec authentification classique.

Application Web partenaire

L’application Web partenaire héberge des sites disponibles en externe en vue de la collaboration sécurisée avec les entreprises partenaires et les partenaires individuels. Cette application doit permettre aux employés de facilement créer des sites pour une collaboration sécurisée. Les partenaires ne sont pas autorisés à accéder aux autres types de contenus hébergés sur la batterie de serveurs. La conception de zones et d’applications de service permet de répondre à cet objectif.

Dans l’exemple de conception, l’application Web partenaire est hébergée par la même batterie que le contenu intranet.

Site Internet de l’entreprise

Le site Internet de l’entreprise est la présence de l’entreprise sur Internet. Le contenu est rendu disponible aux utilisateurs en configurant l’accès anonyme avec des autorisations de lecture seule. Les facteurs déterminant les choix de conception pour cette application sont les suivants :

  • Isolation du contenu : les clients ne peuvent pas accéder à tout autre type de contenu hébergé sur la batterie de serveurs.

  • Gestion ciblée : l’accès authentifié est fourni aux employés qui gèrent le site Web en réalisant des tâches d’administration et de création.

  • Création et publication de contenu sécurisé : une collection de sites distincte est hébergée sur une batterie A dans l’application Web partenaire pour la création. Cela permet la collaboration et le développement de contenu en toute sécurité avec les employés internes et distants, ainsi qu’avec les partenaires éditoriaux spécialisés dans le développement de sites Web ou la création de contenu. La publication de contenu est configurée de manière à ce que le contenu soit automatiquement publié de la collection des sites de création de la première batterie vers la collection de sites de production de la seconde batterie. Le diagramme qui suit illustre le processus de publication.

Sites publiés

Objectifs globaux de conception

L’exemple de conception propose des implémentations concrètes des fonctionnalités de SharePoint Server 2010 dans divers types courants d’applications. L’implémentation de chacune des applications individuelles est étudiée dans cet article. Les objectifs de conception clés de cet exemple de conception sont les suivants :

  • Utilisation d’un nombre minimal de batteries de serveurs pour héberger les types les plus courants de sites Web généralement requis par une entreprise, autrement dit, des sites intranet, extranet et Internet.

  • Création d’une structure pour la conception d’un environnement évolutif. Les choix de conception pour les applications individuelles n’empêchent pas l’ajout de nouvelles applications. Par exemple, un déploiement initial peut inclure uniquement les sites de collaboration des équipes ou uniquement les trois applications qui composent un intranet (sites d’équipes, sites Mon site et contenu intranet publié). L’utilisation d’un modèle d’architecture logique similaire vous permet d’ajouter des applications à la solution sans affecter les applications initiales. En d’autres termes, la conception n’intègre aucun choix de conception limitant l’utilisation de l’environnement.

  • Autorisation d’accès de différents groupes d’utilisateurs sans compromettre la sécurité du contenu dans les différents types de sites. Les utilisateurs de différentes zones du réseau (interne et externe) avec des fournisseurs d’authentification différents peuvent participer à une collaboration. Par ailleurs, les utilisateurs peuvent uniquement accéder au contenu qui leur est destiné. En suivant un modèle d’architecture logique similaire, vous laissez la possibilité de donner l’accès aux utilisateurs situés à différents emplacements et poursuivant des objectifs distincts. Par exemple, votre conception initiale peut être uniquement destinée à l’accès des employés internes. Pourtant, en utilisant une conception similaire, vous laissez la possibilité d’autoriser aussi les employés distants, les employés partenaires, les entreprises partenaires et les clients.

  • Faire en sorte que la conception puisse être utilisée dans un environnement extranet. Des choix de conception délibérés sont faits pour s’assurer que les batteries de serveurs puissent être déployées de manière sécurisée dans un réseau de périmètre.

Le reste de cet article présente chacun des composants logiques de l’exemple de conception (de haut en bas) et explique les choix de conception qui sont appliqués au modèle de conception. Le but de cette approche est de montrer les différentes configurations possibles des composants de l’architecture logique en fonction de l’application.

Batteries de serveurs

Le modèle de conception utilise deux batteries de serveurs. Cette section indique les exigences en matière de licences qui peuvent affecter le nombre de serveurs requis dans un environnement d’entreprise et décrit les topologies des batteries de serveurs qui sont illustrées dans le modèle de conception.

Exigences en matière de licences

Pour héberger du contenu intranet et des sites Internet, deux serveurs sont au minimum requis. Ce nombre est nécessaire pour répondre aux exigences en matière de licences.

Les deux licences serveur suivantes sont disponibles pour SharePoint Server 2010:

  • Microsoft SharePoint Server 2010, licence serveur : cette licence doit être utilisée pour le contenu intranet de collaboration. Elle requiert l’utilisation de licences d’accès client (CAL, Client Access Licenses). Si vous créez des sites pour la collaboration entre partenaires, vous devez veiller à acheter le nombre requis de CAL pour les employés partenaires.

  • Microsoft SharePoint Server 2010 pour sites Internet : cette licence est uniquement destinée aux sites Web sur Internet. Elle ne requiert aucune CAL. Si vous créez des sites pour la collaboration entre partenaires, vous n’avez pas besoin d’acheter des CAL supplémentaires. Toutefois, vous ne pouvez pas créer de sites destinés exclusivement à être utilisés par vos employés.

Notes

Ces licences ne peuvent pas être combinées sur le même ordinateur serveur ou sur la même batterie de serveurs.

Étant données ces options de licence, le choix de conception le plus critique consiste à décider quelle batterie doit héberger l’application Web partenaire. Dans l’exemple de conception, la première batterie héberge le contenu intranet et la seconde le site Internet de l’entreprise. Conformément aux termes de licence, seule l’une des deux batteries peut héberger l’application Web partenaire.

Le choix de la batterie qui hébergera l’application Web partenaire est guidé par les considérations suivantes:

  • Nature de la collaboration : si l’objectif principal d’un site extranet partenaire est de communiquer des informations de manière sécurisée à de nombreux partenaires, le choix le plus économique est une batterie de serveurs Internet. Par contre, préférez de loin une batterie de serveurs intranet si l’objectif principal est de travailler en collaboration avec un petit nombre d’employés. Choisissez l’option que vous permet d’optimiser la batterie pour le rôle qui lui est destiné.

  • Nombre d’employés partenaires : si vous collaborez avec de nombreux employés partenaires et si la maîtrise des coûts est un facteur important, vous pouvez héberger de manière sécurisée à la fois le contenu de collaboration et le contenu anonyme sur une batterie de serveurs Internet à l’aide de la licence de sites Internet.

Dans l’exemple de conception, l’application Web partenaire est destinée à la collaboration intensive avec les entreprises partenaires, avec notamment le développement et le test du site Internet de l’entreprise. Le fait de placer l’application Web partenaire sur la première batterie permet à l’entreprise d’optimiser chacune des deux batteries pour le rôle qui lui est destiné (collaboration versus contenu en lecture seule). Toutefois, l’une ou l’autre batterie peut héberger l’application Web partenaire.

L’exemple de conception inclut Microsoft Office Web Apps. Office Web Apps requiert une licence client Microsoft Office 2010. En d’autres termes, si vous mettez Office Web Apps à disposition des partenaires, vous devez également leur acheter des licences client Office 2010.

Topologie des batteries de serveurs

Chaque batterie de serveurs de l’exemple de conception est composée de cinq serveurs présentant la topologie suivante :

  • Deux serveurs Web frontaux

  • Un serveur d’applications

  • Deux serveurs de bases de données, en cluster ou en miroir

L’exemple de conception illustre l’architecture logique de SharePoint Server 2010 en montrant que :

  • tous les sites sont mis en miroir à travers les serveurs Web frontaux ;

  • le site Administration centrale est installé sur un serveur d’applications pour le protéger contre l’accès direct par les utilisateurs.

Dans les faits, le nombre d’ordinateurs serveurs et la topologie de la batterie de serveurs ne sont pas fondamentaux pour l’architecture logique, sauf pour augmenter la capacité et les performances si nécessaire. L’architecture logique peut être conçue indépendamment de la topologie de la batterie de serveurs. Le processus de planification des performances et de la capacité vous aidera à dimensionner la batterie de serveurs en fonction de vos objectifs de performances et de capacité. Pour plus d’informations, voir Gestion de la performance et de la capacité (SharePoint Server 2010).

Montée en puissance au-delà de deux batteries

Votre entreprise peut avoir besoin de plus de deux batteries. Les sites suivants peuvent nécessiter une batterie dédiée :

  • Sites Mon site : de nombreuses organisations avec beaucoup d’employés ou d’étudiants choisissent d’héberger leurs sites Mon site sur une batterie de serveurs dédiée.

  • Sites de création et de test : si le contenu publié est complexe ou volumineux, les phases de création et le test peuvent être optimisées en hébergeant ces sites sur une batterie dédiée à serveur unique à l’aide de la licence Microsoft SharePoint Server 2010 pour sites Internet. Par exemple, la publication de contenu incluant des métadonnées balisées accroît la complexité de l’exemple de conception de services entre la batterie de création et la batterie publiée, notamment le partage du service entre les batteries et la prise de décision sur la manière dans le service peut être partagé dans d’autres types d’applications Web dans une batterie à usages multiples.

  • Sites partenaires : les exigences de sécurité et d’isolation peuvent justifier une batterie dédiée pour la collaboration entre partenaires. Le contenu interne seulement est ainsi physiquement isolé du contenu développé en collaboration avec des partenaires externes.

Utilisateurs, zones et authentification

Lorsque vous créez une application Web dans SharePoint Server 2010, vous devez choisir entre l’authentification basée sur les revendications et l’authentification en mode classique. Le mode d’authentification détermine la manière dont les comptes sont utilisés en interne par SharePoint Server 2010. Le tableau ci-dessous résume ces deux approches.

Type d’authentification

Description

Recommandations

Authentification en mode classique

Les comptes d’utilisateurs sont traités par SharePoint Server 2010 comme des comptes Windows Active Directory traditionnels. Les protocoles d’authentification suivants sont pris en charge : Kerberos, NTLM, Basic, Digest et anonyme.

L’authentification basée sur les formulaires n’est pas prise en charge.

Une seule méthode d’authentification peut être configurée sur une zone.

L’authentification en mode classique est recommandée pour la mise à niveau des environnements Microsoft Office SharePoint Server 2007, dans lesquels l’authentification basée sur les formulaires n’est pas exigée.

La migration des utilisateurs n’est pas nécessaire si vous effectuez une mise à niveau et sélectionnez l’authentification en mode classique.

Authentification basée sur les revendications

Les comptes d’utilisateurs sont traités par SharePoint Server 2010 comme des identités basées sur les revendications. Les comptes Windows sont automatiquement convertis en identités basées sur les revendications. Ce mode prend par ailleurs en charge l’authentification basée sur les formulaires et l’authentification auprès d’un fournisseur d’identités approuvé.

Plusieurs types d’authentification peuvent être configurés sur une même zone.

L’authentification basée sur les revendications est recommandée pour les nouveaux déploiements SharePoint Server 2010. Elle est exigée en cas de mise à niveaux de solutions Office SharePoint Server 2007 qui requièrent l’authentification basée sur les formulaires.

Les deux modèles de conception présentés dans cet article représentent ces deux options. Les sections qui suivent étudient spécifiquement la manière dont l’authentification est incorporée dans les deux modèles de conception.

Exemple de conception avec authentification en mode classique

L’exemple de conception qui utilise l’authentification en mode classique intègre l’approche traditionnelle d’une zone par type d’authentification qui était proposée dans la version antérieure. C’est pourquoi cet exemple propose un chemin de mise à niveau de Office SharePoint Server 2007 vers SharePoint Server 2010.

La seule mise en garde est que l’authentification basée sur les formulaires n’est pas prise en charge dans l’authentification en mode classique. Avec l’authentification classique, tous les comptes authentifiés doivent résider dans les services de domaine Active Directory. Il est recommandé aux utilisateurs qui accèdent à distance aux sites d’utiliser l’authentification basée sur les formulaires dans le produit de pare-feu ou de passerelle pour collecter les informations d’identification Windows qui sont transmises à la batterie SharePoint.

L’exemple d’authentification en mode classique illustre quatre classes d’utilisateurs, chacune affectée à une zone distincte. Dans chaque application Web, vous pouvez créer jusqu’à cinq zones en utilisant l’un des noms de zone disponibles : Par défaut, Intranet, Internet, Personnalisé ou Extranet.

Le tableau ci-dessous indique les zones, utilisateurs et type d’authentification utilisés dans l’exemple de conception avec authentification en mode classique.

Tableau avec utilisateurs, zones et authentification.

Le compte d’analyse de recherche requiert l’accès à au moins une zone à l’aide de l’authentification NTLM. Si aucune des zones n’est configurée pour utiliser l’authentification NTLM, configurez la zone personnalisée pour qu’elle utilise l’authentification NTLM.

Exemple de conception avec authentification basée sur les revendications

L’authentification basée sur les revendications est recommandée pour tous les nouveaux déploiements de SharePoint Server 2010 et est requise pour la mise à niveau de solutions Office SharePoint Server 2007 qui requièrent l’authentification basée sur les formulaires. En plus de proposer les méthodes d’authentification Windows standard, l’authentification basée sur les revendications permet l’authentification par rapport à d’autres annuaires, comme Windows Live ID, Active Directory Federation Services 2.0 ou un fournisseur d’identités tiers prenant en charge les jetons SAML et le protocole WS Federation.

Dans le modèle de conception avec authentification basée sur les revendications, l’authentification basée sur les revendications est utilisée dans la batterie de collaboration. Ce mode d’authentification permet d’utiliser plusieurs types d’authentification dans la même zone. Le modèle de conception utilise la zone Par défaut pour tous les types d’authentification. Le tableau ci-dessous indique les zones, utilisateurs et type d’authentification utilisés dans l’exemple de conception pour la batterie de collaboration.

Tableau avec utilisateurs, zones et authentification.

Dans l’exemple de conception, le site de contenu Intranet publié, les sites d’équipe et les sites Mon site sont uniquement accessibles par les employés, qu’ils se trouvent à l’intérieur ou à l’extérieur du réseau. L’exemple de conception implémente une seule URL (en utilisant le protocole SSL) qui peut être utilisée en interne comme en externe. Des comptes Active Directory sont utilisés. Si nécessaire, le protocole LDAP peut être utilisé avec l’authentification basée sur les formulaires ou avec l’authentification basée sur les jetons SAML (cette dernière nécessitant une configuration supplémentaire).

Dans l’exemple de conception, l’application Web partenaire représente un site extranet accessible par les employés partenaires et les entreprises partenaires. L’utilisation de l’authentification basée sur les revendications dans ce scénario requiert qu’un ou plusieurs services d’émission de jeton de sécurité (STS, Secure Token Service) externes soient approuvés. Cela peut être fait selon l’une des deux approches suivantes :

  • La batterie SharePoint peut être configurée pour approuver un STS externe, comme le STS associé à Windows Live (pour l’authentification de partenaires individuels) ou le STS qui réside dans une entreprise partenaire (pour l’authentification directe par rapport à l’annuaire du partenaire).

  • Le STS à l’intérieur de l’environnement d’entreprise peut être configuré de manière à approuver un STS externe. Cette relation doit être établie de manière explicite par les administrateurs dans les deux organisations. Dans ce scénario, la batterie SharePoint est configurée de manière à n’approuver que le STS qui réside dans son propre environnement d’entreprise. Ce STS interne vérifie le jeton qu’il reçoit du STS externe, puis émet un jeton qui autorise l’utilisateur partenaire à accéder à la batterie SharePoint. Cette approche est recommandée.

Plutôt que d’implémenter un environnement basé sur les revendications pour authentifier les partenaires, vous pouvez utiliser l’authentification basée sur les formulaires et gérer ces comptes à l’aide d’un magasin distinct, comme une base de données.

Pour plus d’informations sur l’implémentation d’un environnement d’authentification basée sur les revendications, voir le Livre blanc intitulé : Identités basée sur les revendications pour Windows : une introduction à Active Directory Federation Services 2.0, Windows CardSpace 2.0 et Windows Identity Foundation (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x40C) (éventuellement en anglais).

Dans le modèle de conception avec authentification basée sur les revendications, la batterie publiée est configurée de manière à utiliser l’authentification en mode classique. Vous pouvez également faire le choix d’utiliser également l’authentification basée sur les revendications pour la batterie publiée et d’implémenter une zone distincte pour les utilisateurs anonymes. L’élément important de la conception est d’utiliser une zone distincte pour les utilisateurs anonymes afin d’isoler l’environnement en lecture seule de l’environnement en lecture-écriture, quel que soit le mode d’authentification implémenté. Le tableau suivant indique les zones, utilisateurs et type d’authentification illustrés pour la batterie publiée.

Tableau avec utilisateurs, zones et authentification

Là encore, le compte d’analyse de recherche requiert l’accès à au moins une zone à l’aide de l’authentification NTLM. L’authentification NTLM peut être ajoutée si nécessaire à la zone d’authentification basée sur les revendications. En mode classique, si aucune des zones n’est configurée pour utiliser l’authentification NTLM, configurez la zone personnalisée de sorte qu’elle utilise l’authentification NTLM.

Zones

Lors de la conception des zones, plusieurs décisions clés sont fondamentales pour le succès du déploiement. Ces décisions portent sur la conception et la configuration des zones suivantes :

  • zone Par défaut ;

  • zones pour l’accès externe.

Les sections qui suivent décrivent les décisions qui sont intégrées dans le modèle de conception.

Configuration requise pour la zone Par défaut

La zone Par défaut requiert la plus grande réflexion. SharePoint Server 2010 exige que la zone Par défaut soit configurée de la manière suivante :

  • Lorsqu’une demande utilisateur ne peut pas être associée à une zone, l’authentification et les stratégies de la zone Par défaut sont utilisées. Par conséquent, la zone Par défaut doit être la zone la plus sécurisée.

  • Des messages électroniques d’administration contenant des liens sont envoyés à partir de la zone Par défaut. Cela inclut les courriers envoyés aux propriétaires de sites qui approchent les limites de quota. Par conséquent, les utilisateurs qui reçoivent ces types de messages électroniques et des alertes doivent pouvoir accéder aux liens via la zone Par défaut. Ceci est particulièrement important pour les propriétaires de sites.

  • Les collections de sites nommées par l’hôte sont uniquement disponibles via la zone Par défaut. Tous les utilisateurs susceptibles d’accéder aux collections de sites nommées par l’hôte doivent avoir accès à la zone Par défaut.

Configuration des zones pour un environnement extranet

Dans un environnement extranet, la conception des zones est essentielle pour les deux raisons suivantes :

  • Les demandes des utilisateurs peuvent être lancées depuis plusieurs réseaux différents. Dans l’exemple de conception, les utilisateurs lancent des demandes depuis le réseau interne, Internet et les entreprises partenaires.

  • Les utilisateurs consomment le contenu à travers plusieurs applications Web. Dans l’exemple de conception, l’intranet se compose de trois applications Web distinctes. Par ailleurs, les employés internes et distants peuvent éventuellement contribuer au contenu ou l’administrer à travers toutes les applications Web : intranet, application Web partenaire et site Internet de l’entreprise.

Dans un environnement extranet, assurez-vous que les principes de conception suivants sont respectés :

  • Configurez les zones dans différentes applications Web de façon à les mettre en miroir les unes des autres. La configuration de l’authentification et les utilisateurs prévus doivent être identiques. Toutefois, les stratégies associées aux zones peuvent différer d’une application Web à l’autre. Par exemple, assurez-vous que la zone Intranet est utilisée pour les mêmes employés dans toutes les applications Web. En d’autres termes, ne configurez pas la zone Intranet pour les employés internes dans une application Web et pour les employés distants dans une autre application Web.

  • Configurez les mappages des accès de substitution de manière appropriée et avec précision pour chaque zone et chaque ressource. Les mappages des accès de substitution sont automatiquement créés lorsque vous créez la zone. Toutefois, SharePoint Server 2010 peut être configuré pour analyser le contenu dans des ressources externes, comme un partage de fichiers. Les liens vers ces sources externes doivent être créés manuellement pour chaque zone à l’aide de mappages d’accès de substitution.

Si les zones dans différentes applications Web ne sont pas mises en miroir les unes avec les autres, et que les liens vers des ressources externes ne sont pas appropriés, les risques suivants sont encourus :

  • Les noms de serveur, les noms DNS et les adresses IP peuvent potentiellement être exposés à l’extérieur du réseau interne.

  • Les utilisateurs peuvent être dans l’incapacité d’accéder aux sites Web et à d’autres ressources.

Services

L’architecture des services illustrée montre l’option la plus complexe de déploiement de services à travers les trois types différents de sites : intranet, site Web partenaire et site Internet de l’entreprise. Des services dédiés et partitionnés sont déployés pour le site Web partenaire. Une instance distincte de l’application de service Métadonnées gérées est déployée pour un usage exclusif par la collection de sites de création et le site Internet publié.

Une autre option beaucoup plus simple consiste à déployer un jeu d’applications de service et de partager chaque service, en fonction des besoins, à travers les sites. Cette architecture repose sur le filtrage de sécurité de manière à n’afficher que le contenu auquel les utilisateurs ont accès. Le diagramme suivant illustre cette approche simplifiée.

Architecture des services

La principale décision de conception à prendre pour le déploiement d’applications de service concerne la largeur de diffusion de la taxonomie de l’entreprise. L’architecture des services peut être simplifiée en partageant les métadonnées gérées, le profil utilisateur et la recherche à travers toutes les applications Web et en laissant le filtrage de sécurité gérer l’accès au contenu. Dans l’architecture simplifiée décrite dans cet article, une instance du service Métadonnées gérées est partagée à travers tous les sites. Toutefois, avec cette configuration, tous les utilisateurs ont accès à la taxonomie de l’entreprise. Les architectes de solutions doivent décider si plusieurs instances du service Métadonnées gérées doivent ou non être implémentées. Ils devront également décider du niveau de partage des données de profil utilisateur.

Site Web partenaire

Pour le site Web partenaire (groupe personnalisé dans la Batterie 1), les services minimum utilisés dans le modèle de conception sont Recherche et Métadonnées gérées. Si vous ajoutez Office Web Apps au groupe de services utilisés par le site Web partenaire, assurez-vous de disposer des licences appropriées pour tous les utilisateurs de ce site, y compris les partenaires. L’application de service Profil utilisateur n’est pas incluse dans l’exemple de conception afin d’empêcher les utilisateurs partenaires de parcourir les données sur les employés de l’organisation.

Dans l’architecture simplifiée, les partenaires ont accès à la taxonomie complète de l’entreprise et peuvent parcourir les données sur les employés de l’entreprise. Toutefois, la recherche limite les résultats aux sites et contenus auxquels les partenaires ont accès.

Si vos sites partenaires ont besoin que le contenu de chaque projet soit isolé, le déploiement d’applications de service dédiées et partitionnées est approprié, comme illustré dans l’exemple de conception. Cela rend plus complexe l’architecture des services mais garantit que les partenaires n’ont pas accès aux métadonnées associées au contenu Intranet ni à d’autres projets dans le site Web partenaire.

Site Internet de l’entreprise

Dans l’architecture de conception simplifiée, l’application de service Métadonnées gérées de l’entreprise est également partagée avec le site Internet publié. Dans l’exemple de conception, une instance dédiée de l’application de service Métadonnées gérées est déployée dans la batterie de collaboration pour un usage exclusif par la collection de sites de création et la batterie publiée.

Si la batterie publiée est anonyme et en lecture seule, il n’y a aucun risque d’exposition des métadonnées gérées qui ne sont pas associées au contenu publié. Les utilisateurs anonymes ont uniquement accès au contenu publié et ne peuvent pas soumettre des classements ni créer d’autres types de métadonnées.

Avec le partage de l’application de service Métadonnées gérées à travers l’organisation (comme illustré dans l’architecture simplifiée de cet article), les auteurs peuvent utiliser la taxonomie de l’entreprise. À l’inverse, le déploiement d’une instance dédiée du service pour la création et la publication (illustré dans l’exemple de conception) garantit que les métadonnées gérées sont isolées.

Une instance dédiée de l’application de service de recherche est déployée dans la batterie hébergeant le site Internet de la société. Cette configuration est recommandée pour un site Internet publié.

Autres options de création et de publication

Pour le site Internet de l’entreprise, l’exemple de conception illustre un processus de publication utilisant la fonctionnalité de déploiement de contenu pour déplacer le contenu d’une collection de sites de création vers une batterie de publication. Il existe une alternative plus simple à cette approche consistant à effectuer directement la création sur la batterie de publication. Ceci est généralement désigné sous le terme de création en production.

La création dans l’environnement de production simplifie considérablement la solution en consolidant les services sur une batterie, ce qui rend inutile le déploiement de contenu. Le modèle de conception inclut des zones supplémentaires qui peuvent être utilisées par les auteurs pour travailler de manière sécurisée sans affecter les utilisateurs anonymes. Veillez à bloquer l’accès anonyme entrant sur le port associé aux zones utilisées par les auteurs. Si votre site compte moins de 500 écritures par heure d’activité de création, il est improbable que les performances du site publié soient affectées en cas de création dans l’environnement de production.

SharePoint Server 2010 inclut des fonctionnalités de publication qui peuvent être utilisées dans ce scénario pour garantir que le contenu n’est pas exposé aux utilisateurs anonymes tant qu’il n’est pas prêt. Pour plus d’informations, voir les articles suivants :

Sites d’administration

Dans l’exemple de conception, le site Administration centrale de chaque batterie de serveurs est hébergé sur un serveur d’applications. Le site est ainsi protégé contre l’accès direct des utilisateurs. Si les serveurs Web frontaux ne sont pas disponibles en raison d’un goulet d’étranglement au niveau des performances ou d’une faille de sécurité, le site Administration centrale reste disponible.

Les URL avec équilibrage de la charge réseau des sites d’administration ne sont pas mentionnées dans l’exemple de conception ni dans cet article. Les recommandations suivantes doivent être suivies :

  • Si des numéros de port sont utilisés dans les URL d’administration, utilisez des ports non standard. Les numéros de port sont par défaut inclus dans les URL. Alors que les numéros de port ne sont généralement pas utilisés dans les URL présentées aux clients, l’utilisation de numéros de port pour les sites d’administration peut améliorer la sécurité en limitant l’accès à ces sites aux ports non standard.

  • Créer des entrées DNS standard pour les sites d’administration.

Outre ces recommandations, vous avez également la possibilité d’équilibrer la charge du site Administration centrale sur des serveurs d’applications multiples afin d’assurer une redondance.

Pools d’applications

Des pools d’applications de service Internet (IIS) sont généralement implémentés afin d’isoler les processus entre contenus. Avec les pools d’applications, plusieurs sites peuvent s’exécuter sur le même ordinateur serveur, mais chacun conserve ses propres processus de travail et sa propre identité. Cela réduit les risques qu’une faille de sécurité sur un site laissant la possibilité à un attaquant d’injecter du code sur le serveur n’expose les autres sites.

En pratique, envisagez d’utiliser un pool d’applications dédié dans chacun des scénarios suivants :

  • Pour séparer le contenu authentifié du contenu anonyme.

  • Pour isoler les applications qui stockent des mots de passe pour des applications métier externes et qui interagissent avec ces applications (même si le service Banque d’informations sécurisé peut être utilisé à cette fin).

  • Pour isoler les applications dans lesquelles les utilisateurs jouissent d’une plus grande liberté de création et d’administration de sites, ainsi que de collaboration sur le contenu.

L’exemple de conception utilise les pools d’applications de la manière suivante :

  • Chaque site d’administration est hébergé dans un pool d’applications dédié. Ceci est requis par Produits SharePoint 2010.

  • Le contenu intranet et divisé en deux pools d’applications distincts. Le contenu de collaboration (Sites Mon site et sites d’équipe) est hébergé dans un pool d’applications. Le contenu intranet publié est hébergé dans un pool d’applications distinct. Cette configuration permet d’isoler les processus pour le contenu intranet publié dans lequel des connexions aux données métier sont le plus généralement utilisées.

  • L’application Web partenaire est hébergée dans un pool d’applications dédié.

  • Le site Internet de l’entreprise est hébergé dans un pool d’applications dédié dans la seconde batterie. Si cette batterie hébergeait également le contenu destiné à la collaboration entre partenaires, ces deux types de contenus (Internet et partenaire) seraient hébergés dans deux pools d’applications distincts.

Applications Web

Une application Web est un site Web IIS créé et utilisé par les Produits SharePoint 2010. Chaque application Web est représentée par un site Web différent dans les services Internet (IIS).

D’une manière générale, utilisez des applications Web dédiées pour :

  • Séparer le contenu anonyme du contenu authentifié. Dans l’exemple de conception, le site Internet de l’entreprise est hébergé dans une application Web et dans un pool d’applications dédiés.

  • Isoler les utilisateurs. Dans l’exemple de conception, le site Web partenaire est hébergé dans une application Web et un pool d’applications dédiés pour garantir que les partenaires n’ont pas accès au contenu intranet.

  • Appliquer des autorisations. Avec une application Web dédiée, il est possible d’appliquer des autorisations en fonction de stratégies à l’aide de la page Stratégie de l’application Web de l’Administration centrale. Par exemple, vous pouvez créer une stratégie sur le site Internet de l’entreprise afin de refuser explicitement l’accès à un ou plusieurs groupes d’utilisateurs. Les stratégies d’une application Web sont appliquées quelles que soient les autorisations configurées sur des sites ou des documents individuels au sein de l’application Web.

  • Optimiser les performances. Les applications sont plus performantes si elles sont placées dans des applications Web avec d’autres applications ayant des caractéristiques de données similaires. Par exemple, les caractéristiques de données des sites Mon site incluent un grand nombre de sites de petite taille. À l’inverse, les sites d’équipe regroupent généralement un plus petit nombre de très grands sites. En plaçant ces deux types différents de sites dans des applications Web distinctes, les bases de données ainsi créées sont composées de données ayant des caractéristiques similaires, ce qui optimise les performances des bases de données. Dans l’exemple de conception, les sites Mon site et les sites d’équipe n’ont aucune exigence spécifique en matière d’isolation des données ; ils partagent le même pool d’applications. Néanmoins, ils sont placés dans des applications Web distinctes pour optimiser les performances.

  • Faciliter la gestion. Dans la mesure où la création d’applications Web distinctes conduit à des sites et des bases de données distincts, vous pouvez implémenter des limites de site différentes (corbeille, expiration et taille) et négocier des contrats de niveau de service différents. Par exemple, vous pouvez accorder plus de temps à la restauration du contenu du site Mon site s’il ne s’agit pas du contenu le plus critique de votre entreprise. Cela vous permet de restaurer du contenu plus critique avant de restaurer le contenu du site Mon site. Dans l’exemple de conception, les sites Mon site sont placés dans une application Web distincte pour permettre aux administrateurs de gérer de manière plus agressive l’expansion par rapport aux autres applications.

Collections de sites

Les collections de sites font le lien entre l’architecture logique et l’architecture des informations. Les collections de sites du modèle de conception ont pour objectif de répondre aux exigences en matière de conception d’URL et de créer des divisions logiques du contenu.

Pour répondre aux exigences en matière de conception d’URL, chaque application Web inclut une collection unique de sites de niveau racine. Des chemins d’accès gérés sont utilisés pour incorporer un second niveau de collections de sites de niveau supérieur. Pour plus d’informations sur les exigences en matière d’URL et sur l’utilisation de chemins gérés, voir « Zones et URL » plus loin dans cet article. Au-delà du second niveau de collections de sites, chaque site est un sous-site.

Le diagramme ci-dessous illustre la hiérarchie de sites des Sites d’équipe.

Sites d’équipes

Dans la mesure où une collection de sites de niveau racine est exigée, les décisions en matière de conception concernent le second niveau de collections de sites. L’exemple de conception intègre des choix qui sont fonction de la nature de l’application.

Contenu intranet publié

L’application Web de contenu intranet publié présume que plusieurs services de l’entreprise hébergeront du contenu publié. Dans l’exemple de conception, le contenu de chaque service est hébergé dans une collection de sites distincte. Cela présente divers avantages :

  • Chaque service peut gérer son contenu et lui accorder des autorisations indépendamment.

  • Le contenu de chaque service peut être stocké dans une base de données dédiée.

L’utilisation de collections de sites multiples présente les inconvénients suivants :

  • Les pages maîtres, les mises en page, les modèles, les composants WebPart et la navigation ne peuvent pas être partagés entre des collections de sites.

  • La coordination des personnalisations et de la navigation entre les collections de sites requiert davantage d’efforts.

En fonction de l’architecture des informations et de la conception de l’application intranet, le contenu publié peut apparaître à l’utilisateur comme une application déportée. Sinon, chaque collection de sites peut sembler un site Web distinct.

Sites Mon site

Les sites Mon site présentent des caractéristiques distinctes et les recommandations relatives à leur déploiement sont simples. Dans l’exemple de conception, l’application Mon site intègre un site de niveau supérieur avec l’URL http://my. La première collection de sites de niveau supérieur créée utilise le modèle Hôte de sites Mon site. Un chemin d’accès géré est intégré (à l’aide de l’inclusion générique), ce qui permet un nombre infini de sites créés par l’utilisateur. Tous les sites sous le chemin d’accès géré sont des collections de sites indépendantes qui héritent du modèle Hôte de sites Mon site. Le nom d’utilisateur est ajouté à l’URL sous la forme http://my/personal/nom_utilisateur. Le diagramme ci-dessous illustre le site Mon site.

Sites Mon site

Sites d’équipe

Vous pouvez utiliser l’une des deux approches suivantes pour concevoir des collections de sites dans une application Site d’équipe :

  • Autoriser les équipes à créer des collections de sites via la création de sites libre-service. L’avantage de cette approche est que les équipes peuvent facilement créer un site, en fonction de leurs besoins, sans l’assistance d’un administrateur. Toutefois, cette approche présente de nombreux inconvénients, notamment :

    • Vous perdez la possibilité d’implémenter une taxonomie complète.

    • L’application peut finir par être difficile à gérer.

    • Les sites sont facilement abandonnés

    • Vous ne pouvez pas partager des modèles et la navigation avec d’autres projets et équipes, qui pourraient sinon partager une collection de sites.

  • Créer un nombre limité de collections de sites pour votre entreprise en fonction de son mode de fonctionnement. Dans cette approche, les collections de sites sont créées par un administrateur SharePoint. Une fois la collection de sites créée, les équipes peuvent créer des sites dans la collection de sites en fonction de leurs besoins. Cette approche laisse la possibilité d’implémenter une taxonomie complète qui permet de structurer la manière dont les sites d’équipe sont gérés et se développent. Elle laisse par ailleurs davantage de possibilités de partager des modèles et la navigation entre les projets et les équipes qui partagent une collection de sites.

L’exemple de collection utilise cette seconde approche, laquelle permet d’obtenir une collection de sites similaire pour les sites d’équipe et pour le contenu intranet publié. Le défi pour les architectes des informations est de créer un second niveau de collections de sites qui ait du sens pour l’organisation. Le tableau suivant indique des suggestions pour différents types d’organisations.

Type d’organisation Taxonomies de collection de sites suggérée

Développement de produits

  • Créer une collection de sites pour chaque produit en cours de développement. Autoriser les équipes contributives à créer des sites dans la collection de sites.

  • Pour chaque projet de développement à long terme, créer une collection de sites pour chaque grosse équipe qui contribue au produit. Vous pouvez par exemple créer une collection de sites pour chacune des équipes suivantes : concepteurs, ingénieurs et développeurs de contenu.

Recherche

  • Créer une collection de sites pour chaque projet de recherche à long terme.

  • Créer une collection de sites pour chaque catégorie de projets de recherche.

Établissements d’enseignement supérieur

  • Créer une collection de sites pour chaque département universitaire.

Bureau législatif

  • Créer une collection de sites pour chaque parti politique. Les membres officiels du gouvernement qui partagent une affiliation à un parti peuvent partager des modèles et la navigation.

  • Créer une collection de sites pour chaque comité. Ou créer une collection de sites pour tous les comités.

Cabinet d’avocats d’entreprise

  • Créer une collection de sites pour chaque entreprise cliente.

Fabrication

  • Créer une collection de sites pour chaque gamme de produits

Application Web partenaire

Une application Web partenaire est destinée à être utilisée pour la collaboration avec des partenaires externes sur des projets dont l’objet est bien défini ou la durée limitée. De par leur conception, les sites de l’application Web partenaire ne sont pas destinés à être liés. Parmi les exigences d’une application Web partenaire, vous devez veiller à ce que :

  • les propriétaires des projets puissent facilement créer des sites pour la collaboration entre les partenaires ;

  • les partenaires et autres contributeurs aient accès uniquement au projet sur lequel ils travaillent ;

  • les autorisation soient gérées par les propriétaires du site ;

  • les résultats de recherche au sein d’un projet n’exposent pas le contenu d’autres projets ;

  • les administrateurs puissent facilement identifier les sites qui ne sont plus utilisés et les supprimer.

Pour répondre à ces exigences, l’exemple de conception intègre une collection de sites pour chaque projet. Cette approche présente les avantages suivants :

  • Les collections de sites individuelles offrent le niveau approprié d’isolation entre les projets.

  • La création de sites self-service peut être implémentée.

Dans la mesure où l’application Web partenaire héberge également des collections de sites pour le développement de contenu pour le site Internet de l’entreprise, des collections de sites distinctes sont créées pour la création et le test.

Site Internet de l’entreprise

Le site Internet de l’entreprise intègre une collection unique de sites de niveau racine. Tous les sites sous cette collection de sites sont des sous-sites. Cette structure simplifie les URL des pages au sein du site. Le diagramme ci-dessous illustre l’architecture du site Web de l’entreprise.

Site Internet de la société

Bases de données de contenu

Vous pouvez utiliser les deux approches suivantes pour intégrer des bases de données de contenu dans la conception (l’exemple de conception intègre ces deux approches) :

  • Établir des tailles cibles pour les bases de données de contenu avec des seuils d’avertissement de taille appropriés. Créer une nouvelle base de données lorsque les seuils d’avertissement de taille sont atteints. Avec cette approche, les collections de sites sont automatiquement ajoutées aux bases de données disponibles, en fonction uniquement des objectifs de taille. Cette approche est la plus courante.

  • Associer des collections de sites à des bases de données de contenu spécifiques. Cette approche vous permet de placer une ou plusieurs collections de sites dans une base de données dédiée qui peut être gérée indépendamment du reste.

Si vous choisissez d’associer des collections de sites à des bases de données de contenu spécifiques, vous pouvez utiliser les méthodes suivantes à cet effet :

  • Utiliser Windows PowerShell pour créer une collection de sites dans une base de données spécifique.

  • Dédier une base de données à une collection de sites unique en appliquant les paramètres de capacité de base de données suivants :

    • Nombre de sites avant qu’un événement d’avertissement ne soit généré = 1

    • Nombre maximal de sites pouvant être créés dans cette base de données = 1

  • Ajouter un groupe de collections de sites à une base de données dédiée en procédant commet suit :

    1. Dans l’application Web, créez la base de données et définissez son état sur Prêt.

    2. Définissez l’état de toutes les autres bases de données sur Hors connexion. Lorsque les bases de données de contenu sont hors connexion, aucune nouvelle collection de sites ne peut être créée. Toutefois, les collections de sites existantes dans les bases de données hors connexion sont accessibles à la fois pour les opérations de lecture et d’écriture.

    3. Créer les collections de sites. Elles sont automatiquement ajoutées aux bases de données.

    4. Rétablissez l’état de toutes les autres bases de données sur Prêt.

Contenu intranet publié

Pour le contenu intranet publié, l’exemple de conception intègre une base de données unique pour faciliter la gestion. Ajoutez si nécessaire des bases de données reposant sur des objectifs de taille cible.

Sites Mon site

Pour les sites Mon site, l’exemple de conception permet de réaliser des économies d’échelle en gérant les bases de données jusqu’à la taille cible maximale. Les paramètres suivants sont configurés pour atteindre cet objectif :

  • Limiter le stockage du site à une valeur maximale de : ce paramètre, configuré dans la page Modèles de quotas de l’Administration centrale, limite la taille d’un site personnel.

  • Corbeille secondaire : ce paramètre, configuré dans la page Paramètres généraux de l’Application Web, détermine l’espace supplémentaire alloué à la corbeille secondaire.

  • Nombre maximal de sites pouvant être créés dans cette base de données : ce paramètre est configuré lors de la création d’une base de données. Calculez la taille totale des sites pouvant être allouée en utilisant les nombres spécifiés dans les deux valeurs précédentes. Ensuite, en fonction de l’objectif de taille de chaque base de données, déterminez combien de sites la base de données pourra contenir.

L’exemple de conception donne les exemples de paramètres de taille suivants reposant sur une taille de base de données cible de 200 giga-octets (Go) et une taille de site Mon site cible d’1 Go :

  • Limite de taille des sites par site = 1 Go

  • Taille cible de la base de données = 175 Go

  • Réservé pour la corbeille secondaire = 15 %

  • Nombre maximal de sites = 180

  • Avertissement relatif au niveau du site = 150

Lorsque l’avertissement relatif au niveau du site est atteint, créez une nouvelle base de données. Après avoir créé cette nouvelle base de données, les nouveaux sites Mon site sont ajoutés alternativement à la nouvelle base de données et à la base de données existante jusqu’à ce que le nombre maximal de sites pour l’une des bases de données soit atteint.

Sites d’équipe

Pour les sites d’équipe, le modèle de conception permet également de réaliser une économie d’échelle en gérant les bases des données jusqu’à la taille cible maximale. Dans la plupart des organisations, les sites d’équipe seront beaucoup plus volumineux que les sites Mon site. Le modèle de conception propose des paramètres de base de données reposant sur une limite de 30 Go pour les collections de sites. Choisissez une limite appropriée pour les sites d’équipe dans votre organisation.

Une autre approche pour les organisations dont les équipes ont des besoins importants en matière de stockage consiste à dédier une base de données à chaque collection de sites d’équipe de niveau supérieur.

Site Web partenaire

Comme les sites Mon site, le site Web partenaire réalise des économies d’échelle en gérant les bases de données jusqu’à la taille cible maximale. Toutefois, dans le modèle de conception, le site Web partenaire héberge également la collection de sites de création pour le site Internet de l’entreprise. Par conséquent, la conception de la base de données intègre deux approches :

  • La collection de sites de création est hébergée dans une base de données dédiée.

  • Les paramètres de base de données et de taille sont configurés pour gérer touts les autres sites et bases de données.

Dans la mesure où le site Web partenaire est hébergé dans une application Web dédiée, vous pouvez créer des limites de taille plus appropriées pour les types de sites qui sont créés. L’exemple de conception propose les paramètres de taille suivants :

  • Taille cible de la base de données = 200 Go

  • Quota de stockage par site = 5 Go

  • Nombre maximal de sites = 40

  • Collection de sites de création hébergée dans une base de données dédiée

Site Internet de l’entreprise

En utilisant une collection de sites unique dans la conception du site Internet de l’entreprise, vous utilisez une seule base de données pour cette application Web.

Zones et URL

L’exemple de conception illustre la manière de coordonner les URL à travers plusieurs applications au sein d’un déploiement en entreprise.

Objectifs de conception

Les objectifs suivants influencent les décisions de conception au niveau des URL :

  • Les conventions en matière d’URL ne limitent pas les zones via lesquelles le contenu est accessible.

  • Les ports HTTP et HTTPS standard (80 et 443) peuvent être utilisés dans toutes les applications de l’exemple de conception.

  • Les numéros de port ne sont pas inclus dans les URL. En pratique, les numéros de port ne sont généralement pas utilisés dans les environnements de production.

Principes de conception

Pour atteindre ces objectifs de conception, les principes suivants sont appliqués :

  • Les collections de sites nommées par l’hôte ne sont pas utilisées. Notez que les collections de sites nommées par l’hôte sont différentes des en-têtes d’hôtes IIS. Les collections de sites nommées par l’hôte ne peuvent pas être utilisées avec la fonctionnalité de mappage des accès de substitution. Cette fonctionnalité est requise pour accéder au même contenu par le biais d’URL de domaine multiples. Par conséquent, lorsque des sites nommés par l’hôte sont utilisés, ces sites sont disponibles uniquement par le biais de la zone Par défaut.

  • Chaque application intègre une collection unique de sites racine. Ceci est requis pour les mappages des accès de substitution. Si plusieurs collections de sites racines sont requises dans une application Web et que vous n’envisagez d’utiliser que la zone Par défaut pour l’accès utilisateur, les collections de sites nommées par l’hôte sont une bonne option.

  • Pour les applications qui incluent plusieurs collections de sites de niveau supérieur dans lesquelles chaque collection de site représente une équipe ou un projet de niveau supérieur (par exemple, des sites d’équipe), l’exemple de conception intègre des chemins gérés. Ces chemins gérés offrent davantage de contrôle sur les URL pour ces types de sites.

Compromis de conception

Des compromis sont nécessaires pour atteindre les objectifs de conception, notamment :

  • a>URL plus longues ;

  • collections de sites nommées par l’hôte non utilisées.

Conception d’URL avec équilibrage de la charge réseau

Lorsque vous créez une application Web, vous devez choisir l’URL avec équilibrage de la charge réseau qui est affectée à l’application. Vous devez par ailleurs créer une URL avec équilibrage de la charge réseau pour chaque zone que vous créez dans une application Web. Les URL avec équilibrage de la charge réseau incluent le protocole, le schéma, le nom d’hôte et le port, le cas échéant. L’URL avec équilibrage de la charge réseau doit être unique dans toutes les applications Web et dans toutes les zones. Par conséquent, chaque application et chaque zone de chaque application requiert une URL unique dans l’ensemble du modèle de conception.

Intranet

Chacune des trois applications Web qui composent l’intranet requièrent une URL unique. Dans l’exemple de conception, l’audience cible du contenu intranet est constituée des employés internes et des employés distants. Dans l’exemple de conception avec authentification par revendications, les employés utilisent les mêmes URL pour chacune de ces applications qu’ils soient sur site ou à distance. Tout en ajoutant une couche de sécurité à la conception SharePoint (tout le trafic utilise le protocole SSL), cette approche exige soit que le trafic interne soit routé via le produit de pare-feu ou de passerelle avec le trafic distant, soit qu’un environnement DNS scindé soit créé pour résoudre les demandes internes dans le réseau interne.

Dans l’exemple de conception avec authentification classique, les URL sont différentes pour les employés internes et les employés distants. Le tableau suivant indique les URL pour les employés internes et les employés distants qui sont utilisées pour accéder à chaque application dans l’exemple de conception avec authentification classique.

Application URL pour employés internes URL pour employés distants

Contenu intranet publié

http://fabrikam

https://intranet.fabrikam.com

Sites d’équipe

http://teams

https://teams.fabrikam.com

Sites Mon site

http://my

https://my.fabrikam.com

Site Web partenaire

Dans l’exemple de conception, le site Web partenaire est accessible par les employés internes, les employés distants et les employés partenaires. Dans l’exemple de conception avec authentification par revendications, chacun de ces utilisateurs entre la même URL, quelle que soit la méthode d’authentification. Dans l’exemple de conception avec authentification classique, chaque type d’utilisateur entre une URL différente. Même si les employés distants et les employés partenaires accèdent au site Web partenaire depuis l’extérieur à l’aide du protocole SSL (HTTPS), chaque groupe requiert une URL différente pour profiter des avantages de l’utilisation de zones distinctes ; autrement dit, des méthodes d’authentification différentes et des stratégies de zone différentes. Le tableau suivant indique les URL utilisées par les employés internes, les employés distants et les partenaires pour accéder au site Web partenaire, comme indiqué dans l’exemple de conception avec authentification classique.

Zone URL

URL pour employés internes

http://partnerweb

URL pour employés distants

https://remotepartnerweb.fabrikam.com

URL partenaire

https://partnerweb.fabrikam.com

Site Internet de l’entreprise

Le site Internet de l’entreprise est un site public accessible par tout utilisateur à l’aide de l’URL par défaut, http://www.fabrikam.com. Les stratégies de la zone Internet sont appliquées (autrement dit, accès anonyme et refuser l’écriture).

Toutefois, pour prendre en charge les tâches d’administration et de création sur le site public, l’exemple de conception intègre des URL pour les employés internes et distants. Vous pouvez utiliser des stratégies pour ces zones afin de garantir l’accès approprié aux groupes de sécurité ciblés pour les tâches de création et de maintenance. Les exemples de conception avec authentification classique et avec authentification par revendications utilisent tous deux la même approche pour cette batterie. Le tableau ci-dessous indique les URL pour chaque zone.

Zone URL

URL pour employés internes

http://fabrikamsite

URL pour employés distants

https://fabrikamsite.fabrikam.com

URL personnalisée

http://www.fabrikam.com

Utilisation d’inclusions explicites et génériques pour les chemins d’URL

En définissant des chemins gérés, vous pouvez spécifier quels chemins de l’espace de noms d’URL d’une application Web sont utilisés pour les collections de sites. Vous pouvez spécifier qu’une collection de sites ou plus existent au niveau d’un chemin distinct sous le site racine. Sans les chemins gérés, tous les sites créés sous la collection de sites racine font partie de la collection de sites racine.

Vous pouvez créer les deux types suivants de chemins gérés :

  • Inclusion explicite : une collection de sites avec l’URL explicite que vous lui affectez. Une inclusion explicite est appliquée à une seule collection de sites. Vous pouvez créer de nombreuses inclusions explicites sous une collection de sites racine. http://fabrikam/hr est un exemple d’URL pour une collection de sites créée à l’aide de cette méthode. Les chemins d’accès explicites ont un impact sur les performances. Il est donc recommandé de limiter à environ 20 le nombre de collections de sites créées avec une inclusion explicite.

  • Inclusion générique : un chemin qui est ajouté à l’URL. Ce chemin indique que tous les sites spécifiés directement après le nom du chemin sont des collections de sites uniques. Cette option est généralement utilisée pour les collections de sites prenant en charge la création de sites self-service, comme les sites Mon site. http://my/personal/user1 est un exemple d’URL pour une collection de sites créée à l’aide de cette méthode.

L’exemple de conception intègre l’utilisation de ces deux types de chemins gérés comme décrit dans les sections qui suivent.

Inclusions explicites : contenu intranet publié

Dans l’exemple de conception, l’application Web de contenu intranet publié intègre l’utilisation des inclusions explicites.

Contenu intranet publié

Dans l’application Web de contenu intranet publié, une inclusion explicite est utilisée pour chaque sous-site, par exemple, HR, Facilities et Purchasing. Chacune de ces collections de sites peut être associée à une base de données de contenu distincte si nécessaire. L’utilisation d’inclusions explicites dans cet exemple suppose qu’aucun autre type de site n’est créé dans l’application Web, y compris des inclusions génériques.

Il est recommandé de limiter à environ 20 le nombre de sites créés à l’aide d’une inclusion explicite. Si votre organisation requiert un plus grand nombre de collections de sites, envisagez d’utiliser une inclusion générique ou des collections des sites nommées par l’hôte.

Dans l’exemple de conception avec authentification classique, l’utilisation d’inclusions explicites donne les URL indiquées dans le tableau ci-dessous.

Employé interne (zone Intranet) Employé distant (zone Par défaut)

http://fabrikam

https://intranet.fabrikam.com

http://fabrikam/hr

https://intranet.fabrikam.com/hr

http://fabrikam/facilities

https://intranet.fabrikam.com/facilities

http://fabrikam/purchasing

https://intranet.fabrikam.com/purchasing

Dans cet exemple, la collection de sites racine, http://fabrikam, représente la page d’accueil par défaut de l’intranet. Ce site est destiné à héberger le contenu pour les utilisateurs.

Inclusions génériques : sites d’équipe, sites Mon site et application Web partenaire

Les sites d’équipe, les sites Mon site et l’application Web partenaire intègrent l’utilisation d’une inclusion générique. Les inclusions génériques sont idéales pour les applications permettant aux utilisateurs de créer leurs propres collections de sites et pour les applications Web qui incluent un grand nombre de collections de sites. Une inclusion générique indique que l’élément qui suit le caractère générique est un site racine d’une collection de sites.

Sites d’équipe

Dans l’application Sites d’équipe, l’inclusion générique est utilisée pour chaque collection de sites d’équipe. Il est recommandé de maintenir le nombre de sites d’équipe de niveau supérieur à un nombre gérable. Par ailleurs, la taxonomie des sites d’équipe doit être logique pour le fonctionnement de votre entreprise.

Dans l’exemple de conception avec authentification classique, l’utilisation d’inclusions génériques donne les URL indiquées dans le tableau ci-dessous.

Employé interne (zone Intranet) Employé distant (zone Par défaut)

http://teams/sites/Team1

https://teams.fabrikam.com/sites/Team1

http://teams/sites/Team2

https://teams.fabrikam.com/sites/Team2

http://teams/sites/Team3

https://teams.fabrikam.com/sites/Team3

Dans cet exemple, la collection de sites racine, http://team, n’héberge pas nécessairement du contenu pour les utilisateurs.

Sites Mon site

Les sites Mon site proposent la création de sites libre-service. Lorsqu’un utilisateur naviguant sur l’intranet clique pour la première fois sur Mon site, un site Mon site est automatiquement créé pour l’utilisateur. Dans l’exemple de conception, les sites Mon site intègrent une inclusion générique nommée /personal (http://my/personal). La fonctionnalité Mon site ajoute automatiquement le nom d’utilisateur à l’URL.

Dans l’exemple de conception avec authentification classique, cela conduit aux URL au format indiqué dans le tableau ci-dessous.

Employé interne (zone Intranet) Employé distant (zone Par défaut)

http://my/personal/user1

https://my.fabrikam.com/personal/user1

http://my/personal/user2

https://my.fabrikam.com/personal/user2

http://my/personal/user3

https://my.fabrikam.com/personal/user3

Application Web partenaire

L’application Web partenaire est destinée à permettre aux employés de facilement créer des sites sécurisés pour la collaboration avec des partenaires externes. Pour atteindre cet objectif, la création de sites self-service est autorisée.

Dans l’exemple de conception avec authentification classique, l’application Web partenaire intègre une inclusion générique nommée /sites (http://partnerweb/sites). Cela donne les URL au format indiqué dans le tableau suivant .

Employé interne (zone Intranet) Employé distant (zone Par défaut)

http://partnerweb/sites/project1

https://remotepartnerweb.fabrikam.com/sites/project1

http://partnerweb/sites/project2

https://remotepartnerweb.fabrikam.com/sites/project2

http://partnerweb/sites/project3

https://remotepartnerweb.fabrikam.com/sites/project3

Les contributeurs partenaires peuvent accéder aux sites Web partenaires à l’aide des URL indiquées dans le tableau suivant.

Partenaire (zone Extranet)

https://partnerweb.fabrikam.com/sites/project1

https://partnerweb.fabrikam.com/sites/project2

https://partnerweb/fabrikam.com/sites/project3

L’exception pour l’application Web partenaire, comme illustré dans les exemples de conception, est la collection dédiée à la création de contenu pour le site Internet de l’entreprise. Pour cette collection de sites, une inclusion explicite est utilisée. Cela donne un exemple d’utilisation à la fois d’inclusions explicites et d’inclusions génériques dans la même application Web.

Stratégies de zone

Vous pouvez créer une stratégie pour une application Web afin d’appliquer des autorisations au niveau de l’application Web. Une stratégie peut être définie pour l’application Web en général ou uniquement pour une zone spécifique. Une stratégie applique les autorisations à l’ensemble du contenu d’une application Web ou à la zone. Les autorisations d’une stratégie remplacent tous les autres paramètres de sécurité qui sont configurés pour les sites et pour le contenu. Vous pouvez configurer la stratégie en fonction d’utilisateurs ou de groupes d’utilisateurs, mais pas en fonction de groupes SharePoint. Si vous ajoutez ou modifiez une stratégie de zone, la recherche doit réanalyser les sites pour recueillir les nouvelles autorisations.

Les stratégies ne sont pas utilisées dans l’exemple de conception avec authentification par revendications pour la batterie de collaboration dans laquelle plusieurs types d’authentification sont autorisés dans une même zone. Les stratégies sont implémentées dans le modèle de conception avec authentification classique et dans la batterie publiée du modèle de conception avec authentification par revendications dans laquelle l’authentification Windows est imposée. Dans la batterie publiée, l’utilisation de stratégies ajoute une couche de sécurité supplémentaire entre les utilisateurs anonymes et les utilisateurs ayant accès aux sites gérés.

Les exemples conception proposent différentes stratégies permettant de :

  • refuser l’accès en écriture au contenu publié ;

  • garantir que les auteurs et les testeurs aient un accès approprié au contenu publié.