Connexion unique

La connexion unique HTTP conserve l'authentification d'utilisateur sur différentes applications web. L'utilisation de la connexion unique (SSO) HTTP permet à l'utilisateur de ne pas avoir à entrer à plusieurs reprises ses autorisations d'accès au sein d'un domaine de confiance.

Le domaine de confiance comprend les applications et les serveurs suivants :
  • Des serveurs WebSphere Application Server coopérants mais disparates.
  • Des applications coopérantes telles qu'IBM Security Directory Server.

Dans un scénario de connexion unique, un cookie HTTP est utilisé pour propager les informations d'authentification d'un utilisateur vers des serveurs web disparates. Cette propagation évite à l'utilisateur d'avoir à entrer des informations d'authentification pour chaque nouvelle session client / serveur (en supposant une authentification de base).

Par défaut, HCL Commerce peut lire et générer le cookie LTPA (Lightweight Third Party Authentication), qui est utilisé pour transmettre les données d'identification SSO entre les applications WebSphere Application Server. Le mécanisme par défaut pour prendre en charge la connexion unique requiert que HCL Commerce soit utilisé comme référentiel d'utilisateurs commun partagé par toutes les applications nécessitant la connexion unique et que le nom distinctif de l'utilisateur dans le cookie LTPA corresponde à la valeur USERS.DN dans la base de données HCL Commerce. Si l'utilisateur n'existe pas dans la base de données, il est créé lors de la première demande de connexion unique.

Sinon, si LDAP n'est pas utilisé ou si le cookie LTPA ne contient pas USERS.DN ou si un autre jeton SSO est utilisé, vous devez personnaliser la classe LDAPIntegrationCmdImpl pour prendre en charge la connexion unique dans HCL Commerce. Pour plus d'informations, voir 1.

Lorsque LDAP est utilisé pour les magasins de données migrés, un module de connexion JAAS nommé WCLogin est créé et utilisé au cours de l'authentification pour permettre à HCL Commerce de générer le cookie d'authentification LTPA. Le module de connexion est appelé au cours du processus, LogonCmd étant mis en correspondance avec l'action Struts com.ibm.commerce.struts.v2.LTPATokenGenerationEnabledBaseAction. Il procède alors à l'authentification par rapport au module de connexion JAAS WCLogin pour créer les cookies d'authentification LTPA si l'utilisateur s'authentifie correctement.
Remarque : La commande AjaxLogon ne peut pas être utilisée à la place de LogonCmd car elle ne prend pas en charge la génération de jetons LTPA.

Si une application autre que WebSphere Application Server doit participer à une session à connexion unique avec HCL Commerce, un produit IBM tel que Tivoli Access Manager WebSEAL peut être utilisé pour appliquer une connexion unique dans toutes les différentes applications. WebSEAL est un proxy inverse qui intercepte les demandes protégées et génère un jeton LTPA une fois l'authentification réussie. Par ailleurs, si vous choisissez d'utiliser un proxy inverse non-IBM, par exemple CA SiteMinder, vous devez incorporer un intercepteur de relations de confiance (TAI). Un intercepteur de relations de confiance permet de convertir le jeton de connexion unique personnalisé en un jeton LTPA que HCL Commerce peut comprendre.

Si vous utilisez un proxy inverse non-IBM, et ne souhaitez pas utiliser LTPA comme jeton de connexion unique, HCL Commerce peut alors être personnalisé pour lire (mais pas générer) le jeton de connexion unique personnalisé en substituant ce qui suit :
  1. Pour les requêtes de connexion unique via HTTP, la méthode suivante de com.ibm.commerce.member.syncbeans.commands.LDAPIntegrationCmd doit renvoyer la valeur USERS.DN de l'utilisateur HCL Commerce sur la base de l'identité du jeton à connexion unique personnalisé :
    public String getLDAPDNFromSingleSignOnTokenForWeb(HttpServletRequest request) 
  2. Pour les demandes de connexion unique via les services Web, en supposant que MemberFacadeClient.authenticateLTPA(Map) est appelé en premier et transmet la valeur String du jeton de connexion unique personnalisé à l'aide du nom de paramètre "LTPAToken". Puis, la méthode suivante de com.ibm.commerce.member.syncbeans.commands.LDAPIntegrationCmd doit renvoyer la valeur USERS.DN de l'utilisateur HCL Commerce sur la base de l'identité du jeton à connexion unique personnalisé :
    public String getLDAPDNFromSingleSignOnTokenForWebServices(String ssoToken) 
Remarque :
  • Si HCL Commerce n'est pas configuré avec LDAP et que vous utilisez un serveur d'authentification tiers et un jeton SSO personnalisé, vous pouvez activer le SSO dans HCL Commerce en effectuant les étapes suivantes.
    • HCL Commerce Developer
      1. Ouvrez la WebSphere Application Server Administrative Console dans l'image Docker Transaction server (ts-app).
      2. Voir Serveurs d'applications > server 1 > Gestion des processus et Java > Définition de processus > Machine virtuelle Java > Propriétés personnalisées.
      3. Définissez la propriété SingleSignOnEnabled sur true.
    • LinuxDans ce cas, le profil utilisateur (à l'exception du mot de passe) doit exister dans la base de données HCL Commerce avant la connexion ou la connexion unique dans HCL Commerce. Pour configurer HCL Commerce afin qu'il utilise l'authentification tierce, voir HCL Commerce modèle d'authentification.

    Désormais, lorsque les utilisateurs s'enregistrent sur HCL Commerce, le profil utilisateur est créé dans la base de données HCL Commerce et le mot de passe est stocké dans le serveur d'authentification tiers.

  • Pour l'intégration SAML, vous pouvez utiliser la fonction SAML WebSphere Application Server. Pour plus d'informations sur l'implémentation de WebSphere Application Server, voir Enabling your system to use the SAML web single sign-on (SSO) feature dans la documentation WebSphere Application Server. Dans cette approche, HCL Commerce est le fournisseur de services. Vous devez personnaliser les méthodes LDAPIntegrationCmd qui sont répertoriées aux étapes #1 et #2 pour traiter le jeton LTPA, récupérer les attributs SAML correspondants qui identifient l'utilisateur, puis renvoyer la valeur USERS.DN qui correspond à cet utilisateur dans la base de données HCL Commerce.
  • Pour une intégration OpenID Connect (OIDC), vous pouvez utiliser la fonction Partie utilisatrice WebSphere Application Server OIDC. Dans cette approche, HCL Commerce est la partie utilisatrice. Vous devez personnaliser les méthodes LDAPIntegrationCmd qui sont répertoriées aux étapes #1 et #2 pour traiter le jeton LTPA, puis renvoyer la valeur USERS.DN qui correspond à cet utilisateur dans la base de donnéesHCL Commerce. Pour plus d'informations sur l'implémentation WebSphere Application Server, voir Configuration d'une partie utilisatrice openID Connect dans la documentation WebSphere Application Server.
Avertissement : Passez en revue les principales limitations suivantes de la connexion unique lorsqu'elle est utilisée avec HCL Commerce :
  • Les cookies d'authentification LTPA peuvent passer par différents ports de serveur web.
  • Les applications qui peuvent lire et émettre le jeton LTPA WebSphere Application Server sont prises en charge.
  • Les navigateurs Web qui acceptent les cookies sont pris en charge, de sorte que les cookies LTPA puissent être écrits.