User:Wsuaw-carver/Sandbox/fr

Renforcement de la sécurité des services Web

Cette section traite des techniques et des méthodes pour améliorer la sécurité des services Web.

Le WS-Policy a été standardisé par le W3C groupe et est devenu connu sous le nom de la norme de facto de la politique de spécifications de services Web. Il y avait un certain nombre de propositions à traduire le WS-Policy dans la logique. Une telle proposition utilise OWL-DL pour fournir la sémantique formelle. Utilisation d'un Reasoner, il fournit un mécanisme qui détermine si les deux politiques sont compatibles. Le Reasoner Pellet est utilisé comme un standard de plug-in pour l'open-source outil appelé Protégé disponibles par le biais de l'Université de Stanford. WS-Policy dans des dossiers sont mis en correspondance avec OWL-DL repose sur l'idée que la politique du service affirmations sont mappés à des classes, et les demandeurs de services Web sont mis en correspondance avec OWL individus. Le Reasoner fournit un certain nombre de services dans le confinement, l'équivalence, l'incompatibilité, l'incohérence (rien ne peut satisfaire à la politique) et de la politique de conformité, entre autres. Ainsi, la cartographie nous permet d'utiliser un "off-the-shelf" OWL Reasoner comme un moteur politique et outil d'analyse, et un "off-the-shelf" OWL éditeur comme une politique de développement et d'intégration environnement. OWL éditeurs peuvent également être utilisés pour développer de domaine spécifique affirmation langues (essentiellement, les ontologies de domaine), avec un uniforme de la syntaxe et la sémantique bien définies. Politique de l'intersection est aussi utilisée quand un web service demandeur et le fournisseur veulent calculer la compatibilité entre les politiques de rechange. OWL-DL est un standard du W3C, un langage clair à la syntaxe et la sémantique qui est omniprésent dans le Web sémantique. Le nombre de reasoners-DL et les éditeurs OWL n'ont pas cessé de croître. Une politique fondée sur la langue-OWL DL peut capitaliser sur la popularité de OWL-DL. Les exemples précédents décrits n'auraient pas été possibles sans les modifications de Pellet. En outre, une interface utilisateur a été développé dans le cadre du projet appelé SWOOP. Il peut être téléchargé à l'adresse suivante: [1].

Une autre méthode pour étendre la sécurité des services Web est d'utiliser la spécification JAX-WS, en liaison avec JAX-WS RI. Les gestionnaires de JAX-WS ont certaines limites. Par exemple, LogicalHandler permet d'accéder à la charge utile et ne pas donner accès aux têtes SOAP et binaire de données effectués en tant que pièces jointes dans le message SOAP, et est plus adapté à XML / HTTP contraignant. En outre, bien que SOAPHandlers fournisse l'accès à l'ensemble du message SOAP, il a des implications que la performance est basée sur SOAPMessage DOM et essaie de charger l'ensemble du message en mémoire. D'autre part, JAX-WS RI lit le message en mode streaming et essaie de lire les informations paresseusement à fournir de meilleures performances. La spécification JAX-WS supporte le WS-I, y compris les spécifications WS-I Basic Profile, WS-I Attachments Profile, WS-I Simple SOAP Binding Profile 1.0 WS-Addressing - Core, reliure SOAP, WSDL et de reliure. JAX-WS RI définit message abstraction-cacher la représentation des données, soit le message est construit à partir d'un objet ou JAXB InputStream d'un HttpConnection. Le message API fournit divers moyens d'accéder à la charge utile et les implémentations peuvent mettre en œuvre ces méthodes de la meilleure façon possible. JAX-WS runtime choisit le Message quand il construit un nouveau message. En outre, il fournit quelques méthodes d’implémentation utilisés par le message de mise en oeuvre de la classe de base (par exemple, JAXBMessage, DOMMessage, SAAJ Message, et ProtocolSourceMessage). Chacune de ces classes a un message particulier, les caractéristiques et les mai-être plus utile ou adapté en fonction de la situation. Avec l'ajout de l'IR, le développeur a accès à l'usine de méthodes statiques pour créer facilement des messages avec les messages API. En utilisant cette approche, il peut facilement accéder et de créer des messages, indépendamment de la représentation des données. Utilisant les extensible Handler cadre prévu par la spécification JAX-WS et une meilleure Message abstraction RI, une nouvelle classe de traitement mai être mis en place un MessageHandler appelé à étendre les applications de service Web. MessageHandler est similaire à SOAPHandler, à l'exception de la mise en œuvre est de l'accès à MessageHandlerContext (une extension de MessageContext). Grâce à la MessageHandlerContext classe, les messages peuvent être consultées et traitées à l'aide de l'API Message [2].

Références

[1] Vladimir Kolovski et Bijan Parsia, WS-Policy et au-delà: Application de la valeur par défaut est OWL Web Service Policies. Department of Computer Science, University of Maryland, College Park, MD, USA, 2008.

[2] JAX-WS 2.1 GH Document Architecture, Sun Microsystems, 2009.