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.

WebSphere Application Server prend en charge les interfaces TAI (Trust Association Interceptor) suivantes :
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é.
[z/OS]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).
Le fait que WebSphere Application Server puisse prendre en charge l'assocation de confiance implique que la sécurité de l'application du produit reconnaît et traite les demandes HTTP reçues d'un serveur proxy inverse. WebSphere Application Server et le serveur proxy entrent dans un contrat dans lequel le produit fait totalement confiance au serveur proxy et le serveur proxy applique ses règles d'authentification sur chaque demande Web envoyée à WebSphere Application Server. Cette confiance est validée par les intercepteurs qui résident dans l'environnement du produit pour chaque demande reçue. La méthode de validation fait l'objet d'un accord entre le serveur proxy et l'intercepteur.

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.

Le gestionnaire de règles délègue le traitement de toutes les requêtes web à son composant web, le serveur WebSEAL. L'une des principales fonctions du serveur est d'authentifier l'utilisateur à l'origine de la requête. Pour cela, le serveur WebSEAL consulte un annuaire LDAP (Lightweight Directory Access Protocol. Il peut aussi mapper l'ID utilisateur original à un autre ID utilisateur, par exemple quand vous utilisez GSO.

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.
La jonction créée dans le serveur WebSEAL doit aboutir au serveur HTTP qui sert de système frontal pour le produit. Cependant, le serveur HTTP ignore qu'une association de confiance est utilisée. De son point de vue, le programme WebSEAL n'est qu'un client HTTP parmi d'autres et, dans le cadre de son fonctionnement normal, il lui envoie la requête HTTP. La seule exigence pour le serveur HTTP est de disposer d'une configuration SSL utilisant l'authentification par serveur uniquement. Cette exigence protège les requêtes qui transitent par la jonction.

Collaborateur Web

Lorsque des relations de confiance sont établies, le collaborateur web gère les intercepteurs configurés sur le système. Il charge et initialise ces intercepteurs au démarrage du serveur. Lorsqu'une demande est transmise à WebSphere Application Server par le serveur Web, le collaborateur web reçoit la demande pour un contrôle de sécurité. Deux actions doivent s'effectuer :
  1. La demande doit être authentifiée.
  2. La demande doit être autorisée.
Le système appelle l'authentificateur web pour authentifier la demande transmise. Si l'authentification aboutit, un enregistrement de justificatif valide est renvoyé par l'authentificateur et utilisé par le collaborateur web pour définir l'autorisation par rapport à la ressource demandée. Si cette seconde opération aboutit, le collaborateur informe WebSphere Application Server que le contrôle de sécurité a abouti et que la ressource demandée peut être transmise.

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.

Remarque :

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.

Lorsqu'un serveur web, tel qu'IBM HTTP Server, utilise une interface TAI pour communiquer avec WebSphere Application Server, il est parfois essentiel pour l'interface TAI de savoir si une demande a été transmise via un serveur web ou si elle est envoyée directement au serveur WebSphere Application Server. Ainsi, le conteneur Web de WebSphere Application Server utilise trois attributs HttpServletRequest pour fournir à l'intercepteur TAI les informations de certificat d'une demande :
  • 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.


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=csec_trust
Nom du fichier : csec_trust.html