Twitter     Facebook     Envoyer à un ami     Imprimer cet article

Il existe de nombreuses approches pour publier, c'est-àdire rendre accessibles ces services depuis l’internet. Dans leur grande majorité, les architectures utilisent des équipements réseau qui servent de « relais » (proxy) entre le réseau internet et le réseau de l’entreprise. Je vais décrire ici les apports d’Intelligent Application Gateway (IAG), la passerelle de publication, de sécurisation et de SingleSignOn (SSO) de Microsoft, dans ce type de scénario.

L’architecture à mettre en place pour ce type de service est assez classique. IAG va se positionner en général en DMZ, et va jouer le rôle de « super reverse proxy ». La différence entre IAG et des boîtiers réseau va se situer dans les services proposés par cette passerelle en termes de publication et de sécurité.

Plus précisément, la différence se situe entre une approche réseau (travail au niveau IP/TCP/ HTTP) et une approche applicative (au niveau http, et audelà : données transportées, comportement utilisateur, etc). Tout d’abord, publier un site MOSS avec IAG est très simple et très intuitif: Comme pour toutes les autres applications d’entreprise (OWA, CRM, … SAP, JDEdwards, PeopleSoft, .. Citrix, Lotus Notes, …) vous allez passer par un assistant et répondre à un certain nombre de questions comme l’IP de votre serveur, les ports, le nom du site MOSS, comment gérer le Signe Sign On (Web, intégré, Kerberos, ..), etc. Voir Figure 3. Si pour certaines applications un simple reverse proxy peut fonctionner, pour d’autres comme pour MOSS (ce n’est pas la seule, et il y en a de plus en plus suite à l’arrivée de nouvelle techniques web comme l’Ajax), la publication se révèle être techniquement beaucoup plus complexe à mettre en oeuvre.

Prenons un exemple : ici l’utilisateur va se connecter via l’URL « IAG.con toso.com » alors qu’en interne, le site web se nomme « HRPortal ». Nous avons donc besoin ici de faire de la « translation de lien » et ceci est relativement classique. Malheureusement cette translation n’est efficace que lorsque l’application publiée est simple (du code HTML, des liens, ..). MOSS utilise des techniques « Web » très récentes.

La page générée par le serveur est relativement complexe car elle contient non seulement du HTML, mais également du code s’exécutant sur le poste de travail lors de son arrivée. On peut donc dire que cette page Web va se « finir » sur le poste de travail de l’utilisateur. Une simple réécriture des liens ne suffit plus, il faut aussi être capable de retoucher tout ou partie du flux qui transite dans la passerelle (html, javascript, java, XML, autre..).

Or, un flux Web contient pour schématiser deux choses :
1)le protocole http
2) la donnée transportée (payload) constituée de HTML, de scripts, etc…

Publier une application Web nécessite de nos jours d’être en mesure de pouvoir inspecter toutes les strates de la conversation http, et d’être en mesure de les modifier si nécessaire. Ceci est encore plus complexe pour les applications qui utilisent des fichiers « Java ». En effet, l’exécution de ce code se fait en dehors du navigateur Web. IAG dispose de moteurs capables d’inspecter et de modifier, pour chaque application, le flux web et donc de le rendre publiable.
Attention : côté administrateur de la passerelle, vous n’avez rien à faire !

Les équipes IAG ont déjà indiqué au produit les actions nécessaires pour chacune des applications de l’entreprise. Les équipes MOSS et IAG travaillent au quotidien ensemble pour fournir les composants nécessaires pour publier à 100 % Sharepoint. Je pense en particulier à ces fonctions avancées comme Datasheets, Explorer view, InfoPath forms, Office intégration, Excel Services, Dash - boards.

Vous pouvez voir ici un extrait de l’assistant de publication de MOSS dans IAG. On peut y voir quelques questions simples, mais également les champs « publicHostName » et « ReplaceHostHeaderWithTheFollowing » qui permet de gérer TOUTES les architectures MOSS possibles. Publier MOSS à 100 % nécessite donc IAG mais égaleiTPro ment un paramétrage spécifique appelé Alternate Access Mapping (AAM) coté Sharepoint. Important : de nombreux clients utilisent des systèmes d’authentification non Windows (page Web ou intégré) au sein de l’entreprise.

On peut citer les technologies de fédération comme ADFS, ou des produits tiers comme Site Minder de Computer Associates. Dans ce type d’architecture, les utilisateurs peuvent se connecter à Sharepoint (via des plugins de ces éditeurs), mais ils perdent l’intégration avec Office. En effet, Office s’exécute en dehors du contexte de sécurité du navigateur, perdant le « cookie de session » ce qui se traduit par une nouvelle demande d’authentification, et ce à chaque téléchargement de document. IAG va permettre également de régler ce problème car il gère son propre cookie de session.

Dans ce type d’architecture de publication interne à l’entreprise, vous aurez donc avec IAG un panel de services vous permettant de faire face à une grande variété de situations, tant au niveau de l’authentification de bordure (transparent, login mot de passe, ADFS, carte à puce, autre..), du Single Sign On (web, kerberos, autre ...), la traçabilité, et surtout de la sécurité applicative. IAG peut donc être positionné en mobilité (VPN/SSL) mais également sur des projets très structurants comme la publication interne.

Twitter     Facebook     Envoyer à un ami     Imprimer cet article