SOA & Interop @ Microsoft France : Livre blanc

The Architecture Journal : Gestion des identités et des accès

Steve SFARTZ — Mon, 01 Sep 2008 09:49:00 GMT

Le 16ème numéro de l’Architecture Journal se concentre sur la gestion des identités et des accès. Si vous débutez sur le sujet, vous serez intéressé par The Evolving Role of the Identity: From the Lone User to the Internet.

Pour ceux qui ont déjà quelques notions ou bien commencé à travailler sur des applications Claims-Aware, je vous recommande la lecture de Federated Identity Patterns in a Service-Oriented World qui présente 5 patterns : Inter-Domain Token Exchange, Intra-Domain Token Exchange, Third-Party Trust Establisher, Pseudonym Claim Service, Attribute Claim Service, ainsi que la problématique de mise à jour des données.

Pour projeter ces concepts sur des exemples concrets, il ne vous reste plus qu’à lire Claims and Identity: On-Premise and Cloud Solutions et maquetter une transformation de claims avec les BizTalk Services ou bien mettre en place un environnement de test local via le framework de gestion des identités Zermatt (voir ce billet de Vittorio Betocci).

WCF : Scenarios de déploiements

Steve SFARTZ — Fri, 25 Jul 2008 12:37:00 GMT

L'article MSDN "Windows Communication Foundation: Application Deployment Scenarios" proposé par la Michele Leroux Bustamante d' IDesign, présente 5 scénarios de déploiement de services basés sur WCF. Architecture, implémentation et sécurité, tout y est.

Un guide qui méritera d'être actualisé avec l'arrivée de Silverlight 2, et les spécificités du proxy client WCF.

Bande dessinée : A la quête de la SOA

Steve SFARTZ — Thu, 20 Mar 2008 12:40:00 GMT

François Cointe signe cette bande dessinée qui met en exergue les atouts et les déboires des initiatives SOA en entreprise

Bravo Angélica Reyes et Eric Ortiz pour cette démocratisation réussie de la SOA !

Administrer et optimiser BizTalk Server en 660 pages

Steve SFARTZ — Wed, 19 Mar 2008 18:18:00 GMT

Le guide Microsoft BizTalk Server Operations Guide a été rédigé à partir de nombreuses expériences terrain. Il est intéressant pour son côté opérationnel : comment intervenir sur la disponibilité de mon infrastructure BizTalk ? comment optimiser les flux de messages ? ...

C'est une lecture qui séduira les Architectes BizTalk par les scénarios concrets qu'il propose.

Un seul bémol : les aspects spécifiques à la R2 sont peu couverts, même si la quasi-totalité des concepts et solutions proposés s'appliquent non seulement à BizTalk 2006 mais aussi BizTalk 2006 R2.

Disponibilité de .Net 3.5 : Du neuf pour vos Services

Steve SFARTZ — Thu, 22 Nov 2007 03:48:00 GMT

Avec la disponibilité du framework .Net 3.5, ce sont deux années d'investissements Microsoft qui bénéficieront progressivement à toute la plate-forme applicative (SQL Server, BizTalk et SharePoint), et dès maintenant pour vos développements spécifiques. Pour plus d'informations sur .Net 3.5, consulter ce billet.

Nous nous intéressons ici aux nouveautés concernant les frameworks WCF et WF, ainsi que l'outillage proposé par Visual Studio 2008 lui aussi disponible en version finale.

Nouveautés WCF et WF avec .Net 3.5

Côté protocoles :

WCF supporte des versions de spécifications WS-* supplémentaires : Web Services Atomic Transaction (WS-AtomicTransaction) 1.1, WS-ReliableMessaging 1.1, WS-SecureConversation, and Web Services Coordination (WS-Coordination) 1.1.

