Les plus pour les développeurs d’applications

une autre plate-forme (Windows 2000 par exemple).
Windows 2000 utilise la technologie Kerberos et sa propre version de GSSAPI appelée
Security Services Provider Interface (SSPI, compatible avec GSSAPI). Une application
utilisant GSSAPI sur un AS/400 et une application utilisant SSPI sur Windows 2000
peuvent s’authentifier mutuellement.
Une application tournant sous Windows 2000 peut utiliser un ticket Kerberos généré
pendant le log-in de Windows 2000, la SSPI et un socket TCP/IP pour transférer
les données d’authentification à  une autre application s’exécutant sur l’AS/400,
le tout sans demander une quelconque information à  l’utilisateur. Celui-ci n’aurait
par exemple même pas à  réentrer son ID et son mot de passe. L’application s’exécutant
sur l’AS/400 accepte les informations via les GSSAPI qui, si l’authentification
est concluante, indiquent que l’utilisateur est bien celui qu’il prétend être.
On peut extraire des informations sur celui que l’utilisateur prétend être via
les GSSAPI. Une fois l’utilisateur authentifié, il reste à  l’application le soin
de déterminer s’il est autorisé à  accéder aux services ou aux ressources de l’application.

De nouvelles API offrent aux développeurs d’applications des méthodes pour modifier
le profil utilisateur sous lequel un thread est en train de s’exécuter. C’est
une technique importante pour limiter les utilisateurs aux fonctionnalités nécessaires
à  leur travail. Avant la V4R5, la seule méthode existante imposait aux développeurs
de se servir des API Profile Swap (Permutation de profil). En possession du nom
de profil et du mot de passe d’un utilisateur ou, si l’utilisateur exécutant l’API
possède les droits adéquats sur le profil, l’API QSYGETPH génère un handle de
profil. On utilise le handle de profil pour  » permuter  » ou modifier le thread
à  exécuter sous le profil pour lequel le handle est généré. Outre la modification
du profil sous lequel le thread s’exécute, la permutation du profil modifie également
les profils de groupes, les droits spéciaux et les caractéristiques des différentes
limitations du profil  » swap-to  » (permuter avec). On peut utiliser les handles
de profils plusieurs fois pour faire permuter des utilisateurs, mais les handles
ne peuvent pas être transmis à , ou utilisés par, un autre thread.

La V4R5 apporte également les API Profile Token (jeton de profil)

La V4R5 apporte également les API Profile Token (jeton de profil). Ces API fonctionnent
selon les mêmes principes que les API Profile Handle ; cependant, lors de la génération
des jetons, on peut préciser que le jeton de profil permet une ou plusieurs utilisations
ainsi que sa durée de validité. Les jetons peuvent être transmis et utilisés par
d’autres threads sur le même AS/400. Les mêmes attributs associés à  la sécurité
des threads sont modifiés de la manière que quand on utilise un handle de profil.

En utilisant l’ID utilisateur (UID) et l’ID de groupe (GID), les API sont un autre
moyen de modifier l’utilisateur ou le groupe sous lequel un thread s’exécute.
On utilise en principe ces API pour modifier l’utilisateur ou le premier groupe
d’un thread quand on accède à  des objets dans l’IFS (Integrated File System) de
l’AS/400. L’UID est la représentation numérique d’un utilisateur ; le GID est
la représentation numérique d’un groupe. Tous deux représentant l’utilisateur
et les groupes (plutôt que les noms de profils d’utilisateurs ou de groupes) pendant
la vérification des droits, quand on accède aux objets dans l’IFS. Pour bien comprendre
ces API, il faut connaître quelques concepts sur les standards POSIX.

Dans POSIX, chaque job matérialise le concept d’ID d’utilisateur et de groupe
 » réel « ,  » effectif  » et  » sauvegardé « . L’ID utilisateur réel est l’UID de l’utilisateur
qui a démarré le job. L’ID utilisateur effectif est l’UID sous lequel le job est
en train de s’exécuter (et d’effectuer le contrôle d’accès). Certaines applications
utilisent l’ID utilisateur sauvegardé pour stocker un UID quand de multiples modifications
sont apportées aux UID réelles et effectives. Les concepts sont les mêmes pour
les GID réels, effectifs et sauvegardés.

Contrairement aux API Profile Swap (QSYGETPH et QWTSETP), les API UID et GID modifient
l’utilisateur et le premier groupe indépendamment. Ainsi, quand on utilise les
API Profile Swap pour permuter avec l’utilisateur Carol, tous les groupes associés
à  Carol sont également permutés dans le thread. L’utilisation des API UID et GID
permet de modifier soit l’ID utilisateur, soit le premier ID groupe du thread.