Utiliser la fonction de restriction d’accès aux programmes de la V4R3

La
fonction Limit Access to Program compte sept API; la figure 1 liste ces API
ainsi que leurs paramètres associés. Les fichiers en-tête RPG des API se
trouvent dans les bibliothèques QSYSINC/QRPGSRC et QSYSINC/QRGPLESRC, les
fichiers en-tête C dans QSYSINC/H et les fichiers en-tête Cobol dans QSYSINC/QCBLSRC
et QCBLLESRC. Pour utiliser le support de la fonction de restriction d’accès
dans une application, inscrivez vos fonctions lorsque vous installez
l’application sur une machine de production. Lorsqu’une application est sur le
point d’invoquer la portion de code qui correspond à  une fonction inscrite,
l’application appelle l’API QSYCKUFU (Check User Function Usage) pour vérifier
si l’utilisateur a le droit d’utiliser la fonction. Si c’est bien le cas, la
portion de code peut être exécutée. Dans le cas contraire, le code que vous
avez rédigé dans l’application empêche l’utilisateur d’exécuter la fonction
et renvoie un message au programme appelant ou un code erreur. La figure 2 présente
un exemple de code CL qui vérifie si un utilisateur bénéficie de l’accès à 
une fonction.

           
Pour inscrire des fonctions, déterminez d’abord le support auquel vous
souhaitez limiter l’accès et définissez une fonction pour chaque interface à 
contrôler. Une fonction présente les caractéristiques suivantes :

• Un nom (ID) de 30 caractères de long qui identifie de façon
  unique la fonction à  laquelle on souhaite limiter l’accès. Il est préférable
  que l’ID commence par le nom de l’entreprise pour éviter d’entrer en conflit
  avec les ID des fonctions d’autres entreprises (comme par exemple celles d’éditeurs
  de logiciels).
  
  

• La possibilité de classer les fonctions en fonction du système
  sur lequel le code associé à  la fonction s’exécute: sur l’AS/400, sur le
  client ou comme un plug-in Operations Navigator sur le client.
  
  

• La possibilité de définir une hiérarchie des fonctions qui
  illustre la façon dont elles s’accordent entre elles et permettent à  un
  administrateur de gérer l’accès à  toutes les fonctions au sein d’un groupe hiérarchique
  
  
  

• La possibilité d’affecter un nom à  la fonction qui soit plus
  "lisible" que l’ID de la fonction
  
  

• La possibilité d’empêcher un utilisateur disposant des droits spéciaux
  *ALLOBJ d’accéder à  une fonction
  

           
La figure 3 présente les différentes catégories de fonctions et
l’utilisation du support  hiérarchique et des noms textes des fonctions. Depuis cette
fenêtre, un administrateur peut modifier les paramètres sous les colonnes
Default Usage, All Object Usage et Customized Usage pour l’ensemble des
fonctions dans un groupe hiérarchique en changeant les paramètres de la
fonction "parent". Par exemple, la modification un paramètre de la
fonction Operations Navigator Basic Operations change également ce paramètre
pour les fonctions Messages, Printer Output et Printers.

           
Lorsqu’on a déterminé les fonctions à  contrôler dans une application,
on peut écrire un programme qui appelle l’API QSYRGFN (Register Function) pour
inscrire les fonctions. L’application ne devra appeler ce programme qu’une seule
fois, lors de l’installation de l’application. La figure 4 présente un extrait
du programme CL qui inscrit les fonctions.

           
Après qu’une fonction ait été inscrite, le responsable de la sécurité
(un utilisateur disposant des droits spéciaux *SECADM par exemple) peut spécifier
qui a ou n’a pas le droit d’accéder à  cette fonction. Le moyen le plus simple
de gérer l’utilisation d’une fonction reste l’interface graphique Application
Administration d’Operations Navigator (OpNav). Parallèlement, on peut utiliser
l’API QSYCHFUI (Change Function Usage Information) dans un programme. Pour avoir
plus d’informations sur l’utilisation de cette API et sur les autres API de la
fonction Limit Access to Program, consultez le manuel System API Reference (SC41-5801).

           
OpNav lui-même utilise la fonction de restriction d’accès pour
permettre aux administrateurs de contrôler l’accès aux fonctions OS/400. OpNav
a inscrit des fonctions qui correspondent à  tous les dossiers de niveau supérieur
et à  quelques sous-dossiers de la hiérarchie OpNav. Lorsqu’un utilisateur se
sert de OpNav pour travailler sur un AS/400, celui-ci vérifie les fonctions
(par exemple, dossiers/sous-dossiers) auxquelles l’utilisateurs peut accéder et
n’affiche que ces fonctions-là .