Publié
dimanche 12 septembre 2010 22:52
par
Arnault Nouvel
Ce billet fait partie d’une série :
Je travaille en ce moment sur la mise en place d'un portail extranet client en SharePoint 2010 dont l'infrastructure est intéressante. Cet extranet propose aux clients de manipuler des données provenant de divers systèmes d'informations existants mais hétérogènes, notamment du SAP. Afin de fournir à SharePoint un back-end unique pour manipuler les données, une infrastructure de web services SOA est développée en parallèle du portail. Celle-ci est hébergée sur une plateforme IBM WebSphere (contrainte client) qui se charge d’agréger les données à partir des back-ends existants.
3 équipes ont été mises en place et travaillent de concert :
- Une équipe chargée d'effectuer les adaptations nécessaires dans les différents S.I. cibles
- Une équipe en charge de la mise en place de la plateforme SOA
- Une équipe en charge de la mise en place et de la réalisation du portail extranet
Mon rôle dans ce projet est de définir l'architecture du portail et de mettre en place l’infrastructure qui va avec.
Nous tirons partie de plusieurs des nouvelles fonctionnalités de SharePoint Server 2010 : les claims et le Secure Store Service pour la délégation d’identité, et le Business Data Connectivity Service qui permet à SharePoint de manipuler aisément des données provenant de systèmes externes. Dans notre cas les données proviennent des web services de la plateforme S.O.A.
Pour des raisons évidentes de sécurité, les Web Services ont besoin de connaitre l’identité de l’utilisateur courant afin de l’autoriser ou non en lecture et en écriture sur les divers objets métiers. L'annuaire utilisateur doit donc être partagé entre SharePoint 2010 (authentification et autorisations d’accès au portail) et la plateforme SOA (autorisations d’accès aux objets métiers).
Livré avec Windows 2008 R2, Active Directory LightWeight Services (AD-LDS) fournit un annuaire LDAP standard qui est exploitable à la fois par SharePoint 2010 et par les web services WebSphere. Il permet aussi d'assurer une haute disponibilité grâce à son système de réplication. Tous ces points étant des pré-requis du projet, nous avons adopté AD-LDS.
Ci dessous un schéma macroscopique de l’infrastructure globale :
Dans cette série de billets, nous allons nous concentrer sur la mise en place d’un annuaire utilisateurs dans AD-LDS et de l'authentification par formulaire sur SharePoint Server 2010. Nous configurerons ensuite la haute disponibilité au niveau d’AD-LDS en ajoutant un autre serveur et en utilisant le Windows Network Load Balancing (NLB). Dans le projet en question tous les nœuds applicatifs bénéficient de haute disponibilité (3 frontaux SP, cluster SQL, etc.), mais ici nous ne nous intéresseront qu’à sa mise en place sur AD-LDS.
Voici l'infrastructure sur laquelle je me suis appuyé pour réaliser ce tutorial :
Les 5 serveurs font partie d'un même domaine Active Directory extranet.test. Ce domaine contient les comptes de services utilisés par SharePoint 2010 et SQL Server, et les comptes utilisateurs des administrateurs des serveurs. Les utilisateurs distants qui pourront se connecter au portail extranet seront, eux, définis dans l'annuaire AD-LDS, ce qui permet en outre de ne pas polluer l'AD principal.
Contexte de départ :
- Les 5 serveurs sont des Windows 2008 R2 et font partie du domaine extranet.test
- Le compte EXTRANET\spadmin est administrateur de tous les serveurs
- SQL Server 2008 R2 est installé
- SharePoint Server 2010 est installé en mode ferme et configuré selon les “best-practices” (avec des comptes de service dédiés pour les application pools, etc)
Passons maintenant à l'installation et à la configuration de l'annuaire AD-LDS : Partie 2 - installation et configuration de AD-LDS
Arnault Nouvel – Winwise
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
