Lorsqu'un utilisateur veut accéder à une application d'entreprise, la première chose qu'il voit est la page de connexion. Cette page n'est pas qu'un formulaire collectant un nom d'utilisateur et un mot de passe ; c'est le premier point où la fiabilité de la marque, le professionnalisme de l'organisation et la qualité du service sont transmis.
La plupart des gateways d'authentification échouent à ce stade. La page de connexion qu'ils offrent est soit générique et sans marque, soit elle ne prend en charge qu'un changement de logo superficiel. Une personnalisation plus profonde — mise en page personnalisée, champs personnalisés, texte personnalisé, langues personnalisées — nécessite un déploiement frontend distinct, un serveur web distinct ou une installation de CDN distincte.
Pour les fournisseurs de services ou les organisations multi-tenant, ce problème se multiplie. Un fournisseur voulant servir chaque client avec sa propre marque doit porter un déploiement distinct, une configuration DNS distincte et une version de maintenance distincte pour chaque client. Le branding devient une promesse faite à l'utilisateur plutôt qu'un engagement technique.
Pire encore : la plupart des solutions ne prennent pas en charge l'héritage de template. Il n'existe pas de possibilité de définir une fois le style de base de l'organisation et de n'override que ce qui diffère pour chaque gateway. Chaque template est soit écrit de zéro, soit dupliqué par copier-coller ; cela conduit à l'incohérence et à une maintenance non durable.
La page de connexion est le visage visible de l'infrastructure d'authentification. Elle doit être à la fois brandable et durable.
Car chaque client attend une page de connexion à son nom — mais si chaque page de connexion se transforme en un déploiement distinct, l'infrastructure s'effondre.
Héritage de template, variantes par tenant et assets servis depuis l'appliance — le tout sur une seule plateforme.
Le template de base d'entreprise est défini une seule fois : couleurs, polices, mise en page, textes communs. Chaque gateway ou tenant n'override que les parties qui diffèrent — un logo, une couleur, un texte de titre. Les changements effectués sur le template de base se répercutent automatiquement sur tous les templates dérivés ; le coût de maintenance n'augmente pas linéairement pour chaque marque.
Les templates ne sont pas qu'un changement de couleur ou de logo. La mise en page HTML complète, le CSS personnalisé, les images personnalisées, le JavaScript personnalisé et les champs personnalisés ajoutés au formulaire de connexion sont pris en charge. Tout design correspondant à votre charte de marque — de zéro ou dérivé du template de base — est pris en charge.
Lorsque la même plateforme AAM sert plusieurs clients, chaque client obtient sa propre page de connexion brandée. La détection du tenant se fait via la correspondance de gateway, le nom d'hôte ou un motif d'URL. Lorsqu'un utilisateur arrive à la bonne porte, il voit la bonne marque ; sans laisser de trace pointant vers la plateforme propre au fournisseur de services.
HTML, CSS et images sont servis directement depuis l'appliance AAM. Il n'y a aucun serveur web distinct, aucun CDN distinct ni aucun déploiement frontend distinct. Cela assure à la fois la simplicité opérationnelle et l'absence d'un point de dépendance externe supplémentaire — la page de connexion provient de la même pile qui exécute l'authentification.
Les blocs de construction des templates en détail, plus le contrôle opérationnel et la voie d'extension future.
Le template de base de l'organisation définit les couleurs, les polices, la mise en page et les textes communs. Chaque gateway ou tenant n'override que les parties qui diffèrent. Les changements effectués sur le template de base se répercutent automatiquement sur tous les templates dérivés ; pas de maintenance par copier-coller pour chaque nouvelle marque.
Chaque gateway AAM choisit le template qu'il utilisera depuis l'interface de gestion. Sur la même plateforme, différentes gateways peuvent exécuter différents templates ; une UX de connexion distincte pour chaque application, chaque marque ou chaque client — depuis une seule appliance.
Lorsque la même gateway sert plusieurs tenants, chaque tenant obtient sa propre variante de template. La détection du tenant est configurée via le nom d'hôte, un motif d'URL, une composante de chemin ou un header personnalisé ; le bon template est servi au bon utilisateur, avec le bon déclencheur.
Les templates prennent en charge le HTML, le CSS, le JavaScript et les assets d'image complets. Pas seulement le changement de logo et de couleur ; les mises en page personnalisées, les champs de formulaire personnalisés, la logique de validation personnalisée, les animations personnalisées et tout ce que votre charte de marque exige sont pris en charge.
En plus des champs standard nom d'utilisateur/mot de passe, un identifiant client, un code de tenant, un sélecteur de localisation, un sélecteur de langue ou tout autre champ souhaité peut être ajouté. Ces champs sont reliés au flux d'authentification ; la valeur collectée est transmise aux systèmes backend ou au moteur de politique.
Chaque template peut prendre en charge plusieurs langues. La détection de la langue se fait via la préférence de l'utilisateur, le header Accept-Language ou un paramètre d'URL. Un seul template offre une UX de connexion cohérente dans chaque langue ; il n'est pas obligatoire de dupliquer un template distinct par langue.
HTML, CSS, images et autres assets sont servis directement depuis l'appliance AAM. Aucun serveur web distinct, aucun CDN distinct ni aucun déploiement frontend distinct n'est requis. La simplicité opérationnelle est préservée ; aucun point de dépendance externe n'est ajouté.
Un éditeur visuel de template prévu permettra aux équipes de branding de créer et de prévisualiser des templates sans écrire de HTML/CSS. Le contrôle de version des templates permettra d'auditer, d'annuler chaque changement et de servir des versions parallèles pour les tests A/B.
La mécanique qui rend la gestion des templates scalable et durable.
Dans la configuration de la gateway, le template à utiliser est défini comme un champ. Le changement de configuration est appliqué sans affecter les utilisateurs en ligne ; les sessions actives continuent avec le template existant, les nouvelles sessions voient le template mis à jour.
Lorsqu'une gateway sert plusieurs tenants, la détection du tenant est configurée via la correspondance de nom d'hôte (customer-a.portal.example.com), le chemin d'URL (/customer-a/login), une valeur de header ou un cookie. Lorsque le bon tenant est détecté, la bonne variante de template est servie.
Les templates sont mis en cache sur l'appliance AAM ; il n'est pas nécessaire de lire le disque à chaque requête. Lorsqu'une mise à jour de template est publiée, le cache est invalidé automatiquement ; les performances sont préservées, les mises à jour se répercutent instantanément.
Un template est chargé depuis l'interface de gestion sous forme d'un seul paquet, avec HTML, CSS, images et autres assets. La structure de paquet facilite les opérations de maintenance, de sauvegarde et de synchronisation entre plusieurs appliances.
Un template nouveau ou modifié peut être testé dans l'aperçu de l'administrateur avant d'être servi aux utilisateurs en ligne. L'aperçu exécute exactement le même chemin de connexion réel, mais n'est servi qu'à l'administrateur qui prévisualise. Une erreur reste visible uniquement aux yeux de l'administrateur.
Au-delà des templates individuels, une définition centrale des variables de thème d'entreprise (couleurs, polices, tailles) est dans la roadmap. Lorsqu'une variable de thème est mise à jour, tous les templates qui y sont liés sont mis à jour automatiquement ; l'équipe de branding gère l'apparence de toutes les gateways depuis un seul point de contrôle.
Un MSP ou un fournisseur SaaS fournit un service d'authentification à plusieurs de ses clients. Chaque client veut voir son propre logo, ses propres couleurs et ses propres textes. Une seule plateforme AAM, avec la détection du tenant, sert à chaque client sa propre page de connexion brandée — sans déploiements distincts.
Une organisation possédant plusieurs marques (par exemple une structure de holding ou une distribution multi-marques) veut une page de connexion distincte pour chaque marque. La même infrastructure de base, avec une variante de template par marque, offre à chaque marque sa propre expérience utilisateur ; l'infrastructure technique converge en un point, l'identité de marque est séparée.
Une organisation internationale veut offrir une page de connexion dans la langue de chaque région et avec son adaptation locale. Avec la prise en charge i18n par template, un seul template fonctionne dans plusieurs langues ; la détection de la langue est automatique et chaque utilisateur se connecte dans sa propre langue.
Un partenaire ou un revendeur veut offrir un service d'authentification à ses propres clients, mais veut rendre invisible le fait que la plateforme TR7 est en dessous. Des templates entièrement personnalisables offrent une UX présentée entièrement à la marque du partenaire, sans trace de TR7 dans le code source de la page, le logo ou les textes.
Héritage de template, variantes par tenant et assets servis depuis l'appliance — le tout sur une seule plateforme. Nous vous guidons dans une installation en direct avec votre propre charte de marque.