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é.
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.
- 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.
- Le serveur en aval valide les informations d'authentification du serveur intermédiaire.
- 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.
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> :
|
LTPA | LTPA requiert <wsse:BinarySecurityToken> avec un jeton LTPA. |
<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"/>
<loginConfig xmi:id="LoginConfig_1051555852697">
<authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>

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.