La sécurité et la structure de services Web de HCL Commerce

La spécification WS-Security (http://www.oasis-open.org/committees/wss/) définit plusieurs techniques d'implémentation de la sécurité des services Web.

Par défaut, toutes les requêtes de service Web reçoivent l'authentification de l'utilisateur générique. Cependant, comme une grande part de la logique métier de HCL Commerce qui doit être exposée à travers des services Web ne peut pas être exécutée par l'utilisateur générique, WS-Security peut être mis à contribution pour permettre l'utilisation de justificatifs différents.

Les sections suivantes traitent des points de sécurité à prendre en considération lorsque les services Web de HCL Commerce sont activés.

Authentification de base

L'basic authentication est l'une des approches possibles en matière de sécurité des services Web. Elle consiste à joindre les justificatifs de l'utilisateur à l'en-tête de l'enveloppe SOAP. Le principal défaut de cette technique est que les données d'authentification figurent en texte brut dans le message SOAP. Si le protocole de transport sous-jacent n'est pas sécurisé, elles sont facilement accessibles à toute personne munie des outils de reniflage appropriés. Par conséquent, l'authentification standard ne doit être utilisée que avec un protocole de transport sécurisé, tel que HTTPS.

Voici un exemple de demande SOAP utilisant l'authentification standard :

<soapenv:Envelope
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header>
    <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsse:UsernameToken>
        <wsse:Username>myUserName</wsse:Username>
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
          myPassword
        </wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <!-- message pay load -->
  </soapenv:Body>
</soapenv:Envelope>

Conformément à la dernière mouture de la spécification WS-Security, les justificatifs (données d'identification) de l'utilisateur se trouvent à l'intérieur du nœud Security de l'en-tête SOAP. Ce nœud tient lieu de conteneur dans lequel doivent être placées toutes les informations de sécurité à associer à la requête de service Web.

Lorsque l'authentification standard est utilisée pour authentifier un utilisateur, le contrôleur de services Web de HCL Commerce extrait le justificatif de l'en-tête SOAP et appelle le service du contexte métier pour démarrer une nouvelle session en fonction du justificatif trouvé. Cette session établit une activité associée à l'utilisateur spécifié, mais elle n'existe que pendant la durée que prend le traitement de la requête. On suppose qu'elle n'est pas utile au traitement des requêtes suivantes ; le jeton d'activité est renvoyé au client appelant. Une fois la requête servie, l'activité est terminée et ne peut plus être utilisée pour d'autres requêtes.

Sécurité WebSphere

Lorsque la sécurité globale de WebSphere est activée, le moteur de services Web de WebSphere Application Server se charge d'authentifier l'utilisateur et de placer ses justificatifs sur l'unité d'exécution. A son tour, le contrôleur de services Web crée une activité temporaire avec l'ID utilisateur obtenu du contexte d'authentification de l'unité d'exécution.

Cette approche utilise la sécurité WebSphere et du moteur de services Web pour assurer l'authentification de l'utilisateur ; elle ne nécessite pas d'autre implémentation pour la lecture du justificatif dans l'unité d'exécution.

Authentification par protocole

Remarque : La méthode d'authentification du protocole n'est applicable que si l'une des classes suivantes est utilisée :

Imposer l'activation de la sécurité sur le serveur d'applications peut être néfaste aux performances. Cependant, comme le concept de certificat est propre au protocole de transport, vous pouvez toujours utiliser cette approche de certificat sans nuire aux performances si vous permettez au transport de fournir cette validation sans activer la sécurité globale de WebSphere.

Une solution consiste à utiliser un indicateur générique, nommé secureTransportProtocol. Si aucun justificatif ne figure dans les requêtes de service Web et que cet indicateur est activé (true), au lieu d'exécuter les requêtes sous l'autorité d'un utilisateur générique, c'est l'utilisateur de messagerie par défaut qui est utilisé. Cet indicateur générique se trouve dans la section Messagerie du HCL Commercefichier de configuration. Lorsque sa valeur est true, la structure de services Web considère que le protocole a été configuré pour assurer la validation des justificatifs de la requête. L'ID utilisateur de l'activité est celui de l'utilisateur de messagerie par défaut. Dans le fragment de fichier de configuration ci-après, toute requête non accompagnée de justificatifs est exécutée sous l'autorité de wcsadmin.

<Messaging
  EcInboundMessageDtdFiles="NCCommon.mod, NCCustomer_10.mod"
  EcInboundMessageDtdPath="messaging"
  EcMimePropFile="lang_mime.data"
  EcSystemTemplateFile="sys_template.xml"
  EcTemplatePath="messaging"
  EcUserTemplateFile="user_template.xml"
  
XMLWebControllerUserId="wcsadmin"
  secureTransportProtocol="true" />

Remarque : L'indicateur secureTransportProtocol ne peut pas être positionné avec le gestionnaire de configuration. Vous devez éditer directement le fichier de configuration HCL Commerce.

Important : L'utilisation de cette technique implique que toutes les précautions de sécurité nécessaires ont été prises au niveau de la couche transport pour sécuriser la transmission des messages et la validation des requêtes. Si le transport n'est pas sécurisé et que l'indicateur secureTransportProtocol est défini sur true, chaque requête non authentifiée est exécutée avec l'autorité de l'utilisateur de messagerie par défaut. L'utilisation de cette autorité peut être une exposition à la sécurité.

Jeton d'activité

Le activity token est un moyen d'établir une session pour un protocole qui, normalement, fonctionne sans session.

HCL Commerce La structure de services Web utilise l'architecture connectable de jetons personnalisés fournie par le moteur de services Web de WebSphere Application Server pour insérer le jeton d'activité dans l'en-tête SOAP de la requête. La seule différence entre cette forme d'authentification et les autres méthodes d'authentification est que l'activité n'est pas terminée une fois la requête servie. L'activité est maintenue en vie pour servir aux requêtes suivantes.

Pour récupérer les informations de jeton d'activité, vous pouvez appeler les méthodes MemberFacadeClient.authenticatePassword ou authenticateLTPA pour authentifier l'utilisateur et récupérer les jetons. Pour plus d'informations sur les méthodes d'authentification, voir com.ibm.commerce.member.facade.client. Pour plus d'informations sur le message de mot de passe authentifié, voir Nom Person

Voici un exemple de demande SOAP qui utilise un jeton d'activité :

<soapenv:Envelope
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsswssecurity-secext-1.0.xsd"> 
      <wc:IdentityToken xmlns:wc="http://www.ibm.com/xmlns/prod/WebSphereCommerce"> 
        <wc:IdentityIdentifier>10001</wc:IdentityIdentifier>
        <wc:Signature>poifhhOgAs+eRlajfn7mzt+m3Dqbw=</wc:Signature>
      </wc:IdentityToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <!-- message pay load -->
  </soapenv:Body>
</soapenv:Envelope>