Relations de confiance
La relation de confiance permet d'intégrer la sécurité IBM® WebSphere Application Server et des serveurs de sécurité tiers. Plus précisément, elles permettent à un serveur proxy inversé d'agir comme serveur d'authentification frontal lorsque WebSphere applique sa stratégie d'authentification aux justificatifs transmis par le proxy.
La demande d'une configuration si intégrée s'est de plus en plus imposée, notamment lorsqu'une produit ne peut pas répondre à tous les besoin de l'utilisateur ou lorsque la migration ne s'avère pas possible.
Dans cette configuration, WebSphere Application Server sert de serveur dorsal afin d'exploiter un contrôle plus précis des accès. Le serveur proxy inversé transmet à WebSphere Application Server la requête HTTP incluant les justificatifs de l'utilisateur authentifié. WebSphere Application Server utilise alors ces justificatifs pour autoriser la demande.
Modèle de relations de confiance
Pour que WebSphere Application Server puisse prendre en charge les relations de confiance, la sécurité de l'application doit reconnaître et traiter les requêtes HTTP reçues d'un serveur proxy inversé. WebSphere Application Server et le serveur proxy s'engagent mutuellement : le premier fait totalement confiance au second, ce dernier appliquant en retour ses stratégies d'authentification à chaque demande web envoyée à WebSphere Application Server. Cette relation est validée par les intercepteurs résidant dans l'environnement du produit pour chaque demande reçue. La méthode de validation est acceptée par le serveur proxy et l'intercepteur.
L'exécution en mode de confiance n'empêche pas WebSphere Application Server d'accepter les demandes qui ne sont pas passées par le serveur proxy. Dans ce cas, aucun intercepteur n'est nécessaire pour valider la relation de confiance.
- com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
- Cette implémentation de l'intercepteur TAI, qui met en oeuvre la nouvelle interface WebSphere
Application Server, prend en charge WebSphere
Application Server version 5.1.1 et plus. Cette interface prend en charge WebSEAL version 5.1 mais pas WebSEAL version 4.1. Pour plus d'informations sur la propagation des attributs de sécurité, voir Propagation des attributs de sécurité.
Remarque : L'implémentation de l'intercepteur TAI prend également en charge WebSphere Application Server version 5.1.0.2 for z/OS.
- com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl
- Cet intercepteur est une des nouveautés de la présente édition. Désormais, l'authentificateur web de WebSphere Application Server est le mécanisme SPNEGO (et non l'intercepteur TAI SPNEGO).

IBM WebSphere Application Server : Intégration WebSEAL
L'intégration de WebSEAL et de la sécurité WebSphere Application Server s'effectue en plaçant le serveur WebSEAL comme récepteur, en tant que serveur proxy inversé. Du point de vue de gestion de WebSEAL, une jonction est créée entre WebSEAL et le serveur web du produit. Une jonction fait référence à une connexion logique établie pour créer un chemin du serveur WebSEAL vers un autre serveur.
Dans cette configuration, la demande d'une ressource stockée dans un domaine protégé de WebSphere est soumise à WebSEAL où elle est authentifiée par rapport au domaine de sécurité de ce dernier. Si le demandeur accède à la jonction, la demande est transmise au serveur HTTP de WebSphere Application Server, puis au serveur d'applications.
En parallèle, WebSphere Application Server valide chaque demande émanant de la jonction pour garantir que la source est un tiers digne de confiance. Ce processus correspond à une validation de la relation de confiance et est effectué par un intercepteur WebSEAL désigné par le produit. Si la validation aboutit, WebSphere Application Server autorise la demande en vérifiant si le client dispose des droits d'accès requis pour accéder à la ressource web. Si tel n'est pas le cas, la ressource web est remise au serveur WebSEAL, via le serveur web, puis transmise au client.
Serveur WebSEAL
Policy Director délègue toutes les demandes web à son composant web, à savoir le serveur WebSEAL. L'une des fonctions principales du serveur consiste à authentifier le demandeur. Le serveur WebSEAL consulte un répertoire LDAP (Lightweight Directory Access Protocol). Il peut également mapper l'utilisateur d'origine vers un autre ID, lorsqu'une procédure GSO (Global Single Sign-On) est utilisée, par exemple.

