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
- Démarrez la console d'administration.
- Cliquez surSécurité > Sécurité globale.
- Sous Sécurité RMI/IIOP, cliquez sur Communications entrantes CSIv2.
- 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]](../images/dist.gif)
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]](../images/ngzos.gif)
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: 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]](../images/dist.gif)
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é.
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é.
- Prenez en compte les points suivants lorsque vous déterminez le
type d'authentification à accepter :
- 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: 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
- 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.