다음을 통해 공유

Planification de l’infrastructure nécessaire au nouveau modèle d’application dans SharePoint 2013

  • 아티클

Article d’origine publié le mardi 04 septembre 2012

SharePoint 2013 est accompagné d’un tout nouveau modèle d’application, que nous appelons également « modèle d’applications Cloud ». Bien que ce programme soit fourni avec un tout nouvel ensemble de possibilités pour le développement, il implique également des exigences au niveau de l’infrastructure que vous devez planifier et créer pour prendre en charge ces opportunités. Quand je pense au modèle d’application, il y a trois principaux points qui me viennent à l’esprit :

  1. Le modèle de développement : il s’agit principalement de savoir comment je vais développer mon application, quelles nouvelles fonctionnalités je vais mettre en œuvre, etc. C’est essentiellement le travail du développeur.
  2. Le modèle de sécurité : le modèle de sécurité associé à ces nouvelles applications est une combinaison intéressante d’« éléments ». Vous avez le nouveau concept de principal d’application, qui correspond à la manière dont vous définissez les droits pour vos applications. Il y a le modèle OAuth, qui définit le type de contenu que vous pouvez récupérer, ainsi qu’un mécanisme de présentation de SharePoint avec un jeton qui décrit votre identité (ce mécanisme est similaire aux revendications pour les applications). Le modèle de sécurité et les moyens par lesquels ces jetons sont créés et présentés varient considérablement si votre application est hébergée dans SharePoint ou ailleurs, et si vous utilisez les services de contrôle d’accès (ACS) comme broker d’approbation ou non. Il y a de nombreux points à aborder à ce sujet, que je ne couvrirai pas dans ce billet de blog, mais il s’agit d’une activité de professionnel de l’informatique et de développeur.
  3. L’infrastructure : nous parlons ici du ciment qui fait fonctionner des applications au sein d’une organisation. Cela inclut les applications de service, le domaine et le préfixe d’une application, le DNS, SSL et les configurations d’application web. Il s’agit principalement d’une activité d’informaticien et constitue la base de ce billet de blog. Cette publication va également traiter des applications hébergées dans SharePoint, par rapport à une application hébergée en externe dans un autre site ou cloud comme Windows Azure. Quand vous installez une application hébergée dans SharePoint, un nouvel objet SPWeb est créé pour celle-ci. Ainsi, chaque application possède son propre jeu de données et ne peut pas écrire sur les données d’autres applications. Cela ajoute un niveau de sécurité afin qu’une personne disposant de droits sur une application ne puisse pas exécuter un code malveillant utilisant les droits de l’utilisateur actuel pour accéder à des données dans un autre site de la batterie de serveurs. C’est un concept de base essentiel dont vous devez vous souvenir pour les applications reposant sur le nouveau modèle d’application : quand les applications sont hébergées sur SharePoint, une application = un objet SPWeb.

Commençons par examiner la liste de ces différents composants d’infrastructure. Avant toute chose, vous devez vérifier qu’une instance des applications de service Gestion des applications et Paramètres d’abonnement est créée et en cours d’exécution dans la batterie de serveurs. Le service Gestion des applications est utilisé, par exemple, effectuer le suivi des applications et des déploiements, de la gestion des licences, etc. Le service Paramètres d’abonnement représente la même application de service qui est utilisée pour les déploiements partagés au sein d’une architecture mutualisée. Ce service permet également au modèle d’application de créer les URL uniques qu’utilisent les applications.

Comment ces URL sont-elles créées ? Cela commence avec la configuration d’applications que vous paramétrez dans Administration centrale. Quand vous accédez à l’administration centrale, vous remarquez une nouvelle section intitulée Applications. Si vous cliquez sur celle-ci, une option permettant de configurer les URL d’une application s’affiche. Vous remarquez ensuite deux valeurs utilisées pour créer une URL d’application, à savoir Domaine d’application et Préfixe d’application. Le domaine d’application est comparable au nom d’hôte à utiliser pour toutes les applications dans la batterie de serveurs. Vous devez prendre en compte trois éléments lorsque vous envisagez de créer ce nom :

  1. Premièrement, étant donné que ce nom est utilisé par l’ensemble de la batterie de serveurs, il doit faire l’objet du même niveau de planification et de réflexion que vous avez mis en œuvre pour les autres applications web.
  2. Deuxièmement, il doit s’agir d’un nom de domaine complet. Vous remarquerez que le fait d’utiliser un nom de style NetBIOS ne fonctionne pas correctement pour la résolution de noms.
  3. Troisièmement, il ne doit PAS s’agir d’un domaine enfant de vos applications web.

