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

Cette page permet de définir les fonctionnalités prises en charge par un serveur lorsque ce dernier est client d'un autre serveur en aval.

Pour afficher cette page de la console d'administration, procédez comme suit :
  1. Cliquez sur Sécurité > Sécurité globale.
  2. Dans Authentification, cliquez sur Sécurité RMI/IIOP > Communications sortantes CSIv2.
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 de la propagation 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 l'identité sécurisée du serveur

Indique l'identité de serveur que le serveur d'applications emploie pour établir une relation de confiance avec le serveur cible. L'identité de serveur peut être envoyée de l'une des façons suivantes :

  • un identificateur et un mot de passe serveur sont indiqués dans la configuration du registre ;
  • un identificateur serveur dans un jeton LTPA (Lightweight Third Party Authentication) que l'ID de serveur interne est employé.
Pour une interopérabilité avec des serveurs d'applications autres que WebSphere Application Server, procédez comme suit :
  • Configurez l'ID et le mot de passe serveur dans le registre.
  • Sélectionnez l'option Identité digne de confiance de serveur et indiquez l'identité et le mot de passe dignes de confiance pour qu'un jeton GSSUP (Generic Security Services Username Password) soit envoyé au lieu d'un jeton LTPA.
Valeur par défaut Désactivé
Indiquer une identité sécurisée alternative

Désigne un autre utilisateur comme identité digne de confiance envoyée aux serveurs cible au lieu de l'identité du serveur.

Cette option est conseillée pour la vérification d'identité. L'identité est automatiquement digne de confiance lorsqu'elle est envoyée dans la même cellule et n'a pas besoin de figurer dans la liste d'identités dignes de confiance de cette cellule. Toutefois, cette identité doit se trouver dans le registre des serveurs cible d'une cellule externe et l'ID utilisateur doit figurer dans la liste d'identités sécurisées ; sinon, l'identité est refusée lors de l'évaluation de la sécurité.

Valeur par défaut Désactivé
Identité digne de confiance

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

Si vous indiquez une identité dans cette zone, elle peut être sélectionnée dans le panneau pour le référentiel de comptes utilisateur configuré. Si vous ne précisez pas d'identité en revanche, un jeton LTPA (Lightweight Third Party Authentication) est envoyé entre les serveurs.

[AIX Solaris HP-UX Linux Windows] [iSeries] 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.

[z/OS] Permet d'indiquer une liste d'ID de serveur, séparés par des points-virgules (;) ou des virgules (,), 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 ou idserveur1,idserveur2,idserveur3.

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.

Mot de passe

Indique le mot de passe associé à l'identité digne de confiance.

Type de données : Texte
Confirmation du mot de passe

Confirme le mot de passe associé à l'identité digne de confiance.

Type de données : Texte
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 cette option pour configurer et activer l'authentification de jeton LTPA (Lightweight Third-Party Authentication).
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 et LTPA et que le mécanisme d'authentification actif est LTPA, le serveur est associé à un serveur en aval à un nom d'utilisateur, un mot de passe ou un jeton LTPA.

Si vous sélectionnez Authentification de base et KRB5 et que le mécanisme d'authentification actif est KRB5, le serveur est associé à un serveur en aval à un nom d'utilisateur, un mot de passe, un jeton Kerberos ou LTPA.

Si vous ne sélectionnez pas Authentification de base, le serveur ne correspond pas à un serveur en aval avec un nom d'utilisateur et un mot de passe.

Transport

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

Vous pouvez choisir d'utilise 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 le système d'exploitation z/OS, sauf si des noeuds de versions 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 le système d'exploitation z/OS, sauf si des noeuds de versions 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 du certificat client

Indique si un certificat client du magasin de clés configuré est utilisé pour l'authentification sur le serveur lorsque la connexion SSL est établie entre ce serveur et un serveur en aval, à condition que le serveur en aval prenne en charge l'authentification par certificat client.

En général l'authentification par certificat client permet d'obtenir de meilleures performances que l'authentification par couche de messages, mais elle requiert des étapes de configuration supplémentaires. Ces étapes supplémentaires permettent notamment de vérifier que ce serveur dispose d'un certificat personnel et que le serveur en amont possède le certificat signataire de ce serveur.

Si vous sélectionnez l'authentification à l'aide de certificats client, les options disponibles sont les suivantes :
Jamais
Indique que ce serveur ne tente pas de procéder à l'authentification à l'aide de certificats client SSL (Secure Sockets Layer) auprès des serveurs en aval.
Pris en charge
Indique que ce serveur peut utiliser des certificats client SSL pour s'authentifier auprès des serveurs en aval. Cependant, une méthode peut être appelée sans ce type d'authentification. Par exemple, le serveur peut utiliser une authentification anonyme ou une authentification de base à la place.
Requis
Indique que ce serveur doit utiliser des certificats client SSL pour s'authentifier auprès des serveurs en aval.
Valeur par défaut Activé
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 échec du serveur et opération de reprise). Lorsque cette valeur est désactivée, tous les appels de méthode doivent être à nouveau authentifiés.

