Pour rappel, les listes de validation sont des objets sur IBMi, de type VLDL.

Par ligne de commande, on peut seulement créer une liste ou la supprimer.

L’utilisation classique des listes d’autorisation est la sécurisation de vos serveurs IWS par authentification basique. Celles-ci permettent l’utilisation d’un profil qui n’est pas un réel utilisateur IBM i.

La gestion, de ces listes, se passe dans navigator for i, dans le HTTPAdmin :

Onglet « Advanced »

Ce que vous pouvez faire :

• Ajouter une entrée dans la liste, si la liste de validation n’existe pas, elle sera créé pour l’occasion. A minima, il faut renseigner la liste de validation, un profil et un mot de passe
• Changer le mot de passe d’une entrée
• Supprimer une entrée
• Lister les entrées d’une liste

Ce que vous ne pouvez pas faire :

• Consulter le mot de passe en cours d’une entrée, un classique en terme de sécurité.
• Supprimer une liste de validation, il faut utiliser la commande 5250 DLTVLDL

Pour mettre en place la sécurisation d’un serveur via ces listes, il faut, toujours depuis le HTTPAdmin, au niveau de la gestion des sécurités de votre serveur HTTP*, sélectionner l’option liste de validation :

Avantage :

• Ne pas créer de réel utilisateur IBMi pour l’authentification.
• Permettre à des tiers extérieurs d’avoir un login ne pouvant servir que dans le cadre d’appel HTTP à un serveur protéger par la liste d’autorisation dont est issu le login
• Encryption de la liste au niveau OS. Pas de possibilité d’accès aux données de la liste de façon simple.
  
  En cas d’appel depuis l’extérieur du réseau de confiance, ça semble une bonne option.

Inconvénient :

• Il faut connaître en amont le client qui va se connecter, et donc avoir une gestion de demande /création de compte
• L’interface de gestion n’est pas compatible avec un grand nombre d’entrées dans la liste. Dans ce cas il faudra, soit trouver une autre solution pour sécuriser son serveur, soit utiliser les API misent à disposition par IBM

* Sur les versions récentes, la sécurité peut aussi être gérée au niveau du serveur applicatif. A vous de voir, si vous voulez un duo de serveurs HTTP/applicatif ou seulement un serveur applicatif, mais c’est un autre sujet…

Les API de gestion des listes de validation

La documentation officielle :

https://www.ibm.com/docs/fr/i/7.5?topic=ssw_ibm_i_75/apis/sec6.html

IBM nous fournit des API pour gérer les listes de validation. On retrouve les actions possibles dans Navigator for i…. Et d’autres !

En regardant de plus près ces API, on constate sur la création d’une entrée de la présence d’un attribut permettant ou non de décrypter un mot de passe :

Navigator for i utilisant les valeurs par défaut, lorsqu’on crée une entrée par ce biais, le mot de passe n’est pas décryptable.
Par contre, si on crée une entrée par l’API correspondante, avec cet attribut positionné à QSY_VFY_FIND (1), on peut par la suite récupérer le mot de passe via l’API C QsyFindValidationLstEntry() ou son équivalent QSYFDVLE

Prenons des exemples :

Je crée dans une liste de validation, dédié à l’article, DTFORM/DEMOBLOG, un profil MdpnonVIsible avec l’attribut de décryptage à ‘0’, et un profil MdpVisible avec l’attribut de décryptage à ‘1’.

Première remarque : l’appel d’api d’ajout d’une entrée dans une liste de validation renvoie un erreur si la liste n’existe pas. Il faut la créer au préalable par la commande CRTVLDL.

En regardant dans Navigator for i, les deux entrées apparaissent sans distinction :

Lors du décryptage, si on tente un appel de l’API find avec une erreur, mauvais nom de liste, profil inexistant, …, le retour est en erreur, comme pour toutes les API : -1. On peut récupérer le message détaillé de l’erreur, on reste sur de la gestion standard :

Si on lance l’API Find avec pour le profil MdpnonVisible :

L’API renvoie un code retour ok, mais pas de mot de passe, normal, il n’est pas décryptable.

Avec le profil décryptable, on récupère bien le mot de passe initial :

Par cette méthode, vous pouvez donc récupérer des mots de passe stockés dans une liste de validation, à la condition que l’entrée ait été créée avec le top de décryptage à ‘1‘.

Pour compléter la sécurité sur le décryptage des mots de passe, vous pouvez mettre :

• Sur la liste de validation
  • Un profil technique comme propriétaire
  • Aucun droit sur aucun autre profil .
• Avoir un programme dédié au décryptage avec :
  • Comme propriétaire le même que celui de la liste de validation
  • Compilé pour faire de l’adoption de droit.
• Et si on veut aller plus loin, en cas de debug possible en prod, protéger les sources, du programme de décryptage et ses appelants, par mot de passe.

Bien entendu cette stratégie n’est valable que si la gestion des droits utilisateurs est rigoureuse… Pas de *allobj sur les profils par exemple !

Conclusion :

Vous pouvez utiliser les listes de validation pour stocker des profils/mot de passe, sans les stocker en clair sur la machine. Mais on peut très bien imaginer utiliser ces listes pour stocker toutes les données sensibles permettant les échanges inter-applications ou autre :

• URL d’invocation de WS
• IP ou nom DNS pour FTP / SFTP
• …

Et pour cela de se créer une liste par usage, liste pour URL, liste pour IP/DNS, …, de mettre dans le profil, un code application, et dans le mot de passe la valeur que l’on veut récupérer, avec la limitation de 600 caractères pour le mot de passe, à part pour des URL très spécifique, ça ne devrait pas être limitatif.

Les listes de validation restent des objets très peu connu, mais qui mérite de l’être !