Paramètres des communications entrantes CSIv2 (Common Secure Interoperability Version 2)

Cette page permet d'indiquer les caractéristiques prises en charge par un serveur pour un client qui accède à ses ressources.

Pour afficher cette page de la console d'administration, procédez comme suit :
  1. Cliquez sur Sécurité > Sécurité globale.
  2. Dans la section Authentification, cliquez sur Sécurité RMI/IIOP > Communications entrantes CSIv2.

Les paramètres des communications entrantes CSI (Common Secure Interoperability) permettent de configurer le type d'informations d'authentification contenues dans un protocole de transport ou une demande entrante.

Les fonctions d'authentification incluent trois couches d'authentification pouvant être utilisées simultanément :
Propager les attributs de sécurité

Indique la prise en charge des attributs de sécurité pendant les demandes de connexion. Si vous sélectionnez cette option, le serveur d'applications conserve des informations supplémentaires sur la demande de connexion, telles que la puissance d'authentification utilisée, et conserve l'identité et l'emplacement de l'émetteur de la demande.

Si vous ne sélectionnez pas cette option, le serveur d'applications n'accepte pas d'autres informations de connexion à propager vers les serveurs en aval.

Valeur par défaut Activé
Important : Lorsque vous utilisez les services de réplication, vérifiez que l'option Propager les attributs de sécurité est activée.
Utiliser la vérification d'identité

Indique que la vérification d'identité est un moyen permettant de vérifier les identités d'un serveur à un autre au cours d'un appel d'EJB (Enterprise JavaBeans) en aval.

Ce serveur n'authentifie pas une nouvelle fois l'identité vérifiée car il fait confiance au serveur en amont. La vérification d'identité prévaut sur tous les autres types d'authentification.

La vérification de l'identité est effectuée dans la couche des attributs et ne s'applique qu'aux serveurs. Le principal déterminé sur le serveur se base sur les règles de préséance. Si la vérification de l'identité est utilisée, l'identité est toujours dérivée de la couche des attributs. Si l'authentification de base est utilisée sans la vérification d'identité, l'identité est toujours dérivée de la couche message. Enfin, si l'authentification par certificat client SSL est effectuée sans authentification de base ou vérification de l'identité, l'identité est dérivée de la couche de transport.

L'identité vérifiée constitue le justificatif d'appel déterminé par le mode d'exécution pour le bean enterprise. Si le mode d'exécution est Client, l'identité est celle du client. Si le mode d'exécution est Système, l'identité est celle du serveur. Si le mode d'exécution est Spécifié, l'identité est celle indiquée. Le serveur récepteur reçoit l'identité dans un jeton d'identité, ainsi que celle du serveur émetteur dans un jeton d'authentification client. Le serveur récepteur vérifie si l'identité du serveur émetteur est sécurisée à l'aide de la zone d'entrée ID serveur sécurisés. Entrez une liste de noms de principaux séparés par un signe (|), par exemple, idserveur1|idserveur2|idserveur3.

Tous les types de jeton d'identité sont mappés à la zone d'ID utilisateur du registre d'utilisateurs actif. Pour un jeton d'identité ITTPrincipal, celui-ci est mappé un-à-un aux zones ID utilisateur. Pour un jeton d'identité ITTDistinguishedName, la valeur du premier signe égal est mappée à zone ID utilisateur. Pour un jeton d'identité ITTCertChain, la valeur du premier signe égal du nom distinctif est mappée à la zone ID utilisateur.

Lors de l'authentification par rapport à un registre d'utilisateurs LDAP, les filtres LDAP déterminent comment des identités de type ITTCertChain et ITTDistinguishedName sont mappées au registre. Si le jeton est de type ITTPrincipal, le principal est mappé à la zone d'UID dans le registre LDAP.

Valeur par défaut Désactivé
Identités dignes de confiance

Spécifie l'identité digne de confiance envoyée par le serveur émetteur au serveur récepteur.

Permet d'indiquer une liste d'ID utilisateur d'administrateurs de serveur, séparés par un signe (|), reconnus comme étant dignes de confiance et pouvant être utilisés pour effectuer les vérifications d'identité sur ce serveur. Par exemple, idserveur1|idserveur2|idserveur3. Le serveur d'applications accepte le caractère virgule (,) comme séparateur de liste pour la compatibilité amont. Les serveur d'applications vérifie le caractère virgule lorsque le caractère (|) fait échouer la recherche d'un ID de serveur de confiance valide.

