Après plusieurs articles orientés vers la sécurité des APIs RSE, revenons à leurs utilisations.
Dans l’API de demande d’un token, POST /api/v1/session, il y a possibilité de renseigner un host.
Possibilité que j’ai testé. L’idée étant dans un contexte multi partitions de pouvoir utiliser les API RSE, en ayant ouvert ces APIs que sur une seule partition. Les communications entre partition passeront par le host serveur.
Cette stratégie permettra d’en faciliter le contrôle, et de vous assurer hormis pour la partition localhost que toutes transactions se fassent via token, et non par authentification basique.
Dans le reste de l’article, j’appellerais partition maître, la localhost ,et partition cible, toutes les autres.
Pour la demande de token, il faut renseigner en host le nom de la partition cible à la place de localhost :
{
« host »: « MaCible »,
« userid »: « user »,
« password »: « pwd »,
« additionalFactor »: « »
}
Le couple profil/mot de passe sert à se connecter sur la cible via le host serveur, il doit donc exister sur la cible. Le profil utilisé n’a pas besoin d’exister sur la partition maître.
Une fois tout bien renseigné, vous allez vraisemblablement avoir un retour http 400, sauf si vous avez déjà un certificat d’assigné sur le host serveur de la cible :
Il faut en effet avoir associé dans DCM, un certificat sur certaine(s) application(s), en fonction de la version d’OS du serveur cible.
La gestion des connexions au host serveur a changé avec la V7.6.
Cible en V7.6 et postérieure, application de DCM : QIBM_QSVR_OBJC_SERVER
Cible en V7.5 et antérieure, application de DCM : QIBM_OS400_QZBS_*
Attention, le SAN (Subject Alternative Name) du certificat doit être porteur du même nom que le host renseigné dans la demande de token.
Par exemple, sur notre réseau, nos partitions sont accessible via un nom court : xxxxx ou le nom suivi du domaine : xxxxx.gaia.lan.
Si le SAN du certificat porte xxxxx.gaia.lan, je serais obligé de faire la demande de token en renseignant :
{
« host »: « xxxxx.gaia.lan »,
« userid »: « user »,
« password »: « pwd »,
« additionalFactor »: « »
}
Si dans le host, je renseigne uniquement xxxxx ou j’utilise l’adresse IP, la cible rejettera la demande de connexion, par une erreur HTTP 403 :
Comment renseigner le SAN du certificat autosigné ?
A la création d’un certificat, en bas :
Une configuration avec le nom de la partition en common name, à la place du SAN, fonctionne aussi, mais de plus en plus de navigateur bloque ce genre de configuration. Le sens de l’histoire du protocole HTTP est de renseigner le SAN.
Toujours dans DCM, il faut ensuite assigner le certificat à l’application gérant la connexion host server.
Une fois la configuration faite, vous pourrez demander un token pour la cible :
En utilisant ce token, les actions des APIRSE s’effectueront sur la cible.
Prenons le cas d’une bibliothèque inexistante sur la cible :
En utilisant, l’API permettant de lancer des commandes CL, PUT /api/v1/cl, avec le json :
{
« continueOnError »: true,
« includeMessageOnSuccess »: true,
« includeMessageHelpText »: false,
« clCommands »: [
« qsys/crtlib testrseapi »,
« qsys/crtsrcpf testrseapi/qrpglesrc »
]
}
Sur la requête http, seul le token permet de retrouver la cible. Elle n’apparait pas explicitement.
La réponse ne permet pas plus de connaître la cible :
Mais en regardant sur ma partition cible, je retrouve bien les objets créés :
Concrètement, sur votre partition cible, par netstat option3 (Work with IPv4 connection status), en filtrant sur les IP remote sur l’IP de la partition maître par F15, vous allez retrouver le job de connexion avec le port remote et le port local:
Par l’option 8, vous retrouvez le job QZRCSRVS correspondant.
Sur la machine maître, toujours pas netstat, option3, mais en filtrant sur le port local, 27467 dans notre exemple, on retrouve aussi le job de communication, avec l’IP de la partition cible en remote address :
Et toujours par 8, on retrouve le job correspondant, qui est bien le job admin5, le serveur des API RSE.
Lors de la révocation du token, les jobs sont arrêtés, comme il se doit !
En conclusion, dans un contexte multi partition, vous pouvez ouvrir les API RSE sur une seule partition, et bénéficier de ces APIs sur toutes vos partitions.
Par sécurité, on préfèrera prendre un partition non communicante avec l’extérieur en tant que partition maître.
Merci à Thomas Duduyer et Frédéric Gayton du support IBM, pour leurs apports lors de mes recherches sur le sujet.
Nos précédents articles sur les API RSE :
Forcer l’usage des tokens au lieu de l’authentification basique
