Le support pour serveur d'applications disponible sur le système AS/400 lui permet de jouer le rôle d'un serveur pour les demandeurs d'application DRDA. Le demandeur d'application connecté à un serveur d'applications DB2 Universal Database pour AS/400 peut être n'importe quel client prenant en charge les protocoles DRDA.
Le demandeur d'application est autorisé à accéder aux tables stockées en local sur le serveur d'applications DB2 Universal Database pour AS/400. Il doit créer un module sur ce dernier avant qu'une instruction SQL ne puisse être exécutée. Le serveur d'applications DB2 Universal Database pour AS/400 utilise le module contenant les instructions SQL de l'application au moment de l'exécution du programme.
Pour pouvoir traiter les demandes de base de données répartie sur le serveur d'applications AS/400, vous devez définir le nom de la base de données du serveur d'applications dans le répertoire des bases de données relationnelles. Pour les communications SNA, vous devez définir le système de serveur d'applications, ainsi que les tailles de RU et la régulation. Pour les communication TCP/IP prises en charge depuis DB2 Universal Database pour AS/400 version 4.2, reportez-vous au Chapitre Connexion de DB2 Universal Database pour AS/400 au sein d'un réseau DRDA via TCP/IP.
L'identification de la base de données du serveur d'applications (sur ce dernier) s'effectue de la même façon que pour la base de données du demandeur d'application (sur celui-ci). A l'aide de la commande ADDRDBDIRE (Ajouter poste répertoire RDB), indiquez *LOCAL comme nom d'emplacement éloigné.
Pour un accès via SNA, la définition du serveur d'applications sur le réseau est identique à la définition du demandeur d'application sur le réseau. Vous devez créer des descriptions appropriées de ligne, de contrôleurs, d'unités et de mode afin de définir à la fois le serveur d'applications et le demandeur d'application émetteur des demandes. Pour plus de détails sur la définition du serveur d'application, reportez-vous aux sections Définition du système local pour DB2 Universal Database pour AS/400, et Définition du système éloigné pour DB2 Universal Database pour AS/400. Consultez également le manuel AS/400 Distributed Database Programming.
Le programme de transaction utilisé pour démarrer une base de données du serveur d'applications AS/400 porte le nom DRDA par défaut X'07F6C4C2'. Ce nom de programme de transaction est défini dans le système AS/400 pour démarrer le serveur d'applications. Le port est le paramètre correspondant pour les connexions TCP/IP (lorsque DB2/400 prend en charge ce protocole). DB2/400 utilise toujours en tant que serveur le port identifié 446 DRDA.
Vous devez passer en revue les définitions réseau pour déterminer si le réseau de bases de données réparties affecte le réseau existant. Les points à prendre en compte sont les mêmes pour le serveur d'applications et le demandeur d'application.
Lorsqu'un demandeur d'application achemine une requête portant sur une base de données répartie vers le serveur d'applications AS/400, les critères de sécurité suivants peuvent être pris en compte :
Le demandeur d'application transmet un ID utilisateur au serveur d'applications pour permettre le contrôle des droits d'accès. Le travail exécuté sur le serveur d'applications AS/400 emploie cet ID utilisateur ou, dans certaines circonstances, un ID utilisateur par défaut.
Le serveur d'applications AS/400 n'assure pas de conversion d'ID utilisateur entrante pour résoudre les conflits éventuels entre les ID utilisateur qui ne sont pas uniques au sein du réseau, ni pour regrouper plusieurs utilisateurs sous un même identificateur. Chaque ID utilisateur envoyé par un demandeur d'application doit être reconnu sur le serveur d'applications. Une technique de regroupement des requêtes entrantes sous un même ID utilisateur, avec perte partielle de sécurité, consiste à spécifier un ID utilisateur par défaut dans une entrée du sous-système de communication qui gère les demandes de démarrage de travaux éloignés. Reportez-vous aux descriptions des commandes ADDCMNE et CHGCMNE dans le manuel AS/400 CL Reference.
Il existe trois principales fonctions de sécurité réseau pour les unités logiques LU 6.2 :
Le serveur d'applications DB2 Universal Database pour AS/400 utilise la sécurité au niveau des sessions, exactement comme le demandeur d'application DB2 Universal Database pour AS/400.
Le serveur d'applications contrôle les niveaux de sécurité SNA utilisés pour les conversations. Le paramètre SECURELOC de la description d'unité APPC ou la valeur de sécurité indiquée dans la liste d'emplacements éloignés APPN détermine les éléments acceptés en provenance du demandeur d'application lors d'une conversation.
Les options possibles pour les conversations SNA sont les suivantes :
Les services SNADS nécessitent la définition d'un ID utilisateur par défaut. Ils doivent donc disposer de leur propre sous-système si vous n'utilisez pas d'ID utilisateur par défaut pour les applications DRDA.
Reportez-vous à la section Sélection des noms d'utilisateurs finals, pour connaître l'une des techniques de regroupement des demandes de démarrage de travaux entrantes sous un même ID utilisateur. Cette technique n'entraîne pas la vérification de l'ID utilisateur transmis par le demandeur d'application. Le démarrage du travail sur le serveur d'applications s'effectue sous l'ID utilisateur par défaut et l'utilisateur qui a demandé la connexion à partir du serveur d'application peut accéder à ce dernier même si son ID utilisateur dispose de droits restreints. Pour que cela soit possible, le serveur d'applications doit être défini comme un emplacement non protégé, un ID utilisateur par défaut doit être spécifié dans le répertoire de communications du sous-système AS/400 et le demandeur d'application doit être configuré pour transmettre uniquement un ID utilisateur lors du traitement de la connexion. Si un mot de passe est transmis, l'ID utilisateur qui l'accompagne est utilisé à la place de l'ID utilisateur par défaut.
Les entrées du répertoire de communications du sous-système AS/400 se distinguent en fonction de l'unité et du nom de mode utilisés pour démarrer la conversation. Si vous affectez un ID utilisateur par défaut distinct aux différentes combinaisons unité/mode, les utilisateurs peuvent être regroupés en fonction du mode de communication avec le serveur d'applications.
Le système AS/400 offre également une fonction de sécurité réseau utilisée uniquement pour la gestion des bases de données et des fichiers répartis. Il existe un attribut réseau pour l'accès à ces types de systèmes qui entraîne le rejet de toutes les tentatives d'accès ou bien qui autorise un contrôle objet-par-objet de la sécurité par le système.
DB2 Universal Database pour AS/400 version 4.2 comporte une nouvelle commande appelée CRTDDMTCPA. Elle vous permet d'indiquer si un serveur accepte ou non les demandes de connexion TCP/IP sans mot de passe.
Toutes les procédures de sécurité sont gérées par la fonction de sécurité du système d'exploitation OS/400.
L'AS/400 ne dispose pas d'un sous-système de sécurité externe. La gestion de la sécurité est assurée dans son ensemble par la fonction de sécurité de l'OS/400, qui fait partie intégrante du système d'exploitation. Ce dernier contrôle les droits d'accès sur tous les objets présents sur le système (programmes, modules, tables, vues et collections).
Le serveur d'applications contrôle les accès aux objets résidant sur ce dernier. Ce contrôle s'effectue en fonction de l'ID utilisateur qui démarre le travail sur le serveur d'applications. La section Sélection des noms d'utilisateurs finals, décrit comment cet ID utilisateur est déterminé.
La sécurité des accès aux objets peut être gérée à l'aide des commandes CL de gestion des droits sur les objets et des instructions SQL GRANT et REVOKE. Il s'agit des commandes CL GRTOBJAUT (Octroyer droits sur un objet) et RVKOBJAUT (Révoquer droits sur un objet), que vous pouvez utiliser pour tout objet résidant sur le système. Les instructions GRANT et REVOKE, en revanche, ne s'appliquent qu'aux objets SQL : tables, vues et modules. Par conséquent, si vous devez modifier les droits d'accès à d'autres objets que ces derniers (à des programmes ou des collections, par exemple), utilisez les commandes GRTOBJAUT et RVKOBJAUT.
Lorsque des objets sont créés sur le système, les utilisateurs se voient octroyer des droits d'accès par défaut à ces derniers : le créateur d'une table, d'une vue ou d'un module reçoit tous les droits sur cet objet, tandis que le public (c'est-à-dire tous les autres ID utilisateur) se voit octroyer les mêmes droits que ceux dont il dispose sur la collection ou la bibliothèque dans laquelle l'objet est créé.
Les droits sur les objets auxquels font référence les instructions statiques ou dynamiques d'un module sont vérifiés au moment de l'exécution de ce module. Si le créateur du module ne dispose pas d'un droit d'accès aux objets référencés, des messages d'avertissement sont renvoyés lorsque le module est créé. Au moment de l'exécution, l'utilisateur qui exécute le module prend les mêmes droits d'accès que le créateur du module. Si ce dernier est autorisé à accéder à une table mais que l'utilisateur qui exécute le module ne l'est pas, il reçoit le même droit que le créateur du module sur la table et peut donc utiliser cette dernière.
Pour plus de détails sur la sécurité système, reportez-vous au manuel AS/400 Security - Reference.
Les produits prenant en charge l'architecture DRDA effectuent automatiquement les opérations de conversion requises sur le serveur d'applications. Pour que cela soit possible, il est toutefois nécessaire que le CCSID du serveur d'applications soit convertible par le demandeur d'application.
Sur un serveur d'applications, prêtez attention au CCSID associé aux éléments suivants :
Le CCSID du travail serveur doit être compatible avec le demandeur d'application. Il est établi en fonction du profil de l'utilisateur qui a émis la demande de connexion. La fonction de support de gestion de travaux OS/400 affecte au CCSID d'un travail la valeur figurant dans le profil utilisateur. Si ce dernier n'en contient pas, la valeur système est utilisée comme CCSID (QCCSID) (fixée initialement à 65535).
Avant de soumettre une demande à DB2 Universal Database pour AS/400, vous devez ouvrir une session et, à l'aide de la commande CHGUSRPRF (Modifier un profil utilisateur), attribuer une valeur de CCSID admise au profil utilisateur du travail qui sera utilisé pour les demandes DRDA.
Une collection SQL est constituée d'un objet bibliothèque OS/400, d'un journal, d'un récepteur de journal et, facultativement, d'un dictionnaire de données IDDU si la clause WITH DATA DICTIONARY est spécifiée dans l'instruction CREATE COLLECTION. Les fichiers physiques et logiques utilisés pour certains de ces objets prennent par défaut le CCSID du travail au moment de la création de ce dernier. Si vous interrogez le dictionnaire de données ou le catalogue à partir d'un demandeur d'application ne prenant pas en charge le CCSID de ces fichiers, vous risquez d'obtenir des données non affichables ou déformées. Il est possible également que le demandeur d'application émette un message indiquant que le CCSID n'est pas pris en charge. Pour remédier à cela, vous devez créer une nouvelle collection SQL avec un CCSID de travail acceptable par d'autres systèmes.
Le CCSID d'un travail peut être modifié à l'aide de la commande CHGJOB (Modifier un travail). Si la modification doit également porter sur les travaux suivants, utilisez la commande CHGUSRPRF (Modifier un profil utilisateur) pour modifier le CCSID défini dans le profil utilisateur. Dans un programme CL, utilisez la commande RTVJOBA (Extraire attributs du travail) pour connaître le CCSID du travail en cours. En mode interactif, exécutez pour ce faire la commande WRKJOB (Gérer un travail), puis sélectionnez l'option 2 (Attributs de définition).
Une table SQL correspond à un fichier physique DB2 Universal Database pour AS/400 contenu dans une bibliothèque portant le même nom que la collection. Les colonnes d'une table correspondent également aux définitions des zones d'un fichier physique. Le CCSID de la table ou des colonnes de cette dernière peut être incompatible avec le demandeur d'application. Pour modifier cette valeur, reportez-vous à la section Représentation des données, qui explique comment modifier les fichiers physiques de base de données. Dans les versions antérieures à OS/400 3.1, les incompatibilités de CCSID étaient principalement liées à l'affectation par défaut du CCSID 65535 à de nombreux fichiers ou tables SQL. Dans la version 3.1 et suivantes, les CCSID de ces fichiers sont modifiés automatiquement, de sorte qu'une valeur plus appropriée leur soit affectée.