Utilisez cette liste pour déterminer si un serveur est digne de confiance. Même si le serveur se trouve dans la liste, le serveur émetteur doit s'authentifier auprès du serveur récepteur pour accepter le jeton d'identité du serveur émetteur.

Type de données : Chaîne
Authentification du certificat client

Indique que l'authentification a lieu lorsque la connexion initiale est établie entre le client et le serveur lors d'une demande de méthode.

Dans la couche de transport, l'authentification par certificat client SSL (Secure Sockets Layer) est effectuée. Dans la couche messages, l'authentification de base (ID utilisateur et mot de passe) est utilisée. L'authentification par certificat client s'effectue généralement mieux que l'authentification par couche de messages, mais requiert des d'opérations de configuration supplémentaires. Ces étapes supplémentaires impliquent de vérifier que le serveur accepte le certificat signataire de chaque client auquel il est connecté. Si le client utilise une autorité de certification (CA) pour créer son certificat personnel, vous n'avez besoin que du certificat racine du CA qui se trouve dans la section signataire du fichier SSL des tiers dignes de confiance.

[AIX Solaris HP-UX Linux Windows] [iSeries] Lorsque le certificat est authentifié par rapport à un registre d'utilisateurs LDAP (Lightweight Directory Access Protocol), le nom distinctif est mappé en fonction du filtre indiqué lors de la configuration LDAP. Lorsque le certificat est authentifié par rapport à un registre d'utilisateurs du système d'exploitation local, le premier attribut du nom distinctif (DN) du certificat, généralement le nom commun, est mappé à l'ID utilisateur dans le registre.

[z/OS] Lorsque le certificat est authentifié dans un registre d'utilisateurs local, le certificat est mappé vers l'ID utilisateur dans le registre.

L'identité extraite des certificats client n'est utilisée que si aucune autre couche d'authentification n'est présentée au serveur.

Jamais
Indique que les clients ne peuvent pas utiliser l'authentification de client SSL (Secure Sockets Layer) avec ce serveur.
Pris en charge
Indique que les clients qui se connectent à ce serveur peuvent procéder à l'authentification à l'aide de certificats client SSL. Cependant, le serveur peut appeler une méthode sans ce type d'authentification. Par exemple, il est possible d'avoir recours à une authentification anonyme ou à une authentification de base.
[z/OS] Remarque : Si "Pris en charge" est défini pour l'authentification entrante CSIv2 sur le serveur, le certificat client est utilisé pour l'authentification.
Requis
Indique que les clients qui se connectent à ce serveur doivent s'authentifier à l'aide de certificats client SSL avant d'appeler la méthode.
Transport

Indique si les processus client se connectent au serveur à l'aide de l'un des transports connectés du serveur.

Vous pouvez choisir le protocole SSL (Secure Sockets Layer), TCP/IP ou les deux protocoles comme transport de communication entrante pris en charge par un serveur. Si vous indiquez TCP/IP,le serveur prend uniquement en charge TCP/IP et ne peut pas accepter les connexions SSL. Si vous indiquez que SSL est pris en charge, ce serveur peut prendre en charge les connexions TCP/IP ou SSL. Si vous indiquez que SSL est requis, tout serveur communiquant avec ce serveur doit utiliser SSL.

Remarque : Cette option n'est pas disponible sur la plateforme z/OS, sauf si des noeuds version 6.0.x et antérieures se trouvent dans la cellule.
TCP/IP
Si vous sélectionnez TCP/IP, le serveur ouvre seulement un port d'écoute TCP/IP et aucune des demandes entrantes ne bénéficie d'une protection SSL.
SSL requis
Si vous sélectionnez SSL requis, le serveur ouvre seulement un port d'écoute SSL et aucune des demandes entrantes n'est reçue à l'aide de SSL.
SSL pris en charge
Si vous sélectionnez SSL pris en charge, le serveur ouvre un port d'écoute TCP/IP et un port d'écoute SSL et la plupart des demandes entrantes sont reçues à l'aide de SSL.
Indiquez un numéro de port fixe pour les ports suivants. Le numéro de port zéro indique que ce port sera attribué de manière dynamiquement lors de l'exécution. [AIX Solaris HP-UX Linux Windows] [iSeries]

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS 
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

[z/OS]

ORB_SSL_LISTENER_ADDRESS

Valeur par défaut SSL pris en charge
Portée TCP/IP, SSL requis, SSL pris en charge
Paramètres SSL

