Suivi de session
Un suivi de session peut – sous condition d'une implémentation spécifique – être instauré entre un client (des clients) et un service Web. Ce suivi de session est directement lié à la notion de portée qui est l'une des caractéristiques de déploiement d'un service Web.
Communément, un service Web a une portée de type 'request' où une nouvelle instance de service est créée pour chaque requête cliente. Par définition, la portée 'Request' ne permet donc pas d'assurer un suivi de session.
D'autres portées telles que la portée 'transportsession' ou la portée 'application' confèrent à l'instance d'un service existant une durée de vie permettant l'instauration d'un dialogue entre le consommateur du service et le service lui-même.
La durée de vie d'une instance de service de portée 'transportsession', est identique à la durée de vie de la session de la couche transport (session HTTP pour une implémentation SOAP via HTTP). Tout au long de la session HTTP le contexte du service est maintenu et le lien entre le client et le service est établi - par défaut - par le classique cookie de session "JSESSIONID". L'instance de service est détruite sur le timeout de la session HTTP.
Pour activer le suivi de session côté client il faut déclarer dans le fichier de configuration l'élément suivant :
<Session><Management>true</Management></Session>
Remarque : Axis2 propose une implémentation supplémentaire du suivi de session de niveau 'transport' (portée nommée 'soapsession') ne s'appuyant pas directement sur la session HTTP (et son cookie de session) mais sur WS-ADDRESSING via l'élément serviceGroupId, dans un en-tête du message SOAP. Il faut alors forcer l'engagement du module 'addressing' en ajoutant l'élément suivant dans le fichier de configuration :
<module><name>addressing</name></module>
Attention : avec Adélia Studio, la consommation d'un service Web Adélia de portée 'transportsession' n'est pas supportée de façon automatisée pour la plate-forme de génération C/Windows. Dans ce cas, pour assurer une gestion automatisée du suivi de session, il faut déclarer un service de portée 'soapsession'.
La durée de vie d'une instance de service de portée 'application' est celle de l'application Web hôte. Une seule instance d'un même service Web existe dans cette application. Tous les clients dialoguent avec la même instance de service et en partagent le contexte. L'instance du service est détruite au déchargement de l'application Web hôte. Il n'est pas nécessaire d'activer le suivi de session puisque par définition une seule session existe. Dans la mesure où le service aurait besoin de connaître avec précision le client avec lequel il dialogue, des règles peuvent être définies entre le client et le serveur sur l'échange d'informations dans le header des messages SOAP. L'utilisation de WS_ADDRESSING ou WS-SECURITY peuvent apporter des solutions à cette problématique.
Remarque : L'instauration d'un suivi de session n'est pas du ressort du consommateur mais est dévolue à la conception/implémentation du service Web. La mise à disposition d'un service aux consommateurs doit toujours s'accompagner d'une information indiquant si oui ou non le suivi de session doit être géré.
Appels asynchrones
Classiquement, un service Web de MEP [Message Exchange Pattern] IN-OUT (aussi appelé 'request-response' ) est appelé de façon synchrone. Le client invoque l'opération d'un service Web et se bloque en attente d'une réponse. Le traitement d'un service pouvant être relativement long, il peut être intéressant de pouvoir appeler ce service de façon asynchrone - sous condition que le moteur de services hébergeant le service Web en soit capable -.
L'ordre Adélia SW_APPELER avec sa directive *ASYN génère un appel asynchrone. Pour savoir si le service a donné sa réponse et s'il est possible de traiter le résultat, il faut régulièrement interroger l'état de la requête adressée au service : l'ordre SW_RECUP_ETAT remplit cette tâche. Si la valeur retournée par l'ordre est différente de 0, alors une réponse est disponible. Plus précisément, une valeur négative indique une erreur de communication entre le client et le serveur, tandis qu'une valeur positive indique un déroulement normal.
L'appel asynchrone peut fonctionner avec un simple ou un double canal de communication. Un canal unique indique que la même connexion HTTP est utilisée pour la requête et pour la réponse. Ce mode est envisageable si le timeout de la couche transport est assez long ou si le traitement de la requête est assez court : si besoin il est possible d'ajuster le timeout de la couche transport dans le fichier de configuration en ajoutant l'élément suivant :
<Transport><Timeout>valeur en ms</Timeout></Transport>
La valeur par défaut du timeout est de 60000 ms, soit 60 secondes.
Pour s'affranchir du timeout de la couche transport il faut utiliser un double canal de communication : un pour la requête et un pour la réponse.
Pour cela, il faut ajouter au fichier de configuration les éléments suivants :
a. Déclaration d'un double canal de communication :
<Transport><UseAsyncDualChannel>true</UseAsyncDualChannel></Transport>
b. Forcer l'engagement du module d'adressage (WS-Addressing) :
<Module><Name>addressing</Name></Module>
Gestion optimisée des éléments binaires (MTOM : Message Transmission Optimization Mechanism)
Les éléments binaires (fichiers image, fichiers audio, etc.) peuvent transiter dans un message SOAP sous forme d'une chaîne encodée en base64. Cette pratique est acceptable pour des éléments de petites tailles mais doit être évitée pour des objets volumineux car, d'une part, l'encodage en base 64 fait augmenter d'environ 1/3 les informations à faire transiter sur la ligne et, d'autre part, le décodage de cette même base 64 est coûteux en temps CPU.
Une optimisation s'appuyant sur le protocole MTOM est possible. La couche transport génère alors un message de type MIME/multipart. Le corps du message SOAP, contenu dans la 1ère partie, fait alors référence au binaire qui est déporté/attaché, dans un format brut, dans une seconde partie.
Pour activer l'optimisation MTOM il faut ajouter au fichier de configuration l'élément suivant :
<ForceMtom>true</ForceMtom>
Remarque : MTOM est compatible avec SwA (SOAP with Attachments).
Déclaration des binaires à optimiser : attributs aws_mtom_src_mem et aws_mtom_src_file
Dans le cadre d'un appel de service en mode "message" il faut, en premier lieu, constituer un document XML. Les éléments binaires, figurant dans le document, devant faire l'objet d'une optimisation MTOM doivent être déclarés à l'aide des attributs aws_mtom_src_mem et aws_mtom_src_file.
- L'attribut aws_mtom_src_mem fait référence à un binaire stocké en mémoire au format d'une chaîne encodée en base 64).
L'ordre Adélia XML_CREER_VAL permet de sérialiser automatiquement une variable IMAGE dans le format requis.
Exemple de création - à l'aide des ordres XML Adélia - d'un élément <pmPICT> avec un attribut aws_mtom_src_mem faisant référence à un binaire stocké en mémoire :
XML_CREER_NOEUD idx *FRERE 'ns0:pmPICT'
XML_CREER_VAL idx aws_mtom_src_mem varImage
- L'attribut aws_mtom_src_file fait référence à un binaire stocké dans un fichier.
Exemple de création - à l'aide des ordres XML Adélia - d'un élément <pmPICT> avec un attribut aws_mtom_src_file faisant référence au fichier binaire à attacher :
XML_CREER_NOEUD idx *FRERE 'ns0:pmPICT'
XML_CREER_VAL idx aws_mtom_src_file 'c:\pics\MonImage.jpg'
Utilisation d'un Proxy
La connexion via un Proxy se paramètre – dans le fichier de configuration – à l'aide des éléments suivants :
<Transport> <Proxy> <Host>?</Host> <Port>?</Port> </Proxy> </Transport> |
Des informations supplémentaires doivent être ajoutées pour un Proxy nécessitant une authentification :
<Proxy> <Host>?</Host> <Port>?</Port> <Credentials> <Usr>?</Usr> <Pwd> <Encrypted>?</Encrypted> <Password>?</Password> </Pwd> </Credentials> </Proxy> |
Connexion sécurisée : HTTPS /SSL
- Chiffrage des données échangées
- Authentification serveur
- Authentification serveur et client
Plateforme client C/Windows
1. Authentification serveur (SSL 1-way) : le client s'assure que le serveur est celui qu'il prétend être.
Par défaut le client fait référence au fichier %adeliws%/certifs/cacert.pem contenant un ensemble de certificats CA pour assurer l'authentification du serveur et établir automatiquement la connexion SSL.
Dans le cas d'un échec de cette connexion, il est possible de renseigner l'élément <Transport><SSLCertificate><ServerCertAuto>true</ServerCertAuto></SSLCertificate></Transport> afin de forcer la récupération d'un certificat depuis le serveur cible capable d'établir la connexion SSL désirée (à utiliser notamment dans le cas d'un certificat auto-signé).
Enfin, si nécessaire il est également possible de renseigner un fichier .pem spécifique pour l'authentification du serveur. Le fichier doit alors être renseigné à l'aide de l'élément <Transport><SSLCertificate><ServerCertFile>.
Exemples :
- Récupération automatique d'un certificat depuis le serveur cible en cas d'échec la connexion SSL automatique :
<Service> <AdeliaName>AX2_DOL</AdeliaName> <Epr>https://vmwas7:8443/axis2/services/AX2_DOL</Epr> <Transport> <SSLCertificate> <ServerCertAuto>true</ServerCertAuto> </SSLCertificate> </Transport> </Service> |
- Utilisation d'un certificat spécifique :
<Service> <AdeliaName>AX2_DOL</AdeliaName> <Epr>https://vmwas7:8443/axis2/services/AX2_DOL</Epr> <Transport> <SSLCertificate> <ServerCertFile>c:\certifs\certif.pem</ServerCertFile> </SSLCertificate> </Transport> </Service> |
2. Authentification serveur et authentification cliente (SSL 2-ways) : le client s'assure que le serveur est celui qu'il prétend être et le serveur s'assure que le client est celui qu'il prétend être.
Pour assurer l'authentification cliente, le client doit posséder un certificat et une clé privée tous deux consignés dans un même fichier .PEM.
Création d'un certificat (auto-signé) et d'une clé privée avec l'outil openssl :
openssl req -x509 -days 365 -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcert.pem
La commande ci-dessus crée un certificat auto-signé dans le fichier hostcert.pem et une clé privée dans le fichier hostkey.pem. Les 2 fichiers doivent être concaténés dans un fichier unique (clientauth.pem par exemple) qui doit être référencé dans le fichier de configuration des services Web :
<Service> <AdeliaName>AX2_DOL</AdeliaName> <Epr>https://vmwas7:8443/axis2/services/AX2_DOL</Epr> <Transport> <SSLCertificate> <ServerCertFile>c:\certifs\certif.pem</ServerCertFile> <KeyFile>c:\certifs\clientauth.pem</KeyFile> </SSLCertificate> </Transport> </Service> |
Remarque : Si un Passphrase (mot de passe) est requis pour accéder à la clé privée, il faut ajouter les éléments suivants :
<SSLCertificate> <ServerCertFile>c:\certifs\certif.pem</ServerCertFile> <KeyFile>c:\certifs\clientauth.pem</ServerCertFile> <Passphrase> <Encrypted>false</Encrypted> <Password>?</Password> </Passphrase> </SSLCertificate> |
Comme tout mot de passe figurant dans le fichier de configuration, le Passphrase peut être passé en clair (Encrypted=false) ou de façon chiffrée (Encrypted=true). Pour chiffrer le Passphrase il faut utiliser la fonction VaToolBxEncryptAdeliaPassword de la VaToolBx avec pour clé de chiffrement la valeur de l'élément <KeyFile>.
3. Côté serveur (exemple Tomcat) :
Le serveur doit être configuré :
- de façon à activer l'authentification cliente (server.xml; HTTPS connector) :
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="20" scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" />
- en désignant le Truststore Java contenant le certificat permettant d'authentifier le client :
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="20" scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" truststoreFile="c:\keystore\.keystore" truststorePass="changeit"/>
Remarque : Le certificat peut être ajouté au Truststore Java à l'aide la commande Keytool :
keytool -import -v -trustcacerts -alias <your alias> -file <your file>.pem -keystore <your key store>.jks -storepass <your storepass>
Plateforme client Java
1. Authentification serveur (SSL 1-way) : le client s'assure que le serveur est celui qu'il prétend être.
Par défaut le client fait référence au fichier %java_home%/lib/jre/security/cacerts contenant un ensemble de certificats CA pour assurer l'authentification du serveur et établir automatiquement la connexion SSL.
Dans le cas d'un échec de cette connexion, il est possible de renseigner l'élément <Transport><SSLCertificate><ServerCertAuto>true</ServerCertAuto></SSLCertificate></Transport> afin de forcer la récupération d'un certificat depuis le serveur cible capable d'établir la connexion SSL désirée (à utiliser notamment dans le cas d'un certificat auto-signé).
Enfin, si nécessaire, il est également possible de renseigner un fichier .pem spécifique ou faire référence à un Truststore JKS spécifique pour l'authentification du serveur. Le fichier ou nom du Truststore doit alors être renseigné à l'aide de l'élément <Transport><SSLCertificate><TruststoreName>.
Exemples :
- Récupération automatique d'un certificat depuis le serveur cible en cas d'échec la connexion SSL automatique :
<Service> <AdeliaName>AX2_DOL</AdeliaName> <Epr>https://vmwas7:8443/axis2/services/AX2_DOL</Epr> <Transport> <SSLCertificate> <ServerCertAuto>true</ServerCertAuto> </SSLCertificate> </Transport> </Service> |
- Utilisation d'un certificat spécifique .PEM :
<Service> <AdeliaName>AX2_DOL</AdeliaName> <Epr>https://vmwas7:8443/axis2/services/AX2_DOL</Epr> <Transport> <SSLCertificate> <TruststoreName>c:\certifs\certif.pem</TruststoreName> </SSLCertificate> </Transport> </Service> |
- Utilisation d'un Truststore JKS :
<Service> <AdeliaName>AX2_DOL</AdeliaName> <Epr>https://vmwas7:8443/axis2/services/AX2_DOL</Epr> <Transport> <SSLCertificate> <TruststoreName>c:/certifs/java/keystore.jks</TruststoreName> <TruststorePwd> <Encrypted>false</Encrypted> <Password>changeit</Password> </TruststorePwd> </SSLCertificate> </Transport> </Service> |
Remarque : Pour chiffrer le mot de passe du Truststore afin qu'il n'apparaisse pas en clair dans le fichier de configuration, il faut utiliser la fonction VaToolBxEncryptAdeliaPassword de la VaToolBx avec pour clé de chiffrement la valeur de l'élément <TruststoreName>.
2. Authentification serveur et authentification cliente (SSL 2-ways) : le client s'assure que le serveur est celui qu'il prétend être et le serveur s'assure que le client est celui qu'il prétend être.
Pour assurer l'authentification cliente, le client doit posséder un certificat et une clé privée tous deux consignés dans un Keystore. Le keystore et le mot de passe permettant d'y accéder doivent être renseignés dans le fichier de configuration des services Web :
<Service> <AdeliaName>AX2_DOL</AdeliaName> <Epr>https://vmwas7:8443/axis2/services/AX2_DOL</Epr> <Transport> <SSLCertificate> <TruststoreName>c:/certifs/java/keystore.jks</TruststoreName> <TruststorePwd> <Encrypted>false</Encrypted> <Password>changeit</Password> </TruststorePwd> <KeystoreName>c:/certifs/java/keystore.jks</KeystoreName> <KeystorePwd> <Encrypted>false</Encrypted> <Password>changeit</Password> </KeystorestorePwd> </SSLCertificate> </Transport> </Service> |
Remarque : Un truststore et un keystore java utilise en standard le même format (JKS). Conséquemment un même store peut être utilisé à la fois comme truststore et keystore.
Exemple de création d'un keystore contenant une clé privée et un certificat avec la commande keytool :
keytool -genkey -alias key1 -keyalg RSA -keystore keystore.jks
Le certificat peut être exporté dans un fichier .cer pour être importé dans le truststore du serveur :
keytool -export -alias key1 -keystore keystore.jks -file clicert.cer
Remarques :
- Dans le cadre d'une authentification cliente, l'utilisation de certificats auto-signés impose l'ajout d'un certificat, dans le truststore du serveur, pour chacun des clients. La solution est de signer les certificats des clients par une même autorité de certification [CA] et d'incorporer le certificat racine de l'autorité en question. Il existe à ce propos des autorités gratuites de certification telle que http://cert.startcom.org/.
- Pour la gestion des certificats, clés privées, autorités de certification, il faut se référer à l'outil keytool du JDK java ou à l'outil openssl.exe.
WS-Addressing, WS-Security, WS-Policy, WS-SecurityPolicy
Ces dénominations définissent des spécifications propres aux services Web.
WS-Addressing est une spécification permettant d'adresser/de router des messages indépendamment de la couche transport.
WS-Security est une spécification permettant de sécuriser les échanges de messages SOAP. Ces mécanismes sont le marquage (timestamp), l'authentification, le chiffrage et la signature digitale. L'ensemble de ces mécanismes permet d'une part de s'assurer qu'un message ne peut être lu ou altéré durant le transit et, d'autre part, de connaître avec certitude l'identité de l'émetteur d'un message.
WS-Policy et WS-SecurityPolicy définissent des grammaires flexibles permettant d'exprimer les possibilités, exigences et caractéristiques générales d'entités dans un système basé sur les services Web.
Adélia Studio s'appuie sur la couche Axis2 et par cet intermédiaire supporte de facto ces spécifications.
WS-Addressing est activé en engageant le module "addressing" depuis le fichier de configuration. Les éléments de configuration propres à WS-Addressing (To, Action, From, ReplyTo, FaultTo, RelatesTo) sont fixés via des propriétés du module.
WS-Security est activé en engageant le module rampart depuis le fichier de configuration. Les éléments de configuration sont passés via un fichier police respectant les grammaires définies par WS-Policy et WS-SecurityPolicy. Le fichier police est référencé à l'aide l'élément PolicyFile du module rampart. Ce fichier doit correspondre aux attentes du service et, la plupart du temps, peut être récupéré depuis le fichier de description (WSDL) de ce dernier. Certains aspects de paramétrage du fichier police sont déclarés soit par des balises propres à Rampart soit par des éléments du fichier de configuration de la consommation des services Web d'Adélia.
Toutes les possibilités offertes par ces spécifications ne sont pas détaillées plus en avant dans cette documentation. Veuillez vous référer aux documentations spécifiques disponibles sur internet pour en savoir plus.