Cet exemple présente un client Java™ pur, C, accédant à un bean enterprise sécurisé sur le serveur S1, via
l'utilisateur bob. La procédure ci-après permet de configurer C, S1 et S2.
Pourquoi et quand exécuter cette tâche
Le code du bean enterprise sur S1 accède à un autre bean enterprise
sur le serveur S2. Cette configuration utilise la vérification d'identité pour propager
l'identité de bob au serveur en aval S2. S2 considère que bob a déjà été authentifié
par S1 auquel il fait confiance. Pour cette habilitation, l'identité de S1 est également
transmise simultanément à S2 qui la valide en vérifiant la liste trustedPrincipalList
pour s'assurer qu'il s'agit d'un principal de type serveur valide. S2 authentifie
également S1.
Procédure
- Configurez le client C pour l'authentification par couche de messages à l'aide d'un transfert
SSL (Secure Sockets Layer).
- Pointez le client vers le fichier sas.client.props.
Utilisez la propriété com.ibm.CORBA.ConfigURL=file:/C:/was/properties/sas.client.props.
Pour toute configuration ultérieure, il est nécessaire de définir les propriétés dans ce fichier.
Utilisez la propriété com.ibm.CORBA.ConfigURL=file:/racine_profil /properties/sas.client.props.
La variable racine_profil correspond au profil spécifique avec lequel vous travaillez. Pour toute configuration ultérieure, il est nécessaire de définir les propriétés dans ce fichier.
- Activez SSL.
Dans ce cas, SSL est pris en charge mais n'est pas requis : com.ibm.CSI.performTransportAssocSSLTLSSupported=true,
com.ibm.CSI.performTransportAssocSSLTLSRequired=false
- Activez l'authentification client par couche de messages.
Dans le cas présent,
l'authentification client est prise en charge, mais elle n'est pas obligatoire :
com.ibm.CSI.performClientAuthenticationRequired=false,
com.ibm.CSI.performClientAuthenticationSupported=true
- Utilisez tous les paramètres par défaut restants du fichier sas.client.props.
- Configurez le serveur S1.
Dans la console d'administration,
le serveur S1 est configuré afin que les demandes entrantes prennent en charge
l'authentification client par couche de messages et que les connexions entrantes prennent
en charge SSL sans authentification par certificat client. S1 est configuré de sorte que
les demandes sortantes prennent en charge la vérification d'identité.
- Configurez S1 pour les connexions entrantes.
- Désactivez la vérification d'identité.
- Activez l'authentification par ID et mot de passe.
- Activez SSL.
- Désactivez l'authentification par certificat client SSL.
- Configurez S1 pour les connexions sortantes.
- Activez la vérification d'identité.
- Désactivez l'authentification par ID et par mot de passe.
- Activez SSL.
- Désactivez l'authentification par certificat client SSL.
- Configurez le serveur S2.
Dans la console d'administration,
le serveur S2 est configuré de telle sorte que les demandes entrantes prennent en charge
la vérification d'identité et acceptent les connexions SSL. Suivez la procédure ci-après
pour configurer les connexions entrantes. La configuration des connexions et des demandes sortantes ne
s'applique pas à cet exemple.
- Activez la vérification d'identité.
- Désactivez l'authentification par ID et par mot de passe.
- Activez SSL.
- Désactivez l'authentification par client SSL.