Plusieurs cas rencontrés chez nos clients nous interpellent.
Dans chaque cas, c’est lié à l’utilisation de la java toolbox par des process IBM.
Voici deux de ces cas identifiés actuellement .
- Sécurisation d’un serveur IWS par liste de validation
- Serveur IWS sans serveur HTTP.
- Profil serveur par défaut QWSERVICE
- Sécurisation du serveur TLS + authentification basique via liste de validation
Alors que sur un serveur IWS avec serveur HTTP et l’authentification basique par liste de validation sur le serveur HTTP, ça fonctionne. Dans ce cas le job serveur tourne avec le profil QTMHHTTP qui est un profil sans mot de passe.
Dans notre cas, pas de serveur HTTP, donc authentification basique sur le serveur d’application qui est un serveur java.
Avec le paramétrage ci-dessus, impossible de faire fonctionner l’authentification basique.
La justification se trouve dans le IWS Programming and Administration guide, aux pages 60 & 76.The IBM i user profile configured to execute the web service must be enabled and the password must be set to a value other than *NONE. This is a requirement implemented by the IBM Toolbox driver used to execute the remote web service program or SQL query. This is considered working-as-designed. The customer will need to either ensure QWSERVICE is enabled and has a password assigned OR they can configure the IWS server and/or web services to run under another IBM i user profile that is enabled and has a password assigned.
Selon la documentation, il est nécessaire que le profil de démarrage du serveur ait un mot de passe. Et en effet en faisant des tests dans ce sens, l’authentification fonctionne.
Donc pour rajouter de la sécurité sur notre serveur IWS, via les listes de validation, nous avons du rajouter un mot de passe sur un profil technique qui n’a pas vocation à ouvrir de session mais uniquement à lancer des jobs batch.
- Serveur IWS sans serveur HTTP.
- Démarrage des serveurs IWS par programme par le script Shell
Si on veut démarrer par programme un serveur IWS, via le script Shell – startWebServicesServer.sh, comme par exemple dans le QSTRUP, si on utilise un profil typé batch qui n’a pas de mot de passe, le serveur ne démarre pas.
En rajoutant un mot de passe sur le même profil, le serveur démarre.
Après échange avec le point service, voici les explications :Les scripts IWS utilisent les classes java de la toolbox. Celles-ci nécessitent un mot de passe, ne peut pas être à *NONE.Using IBM Toolbox for Java with Native Optimizations
https://www.ibm.com/support/pages/node/640709 « The host servers require passwords in order to allow a connection even in the case where no networking is used. Therefore, the user profile must have a password; it cannot be set to *NONE and be able to make a connection to a host server. »
Extrait d’une demande rapportée au développement IBM i sur le sujet par le passé :
» This is working as designed since the IWS administration scrips utilize the IBM Toolbox driver to connect to the IBM i Host Servers. The IBM Toolbox does not allow connections to the IBM i Host Servers using an IBM i user profile with a password set to *NONE for security reasons. «Dans les deux cas, nous avons des jobs batchs techniques, avec des profils pouvant avoir des droits forts, par exemple le profil de lancement du QSTRUP, qui sont sans mot de passe. D’utiliser des profils sans mot de passe, ça fait partie de nos préconisations depuis des années, pour raison de sécurité. Il nous semble important de limiter de nombre de profils, et que ceux n’ayant pas vocation à ouvrir de sessions, ne puissent pas en ouvrir, ce qui veut dire le mot de passe à *none. On sait d’expérience, que les profils typés batch avec mot de passe, ont tendance à ne plus avoir de péremption de mot de passe, et donc aucun changement de ces mots de passe, ce qui augmente les risques de sécurité.
Dernièrement, les interactions entre les process java utilisant la java toolbox et nos batchs, nous obligent à renseigner des mots de passe sur nos profils batch, la java toolbox obligeant d’avoir des mot de passe pour raison de sécurité.
Donc pour augmenter la sécurité côté java, on diminue la sécurité côté OS. Ca ne nous semble pas un bon compromis.J’ai ouvert une ideas à ce sujet. Pour rappel, les ideas sont des demandes que nous pouvons faire à IBM pour l’évolution du système. Pour qu’une ideas soit prise en compte, il faut au départ que des personnes votent sur la demande.
Si vous trouvez aussi que le compromis n’est pas bon, je vous propose de voter pour l’ideas que j’ai ouvert :
https://ideas.ibm.com/ideas/IBMI-I-4552Edit du 10/02/2026 : L’idea est passée en « Future consideration »
