Cuando un usuario quiere acceder a una aplicación corporativa, lo primero que ve es la página de login. Esta página no es solo un formulario que recoge usuario y contraseña; es el primer punto donde se transmite la fiabilidad de la marca, la profesionalidad de la organización y la calidad del servicio.
La mayoría de los gateways de autenticación fallan en este punto. La página de login que ofrecen o es genérica y sin marca, o solo soporta un cambio superficial de logo. Una personalización más profunda — diseño personalizado, campos personalizados, texto personalizado, idiomas personalizados — requiere un deployment de frontend aparte, un servidor web aparte o una instalación de CDN aparte.
Para los proveedores de servicios u organizaciones multi-tenant este problema se multiplica. Un proveedor que quiere dar servicio a cada cliente con su propia marca se ve obligado a mantener un deployment aparte, una configuración DNS aparte y una versión de mantenimiento aparte para cada cliente. El branding se convierte en una promesa hecha al usuario en lugar de un compromiso técnico.
Y lo que es peor; la mayoría de las soluciones no soportan la herencia de plantilla. No existe la posibilidad de definir el estilo base de la organización una vez y, para cada gateway, sobrescribir solo lo que es distinto. Cada plantilla o se escribe desde cero o se duplica con el método de copiar y pegar; esto conduce a la inconsistencia y a un mantenimiento insostenible.
La página de login es la cara visible de la infraestructura de autenticación. Tiene que ser a la vez personalizable y sostenible.
Porque cada cliente espera una página de login a su nombre — pero si cada página de login se convierte en un deployment aparte, la infraestructura se desmorona.
Herencia de plantilla, variantes por tenant y assets servidos desde el dispositivo — todo en una sola plataforma.
La plantilla base corporativa se define una vez: colores, fuentes, diseño, textos comunes. Cada gateway o tenant sobrescribe solo las partes que son distintas — un logo, un color, un texto de título. Los cambios hechos en la plantilla base se reflejan automáticamente en todas las plantillas derivadas; el coste de mantenimiento no crece de forma lineal por cada marca.
Las plantillas no son solo un cambio de color o logo. Se soportan un diseño HTML completo, CSS personalizado, imágenes personalizadas, JavaScript personalizado y campos personalizados añadidos al formulario de login. Cualquier diseño que coincida con su guía de marca — desde cero o derivado de la plantilla base — está soportado.
Cuando la misma plataforma AAM presta servicio a varios clientes, cada cliente obtiene su propia página de login con marca. La detección de tenant se hace mediante coincidencia de gateway, nombre de host o patrón de URL. Cuando un usuario llega a la puerta correcta, ve la marca correcta; sin dejar ningún rastro que apunte a la plataforma propia del proveedor de servicios.
El HTML, el CSS y las imágenes se sirven directamente desde el dispositivo AAM. No hay un servidor web aparte, un CDN aparte ni un deployment de frontend aparte. Esto aporta tanto simplicidad operativa como la ausencia de un punto adicional de dependencia externa — la página de login viene del mismo stack que ejecuta la autenticación.
Los bloques de construcción de plantillas en detalle, más el control operativo y la vía de ampliación futura.
La plantilla base de la organización define los colores, las fuentes, el diseño y los textos comunes. Cada gateway o tenant sobrescribe solo las partes que son distintas. Los cambios hechos en la plantilla base se reflejan automáticamente en todas las plantillas derivadas; sin mantenimiento de copiar y pegar por cada nueva marca.
Cada gateway AAM elige qué plantilla usará desde la interfaz de gestión. En la misma plataforma, distintos gateways pueden ejecutar distintas plantillas; un UX de login aparte para cada aplicación, cada marca o cada cliente — desde un solo dispositivo.
Cuando el mismo gateway presta servicio a varios tenants, cada tenant obtiene su propia variante de plantilla. La detección de tenant se configura mediante nombre de host, patrón de URL, componente de ruta o cabecera personalizada; la plantilla correcta se sirve al usuario correcto con el desencadenante correcto.
Las plantillas soportan HTML, CSS, JavaScript y assets de imagen completos. No solo cambio de logo y color; se soportan diseños personalizados, campos de formulario personalizados, lógica de validación personalizada, animaciones personalizadas y todo lo que requiera su guía de marca.
Además de los campos estándar de usuario/contraseña, pueden añadirse identificador de cliente, código de tenant, selector de ubicación, selector de idioma o cualquier otro campo que desee. Estos campos se conectan al flujo de autenticación; el valor recogido se transmite a los sistemas backend o al motor de política.
Cada plantilla puede soportar varios idiomas. La detección de idioma se hace mediante la preferencia del usuario, la cabecera Accept-Language o un parámetro de URL. Una sola plantilla ofrece un UX de login coherente en cada idioma; no hay obligación de duplicar una plantilla aparte por cada idioma.
El HTML, el CSS, las imágenes y los demás assets se sirven directamente desde el dispositivo AAM. No se necesita un servidor web aparte, un CDN aparte ni un deployment de frontend aparte. Se preserva la simplicidad operativa; no se añade ningún punto de dependencia externa.
Un editor visual de plantillas planeado permitirá a los equipos de branding crear y previsualizar plantillas sin escribir HTML/CSS. El control de versiones de plantillas permitirá auditar y revertir cada cambio, y servir versiones paralelas para pruebas A/B.
La mecánica que hace la gestión de plantillas escalable y sostenible.
En la configuración del gateway, qué plantilla se usará está definido como un campo. El cambio de configuración se aplica sin afectar a los usuarios en vivo; las sesiones activas continúan con la plantilla actual, las nuevas sesiones ven la plantilla actualizada.
Cuando un gateway presta servicio a varios tenants, la detección de tenant se configura mediante coincidencia de nombre de host (customer-a.portal.example.com), ruta de URL (/customer-a/login), un valor de cabecera o una cookie. Cuando se detecta el tenant correcto, se sirve la variante de plantilla correcta.
Las plantillas se cachean en el dispositivo AAM; no es necesario leer del disco en cada solicitud. Cuando se publica una actualización de plantilla, la caché se invalida automáticamente; se preserva el rendimiento, las actualizaciones se reflejan al instante.
Una plantilla se carga desde la interfaz de gestión como un solo paquete junto con el HTML, el CSS, las imágenes y los demás assets. La estructura de paquete facilita las operaciones de mantenimiento, copia de seguridad y sincronización entre varios dispositivos.
Una plantilla nueva o modificada puede probarse en una previsualización del administrador antes de servirse a los usuarios en vivo. La previsualización ejecuta exactamente la misma ruta de login real, pero se sirve solo al administrador que previsualiza. El error permanece visible solo ante los ojos del administrador.
Más allá de las plantillas individuales, está en el roadmap una definición centralizada para las variables de tema corporativas (colores, fuentes, tamaños). Cuando se actualiza una variable de tema, todas las plantillas ligadas a ella se actualizan automáticamente; el equipo de branding gestiona la apariencia de todos los gateways desde un solo punto de control.
Un MSP o proveedor SaaS presta servicio de autenticación a varios de sus clientes. Cada cliente quiere ver su propio logo, sus propios colores y sus propios textos. Una sola plataforma AAM, con la detección de tenant, ofrece a cada cliente su propia página de login con marca — sin deployments aparte.
Una organización con varias marcas (por ejemplo, una estructura de holding o un retail multimarca) quiere una página de login aparte para cada marca. La misma infraestructura base, con una variante de plantilla por marca, ofrece la experiencia de usuario propia de cada marca; la infraestructura técnica se unifica en un solo punto, la identidad de marca se separa.
Una organización internacional quiere ofrecer una página de login en su propio idioma y con su propia adaptación local para cada región. Con el soporte de i18n por plantilla, una sola plantilla funciona en varios idiomas; la detección de idioma es automática y cada usuario inicia sesión en su propio idioma.
Un partner o revendedor quiere ofrecer servicio de autenticación a sus propios clientes, pero quiere hacer invisible que debajo está la plataforma TR7. Las plantillas totalmente personalizables aportan un UX presentado por completo con la marca del partner, sin ningún rastro de TR7 en el código de la página, el logo o los textos.
Herencia de plantilla, variantes por tenant y assets servidos desde el dispositivo — todo en una sola plataforma. Le hacemos un recorrido en una instalación en vivo con su propia guía de marca.