IBMi : Profil utilisateur dans l’architecture i

Même avec le niveau de sécurité 10, où vous n’avez pas besoin d’un mot de passe ou de profils utilisateur prédéfinis, le système en créera un d’après vos critères de connexion (sign on).

Parmi les nombreuses tâches du profil utilisateur, seules trois nous intéressent pour l’instant.

Premièrement et principalement, le profil utilisateur identifie qui vous êtes. Où que vous alliez dans le système et quoi que vous fassiez, votre profil utilisateur marque son passage et laisse ses empreintes sur le trajet. C’est vrai, le mot de passe n’a pas besoin d’être unique. Autrement dit, plusieurs personnes peuvent utiliser le même, mais, le plus souvent, chacune a un mot de passe unique et c’est préférable. La situation se corse un peu quand il s’agit d’accéder par le web à votre i, mais ce n’est pas notre propos pour l’instant.

Deuxièmement, le profil utilisateur contient le mot de passe nécessaire pour entrer dans le système, ainsi que d’autres informations : date éventuelle d’expiration du mot de passe, profil activé ou désactivé, la bibliothèque par défaut qui servira à créer la liste de bibliothèques initiale, le programme ou le menu initial qui apparaîtra dès la connexion, et votre nom dans le champ texte si vous risquez de l’oublier.

Autrement dit, le profil utilisateur établit le point d’entrée initial et les caractéristiques avec lesquelles vous entrez dans l’i.

Troisièmement, le profil utilisateur définit les privilèges de sécurité de base vous concernant, c’est-à-dire ce que vous pouvez faire ou non dans le système. Quand une application fonctionnant sous un profil de sécurité particulier demande l’accès à un objet, le système donne à l’application un pointeur système contenant juste les privilèges permis par ce profil utilisateur et divers paramètres d’autorité sur les objets. Le pointeur système collecte toutes les permissions pour l’utilisation d’un objet particulier dans une application particulière, dans un jeton unique. Considérez le pointeur système comme une clé qui déverrouille un objet mais qui le déverrouille d’une manière différente pour chaque application.

Quand nous disons qu’un profil utilisateur définit les privilèges de sécurité de base pour un utilisateur, nous voulons dire qu’il fournit un modèle pour la création ultérieure de pointeurs système pour accéder aux objets. C’est très intéressant, mais la vraie question est de savoir comment vous allez créer ou modifier un profil utilisateur pour exercer cette toute-puissance ? Comme souvent avec l’i, il y a plus d’une réponse. Pour commencer, nous pourrions faire un CHGUSRPRF (si c’est autorisé) et nous plonger dans certains des paramètres de cette commande.

User Class (USRCLS) : La première chose à regarder est la valeur de la classe utilisateur. D’un côté, elle vous donne la possibilité, avec une seule entrée, d’établir des autorités spéciales et de définir ainsi un profil de sécurité avec peu de travail. D’un autre côté, comme nous le verrons, elle n’est pas si discriminante que cela et vous ne pouvez pas compter que sur elle.

Les principales classes utilisateur sont Security Officer (*SECOFR), Security Administrator (*SECADM), Programmer (*PGMR), System Operator (*SYSOPR) et User (*USER). Malheureusement, vous ne pouvez pas établir vos propres classes utilisateur. Je sais, c’est regrettable. Pourtant j’aimerais bien offrir la classe *LOSER à certaines personnes de ma connaissance.

*SECOFR est placé tout en haut, et à tous les niveaux de sécurité (10, 20, 30, etc.) il donne à tout profil avec cette classe, les autorités spéciales suivantes : *ALLOBJ, *SAVSYS, *JOBCTL, *SERVICE, *SPLCTL, *SECADM, *AUDIT et *IOSYSCFG. Si aucune d’elles ne fait votre affaire, c’est dommage pour vous.

*SECADM a l’autorité *SECADM au niveau 30 et au-dessus, et *ALLOBJ, *SAVSYS, *JOBCTL et *SECADM aux niveaux 10 et 20. C’est encore très puissant.

Et cela nous amène à *PGMR, *SYSOPR, et *USER. Aux niveaux 10 et 20, ils ont tous *ALLOBJ, *SAVSYS et *JOBCTL. Au niveau 30 et au-dessus, *USER et *PGMR n’ont pas d’autorités spéciales. *SYSOPR a *SAVSYS et *JOBCTL.

La classe utilisateur est un bon moyen d’établir un profil de sécurité approximatif. Vous devez y mettre quelque chose, mais sans que cela vous obsède. L’important est de ne pas donner *SECOFR ou même *SECADM a beaucoup de personnes. Pour ma part, j’utilise *SECOFR pour le seul profil *SECOFR et je donne *SECADM à un profil générique de telle sorte qu’il ne soit qu’un profil mais pouvant faire l’objet d’une rotation pour les congés (en changeant le mot de passe à chaque rotation).

Special Authorities (SPCAUT) : Cette valeur vous permet d’accorder à un utilisateur une ou plusieurs autorités spéciales. Les possibilités sont nombreuses :

•    *NONE – Si rien n’est indiqué ici, vous ne pouvez rien faire de spécial dans le système. Et ce, même s’il y a quelque chose dans le paramètre USRCLS. Mais vous pouvez quand même faire des choses banales, comme exécuter des programmes d’application, et … c’est à peu près tout.
•    *USRCLS – Si cette valeur est spécifiée, Special authorities recherche la valeur dans le champ USRCLS et l’utilise pour attribuer les autorités.
•    *ALLOBJ, *SAVSYS, *JOBCTL, *SERVICE, *SPLCTL, *SECADM, *AUDIT et *IOSYSCFG – Vous pouvez attribuer directement vous-même des autorités spéciales, en entrant une ou plusieurs de ces valeurs possibles.

Group profile (GRPPRF): Si un profil utilisateur est spécifié ici, votre profil prendra les autorisations de celui-ci. C’est un excellent moyen d’accorder des autorités équivalentes à de nombreux profils sans devoir spécifier les autorisations dans chaque profil.

En conclusion : Le niveau d’autorité dont vous disposez dépend d’abord de votre profil utilisateur. Pour pouvoir travailler sur des objets que vous ne possédez pas, votre profil doit contenir des autorités spéciales. A vrai dire, elles ne sont pas spéciales, elles sont nécessaires.