A página de login é o primeiro e mais crítico contato do usuário com a sua organização
Quando um usuário deseja acessar uma aplicação corporativa, a primeira coisa que vê é a página de login. Essa página não é apenas um formulário que coleta nome de usuário e senha; é o primeiro ponto em que transmite a confiabilidade da marca, o profissionalismo da organização e a qualidade do serviço.
A maioria dos gateways de autenticação falha neste ponto. A página de login que oferecem é genérica e sem marca, ou suporta apenas uma mudança superficial de logo. Personalização mais profunda — layout personalizado, campos personalizados, texto personalizado, idiomas personalizados — exige um deployment de frontend separado, um servidor web separado ou uma instalação de CDN separada.
Para provedores de serviços ou organizações multi-tenant, esse problema se multiplica. Um provedor que deseja atender cada cliente com sua própria marca é obrigado a manter um deployment separado, uma configuração de DNS separada e uma versão de manutenção separada para cada cliente. A marca torna-se uma promessa feita ao usuário em vez de um compromisso técnico.
Pior ainda; a maioria das soluções não suporta templates compartilhados geridos de forma centralizada. Não há como definir a marca da organização uma vez e fazer com que cada gateway a referencie e altere apenas o que é diferente. Cada template é escrito do zero ou multiplicado por copiar-e-colar; isso leva a inconsistência e a manutenção insustentável.
A página de login é a face visível da infraestrutura de autenticação. Ela precisa ser ao mesmo tempo personalizável e sustentável.
Porque cada cliente espera uma página de login com seu próprio nome — mas, se cada página de login se transformar em um deployment separado, a infraestrutura entra em colapso.
Nossa abordagem
Templates compartilhados geridos de forma centralizada, variantes por tenant e assets servidos do appliance — tudo em uma única plataforma.
Templates compartilhados — defina uma vez, reutilize entre gateways
A marca corporativa é definida uma vez em um template compartilhado, gerido de forma centralizada: cores, fontes, layout, textos comuns. Cada gateway ou tenant o referencia e altera apenas as partes que são diferentes — um logo, uma cor, um texto de cabeçalho. A marca é definida uma vez e reutilizada entre gateways; o custo de manutenção não cresce linearmente para cada marca, e não há duplicação por marca.
Personalização completa — HTML, CSS, imagens, campos personalizados
Os templates não são apenas uma mudança de cor ou logo. São suportados layout HTML completo, CSS personalizado, imagens personalizadas e campos personalizados adicionados ao formulário de login. Qualquer design que corresponda ao seu guia de marca — do zero ou construído sobre o template compartilhado — é suportado.
Variantes por tenant — projetadas para provedor de serviços
Quando a mesma plataforma AAM atende a múltiplos clientes, cada cliente recebe sua própria página de login com marca. A detecção de tenant ocorre por correspondência de gateway, nome de host ou padrão de URL. Quando um usuário chega à porta correta, vê a marca correta; sem deixar um rastro que aponte para a própria plataforma do provedor de serviços.
Servido do appliance — sem servidor web ou CDN separado
HTML, CSS e imagens são servidos diretamente do appliance AAM. Não há servidor web separado, CDN separado ou deployment de frontend separado. Isso garante tanto a simplicidade operacional quanto a ausência de um ponto adicional de dependência externa — a página de login vem do mesmo stack que executa a autenticação.
Capacidades
Os blocos de construção de template em detalhe, mais o controle operacional e o caminho de expansão futura.
Templates compartilhados — marca DRY
O template compartilhado da organização, gerido de forma centralizada, define as cores, as fontes, o layout e os textos comuns. Cada gateway ou tenant o referencia e altera apenas as partes que são diferentes. A marca é definida uma vez e reutilizada entre gateways; sem manutenção por copiar-e-colar para cada nova marca.
Atribuição de template por gateway
Cada gateway AAM escolhe pela interface de gestão qual template usará. Na mesma plataforma, diferentes gateways podem executar templates diferentes; um UX de login separado para cada aplicação, cada marca ou cada cliente — a partir de um único appliance.
Suporte multi-tenant — variante de template por tenant
Quando o mesmo gateway atende a múltiplos tenants, cada tenant recebe sua própria variante de template. A detecção de tenant é configurada por nome de host, padrão de URL, componente de caminho ou header personalizado; o template correto é servido ao usuário correto com o disparador correto.
Controle completo de HTML, CSS e imagens
Os templates suportam HTML, CSS e assets de imagem completos. Não apenas mudança de logo e cor; são suportados layouts personalizados, campos de formulário personalizados e tudo o que o seu guia de marca exigir.
Personalização de campos de formulário — adicionar campos personalizados ao fluxo de login
Além dos campos padrão de nome de usuário/senha; podem ser adicionados ID de cliente, código de tenant, seletor de localização, seletor de idioma ou qualquer outro campo que você quiser. Esses campos vinculam-se ao fluxo de autenticação; o valor coletado é encaminhado aos sistemas de backend ou ao motor de política.
Múltiplos idiomas — i18n por template
Cada template pode suportar múltiplos idiomas. A detecção de idioma é feita por preferência do usuário, header Accept-Language ou parâmetro de URL. Um único template oferece um UX de login consistente em todos os idiomas; não há obrigatoriedade de multiplicar um template separado para cada idioma.
Assets servidos do appliance — sem infraestrutura separada
HTML, CSS, imagens e outros assets são servidos diretamente do appliance AAM. Não é necessário um servidor web separado, um CDN separado ou um deployment de frontend separado. A simplicidade operacional é preservada; nenhum ponto de dependência externa é adicionado.
Profundidade operacional
A mecânica que torna a gestão de templates escalável e sustentável.
A atribuição de template é parte da configuração do gateway
Na configuração do gateway, qual template será usado é definido como um campo. A mudança de configuração é aplicada sem afetar os usuários ao vivo; as sessões ativas continuam com o template atual, as novas sessões veem o template atualizado.
A detecção de tenant funciona com disparadores configuráveis
Quando um gateway atende a múltiplos tenants, a detecção de tenant é configurada por correspondência de nome de host (customer-a.portal.example.com), caminho de URL (/customer-a/login), um valor de header ou um cookie. Quando o tenant correto é detectado, a variante de template correta é servida.
Cache de template — sem atrito ao custo de desempenho
Os templates são armazenados em cache no appliance AAM; não é necessária leitura de disco a cada requisição. Quando uma atualização de template é publicada, o cache é invalidado automaticamente; o desempenho é preservado e as atualizações refletem-se instantaneamente.
Templates e assets geridos pela interface de administração
Um template e os seus recursos — HTML, CSS, imagens e outros arquivos — são geridos pela interface de administração. Isso facilita a manutenção e o backup, e os templates são sincronizados entre múltiplos appliances para que cada node sirva a mesma marca.
Atribuição de template por gateway — sem servidor web separado
Cada gateway é vinculado ao seu template por configuração. Uma alteração nessa atribuição tem efeito sem subir ou reimplementar um servidor web separado; o gateway simplesmente referencia o template atualizado e o serve diretamente.
Em quais cenários é usado
Provedor de serviços — login com marca por tenant
Um MSP ou provedor SaaS oferece serviço de autenticação a múltiplos clientes. Cada cliente quer ver seu próprio logo, suas próprias cores e seus próprios textos. Uma única plataforma AAM, com detecção de tenant, oferece a cada cliente sua própria página de login com marca — sem deployments separados.
Organização multimarca — uma porta separada para cada marca
Uma organização com múltiplas marcas (por exemplo, uma estrutura de holding ou varejo multimarca) deseja uma página de login separada para cada marca. A mesma infraestrutura base, com uma variante de template por marca, oferece a experiência do usuário própria de cada marca; a infraestrutura técnica converge em um único ponto, a identidade de marca é separada.
Múltiplos idiomas e adaptação regional
Uma organização internacional deseja oferecer uma página de login para cada região em seu próprio idioma e com sua própria adaptação local. Com o suporte a i18n por template, um único template funciona em múltiplos idiomas; a detecção de idioma é automática e cada usuário faz login em seu próprio idioma.
Solução white-label — login oferecido sob o nome da própria organização
Um parceiro ou revendedor deseja oferecer serviço de autenticação aos seus próprios clientes, mas tornar invisível que por baixo há a plataforma TR7. Templates totalmente personalizáveis proporcionam um UX oferecido inteiramente com a marca do parceiro, sem rastro do TR7 no código-fonte da página, no logo ou nos textos.
Perguntas frequentes
Quão personalizável é o template? Apenas logo e cor?
Como funcionam os templates compartilhados?
No cenário de provedor de serviços é necessário um deployment separado para cada cliente?
É necessário um servidor web ou CDN separado para servir HTML, CSS e imagens?
Quando atualizo o template, os usuários ao vivo são afetados?
A página de login é a primeira impressão da sua marca — assuma-a
Templates compartilhados geridos de forma centralizada, variantes por tenant e assets servidos do appliance — tudo em uma única plataforma. Vamos guiá-lo por uma configuração ao vivo com o seu próprio guia de marca.