For z/OS platforms

Sécurisation des adaptateurs locaux optimisés pour la prise en charge des appels sortants sur Liberty for z/OS

Sécurisez les connexions d'adaptateurs WOLA (WebSphere Optimized Local Adapter) qui procèdent à des appels sortants depuis le serveur Liberty.

Procédure

  1. Facultatif : Configurez la sécurité côté serveur.
    1. Exécutez les serveurs Liberty sous z/OS avec la sécurité serveur. Pour en savoir plus, voir Configuration de l'autorisation pour les applications dans Liberty et Activation des services autorisés z/OS sur Liberty for z/OS.
    2. Si vous procédez à un appel depuis un serveur Liberty vers CICS (Customer Information Control System) et que la sécurité est activée sur le serveur de liaison CICS, choisissez un ID utilisateur pour exécuter le programme CICS cible.

      Par défaut, le sujet de l'appel obtient l'ID utilisateur MVS qui exécute le programme CICS cible. Il s'agit du sujet qui exécute le composant d'application à l'origine de la demande des adaptateurs locaux optimisés. Dans la plupart des cas, ce sujet est l'identité run-as qui est configurée dans le descripteur de déploiement de l'application.

      Vous pouvez définir un autre sujet d'appel de trois façons :
      • Dans la configuration de la fabrique de connexions, spécifiez un ID utilisateur et un mot de passe dans un élément authData et référencez l'élément dans l'élément connectionFactory. Dans l'exemple suivant, la fabrique de connexions de l'adaptateur local optimisé référence l'élément auth2 authData, qui spécifie l'ID utilisateur user2 et un mot de passe associé :
        <connectionFactory jndiName="eis/ola" containerAuthDataRef="auth2">
         <properties.ola RegisterName="OLASERVER"/>
        </connectionFactory>
        <authData id="auth2" user="user2" password="{xor}Lz4sLCgwLTtt"/>

        Pour plus d'informations sur la configuration de fabriques de connexions, voir Configuration des fabriques de connexions JCA.

      • L'administrateur système peut fournir un ID utilisateur et un mot de passe dans la fabrique de connexions des adaptateurs locaux optimisés. Pour plus d'informations, voir Propriétés de la fabrique de connexions pour les adaptateurs locaux optimisés sur Liberty.
      • Le développeur d'applications peut fournir un ID utilisateur et un mot de passe dans l'objet ConnectionSpec qui obtient une connexion depuis la fabrique de connexions des adaptateurs locaux optimisés.

      Le service de sécurité tente de procéder à l'authentification avec l'ID utilisateur et le mot de passe fournis. Si l'authentification aboutit, le nouveau sujet obtient l'ID utilisateur MVS qui exécute le programme CICS cible.

    3. Si vous appelez d'un serveur Liberty à IBM Information Management System (IMS) en utilisant OTMA, le serveur Liberty peut propager l'ID utilisateur du moment à la région IMS si lui et l'application sont configurés pour utiliser sync-to-OS-thread. La région IMS doit aussi fonctionner avec l'option OTMASE=FULL dans le membre IMSPBxxx PROCLIB.
  2. Configurez la sécurité côté client.
    1. Si CBIND est activé dans la fonction d'autorisation système (SAF), accordez l'accès aux clients qui utiliseront des adaptateurs locaux optimisés.
      1. Définissez un profil pour le serveur Liberty dans la classe CBIND. Le nom de profil est BBG.WOLA.<WOLA1>.<WOLA2>.<WOLA3>, où WOLA1, WOLA2 et WOLA3 sont les trois parties du nom de groupe d'adaptateur local optimisé qui sont spécifiées dans l'élément <zosLocalAdapters> dans le fichier server.xml. Vous pouvez définir un profil en utilisant la commande TSO RDEFINE de la fonction d'autorisation système (SAF). Par exemple, la commande suivante crée un profil dans la classe CBIND pour un groupe WOLA nommé LIB1.LIB2.LIB3 :
        rdef cbind bbg.wola.lib1.lib2.lib3 uacc(none)
      2. Accordez l'accès READ au profil. Par exemple, la commande suivante autorise l'accès en lecture pour le nom d'utilisateur nom_utilisateur sur le profil bbg.wola.lib1.lib2.lib3 :
        permit bbg.wola.lib1.lib2.lib3 class(cbind) access(read) id(username)
        You can use asterisks to permit a user access to multiple profiles. The following example permits READ access to the username user for all profiles that start with bbg.wola in the CBIND class:
        rdef cbind bbg.wola.* uacc(none)
        permit bbg.wola.* class(cbind) access(read) id(username)

      For more information about SAF commands and syntax, see the documentation for your version of z/OS.

    2. If you are running a CICS link server with security enabled, configure CICS to enable user identity assertion.
      1. Ensure that the CICS region is running with security enabled and EXEC CICS START checking enabled.
        • Enable security at CICS startup by specifying the parameter SEC=YES.
        • Enable EXEC CICS START checking at startup by specifying the parameter XUSER=YES.

        For more information about CICS system initialization parameters, see the documentation for your version of CICS.

      2. Create a System Authorization Facility (SAF) SURROGAT class definition that permits the user ID of the link server to issue the EXEC CICS START TRAN('BBO#') USERID(<propagated_id>) command.
        The following example shows a SURROGAT class that is defined for the USER1 user ID. The class enables user ID OLASERVE to run the EXEC CICS START TRANS(BBO#) USERID(USER1) command and process optimized local adapters CICS link transactions that run with the identity of USER1.
        RDEFINE SURROGAT USER1.DFHSTART UACC(NONE) OWNER(USER1)  
        PERMIT USER1.DFHSTART CLASS(SURROGAT) ID(USER1)          
        PERMIT USER1.DFHSTART CLASS(SURROGAT) ID(OLASERVE)       
        SETROPTS RACLIST(SURROGAT) REFRESH 

        Pour plus d'informations sur la définition d'une classe SURROGAT, voir la documentation de votre version de CICS.


Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : twlp_dat_security_out.html