Modèle de programmation de l'API Web Services Security
Le modèle de programmation du serveur d'applications fournit des interfaces de programmation d'applications Web Services Security (WSS API) pour la sécurisation des messages SOAP.
Le modèle de programmation d'API est un modèle de programmation basé sur une interface fondée sur les normes Web Services Security Version 1.1. Cependant, la conception inclut également la prise en charge de Web Services Security Version 1.0 pour la sécurisation des messages SOAP. L'implémentation du modèle de programmation WSS API est une version simplifiée. Elle est basée sur un avant projet pour JSR-183, qui est le JSR de définition de la liaison API Java™ pour la sécurité de service Web. Dans la mesure où le code de l'application a été conçu pour être programmé pour l'interface, un code d'application programmé à l'aide de l'implémentation de la source ouverte doit pouvoir s'exécuter sur WebSphere Application Server avec un minimum de modifications voire aucune.
Le modèle de configuration des services Web a également été re-conçu d'un modèle de descripteur de déploiement en un modèle d'ensemble de règles. Web Services Security peut être activé à l'aide d'un ensemble de règles configuré via la console d'administration, ou à l'aide de l'API WSS pour la configuration. Les fonctions proposées par les configurations d'ensemble de règles sont identiques à celles prises en charge par l'API WSS pour le module d'exécution de Web Services Security. Cependant, la règle de sécurité définie à l'aide d'ensembles de règles a la priorité sur l'API WSS. Lorsque l'interface API WSS et l'ensemble de règles sont utilisés dans l'application, le comportement par défaut est valable pour la règle de sécurité tirée de l'ensemble de règles à renforcer et dans l'interface API WSS à ignorer. Pour pouvoir utiliser l'interface API WSS dans l'application, vous devez vous assurer qu'aucune ensemble de règles n'est associée à l'application ou aux ressources d'application. Vous devez également vous assurer qu'il n'y a aucune règle de sécurité associée à l'ensemble de règles.
Vous pouvez toujours utiliser vos applications JAX-RPC existantes avec Web Services Security. Cependant, ces applications ne peuvent pas tirer parti des fonctions de Web Services Security Version 1.1, comme la configuration de la stratégie de sécurité à l'aide d'un ensemble de règles, les améliorations de performances de filtre OM, l'API WSS, les fonctions Web Services Secure Conversation (WS-SecureConversation), le jeton Kerberos et la clé SHA-1 associée pour la protection des messages et la propagation des identités et Web Services Trust (WS-Trust).
Pour tirer parti des fonctions Web Services Security Version 1.1, vous devez récrire une application JAX-RPC existante en tant qu'application JAX-WS, reconfigurer manuellement les contraintes de sécurité applicables à un ensemble de règles et effectuer la migration de code des interfaces SPI DOM vers les interfaces SPI OM.
Par exemple, lors de l'utilisation du modèle de programmation JAX-WS, la conception avancée de l'infrastructure de jeton connectable permet la même implémentation de sécurité à utiliser pour les API et les ensembles de règles. L'infrastructure utilise le module de connexion JAAS et le gestionnaire d'appel JAAS pour la création et la validation des jetons.
Les diagrammes suivants illustrent les différences entre les modèles de programmation.