Prenons maintenant un exemple précis. Supposons que vos applications web soient au format équipe.contoso.com, my.contoso.com et portail.contoso.com. Tout d’abord, vous ne voudrez peut-être pas utiliser un nom de domaine réduit à « contoso.com », car vous devriez ensuite créer une entrée DNS générique pour TOUS les domaines de contoso.com qui pointent vers votre point de terminaison d’applications (je vais apporter des précisions sur ce point dans quelques instants). Je ne vous conseille pas non plus d’utiliser un nom de domaine du type « applications.contoso.com », car il s’agit d’un domaine enfant pour lequel vous utilisez vos applications web (qui sont toutes associées à une racine dans « contoso.com »). En fonction de ces règles, je vous recommande d’utiliser un nom de domaine du type « contosoapps.com ».

Le préfixe d’application peut prendre la valeur de votre choix, car il est apposé à la première partie de l’URL d’une application. Nous allons examiner ce point par la suite.

J’ai mentionné l’utilisation d’une entrée DNS générique plus haut. Nous allons donc aborder ce point. Quand vous installez une application, et que cette application est hébergée dans SharePoint, elle possède une URL de ce type : https://applications-87e90ada14c175.contosoapps.com/mon\_application/pages/default.aspx. Les éléments de l’URL se décomposent comme suit :

  • « applications » : il s’agit de la valeur du préfixe d’application dont j’ai parlé précédemment, celle que vous avez entrée dans l’administration centrale.
  • « 87e90ada14c175 » : il s’agit d’une valeur unique basée sur la collection de sites locaux et web où l’application est installée.
  • « contosoapps.com » : il s’agit du domaine d’application que vous avez entré dans l’administration centrale.
  • « mon_application » : il s’agit du nom de l’application qui a été installée. Le reste de l’URL, à savoir pages/default.aspx, correspond au contenu de l’objet SPWeb où l’application est installée.

En regardant l’URL ainsi que la manière dont elle est formée, vous remarquez certainement pourquoi vous devez utiliser une entrée DNS générique. Étant donné que l’URL sera différente pour chaque instance d’application installée, même si une même application est installée dans plusieurs collections de sites, il n’est pas concevable de continuer à mettre à jour votre DNS pour chaque instance unique. Ceci dit, pour les besoins du scénario que j’ai décrit ici, vous allez devoir utiliser une entrée DNS générique pour *.contosoapps.com. Nous allons aborder le sujet de l’adresse IP vers laquelle elle pointe dans quelques instants.

Une entrée SSL générique est associée à l’entrée DNS générique. Pour être parfaitement clair sur ce point, si vous utilisez des applications, je vous recommande d’utiliser SSL. Le modèle d’application implique de faire passer des jetons d’accès OAuth, dont le rôle est de décrire l’identité de l’utilisateur et de l’application actuels. Comme si vous faisiez passer des jetons SAML pour un utilisateur, vous voulez chiffrer le canal que ces jetons empruntent pour éviter une attaque de type relecture qui octroierait l’accès au contenu à une personne en train de renifler votre trafic réseau. L’utilisation d’SSL empêche l’apparition de tels scénarios, et sachant que les URL de ces applications seront différentes pour chaque instance installée, cela signifie également que vous aurez besoin d’un certificat SSL générique pour les gérer plus facilement. À nouveau, pour les besoins de ce scénario, nous allons obtenir un certificat SSL générique pour *.contosoapps.com.

Bien, jusqu’à présent, nous avons parlé des applications de service nécessaires, de la configuration requise pour le domaine et le préfixe d’application, de la manière dont les URL sont formées et des entrées DNS et SSL nécessaires. Maintenant, pour tout relier, nous devons parler de la façon dont les demandes d’application sont acheminées. En général, vous avez besoin d’une application web SharePoint distincte simplement pour effectuer l’acheminement des demandes d’application. Quelle peut en être la raison ?. Supposons à nouveau que vous avez trois applications web définies comme suit (elles utilisent toutes SSL, nous utiliserons donc une adresse IP unique pour chacune d’entre elles) :

  • équipe.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portail.contoso.com – 192.168.1.12

Comme décrit précédemment, vous ne pouvez configurer qu’un seul domaine d’application dans la batterie de serveurs, et il ne doit pas s’agir d’un domaine enfant. Cela soulève deux problèmes réels avec les applications ci-dessus :

  • Si nous installons des applications dans chacune de ces applications web, comment pouvons-nous faire pour que la bonne demande d’application soit acheminée vers la bonne application web ? Nous n’avons qu’un seul domaine d’application et trois applications web.
  • Si nous essayons et que nous acheminons une demande d’application vers l’une de ces applications web existantes, SSL va cesser de fonctionner. Pourquoi ? Car nous utilisons SSL dans toutes nos applications web (étant donné que nous utilisons Applications), et qu’elles disposent toutes d’un certificat SSL similaire à *.contoso.com. Dans tous les cas, nous ne pouvons pas acheminer des demandes d’application vers elles, car vous ne pouvez pas obtenir de certificat SSL générique fonctionnant avec *.contoso.com et *.contosoapps.com, ce que nos applications vont utiliser.

