The login page is the user's first and most critical contact with your organization
When a user wants to reach a corporate application, the first thing they see is the login page. That page is not just a form that collects a username and password; it is the first point where the trustworthiness of the brand, the professionalism of the organization and the quality of the service are conveyed.
Most authentication gateways fail right here. The login page they provide is either generic and unbranded, or it supports only a superficial logo swap. Deeper customization — custom layout, custom fields, custom copy, custom languages — requires a separate front-end deployment, a separate web server or a separate CDN setup.
For service providers or multi-tenant organizations, this problem multiplies. A provider that wants to serve every customer under that customer's own brand ends up carrying a separate deployment, a separate DNS configuration and a separate maintenance release for each one. Branding becomes a promise made to the user rather than a technical guarantee.
Worse still, most solutions do not support centrally-managed shared templates. There is no way to define the organization's branding once and have each gateway reference it and change only what differs. Every template is either written from scratch or duplicated by copy-and-paste; that leads to inconsistency and unsustainable maintenance.
The login page is the visible face of the authentication infrastructure. It has to be both brandable and sustainable.
Because every customer expects a login page in their own name — yet if every login page turns into a separate deployment, the infrastructure collapses.
Our approach
Centrally-managed shared templates, per-tenant variants and appliance-served assets — all on a single platform.
Shared templates — define once, reuse across gateways
The corporate branding is defined once in a centrally-managed shared template: colors, fonts, layout, shared copy. Each gateway or tenant references it and changes only the parts that differ — a logo, a color, a heading. Branding is defined once and reused across gateways; maintenance cost does not grow linearly with each new brand, and there is no per-brand duplication.
Full customization — HTML, CSS, images, custom fields
Templates are not just a color or logo swap. Full HTML layout, custom CSS, custom images and custom fields added to the login form are all supported. Any design that matches your brand guidelines — from scratch or built on the shared template — is supported.
Per-tenant variants — built for service providers
When the same AAM platform serves multiple customers, each customer gets their own branded login page. Tenant detection happens via gateway mapping, hostname or URL pattern. When a user arrives at the right door, they see the right brand — without any trace pointing back to the service provider's own platform.
Served from the appliance — no separate web server or CDN
HTML, CSS and images are delivered directly from the AAM appliance. There is no separate web server, no separate CDN and no separate front-end deployment. This brings both operational simplicity and the absence of an extra external dependency — the login page comes from the same stack that runs authentication.
Capabilities
The template building blocks in detail, plus operational control and the future extension path.
Shared templates — DRY branding
The organization's centrally-managed shared template defines colors, fonts, layout and shared copy. Each gateway or tenant references it and changes only the parts that differ. Branding is defined once and reused across gateways; no copy-and-paste maintenance for each new brand.
Per-gateway template assignment
Each AAM gateway chooses which template it uses from the management interface. On the same platform, different gateways can run different templates; a separate login UX for every application, every brand or every customer — from a single appliance.
Multi-tenant support — a template variant per tenant
When the same gateway serves multiple tenants, each tenant gets its own template variant. Tenant detection is configured via hostname, URL pattern, path component or custom header; the right template is delivered to the right user with the right trigger.
Full HTML, CSS and image control
Templates support full HTML, CSS and image assets. Not just a logo and color change; custom layouts, custom form fields and anything your brand guidelines require are supported.
Form-field customization — add custom fields to the login flow
In addition to the standard username and password fields, a customer ID, tenant code, location selector, language selector or any other field you want can be added. These fields are bound to the authentication flow; the captured value is passed on to backend systems or the policy engine.
Multi-language — i18n per template
Each template can support multiple languages. Language detection happens via user preference, the Accept-Language header or a URL parameter. A single template delivers a consistent login UX in every language; there is no need to duplicate a separate template for each language.
Appliance-served assets — no separate infrastructure
HTML, CSS, images and other assets are served directly from the AAM appliance. No separate web server, CDN or front-end deployment is required. Operational simplicity is preserved; no external dependency point is added.
Operational depth
The mechanics that make template management scalable and sustainable.
Template assignment is part of the gateway configuration
Which template is used is defined as a field in the gateway configuration. The configuration change is applied without affecting live users; active sessions continue with the current template, while new sessions see the updated template.
Tenant detection works with configurable triggers
When a gateway serves multiple tenants, tenant detection is configured via hostname matching (customer-a.portal.example.com), URL path (/customer-a/login), a header value or a cookie. When the right tenant is detected, the right template variant is served.
Template caching — no friction at the cost of performance
Templates are cached on the AAM appliance; no disk read is required for each request. When a template update is published, the cache is invalidated automatically; performance is preserved and updates take effect immediately.
Templates and assets managed through the administration interface
A template and its assets — HTML, CSS, images and other files — are managed through the administration interface. This simplifies maintenance and backup, and templates are synchronized across multiple appliances so every node serves the same branding.
Per-gateway template assignment — no separate web server
Each gateway is bound to its template via configuration. A change to that assignment takes effect without standing up or redeploying a separate web server; the gateway simply references the updated template and serves it directly.
Where it is used
Service provider — branded login per tenant
An MSP or SaaS provider delivers authentication services to multiple customers. Each customer wants to see their own logo, their own colors and their own copy. A single AAM platform gives each customer their own branded login page through tenant detection — without separate deployments.
Multi-brand organization — a separate gateway for each brand
An organization with multiple brands (a holding structure or multi-brand retail, for example) wants a separate login page for each brand. The same base infrastructure, with a template variant per brand, gives each brand its own user experience; the technical infrastructure converges at one point while brand identity stays separate.
Multi-language and regional adaptation
An international organization wants to offer each region a login page in its own language and with its own local adaptation. With per-template i18n support, a single template works in multiple languages; language detection is automatic, and every user logs in in their own language.
White-label solution — login under the organization's own name
A partner or reseller wants to offer authentication services to their own customers while keeping the underlying TR7 platform invisible. Fully customizable templates deliver a UX that carries no trace of TR7 in the page source, the logo or the copy, and is served entirely under the partner's brand.
Frequently asked questions
How far can the template be customized? Just logo and color?
How do shared templates work?
In a service-provider scenario, is a separate deployment required for each customer?
Is a separate web server or CDN required to serve HTML, CSS and images?
Are live users affected when I update the template?
The login page is your brand's first impression — own it
Centrally-managed shared templates, per-tenant variants and appliance-served assets — all on a single platform. We'll walk you through a live setup with your own brand guidelines.