La page de connexion est le premier et le plus critique contact de l'utilisateur avec votre organisation
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 les templates partagés gérés de façon centralisée. Il n'existe pas de possibilité de définir une fois le branding de l'organisation et que chaque gateway le référence et ne modifie que ce qui diffère. 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.
Notre approche
Templates partagés gérés de façon centralisée, variantes par tenant et assets servis depuis l'appliance — le tout sur une seule plateforme.
Templates partagés — définir une fois, réutiliser entre gateways
Le branding d'entreprise est défini une seule fois dans un template partagé géré de façon centralisée : couleurs, polices, mise en page, textes communs. Chaque gateway ou tenant le référence et ne modifie que les parties qui diffèrent — un logo, une couleur, un texte de titre. Le branding est défini une fois et réutilisé entre les gateways ; le coût de maintenance n'augmente pas linéairement pour chaque marque, et il n'y a pas de duplication par marque.
Personnalisation complète — HTML, CSS, images, champs personnalisés
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, la mise en page personnalisée 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 bâti sur le template partagé — est pris en charge.
Variantes par tenant — conçues pour le fournisseur de services
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.
Servi depuis l'appliance — aucun serveur web ou CDN distinct
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.
Capacités
Les blocs de construction des templates en détail, plus le contrôle opérationnel et la voie d'extension future.
Templates partagés — branding DRY
Le template partagé géré de façon centralisée de l'organisation définit les couleurs, les polices, la mise en page et les textes communs. Chaque gateway ou tenant le référence et ne modifie que les parties qui diffèrent. Le branding est défini une fois et réutilisé entre les gateways ; pas de maintenance par copier-coller pour chaque nouvelle marque.
Attribution de template par gateway
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.
Prise en charge multi-tenant — variante de template par tenant
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.
Contrôle complet du HTML, CSS et des images
Les templates prennent en charge le HTML, le CSS 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 et tout ce que votre charte de marque exige sont pris en charge.
Personnalisation des champs de formulaire — ajouter des champs personnalisés au flux de connexion
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.
Multilingue — i18n par template
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.
Assets servis depuis l'appliance — aucune infrastructure distincte
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é.
Profondeur opérationnelle
La mécanique qui rend la gestion des templates scalable et durable.
L'attribution de template fait partie de la configuration de la gateway
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.
La détection du tenant fonctionne avec des déclencheurs configurables
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.
Mise en cache des templates — aucune friction au détriment des performances
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.
Templates et assets gérés via l'interface d'administration
Un template et ses assets — HTML, CSS, images et autres fichiers — sont gérés via l'interface d'administration. Cela simplifie les opérations de maintenance et de sauvegarde, et les templates sont synchronisés entre plusieurs appliances afin que chaque nœud serve le même branding.
Attribution de template par gateway — aucun serveur web distinct
Chaque gateway est liée à son template par configuration. Un changement de cette attribution prend effet sans déployer ni redéployer un serveur web distinct ; la gateway référence simplement le template mis à jour et le sert directement.
Dans quels scénarios l'utiliser
Fournisseur de services — connexion brandée par tenant
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.
Organisation multi-marques — une porte distincte pour chaque marque
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.
Multilingue et adaptation régionale
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.
Solution white-label — connexion présentée au nom propre de l'organisation
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.
Questions fréquentes
À quel point le template est-il personnalisable ? Seulement le logo et la couleur ?
Comment fonctionnent les templates partagés ?
Dans un scénario de fournisseur de services, faut-il un déploiement distinct pour chaque client ?
Faut-il un serveur web ou un CDN distinct pour servir le HTML, le CSS et les images ?
Lorsque je mets à jour le template, les utilisateurs en ligne sont-ils affectés ?
La page de connexion est la première impression de votre marque — appropriez-vous-la
Templates partagés gérés de façon centralisée, 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.