Sécurité des services Web et relations de sécurité Java Platform, Enterprise Edition
Cet article décrit la relation entre la sécurité des services Web (sécurité au niveau des messages) et le modèle de sécurité Java™ EE (Java Platform, Enterprise Edition). Il comporte également des informations sur les vérifications d'autorisations basées sur les rôles Java EE.
WebSphere Application Server prend en charge les demandes JSR(Java Specification Requests) 101 et 109. Ces spécifications JSR définissent les services Web pour l'architecture Java EE afin que vous puissiez développer et exécuter des services Web sur l'architecture de composants Java EE.
Sécurisation des services Web avec la sécuritéWebSphere Application Server (sécurité fondée sur les rôles Java EE)

Le port de services Web peut être sécurisé à l'aide de la sécurité fondée sur les rôles Java EE. L'expéditeur de services Web envoie les données d'authentification de base à l'aide de l'en-tête HTTP. SSL (HTTPS) peut être utilisé pour sécurisé le transport. LorsqueWebSphere Application Server reçoit le message SOAP, le conteneur web authentifie l'utilisateur (dans cet exemple, utilisateur1) et définit le contexte de sécurité pour l'appel. Une fois le contexte de sécurité défini, le servlet du routeur SOAP envoie la demande à l'implémentation des services Web (il peut s'agir de fichiers de beans enterprise ou JavaBeans). Pour les implémentations de bean enterprise, le conteneur d'EJB effectue une vérification d'autorisation par rapport à l'identité d'utilisateur1.
Le port de services Web peut également être sécurisé à l'aide du rôle Java EE. Puis, l'autorisation est effectuée par le conteneur Web avant la répartition de la demande SOAP vers l'implémentation de services Web.
Sécurisation des services Web avec la sécurité des Services Web au niveau du message
Vous pouvez également sécuriser les services Web à l'aide de la sécurité des Services Web au niveau des messages. Dans ce cas, vous pouvez signer ou chiffrer de manière numérique une certaine partie du message. La sécurité des services Web prend également en charge la propagation du jeton de sécurité dans le message SOAP. Le scénario suivant suppose que le port des services Web n'est pas sécurisé à l'aide de la sécurité fondée sur les rôles Java EE et que le bean enterprise est sécurisé avec la sécurité fondée sur Java EE.

Dans ce cas, le port de services Web n'est pas sécurisé avec la sécurité fondée sur les rôles Java EE. Le moteur de services Web traite le message SOAP avant que le client n'envoie le message au port de services Web. L'exécution de la sécurité des Services Web agit sur les contraintes de sécurité, telles la signature numérique, le chiffrement ou la génération (et l'insertion) d'un jeton de sécurité dans l'en-tête SOAP. Dans ce cas, <wsse:UsernameToken> est généré avec utilisateur1 et le mot de passe. Au niveau du serveur (réception), les services Web traitent le message entrant et la sécurité des Services Web applique les contraintes de sécurité. En appliquant ces contraintes, les services Web s'assurent que les messages sont correctement signés, correctement chiffrés et déchiffrés, authentifient le jeton de sécurité et configurent le contexte de sécurité avec l'identité authentifiée. (Dans ce cas, utilisateur1 est l'identité authentifiée.) Pour finir, le message SOAP est distribué à l'implémentation des services Web (si l'implémentation est un fichier de beans enterprise, le conteneur Enterprise JavaBeans (EJB) effectue une vérification d'autorisation par rapport à utilisateur1). SSL peut également être utilisé dans ce scénario.
Utilisation des deux types de sécurité
Le deuxième scénario indique que la sécurité de Services Web peut être utilisée conjointement à la sécurité fondée sur les rôles Java EE. Par exemple, SSL peut être activé au niveau des transports afin de fournir un canal sécurisé. De plus, si l'implémentation des services Web est un fichier de beans enterprise, vous pouvez mettre à niveau l'autorisation fondée sur les rôles J2EE en effectuant des vérifications d'autorisation. L'exécution de la sécurité des services Web met à niveau l'infrastructure de sécurité afin de définir l'identité authentifiée dans le contexte de sécurité. L'identité authentifiée peut être utilisée dans l'appel en aval vers les ressources Java EE (ou autres types de ressources).
Il existe subtiles conséquences lors de l'association de ces deux scénarios. Par exemple, si le transport HTTP envoie des données d'authentification de base avec utilisateur1 et un mot de passe dans l'en-tête HTTP, <wsse:UsernameToken> avec utilisateur99 et letmein sont également insérés dans l'en-tête SOAP. Dans les scénarios précédents, deux authentifications sont effectuées. Une authentification est effectuée par le conteneur Web pour l'authentification d'utilisateur1 et l'autre est effectuée par la sécurité des services Web pour l'authentification d'utilisateur99. L'environnement d'exécution de la sécurité des services Web s'exécute après le conteneur Web et l'utilisateur99 correspond à l'identité authentifiée définie dans le contexte de sécurité.
La sécurité des Services Web peut également propager les jetons de sécurité de l'expéditeur vers le destinataire pour le transport SOAP sur JMS (Java Message Service).
Vérifications des autorisations basées sur les rôles Java EE
Aucune norme n'existe en matière d'autorisations pour les services Web. Cependant, IBM et Microsoft Corporation ont publié conjointement un livre blanc sur les services Web intitulé Security in a Web Services World: A Proposed Architecture and Roadmap et contenant une proposition de spécification WS-Authorization. Toutefois, la spécification des autorisations WS n'a pas été publiée.
L'implémentation existante de la sécurité des Services Web est basée sur la spécification Java EE ou la spécification Java Specification Requirements (JSR) 109. L'implémentation de la sécurité des services Web exploite les vérifications d'autorisations basées sur les rôles Java EE. Pour obtenir des informations sur le concept, voir la rubrique relative à l'autorisation basée sur le rôle. Si vous développez un service Web qui nécessite des vérifications d'autorisations au niveau de la méthode, vous devez utiliser les beans de session dynamiques pour implémenter votre service Web. Pour plus d'informations sur l'utilisation des beans session sans état en vue d'implémenter un service Web, voir les rubriques "Implémentation d'applications de services Web avec JAX-WS" ou "Implémentation d'applications de services Web avec JAX-RPC", selon votre modèle de programmation. Lisez aussi la rubrique sur la sécurisation des applications de bean enterprise. Si vous développez un service Web implémenté en tant que servlet, vous pouvez utiliser une autorisation à granularité grossière ou basée sur une URL dans le conteneur Web. Néanmoins, dans cette situation, vous ne pouvez pas utiliser l'identité issue de la sécurité des services Web pour les vérifications d'autorisations. Vous pouvez plutôt utiliser l'identité issue du transport. Si vous utilisez SOAP via HTTP, l'identité se trouve dans le transport HTTP.