Les amateurs d'une stack de services plus orientée Web qu'Entreprise (j'entends par là l'utilisation exclusive du transport des messages via HTTP, ainsi que l'utilisation du protocole Web incarné par le vocabulaire GET, POST, PUT, DELETE) ne seront pas en REST.

Les attributs WebGet (HTTP GET) et WebInvoke(HTTP GET, POST, PUT, DELETE) peut maintenant être spécifiés au niveau de l'OperationContract

Côté formats :

WCF simplifie dorénavant la publication d'informations au format XML POX (XML sans enveloppe SOAP) et supporte nativement les formats d'échanges sur le Web, à savoir RSS, ATOM ainsi que JSON

Pour mettre en œuvre ces formats, on privilégiera le protocole HTTP via l'utilisation du WebHttpBinding, et l'attribut d'opération WebGet présenté précédemment

Côté composition :

WF peut maintenant être hébergé dans un hôte WCF, le WorkFlowServiceHost qui permet ainsi de déclencher un Workflow dès la réception d'un message sur un point d'exposition WCF. Il s'agit donc de démarrer un WorkFlow depuis une réception TCP, Pipe Nommé, HTTP, MSMQ voir SAP ou SIBEL en ayant recours au BizTalk Adapter Pack ou encore via JMS via le connecteur proposé par JNBridge.
Par ailleurs, un workflow WF peut désormais invoquer des services externes via WCF.

Côté consommation :

Le support de JSON permet à WCF d'être positionné comme un fournisseur de données pour les technologies AJAX, dont les applications Web ASP.Net AJAX.

Pour aller plus loin, je vous recommande ces trois livres blanc de David Chappell :

Introducing_WCF_in_NET_Framework_35_v1.doc : remarquable introduction à WCF.
WCF_Diversity_Paper_v1.doc : entre dans l'architecture de WCF, à réserver à un public averti. Introduction au WCF LOB Adapter Pack et aux bindings associés à la communication vers les BizTalk Services (Connectivité / Relais et Identité)
Introducing_WF_in_NET_Framework_35_v1.doc : remarquable introduction à WF.

Les bénéfices apportés par Visual Studio 2008

Visual Studio 2008 constitue la première version d'un environnement packagé pour des développements WCF et WF, au bénéfice de la productivité et de l'industrialisation.

Parmi les nouveautés VS2008, vous apprécierez la possibilité de tester vos services sans passer par la création de host. VS2008 se charge de créer un host pour vous avec exploration des méta-données et soumission de messages (requêtes / réponses).

Le designer WF permettant de déclencher l'invocation du workflow sur réception d'un message est aussi intéressant quoiqu'un peu complexe à prendre en main (avec un effet désagréable un peu boîte noire)

Configurations de développement

Dans les mois qui viennent, les technologies reposant sur le framework .Net 3.5 et Visual Studio 2008 s'aligneront sur ces dernières versions. En attendant, vous devrez maintenir 2 configurations si vous utilisez BizTalk ou bien la Service Software Factory :

.Net 3.5 / VS 2008 : permet de développer des projets .Net 2.0, 3.0 et 3.5

Attention, possibilité d'upgrader un projet VS2005 en VS2008, mais pas l'inverse

.Net 3.0 / VS2005 : permet de développer des projets .Net 2.0 et 3.0 (via des extensions à VS2005)

BizTalk 2006 R2 requiert VS2005 (pas de date de support de VS2008 annoncé), ainsi que l'ESB Guidance par voie de conséquence
La Service Software Factory repose sur le SDK de VS2005 (on devrait disposer d'un support de VS2008 pour le premier trimestre 2008 - dixit Don Smith à la conférence SOA & BPM)

Recommandations pour sécuriser ses Services Web

Steve SFARTZ — Mon, 03 Sep 2007 17:16:00 GMT

La division Sécurité des laboratoires de l'IT de l'institut national américain des standards et de la technologie (NIST) publie ses recommandations quant à la sécurisation des Services Web : "Guide to Secure Web Services". Ce guide constitue une excellente introduction à la problématique de sécurisation des échanges via les Services Web.

Le guide débute par une présentation rapide des concepts associés aux Services Web : la mise en relation des services, la transmission de messages, l'accès aux services, les intervenants dans la chaîne d'invocation d'un service (le consommateur, le fournisseur et les intermédiaires), et enfin la nécessaire orchestration.

De façon classique, la sécurité des Services Web reprend les éléments standards de sécurité (Identification, Autorisation, Intégrité, Non répudiation, Confidentialité, et Restriction de l'accès). Ces caractéristiques se traduisent par les dimensions.

La sécurisation des messages : au niveau du transport ou bien du message SOAP

La protection des ressources : au travers de l'authentification et la gestion des autorisations

La négociation des contrats : afin d'établir la future communication, il est nécessaire de

L'établissement de relations de confiance : basées sur une authentification point à point ou la mise en place d'une gestion fédérée des identités

La prédictibilité, la disponibilité et la conformité sont aussi requis comme pour tout logiciel se prétendant sécurisé.

La pile des protocoles concourant à la sécurisation des Services Web y est présentée sous la forme originale d'une stack OSI.

La couverture des fonctionnalités de sécurisation SOA proposée par chaque protocole y est synthétisée comme suit.

Si bien que le guide présente l'ensemble des menaces de sécurité encourues par les Services Web, et comment les standards WS-* se complètent pour endiguer ces menaces sur la figure suivante :

Les rédacteurs soulignent qu'il n'y a pas de standards pour contrer les attaques de type Deny Of Service, et qu'il est bien sûr du ressort de l'infrastructure de préserver la disponibilité des services. Les technologies utilisées pour les applications Web seront de mises sur ce point : Load Balancing, utilisation de clusters et la réplication …

J'ajoute sur ce point que la stack de communication orientée services WCF de Microsoft ainsi que les fonctionnalités intrinsèques des OS Windows Serveur 2003 (complété par IIS) et Windows Serveur 2008 (complété par IIS 7 et le WAS - Windows Activation Service) sont riches de mécanismes complémentaires pour assurer la disponibilité des services Web ou non (TCP…) .Les articles MSDN suivants présentent ces aspects : Etendre ses services au-delà de HTTP avec WAS, Load balancing avec WCF.

Le guide rappelle ensuite les risques les plus courants auxquels sont confrontés les Services Web, en plus des risques traditionnels encourus par tout logiciel connecté à un réseau :

L'utilisation des FireWall est limité puisque les messages sont routés sur un port HTTP, et il est difficile pour des raisons de performances de scruter tous les messages SOAP traversant un firewall
La possibilité de router (intercepter, et transmettre) un message un intermédiaire introduit des failles supplémentaires et empêche l'utilisation des protocoles classiques de sécurité HTTPS et SLL sur tous les nœuds de la chaîne de transmission d'un message SOAP
Le contrat WSDL présente lui aussi un risque de sécurité, s'il n'est pas correctement filtré, il peut exposer des fonctionnalités dépréciées, des points d'exposition réservés aur développement, bref, autant de zones d'attaques clairement exposées.
De la même façon, les annuaires UDDI décèlent des informations telles que les versions de protocoles utilisés, si bien qu'il sera simple d'exploiter une faille de sécurité connue sur tel ou tel protocole. De plus, les annuaires UDDI n'intègrent la possibilité de signer leurs contenus qu'à partir de la version 3, si bien qu'un Service Web malicieux pourrait introduire de fausses entrées !
Enfin, les frameworks .Net ou Java utilisés pour implémenter des services Web, mettent en œuvre des mécanismes de sécurité intégrés à la CLR ou la JVM. Les scénarios de sécurité mettant en œuvre des jetons sont intéressants car indépendant de telle ou telle plate-forme. Néanmoins , les frameworks proposent cette fonctionnalité de façon plus ou moins intégrée si bien que le développeur pourra être amené à réaliser des développements sur mesure, source de faille de sécurité.

Remarque : WCF intègre nativement la gestion des jetons de sécurité. La documentation MSDN présente l'architecture de la sécurité dans WCF, ainsi que l'article Security in Windows Communication Foundation.

La section 3 présente les principes d'utilisation des protocoles WS-* pour répondre à des besoins précis

Gérer l'authentification entre 2 deux services
Utiliser un système de gestion des identités
Etablir une relation de confiance entre deux services
Mettre en œuvre des politiques de sécurité
Mettre en œuvre une authentification et des autorisations distribuées
Garantir l'intégrité et la confidentialité des échanges entre deux services
Tracer les échanges SOA
Assurer la disponibilité de ses services
Sécuriser la découverte des services

Pour plus d'informations la sécurité de la SOA Microsoft

Gestion des identités, consulter l'interview de Bernard Ourghanlian
http://www.magsecurs.com/spip.php?article7820

Stéphane Goudeau propose un livre blanc qui couvre la mise en œuvre de scénarios d'échanges sécurisés entre Services Web avec Windows Communication Foundation
https://www.netfxfactory.org/files/folders/documents/entry105.aspx

MSDN : Windows Communication Foundation et la sécurité
http://msdn2.microsoft.com/en-us/library/ms732362.aspx

Qu'est-ce que le NIST ? Et le CSD ?

Le National Institute of Standards and Technology (Institut national des standards et de la technologie), aussi connu sous le sigle NIST, est une agence du Département du Commerce des États-Unis. Son but est de promouvoir l'économie en développant des technologies, la métrologie et des standards de concert avec l'industrie. Cette agence a pris la suite en 1988 du National Bureau of Standards, fondé en 1901 avec substantiellement les mêmes missions (ref Wikipedia).

Le NSIT dispose d'un budget de 843 millions de dollars et emploie environ 2900 personnes dont scientifiques et administratifs,plus 1800 scientifiques externes.

La division Sécurité des ordinateurs (CSD) de la NSIT fait partie des laboratoires spécialisés dans les technologies de l'information. Cette division a pour objectifs

d'améliorer la sécurité des systèmes en augmentant le niveau d'informations concernant les risques IT , en particulier concernant les technologies nouvelles et émergentes.
d'effectuer des recherches et prodiguer des conseils en ce qui concerne les zones de fragilités de sécurité de l'IT
De promouvoir des standards et des programmes de tests et validation
Et enfin de produire des recommandations afin d'améliorer la sécurité des systèmes d'infomation