La solution est alors de créer une quatrième application web. Vous pouvez la créer sans nom d’en-tête d’hôte et en lui attribuant une adresse IP partagée 192.168.1.13. Votre entrée DNS générique pour *.contosoapps.com pointe vers 192.168.1.13. Votre application web « écoute » sur cette adresse IP et le module HTTP SharePoint responsable de l’acheminement récupère la demande de l’application. Il utilise ensuite l’application de service Gestion des applications pour déterminer l’application web qui héberge actuellement cette application et réachemine la demande vers elle. La demande est alors prise en charge à partir de cette application web, collection de sites et objet SPWeb où cette application est hébergée. Tous leurs paramètres de sécurité et d’authentification seront appliqués correctement.

La configuration de notre batterie de serveurs ressemble à ce qui suit :

  • Configuration des applications
    • Domaine d’application – contosoapps.com
    • Préfixe d’application – applications
  • Applications web

    • équipe.contoso.com

      • Adresse IP : 192.168.1.10
      • Certificat SSL : *.contoso.com

    • my.contoso.com

      • Adresse IP : 192.168.1.11
      • Certificat SSL : *.contoso.com

    • portail.contoso.com

      • Adresse IP : 192.168.1.12
      • Certificat SSL : *.contoso.com

    • Vous ne devez spécifier aucun en-tête d’hôte, ou vous pourriez utiliser un nom comme contosoapps, etc. Cela n’a pas grande importance, car nous n’effectuons pas l’acheminement en fonction de l’en-tête d’hôte, mais en fonction de l’adresse IP. TOUTEFOIS, si vous utilisiez des en-têtes d’hôte et que toutes les applications web utilisaient la même adresse IP, cette application web d’écoute ne doit pas avoir de valeur d’en-tête d’hôte. Autrement, IIS ne récupèrera pas les demandes d’application pour n’importe quelle application web.

      • Adresse IP : 192.168.1.13
      • Certificat SSL : *.contosoapps.com
  • DNS
    • équipe.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portail.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

Maintenant que nous avons couvert tous les aspects de la configuration de l’infrastructure des applications, nous devons aborder deux autres éléments à prendre en considération pour le lancement de nouvelles applications dans SharePoint 2013 :

  • Les applications SharePoint ne fonctionnent pas sur des applications web qui utilisent SAML. Si vous utilisez l’authentification SAML, vous ne serez pas en mesure d’utiliser les applications SharePoint sur ces applications web. Ce problème sera heureusement résolu dans un Service Pack ou correctif futur, mais constitue une limitation dans la version finale de SharePoint 2013.
  • Les applications SharePoint ne prennent pas en charge plusieurs zones (par exemple, le mode d’approbation Administrateur). Toutes les demandes sont prises en charge à partir de la zone par défaut. Si vous utilisez le mode d’approbation Administrateur pour prendre en charge plusieurs zones, vous risquez de ne pas pouvoir utiliser d’applications SharePoint. Toutes les applications sont prises en charge à partir de la zone par défaut. Donc en théorie, si la zone par défaut est exposée et que tous les utilisateurs peuvent y accéder, et si vous utilisiez exactement le même mécanisme d’authentification dans chaque zone (avec quelques limitations possibles que je ne détaillerai pas ici car il s’agit d’un sujet trop complexe), cela pourrait fonctionner. Mais une fois encore, si vous utilisez des zones, cela est généralement dû au fait que a) vous ne souhaitez pas que les points de terminaison soient exposés à tous les utilisateurs ou que b) vous VOULEZ utiliser plusieurs méthodes d’authentification. De même, ce point est susceptible de changer à l’avenir, mais pour l’instant, il sera disponible tel quel dans la version finale de SharePoint 2013.

 

Pour conclure, une dernière remarque importante : les étapes de configuration peuvent sembler assez longues, et elles le sont. Toutefois, gardez à l’esprit que si vous utilisez Office 365, toutes ces étapes sont prises en charge pour vous. C’est propre, net et sans bavure. Vous installez et utilisez les applications en toute simplicité. Vous devriez prendre cet aspect en considération lorsque vous opérez votre choix.

Les voici donc. Les applications SharePoint jouent un rôle important dans SharePoint 2013, mais vous devez effectuez des tâches de planification et de conception en amont pour garantir que l’infrastructure est en place pour les prendre en charge.

 

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale sur Planning the Infrastructure Required for the new App Model in SharePoint 2013