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, cliquez sur Sécurité > Protocole d'authentification > Authentification des communications entrantes CSI.
Les paramètres d'authentification des communications entrantes CSI 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 qui peuvent être utilisées simultanément :
Onglet Configuration
Dans la couche messages, l'authentification de base (ID utilisateur et mot de passe) est effectuée. 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. Il implique également la délégation d'un jeton de justificatif émanant d'un justificatif déjà authentifié, à condition que ce type de justificatif puisse être envoyé (LTPA, par exemple). Si l'option Authentification de base est sélectionnée pour le serveur, spécifiez l'authentification de l'ID utilisateur et du mot de passe, ainsi que l'authentification par jeton.
Si vous sélectionnez Authentification de base, vous devez indiquer si elle est Requise ou Prise en charge. En sélectionnant Requise, seuls les clients configurés pour s'authentifier sur ce serveur via la couche messages sont autorisés à appeler des demandes sur ce serveur. Si l'option Prise en charge est sélectionnée, le serveur accepte l'authentification de base. Toutefois, d'autres méthodes d'authentification peuvent être utilisées si elles sont configurées et que les demandes anonymes sont acceptées. Si l'option Jamais est sélectionnée, le serveur n'est pas configuré pour accepter l'authentification via la couche messages d'un quelconque client.
| Type de données : | Chaîne |
Dans la couche 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 effectuée. L'authentification par certificat client s'effectue généralement mieux que l'authentification sur la couche messages, mais requiert davantage d'étapes de configuration. Ces étapes supplémentaires impliquent l'assurance que le serveur dispose du certificat de 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. Lorsque le certificat est authentifié par rapport à un registre d'utilisateurs LDAP, le nom DN est mappé en fonction du filtre indiqué lors de la configuration de LDAP. Lorsque le certificat est authentifié auprès d'un système d'exploitation local, le premier attribut du nom distinctif du certificat (généralement le nom commun) est mappé à l'ID utilisateur du 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.
Si vous sélectionnez Authentification par certificat client, vous devez indiquer si elle est Requise ou Prise en charge. Si vous sélectionnez Requise, seuls les clients configurés pour s'authentifier sur ce serveur via les certificats client SSL sont autorisés à appeler des demandes sur le serveur. Si vous sélectionnez Prise en charge, ce serveur accepte l'authentification par certificat client SSL, mais d'autres méthodes d'authentification peuvent être utilisées (si elles sont configurées) et les demandes anonymes sont acceptées. Si vous sélectionnez Jamais, ce serveur n'est pas configuré pour accepter l'authentification par certificat client d'un quelconque client.
| Type de données | Chaîne |
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 effectuée, l'identité est toujours dérivée de cet attribut. Si l'authentification de base est effectué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é correspond à l'identité du client. Si le mode d'exécution est Système, l'identité correspond à l'identité du serveur. Si le mode d'exécution est Spécifié, l'identité correspond à 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 principaux séparés par des virgules, par exemple serverid1, serverid2, serverid3.
Lors de l'authentification par rapport à un registre d'utilisateurs LocalOS, 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.
| Type de données : | Chaîne |
Cette liste permet de déterminer rapidement 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 |
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 (il s'agit de la 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 (situation d'é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.
| Type de données | Chaîne |