Indique une liste de paramètres SSL prédéfinis parmi lesquels effectuer une sélection pour les connexions de communications entrantes.

[z/OS] Remarque : Cette option n'est pas disponible sur la plateforme z/OS, sauf si des noeuds version 6.0.x et antérieures se trouvent dans la cellule.
Type de données : Chaîne
[AIX Solaris HP-UX Linux Windows] [iSeries] Valeur par défaut DefaultSSLSettings
[z/OS] Valeur par défaut DefaultIIOPSSL
Portée Tous les paramètres SSL configurés dans le répertoire de configuration SSL.
Authentification par couche de messages

Les options suivantes sont disponibles pour l'authentification de la couche de message :
Jamais
Indique que ce serveur ne peut pas accepter l'authentification par mot de passe et ID utilisateur.
Pris en charge
Indique qu'un client communiquant avec ce serveur peut spécifier un ID utilisateur et un mot de passe. Cependant, une méthode peut être appelée sans ce type d'authentification. Par exemple, il est possible d'utiliser une authentification anonyme ou une authentification à l'aide d'un certificat client à la place.
Requis
Indique que les clients communiquant avec ce serveur doivent spécifier un ID utilisateur et un mot de passe pour toute requête de méthode.
Autoriser l'authentification client sur le serveur avec :

Indique l'authentification client-serveur à l'aide de l'authentification de base, Kerberos ou LTPA.

Les options suivantes sont disponibles pour l'authentification du client sur le serveur :
Kerberos (KRB5)
Permet d'indiquer Kerberos comme mécanisme d'authentification. Vous devez commencer par configurer le mécanisme d'authentification Kerberos. Pour plus d'informations, voir Configuration de Kerberos comme un mécanisme d'authentification utilisant la console d'administration.
LTPA
Sélectionnez l'authentification marqueur LTPA.
Authentification de base
L'authentification de base est de type GSSUP (Generic Security Services Username Password). Ce type d'authentification nécessite généralement l'envoi d'un ID utilisateur et d'un mot de passe à partir du client au serveur pour authentification.

Si vous sélectionnez Authentification de base, LTPA et que LTPA est la méthode d'authentification active, les marqueurs de nom d'utilisateur, de mot de passe et LTPA sont acceptés.

Si vous sélectionnez Authentification de base, KRB5 et que KRB5 est la méthode d'authentification active, les marqueurs de nom d'utilisateur, de mot de passe, les marqueurs Kerberos et LTPA sont acceptés.

Si vous ne sélectionnez pas Authentification standard, le serveur n'accepte pas le nom d'utilisateur et le mot de passe.

Configuration de la connexion

Indique le type de configuration de connexion système à utiliser pour l'authentification des communications entrantes.

Vous pouvez ajouter des modules de connexion personnalisés en cliquant sur Sécurité > Sécurité globale. Dans Authentification, cliquez sur Service d'authentification et d'autorisation Java > Connexions système.

Sessions avec état

Sélectionnez cette option pour activer les sessions avec état utilisées principalement pour améliorer les performances.

Le premier contact entre un client et un serveur doit être totalement authentifié. Toutefois, tous les contacts suivants avec des sessions valides réutilisent les informations de sécurité. Le client transmet un ID de contexte au serveur ; cet ID permet de rechercher la session. L'ID de contexte est sectorisé à la connexion, garantissant son unicité. Lorsque la session de sécurité n'est pas valide et que les nouvelles tentatives d'authentification sont autorisées (valeur par défaut), l'intercepteur de sécurité côté client invalide la session côté client et soumet à nouveau la demande. Ces opérations sont invisibles au niveau utilisateur. Cela peut se produire si la session n'existe pas sur le serveur ; par exemple, le serveur à échoué et a repris l'opération. Lorsque cette valeur est désactivée, chaque appel de méthode doit être à nouveau authentifié.

Valeur par défaut Activé
Domaines d'authentification sécurisés - entrants

Cliquez sur ce lien pour établir une sécurisation entrante pour les domaines. Les paramètres des domaines d'authentification entrante ne sont pas spécifiques à CSIv2 ; vous pouvez aussi choisir les domaines à sécuriser en entrée dans le cas de domaines de sécurité multiples.

L'authentification entrante 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.




Les liens marqués (en ligne) requièrent un accès à Internet.

Tâches associées
Référence associée
Paramètres de configuration de connexion système pour JAAS (Java Authentication and Authorization Service)
Mécanismes et expiration d'authentification


Nom du fichier : usec_inbound.html