Fonctionnalités prises en charge lors de l'utilisation des API WSS
L'API WSS ne peut être utilisée que sur le client. Vous pouvez utiliser le client Java SE 6 client, le client d'application J2EE ou un client serveur (fournisseur de services intervenant en tant que client), à l'aide de l'API pour sécuriser le message SOAP via la sécurité de niveau message.
- sont des interfaces Java ;
- sont implémentées à l'aide d'un modèle Factory (WSSFactory) ;
- prennent en charge les normes WS-Security versions 1.0 et 1.1, qui incluent les profils Username et X.509 token versions 1.0 et 1.1 ;
- sont très orientées XML ;
- incluent une conception orientée objet qui simplifie les API ;
- sont orientées tâche et permettent des scénarios d'usage courant, par exemple, la signature du corps et le chiffrement du contenu de corps de message SOAP ;
- sont souples et extensibles, et permettent l'extension du support de type jeton ;
- sont basées sur l'infrastructure fournisseur et permettent l'utilisation de modèles de données différents, par exemple, AXIOM ou DOM ;
- fournissent au programmateur d'application un meilleur contrôle et une meilleure souplesse lors de la mise en oeuvre de WSS dans leurs applications.
Les valeurs par défaut de l'API WSS sont prédéfinies et font partie du module d'exécution Web Services Security. Des valeurs par défaut sont fournies pour :
- la durée de l'horodatage ;
- l'algorithme de signature, l'algorithme de canonisation, l'algorithme de transformation, la méthode de référence de jeton de sécurité et les parties signées telles que le corps SOAP, les en-têtes Web Services Addressing et l'horodatage ;
- l'algorithme de chiffrement de clé, l'algorithme de chiffrement de données, la méthode de référence de jeton de sécurité et les parties chiffrées telles que le contenu du corps SOAP.
La validation de la signature comporte des valeurs par défaut similaires à celles de la signature (informations de signature). De même, le déchiffrement comporte des valeurs par défaut similaires à celles du chiffrement.
Fonctionnalités non prises en charge lors de l'utilisation des API WSS
L'API WSS fournie avec le serveur d'applications ne prend pas en charge les fonctions suivantes :
- Le modèle de programmation d'application est JAX-WS, ce qui signifie que les applications JAX-RPC (JSR-109) ne sont pas prises en charge.
- L'API WSS est disponible dans l'échange de message synchrone de l'application client JAX-WS. Cependant, l'API WSS n'est pas prise en charge pour le client asynchrone.
- Le support d'API WSS n'est disponible que pour le demandeur et n'est pas disponible pour le fournisseur.
- Le modèle de programmation de la sémantique de vérification d'identité n'est pas pris en charge dans l'API WSS, car la vérification d'identité ne fait pas partie de la norme Web Services Security Version 1.0. Cependant, vous pouvez utiliser l'API WSS pour ajouter la sémantique de vérification d'identité dans le traitement de jeton.
Scénarios WS-Trust et WS-SecureConversation
- utilisation de la règle d'amorce définie dans l'ensemble de règles,
- utilisation de l'API WSS qui prend en charge WS-SecureConversation,
- activation de la règle dynamique pour le fournisseur de sorte que le client puisse extraire la règle côté fournisseur lors de l'exécution.
Une application utilise l'API WSS pour acquérir un jeton de contexte de sécurité pour la conversation sécurisée par programmation basée sur une API. Le service d'accréditation de WebSphere Application Server permet aux applications de demander un jeton de sécurité pour accéder à un service. La portée et la principale fonction du service d'accréditation ne s'appliquent qu'à un jeton de contexte de sécurité (SCT) WebSphere Application Server pour WS-SecureConversation.
Les scénarios WS-SecureConversation et WS-Trust portent essentiellement sur les fonctions d'interopérabilité, telles que l'interaction des divers composants pendant la configuration et l'exécution. Vous pouvez utiliser l'API WSS pour sécuriser les RST et RSTR d'amorce, afin d'obtenir le jeton de contexte de sécurité auprès du service d'accréditation. Après l'acquisition du jeton de contexte de sécurité, un jeton de clé dérivée est créé à l'aide de l'API WSS. Le jeton de clé dérivée peut ensuite être utilisé pour la signature et le chiffrement.
- Génération du message SOAP sécurisé, qui se trouve dans le code d'application du générateur de la demande.
- Consommation du message SOAP sécurisé, qui se trouve dans le code d'application du destinataire de la réponse
Dans les deux cas, une classe d'exception Java com.ibm.websphere.wssecurity.wssapi.WSSException est fournie si une erreur est détectée.
Contexte de sécurité du client de services Web
Lorsque le client JAX-WS appelle des services Web, le contexte de sécurité en cours qui est construit par le gestionnaire de sécurité est stocké dans l'objet RequestContext. Par défaut, le contexte de sécurité dans l'environnement d'exécution du client de services Web JAX-WS est reconstruit pour le prochain appel de demande de services Web. Vous pouvez préserver le contexte de sécurité pour les appels de services Web ultérieurs. Un exemple de ceci est un scénario dans lequel la stratégie de sécurité requiert que le client envoie un jeton de sécurité Username avec le nom d'utilisateur et le mot de passe. Lorsque le client envoie la première demande d'appel de service, vous êtes invité à saisir le nom d'utilisateur et le mot de passe requis. Ces derniers sont enregistrés dans un jeton Username SecurityToken dans un sujet dans le jeton de sécurité. Pour éviter que le système vous invite à nouveau à saisir les mêmes nom d'utilisateur et mot de passe lors des appels de demande suivants, vous pouvez conserver le contexte de sécurité. Il existe deux méthodes pour préserver le contexte de sécurité : 1) configurer l'exécution client afin de conserver automatiquement le contexte de sécurité pour les appels de demande ultérieurs ou 2) préserver manuellement le contexte de sécurité.
Pour configurer l'environnement d'exécution client JAX-WS afin qu'il conserve automatiquement le contexte de sécurité, attribuez la valeur true à la propriété système Java com.ibm.websphere.wssecurity.context.management. Si la valeur de cette propriété système est true, la phase d'exécution du client JAX-WS copie automatiquement le contexte de sécurité construit par le gestionnaire de sécurité dans RequestContext. Ce contexte est ensuite utilisé pour les appels de demande ultérieurs.
// première requête
Service svc = Service.create(...);
svc.addPort(...);
Dispatch<String> dispatch = svc.createDispatch(...);
Map<String, Object> requestContext = dispatch.getRequestContext();
String response = dispatch.invoke(body.toString());
Object securityContext = requestContext.get(com.ibm.wsspi.websvcs.Constants.WEBSPHERE_SECURITY_CONTEXT);
// Demande suivante
Dispatch<String> dispatch = svc.createDispatch(...);
Map<String, Object> requestContext = dispatch.getRequestContext();
Object securityContext = requestContext.put(com.ibm.wsspi.websvcs.Constants.WEBSPHERE_SECURITY_CONTEXT, securityContext);