Activer la limite de cache des sessions CSIv2

Indiquez si la taille du cache des sessions CSIv2 doit être limitée.

Lorsque vous activez cette optioon, vous devez définir une taille maximale de cache et un délai d'expiration des sessions inactives. Si vous n'activez pas cette option, le cache de session CSIv2 n'est pas limité.

Dans les versions précédentes du serveur d'applications, vous pouvez avoir défini cette option comme propriété personnalisée com.ibm.websphere.security.util.csiv2SessionCacheLimitEnabled. Dans cette version du produit, il est recommandé de définir cette valeur dans la console d'administration et non pas sous la forme d'une propriété personnalisée.

Valeur par défaut false
Taille maximale du cache

Définissez la taille maximale du cache de session au-delà de laquelle les sessions ayant expiré sont supprimées du cache.

Les sessions ayant expiré sont des sessions qui restent inactives plus longtemps que le délai défini dans la zone Délai d'expiration des sessions inactives. Si vous entrez une valeur dans la zone de taille maximale du cache, définissez une valeur comprise entre 100 et 1 000.

Définissez une valeur dans cette zone si l'environnement utilise l'authentification Kerberos et que le décalage de son horloge est minime pour le centre KDC (Key Distribution Center) configurée. Dans ce scénario, un faible décalage d'horloge est inférieur à 20 minutes. Augmentez la valeur dans cette zone si une petite taille de cache amène la récupération d'espace à s'exécuter fréquemment et affecte alors les performances du serveur d'applications.

Dans les versions précédentes du serveur d'applications, vous pouvez avoir défini cette option comme propriété personnalisée com.ibm.websphere.security.util.csiv2SessionCacheMaxSize. Dans cette version du produit, il est recommandé de définir cette valeur en utilisant la console d'administration et non pas comme propriété personnalisée.

Cette zone s'applique uniquement si vous activez les options Sessions sans état et Activer la limite du cache des sessions CSIv2.

Valeur par défaut Aucune valeur n'est définie par défaut.
Portée 100 à 1 000 entrées
Délai d'expiration des sessions inactives

Cette propriété définit le délai d'inactivité en millisecondes d'une session CSIv2 avant sa suppression. La session est supprimée si vous sélectionnez l'option Activer la limite du cache des sessions CSIv2 et que la taille maximale du cache est dépassée.

Cette valeur d'expiration s'applique uniquement si vous activez les options Session sans état et Activer la limite du cache des sessiins CSIv2. Diminuez la valeur de cette zone si l'environnement utilise l'authentification Kerberos et que le décalage de son horloge est minime pour le centre KDC (Key Distribution Center) configuré. Dans ce scénario, un faible décalage d'horloge est inférieur à 20 minute. Si le décalage d'horloge est faible, un grand nombre de sessions CSIv2 peuvent être rejetées. Toutefois, si vous entrez une petite valeur dans la zone Délai d'expiration des sessions inactives, le serveur d'applications peut effacer les sessions rejetées plus fréquemment et réduire potentiellement le manque de ressources.

Dans les versions précédentes du serveur d'applications, vous pouvez avoir défini cette option comme propriété personnalisée com.ibm.websphere.security.util.csiv2SessionCacheIdleTime. Dans cette version du produit, il est recommandé de définir cette valeur en utilisant la console d'administration et non pas comme propriété personnalisée. Si vous l'avez définie sous la forme d'une propriété, la valeur a été définie en millisecondes et convertie en secondes dans la console d'administration. Dans le panneau de la console d'administration, vous devez définir un nombre de secondes.

Valeur par défaut Aucune valeur n'est définie par défaut.
Portée Entre 60 et 86 400 secondes
Mappage sortant personnalisé

Permet l'utilisation des modules de connexions sortantes RMI (Remote Method Invocation).

Le module de connexion personnalisé effectue un mappage ou d'autres fonctions avant l'appel sortant RMI prédéfini.

Pour créer un mappage sortant personnalisé, procédez comme suit :
  1. Cliquez sur Sécurité > Sécurité globale.
  2. Dans Authentification, cliquez sur Service d'authentification et d'autorisation Java > Connexions système > Nouveau.
Domaines d'authentification sécurisés - sortants

Si la communication RMI/IIOP se fait via différents domaines, utilisez ce lien pour ajouter des domaines sécurisés sortants.

Les jetons de justificatif sont uniquement envoyés aux domaines sécurisés. De plus, le serveur récepteur doit sécuriser ce domaine via la configuration des domaines sécurisés entrants pour valider le jeton LTPA.




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

Tâches associées


Nom du fichier : usec_outbound.html