Configuration des communications entrantes CSIv2

L'expression communications entrantes fait référence à la configuration qui détermine le type d'authentification acceptée pour les demandes entrantes. Cette authentification est spécifiée dans la référence IOR (Interoperable Object Reference) extraite du serveur de noms par le client.

Procédure

  1. Démarrez la console d'administration.
  2. Cliquez surSécurité > Sécurité globale.
  3. Sous Sécurité RMI/IIOP, cliquez sur Communications entrantes CSIv2.
  4. Les couches de sécurité suivantes sont disponibles :
    • Vérification des identités (couche des attributs).

      Si cette option est sélectionnée, le serveur accepte les jetons d'identité des serveurs en amont. Si le serveur reçoit un jeton d'identité, l'identité est extraite du client émetteur. Par exemple, l'identité se trouve dans le formulaire présenté au premier serveur par le client émetteur. Un serveur en amont envoie l'identité du client émetteur. Cette identité peut prendre la forme d'un nom de principal, d'un nom distinctif ou d'une chaîne de certificats. Dans certains cas, l'identité est anonyme. Une relation de confiance doit être établie avec le serveur en amont qui envoie le jeton d'identité, car l'identité s'authentifie sur ce serveur. Une relation de confiance avec le serveur en amont est établie à l'aide de l'authentification par certificat client SSL (Secure Sockets Layer) ou de l'authentification de base. Vous devez sélectionner l'une des deux couches d'authentification pour l'authentification des communications entrantes et sortantes lorsque vous choisissez la vérification d'identité.

      [AIX Solaris HP-UX Linux Windows][IBM i]L'ID serveur est envoyé dans le jeton d'authentification du client avec le jeton d'identité. Il est vérifié par rapport à la liste des ID serveur sécurisées. Si c'est le cas, l'ID serveur est authentifié. Si l'ID serveur est valide, le jeton d'identité est placé dans un justificatif afin d'autoriser la demande.

      [z/OS]
      Remarque : Si votre registre configuré est de type système d'exploitation local, la relation de confiance est alors établie en vérifiant si l'identité du serveur en amont est autorisée sur le serveur en aval avec les droits de mise à jour (UPDATE) sur la classe CBIND, profil CB.BIND.<optionalSAFProfilePrefix>.<nom_abrégé_cluster>. L'identité du serveur en amont est envoyée à l'aide d'un certificat client SSL. Si SSL n'est pas utilisé, la vérification CBIND s'effectue à partir de l'identité de la tâche démarrée du serveur en amont.
      Eviter les incidents Eviter les incidents: Lorsque la vérification d'identité est activée, la couche messages ou la couche transport doit également être activée. Pour la communication serveur à serveur, outre l'activation de la couche transport/l'authentification client, la vérification d'identité ou la couche de messages doit également être activée.gotcha

      Pour plus d'informations, voir Vérification d'identité.

    • Couche messages :

      Authentification de base (GSSUP) :

      Ce type d'authentification est le plus courant. L'ID utilisateur et le mot de passe ou le jeton authentifié sont envoyés par un client pur ou un serveur en amont. Lorsque le serveur reçoit un ID utilisateur et un mot de passe, ces derniers sont authentifiés dans le registre d'utilisateurs du serveur en aval.

      Lightweight Third Party Authentication (LTPA) :

      Dans ce cas, un jeton LTPA est envoyé à partir du serveur en amont. Si vous optez pour LTPA, les deux serveurs doivent partager les mêmes clés LTPA.

      Kerberos (KRB5) :

      Pour pouvoir sélectionner Kerberos, le mécanisme d'authentification actif doit être Kerberos. Dans ce cas, un jeton Kerberos est envoyé à partir du serveur en amont.

      Pour plus d'informations, reportez-vous à la rubrique relative à l'authentification de la couche de messages.

    • Authentification par certificat client SSL (couche de transport).

      Le certificat client SSL remplace l'ID utilisateur et le mot de passe pour l'authentification. Si un serveur délègue une identité à un serveur en aval, cette identité provient de la couche de message (jeton d'authentification d'un client) ou de la couche d'attribut (jeton d'identité), mais pas de la couche de transport, via l'authentification du certificat du client.

      [AIX Solaris HP-UX Linux Windows][IBM i]Un client possède un certificat client SSL stocké dans le fichier du magasin de clés de la configuration client. Lorsque l'authentification des clients SSL est activée sur ce serveur, le serveur demande au client de lui envoyer le certificat client SSL une fois la connexion établie. La chaîne du certificat est disponible sur le socket pour toute demande envoyée au serveur. L'intercepteur de demandes du serveur extrait du socket la chaîne de certification et la mappe à un utilisateur figurant dans le registre d'utilisateurs. Ce type d'authentification est optimal pour communiquer directement d'un client à un serveur. Toutefois, pour les communications en aval, l'identité passe généralement par la couche de messages ou la vérification d'identité.

      [z/OS]Un client possède un certificat client SSL stocké dans le fichier de clés de la configuration client. Lorsque l'authentification des clients SSL est activée sur ce serveur, le serveur demande au client de lui envoyer le certificat client SSL une fois la connexion établie. La chaîne du certificat est disponible sur le socket pour toute demande envoyée au serveur. L'intercepteur de demandes du serveur extrait du socket la chaîne de certification et la mappe à un utilisateur figurant dans le registre d'utilisateurs. Ce type d'authentification est optimal pour communiquer directement d'un client à un serveur. Toutefois, pour les communications en aval, l'identité passe généralement par la couche de message ou la vérification d'identité.

  5. Prenez en compte les points suivants lorsque vous déterminez le type d'authentification à accepter :
    • Un serveur peut recevoir plusieurs couches simultanément et par conséquent, une règle des priorités détermine l'identité à utiliser. La couche de vérification d'identité est associée à la priorité la plus élevée. Elle est suivie de la couche de messages. La couche transport est associée à la priorité la moins élevée. L'authentification des certificats de client SSL est utilisée lorsque c'est la seule couche fournie. Si seules la couche de messages et la couche transport sont fournies, la première est utilisée pour établir l'identité utilisée pour l'autorisation. La couche de vérification d'identité, lorsqu'elle est fournie, est utilisée pour définir les priorités.
    • Ce serveur reçoit-il généralement les demandes d'un client, d'un serveur ou des deux ? Si le serveur reçoit toujours les demandes d'un client, la vérification d'identité n'est pas nécessaire. Vous pouvez choisir la couche des messages, la couche des transports ou les deux. De plus, vous pouvez choisir si l'authentification est requise ou prise en charge. Si une couche est requise, le client émetteur doit la fournir (s'il ne la fournit pas, la demande est rejetée). Toutefois, si la couche n'est que prise en charge, elle peut ne pas être fournie.
    • Quel type d'identité client a été fournie ? Si l'identité du client est déterminée par l'authentification de ses certificats et que vous voulez que la chaîne de certification soit communiquée en aval pour qu'elle soit mappée aux registres d'utilisateurs des serveurs en aval, vous devez opter pour la vérification d'identité. Ce type d'authentification permet de conserver le format du client émetteur. Si le client émetteur est authentifié par un ID utilisateur et un mot de passe, une identité principale est envoyée. Si l'authentification s'effectue par certificat, la chaîne de certification est envoyée.

      [AIX Solaris HP-UX Linux Windows][IBM i]Dans certains cas, si le client est authentifié par un jeton et que le registre d'utilisateurs est un registre LDAP (Lightweight Directory Access Protocol), un nom distinctif est envoyé.

  6. Configurez une liste de serveurs dignes de confiance. Lorsque la vérification d'identité est sélectionnée pour les demandes entrantes, insérez la liste des ID administrateur de serveur, séparés par le signe (|), pour lesquels ce serveur pourra prendre en charge la soumission de jetons d'identité. Pour une compatibilité amont, vous pouvez encore utiliser des virgules comme séparateur. Toutefois, si l'ID serveur est un nom distinctif, vous devez utiliser le signe (|) comme séparateur car les virgules ne sont pas admises. Pour prendre en charge n'importe quel serveur envoyant un jeton d'identité, entrez un astérisque (*) dans cette zone. Cette action est appelée relation de confiance présumée. Dans ce cas, utilisez l'authentification par certificat de client SSL entre les serveurs pour établir la relation de confiance.
    Configurations prises en charge Configurations prises en charge: Cette étape s'applique si vous utilisez LDAP (Lightweight Directory Access Protocol) ou un registre d'utilisateurs personnalisé. Cependant, elle ne s'applique pas si vous utilisez le registre d'utilisateurs local du système d'exploitation ou un registre d'utilisateurs SAF (System Authorization Facility).sptcfg
  7. Configurez la gestion des sessions. Vous pouvez choisir une sécurité avec état ou sans état. Les performances sont optimales pour les sessions avec état. La première demande de méthode entre un client et un serveur est authentifiée. Toutes les demandes ultérieures (ou jusqu'à expiration du jeton du justificatif) réutilisent les informations sur la session, y compris le justificatif. Un client envoie un ID contexte pour les demandes ultérieures. L'ID contexte est sectorisé à la connexion, ce qui garantit son unicité.

Résultats

Une fois que vous avez fini de configurer les paramètres de ce panneau, vous avez configuré la plupart des informations qu'un client collecte lorsqu'il détermine ce qu'il doit envoyer à ce serveur. La configuration sortante d'un client ou d'un serveur et la configuration entrante de ce serveur déterminent la sécurité appliquée. Si vous savez ce qu'envoient les clients, la configuration est simple. Toutefois, si vous disposez de clients différents dotés chacun de conditions de sécurité distinctes, votre serveur étudie différentes couches d'authentification.

Pour un serveur d'applications Java Platform, Enterprise Edition, l'authentification s'effectue généralement par vérification d'identité ou par couche de messages car l'identité du client émetteur doit être communiquée en aval. Vous ne pouvez pas déléguer facilement un certificat client à l'aide d'une connexion SSL. Il est possible d'activer la couche de transport car une sécurité accrue du serveur (comme la portion de certificat client supplémentaire de l'établissement de connexion SSL) augmente la charge liée à l'établissement de connexion SSL.

Que faire ensuite

Après avoir déterminé le type de données d'authentification pouvant être reçues par ce serveur, vous pouvez déterminer ce que vous voulez sélectionner pour la sécurité sortante. Pour obtenir plus d'informations, voir Configuration des paramètres d'authentification des communications sortantes CSIv2.

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



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_csiv2inbound
Nom du fichier : tsec_csiv2inbound.html