Pour que l'authentification aboutisse, le serveur joue le rôle d'un client de WebSphere Application Server lors de transmission de la demande. Le serveur a besoin de son propre ID utilisateur et mot de passe pour s'identifier auprès de WebSphere Application Server. Cette identité doit être valide dans le domaine de sécurité de WebSphere Application Server. Le serveur WebSEAL remplace les informations d'authentification de base dans la demande HTTP par son ID utilisateur et son mot de passe. En outre, WebSphere Application Server doit déterminer les justificatifs du client demandeur afin que le serveur d'applications dispose d'une identité pour prendre les décisions d'autorisation. Ces informations sont transmises via la demande HTTP et la création d'un en-tête appelé iv-creds, avec les justificatifs d'utilisateur de Tivoli Access Manager comme valeur associée.
Serveur HTTP
La jonction créée dans le serveur WebSEAL doit atteindre le serveur HTTP utilisé comme système frontal WebSphere. Le serveur HTTP est toutefois incapable de savoir si des relations de confiance sont établies. WebSEAL est donc considéré comme un autre client HTTP qui se contente d'envoyer la demande HTTP à WebSphere. La seule condition imposée par le serveur est une configuration SSL (Secure Sockets Layer) utilisant uniquement l'authentification du serveur. Cette condition permet de protéger les demandes qui passent par la jonction.
Collaborateur Web
- La demande doit être authentifiée.
- La demande doit être autorisée.
Authentificateur Web
Le collaborateur web demande à l'authentificateur Web d'authentifier une requête HTTP. Sachant que des relations de confiance sont établies, la tâche de l'authentificateur consiste à localiser l'intercepteur approprié pour diriger la demande à traiter. L'authentificateur web sollicite tous les intercepteurs disponibles. Si l'intercepteur recherché est introuvable. l'authentificateur web traite la demande comme si les relations de confiance n'existaient pas.
Les versions 4 à 6.x de WebSphere Application Server prennent en charge l'interface com.ibm.websphere.security.TrustAssociationInterceptor.java. WebSphere Application Server version 7.0.x et versions ultérieures prennent en charge l'interface com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl.
Interface TAI (Trust Association Interceptor)
Le but de cette interface est de placer des serveurs de sécurité proxy inversés comme points d'entrée pour réaliser une authentification et une autorisation à granularité générale, pendant que WebSphere Application Server effectue un contrôle d'accès plus détaillé. Les relations de confiance améliorent la sécurité en réduisant la portée et le risque d'exposition.
Dans une infrastructure e-business standard, l'environnement réparti d'une société se compose de serveurs d'applications web, de serveurs web, de systèmes existants et d'un ou plusieurs composants RPSS, tels que le produit Tivoli WebSEAL. Les serveurs proxy inversés, les serveurs de sécurité frontaux ou les plug-in de sécurité enregistrés au sein des serveurs web surveillent les demandes d'accès HTTP aux serveurs web et aux serveurs d'applications. Tout en protégeant l'accès aux URI (Uniform Resource Identifiers), ces composants RPSS effectuent l'authentification, gèrent les autorisations de manière globale et acheminent la demande au serveur d'applications cible.
- L'attribut com.ibm.websphere.ssl.direct_connection_peer_certificates contient un objet X509Certificate[] du certificat pour un homologue direct.
- L'attribut com.ibm.websphere.ssl.direct_connection_cipher_suite contient un objet string d'un algorithme de cryptographie directe.
- L'attribut com.ibm.websphere.webcontainer.is_direct_connection contient un objet booléen qui indique si la connexion a été établie par l'intermédiaire d'un serveur web, ou si elle a été envoyée directement à WebSphere Application Server.
Voir la rubrique Attributs de demande de conteneur Web pour plus d'informations sur ces attributs.