Présentation des méthodes d'authentification

L'implémentation de la sécurité des Services Web pour WebSphere Application Server prend en charge les méthodes d'authentification suivantes : BasicAuth, Lightweight Third Party Authentication (LTPA), signature numérique et assertion d'identité.

Important : Il existe une différence importante entre les applications version 5.x, version 6 et ultérieure. Les informations concernent uniquement les applications Version 5.x utilisées avec WebSphere Application Server Version 6.0.x et versions ultérieures. Les informations ne s'appliquent pas aux applications version 6 et suivantes.

Lorsque WebSphere Application Server est configuré pour utiliser la méthode d'authentification BasicAuth, l'expéditeur joint le jeton Lightweight Third Party Authentication (LTPA) en tant qu'élément BinarySecurityToken à partir du contexte de sécurité en cours ou à partir de la configuration de données d'authentification de base dans le fichier de liaisons de l'en-tête de message SOAP. Le destinataire du message de sécurité de services Web authentifie l'expéditeur en validant le nom d'utilisateur et le mot de passe en fonction du registre des utilisateurs configurés. Avec la méthode LTPA, l'expéditeur joint l'élément BinarySecurityToken LTPA qu'il a précédemment reçu dans l'en-tête du message SOAP. Le destinataire authentifie l'expéditeur en validant le jeton LTPA et le délai d'expiration du jeton. A l'aide de la méthode d'authentification par signature numérique, l'expéditeur joint un élément BinarySecurityToken provenant d'un certificat X509 à l'en-tête de message de sécurité de services Web avec une signature numérique du corps du message, de l'horodatage, du jeton de sécurité ou d'une combinaison de ces trois éléments. Le destinataire authentifie l'expéditeur en vérifiant la validité du certificat X.509 et de la signature numérique à l'aide de la clé publique du certificat vérifié.

La méthode d'authentification par assertion d'identité est différente des trois autres méthodes. Cette méthode établit le justificatif de sécurité de l'expéditeur en fonction de la relation de confiance. Vous pouvez utiliser la méthode d'authentification par assertion d'identité, par exemple, lorsqu'un serveur intermédiaire doit appeler un service à partir d'un serveur en aval au nom du client mais qu'il ne dispose pas des informations d'authentification client. Le serveur intermédiaire peut établir une relation de confiance avec le serveur en aval puis vérifier l'identité du client auprès du même serveur en aval.

La sécurité des services Web prend en charge les modes de sécurisation suivants :
  • BasicAuth
  • Signature numérique
  • Relation de confiance présumée

Lorsque vous utilisez les modes de sécurisation BasicAuth et par signature numérique, le serveur intermédiaire transmet ses propres informations d'authentification au serveur en aval pour authentification. Le mode de relation de confiance présumée établit une relation de confiance à l'aide d'un mécanisme externe. Par exemple, le serveur intermédiaire peut transmettre des messages SOAP via une connexion SSL (Secure Socket Layers) avec le serveur en aval et l'authentification de certificat client de couche transport.

L'implémentation de la sécurité des Services Web pour WebSphere Application Server valide la relation de confiance en suivant la procédure ci-après :
  1. Le serveur en aval valide les informations d'authentification du serveur intermédiaire.
  2. Le serveur en aval vérifie si le serveur intermédiaire authentifié est autorisé à effectuer la vérification de l'identité. Par exemple, le serveur intermédiaire doit être dans la liste de confiance du serveur en aval.

L'identité du client peut être représenté par une chaîne de nom, un nom distinctif (DN), ou un certificat X.509. L'identité du client est jointe dans le message de sécurité des services Web dans un élément UsernameToken avec uniquement un nom d'utilisateur, un nom distinctif ou dans un élément BinarySecurityToken d'un certificat. Le tableau suivant indique le type de jeton de sécurité requis pour chaque méthode d'authentification.

Tableau 1. Méthodes d'authentification et jetons de sécurité associés. Utilisez les méthodes pour authentifier l'expéditeur d'un message.
Méthode d'authentification Jeton de sécurité
BasicAuth BasicAuth requiert <wsse:UsernameToken> avec <wsse:Username> et <wsse:Password>.
Signature La signature requiert <ds:Signature> et <wsse:BinarySecurityToken>.
IDAssertion IDAssertion requiert <wsse:UsernameToken> avec <wsse:Username> ou <wsse:BinarySecurityToken> avec un certificat X.509 pour l'identité du client qui dépend de <idType>. Cette méthode requiert également d'autres jetons de sécurité, comme il est définie dans l'élément <trustMode> :
  • If the <trustMode> is BasicAuth, IDAssertion requires <wsse:UsernameToken> with <wsse:Username> and <wsse:Password>.
  • Si <trustMode> est Signature, IDAssertion requiert <wsse:BinarySecurityToken>.
LTPA LTPA requiert <wsse:BinarySecurityToken> avec un jeton LTPA.
Un service web peut prendre en charge plusieurs méthodes d'authentification simultanément. Le descripteur de déploiement de services Web côté destinataire peut spécifier toutes les méthodes d'authentification prises en charge dans le fichier XML ibm-webservices-ext.xmi. Le destinataire des services web, tel qu'il est décrit dans l'exemple suivant, est configuré de manière à accepter toutes les méthodes d'authentification décrites précédemment :
<loginConfig xmi:id="LoginConfig_1052760331326">
      <authMethods xmi:id="AuthMethod_1052760331326" text="BasicAuth"/>
      <authMethods xmi:id="AuthMethod_1052760331327" text="IDAssertion"/>
      <authMethods xmi:id="AuthMethod_1052760331336" text="Signature"/>
      <authMethods xmi:id="AuthMethod_1052760331337" text="LTPA"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1052760331336" idType="Username" trustMode="Signature"/>
Vous pouvez définir uniquement une méthode d'authentification dans le descripteur de déploiement des services Web côté expéditeur. Un client de service web peut utiliser une des méthodes d'authentification prise en charge par l'application des services Web particuliers. L'exemple suivante illustre une configuration de méthode d'authentification par assertion d'identité dans l'extension du descripteur de déploiement ibm-webservicesclient-ext.xmi du client de services web :
<loginConfig xmi:id="LoginConfig_1051555852697">
      <authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>
Comme indiqué dans l'exemple précédent, le type ideComntity du client est Username et le mode de relation de confiance est la signature numérique.
Figure 1. Génération et validation de jeton de sécurité Génération et validation de jeton de sécurité

Le gestionnaire de sécurité de l'expéditeur appelle la méthode handle() d'une implémentation de l'interface javax.security.auth.callback.CallbackHandler. L'interface javax.security.auth.callback.CallbackHandler crée le jeton de sécurité et le transmet au gestionnaire de sécurité de l'expéditeur. Le gestionnaire de sécurité de l'expéditeur crée le jeton de sécurité en fonction des informations d'authentification dans le tableau des appels et insère le jeton de sécurité dans l'en-tête du message de sécurité des services Web.

Le gestionnaire de sécurité du destinataire compare le type de jeton de l'en-tête de message avec les types de jeton attendus configurés dans le descripteur de déploiement. Si aucun des types de jeton attendus n'est trouvé dans l'en-tête de sécurité des services Web du message SOAP, la demande est rejetée avec une exception d'erreur SOAP. Sinon, le type de jeton permet d'effectuer un mappage vers une configuration de connexion JAAS (Java™ Authentication and Authorization Service) pour la validation du jeton. Si l'authentification a abouti, un sujet JAAS est créé et associé à l'unité d'exécution en cours. Sinon, la demande est rejetée avec une erreur SOAP.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_authmeth
Nom du fichier : cwbs_authmeth.html