Configuration des communications sortantes CSIv2
Les options suivantes sont disponibles lors de la configuration du panneau des communications sortantes CSIv2 (Secure Interoperability Version 2).
Avant de commencer
Pourquoi et quand exécuter cette tâche
Procédure
- Sélectionnez Vérification d'identité (couche d'attribut). Lorsque cette option est sélectionnée, ce serveur envoie un jeton d'identité à un serveur en aval, si ce dernier prend en charge la vérification d'identité. Lorsqu'un client émetteur s'authentifie auprès de ce serveur, les informations d'authentifications fournies sont conservées dans le jeton d'identité sortant. Si le client s'authentifie à l'aide d'un certificat auprès de ce serveur, le format du jeton d'identité correspond à la chaîne de certificats du client sur la socket entrante. Cela est également vrai pour les autres mécanismes d'authentification. Pour plus d'informations, voir la rubrique Vérification d'identité.
Sélectionnez ID utilisateur et Mot de passe (couche de message). Ce type d'authentification est le plus courant. L'ID utilisateur et le mot de passe (pour un justificatif BasicAuth) ou le jeton authentifié (pour un justificatif authentifié) sont envoyés au serveur en aval si ce dernier prend en charge l'authentification par couche de messages dans le panneau d'authentification des communications entrantes. Pour plus d'informations, voir l'article Authentification par couche de message.
- Sélectionnez Authentification par certificat client SSL (couche de transport). L'activation de l'authentification des communications sortantes des clients SSL d'un serveur vers un serveur en aval permet avant tout de créer un environnement sécurisé entre ces serveurs. Pour déléguer les justificatifs client, utilisez l'une des deux couches citées précédemment. Toutefois, si vous le voulez, vous pouvez créer des certificats SSL personnels pour tous les serveurs de votre domaine et n'établir une relation de confiance qu'avec ceux du fichiers de tiers SSL dignes de confiance. Aucun autre serveur ou client ne peut se connecter aux serveurs de votre domaine, exceptés aux tiers de votre choix. Ce processus permet d'interdire aux serveurs autres que vos serveurs de servlet l'accès à vos serveurs de beans enterprise.
Exemple
En général, la configuration de l'authentification des communications sortantes permet à un serveur en amont de communiquer avec un serveur en aval. Par ailleurs, la plupart du temps, le serveur en amont est un serveur de servlets et le serveur en aval, un serveur d'EJB (Enterprise JavaBeans). Sur un serveur de servlet, différents types d'authentification de client peuvent être choisis pour accéder au servlet, y compris le certificat client et l'authentification de base. Lorsque des données d'authentification de base sont reçues via une connexion par invite ou par formulaire, ces données sont généralement authentifiées pour créer un justificatif adapté au type de mécanisme pris en charge par le serveur, par exemple LTPA (Lightweight Third Party Authentication). Si LTPA est utilisé, le justificatif contient un jeton acheminable. Choisissez une authentification par couche de messages (BasicAuth) pour propager les justificatifs du client. Si le justificatif est créé à l'aide d'une connexion par certificat et que vous voulez éviter d'envoyer le certificat en aval, optez pour un envoi avec vérification d'identité.