Tenant-Isolated Portal Edge

Overview#

Deploy a fully branded, cryptographically isolated citizen or member portal for each organisation in minutes, with no shared code paths between tenants and no separate platform deployment per customer.

A regional municipality wants its own citizen portal at a custom domain. A shared-services arrangement hosts five local authorities on a single platform, and each authority needs its own brand, its own member database, and portal traffic that cannot cross into another authority's space. A national police service needs a portal for its civilian partners that is visibly distinct from the staff-facing tool. None of these customers should require a separate platform deployment, but none of them can tolerate a generic, catch-all portal either.

The Tenant-Isolated Portal Edge provides a single codebase that is published as one independent portal deployment per tenant, resolves tenant identity at the network edge before any content is rendered, injects the tenant's branding and theme into the portal shell, and forwards authenticated traffic to the platform with hard tenant identifiers attached to every request. A council gets its own portal at its own domain in minutes. A multi-tenant shared service gets true per-tenant isolation without a per-tenant codebase.

Key Features#

• One independent portal deployment per tenant: Each tenant portal is published as its own edge deployment, all sharing the same codebase. A tenant's deployment lifecycle, deploys, rollbacks, custom domains, and analytics, is fully independent of every other tenant. A deployment failure in one tenant does not affect any other.

• Edge-served static shell: The portal is built as a static export and served directly from the edge network's asset binding. This keeps the portal shell on the edge with near-zero startup latency and eliminates the need to route static requests through the platform origin at all.

• Edge host-to-tenant resolution: On a cold request, the edge worker resolves the request host header to an organisation identifier by querying the platform API. The result is cached at the edge so subsequent requests skip the origin call entirely. Warm requests resolve tenant identity in sub-millisecond time.

• API and authentication proxying with tenant headers: API traffic and authentication traffic are each proxied to the appropriate platform service. Every proxied request has tenant identity headers injected at the edge before it leaves, so downstream services can enforce per-tenant data scoping without trusting any value supplied by the client.

• Per-tenant branding and theme: The edge layer resolves each tenant's brand, logo, tagline, and colour theme on first access and serves them through the portal shell. A brand change takes effect on the next cache expiry without a redeployment.

• Strict per-tenant CORS origin allowlist: Cross-origin behaviour is handled by echoing the request origin only if it appears in the tenant's configured allowlist. The portal never combines a wildcard Access-Control-Allow-Origin with credentials, which is a common source of cross-tenant cookie leakage. All other origins receive a denial.

• Security headers on every HTML response: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are applied to every HTML response at the edge. Because headers are generated at the edge rather than relying on the origin to set them, a misconfigured origin cannot weaken the posture.

• Multi-locale routing: Portal pages live under locale-prefixed routes (for example /en/, /cy/, /ga/, /fr/) so a tenant with bilingual or multilingual obligations can present members in their preferred language. Locale is resolved from the URL path; the portal shell loads the appropriate translations at render time.

• Single-command tenant provisioning: Adding a new tenant portal is a single, automated operation against a tenant name. The build artefact is exported for the target tenant and published to its independent edge deployment. With build caching in place the end-to-end time is measured in seconds.

Use Cases#

Municipal Citizen Portal#

A city council needs a citizen portal at its own domain where residents report issues, follow cases, and complete surveys. The platform team adds the tenant configuration and assigns the custom domain. Residents land on the portal with the council's branding and connect exclusively to that council's data. No configuration change or code change is required to any other tenant.

Representative Portal for Elected Members#

A council provisions a second portal for elected members using the same codebase but a distinct tenant identity and a representative portal designation. Members authenticate through the same auth service, see their council's branding, and access the constituency casework, meeting, and motions surfaces described in the Representative Portal module.

Shared-Services Multi-Authority Deployment#

A shared-services arrangement operates a single platform deployment for multiple local authorities. Each authority has its own portal deployment, its own custom domain, its own brand, its own member database, and its own edge cache entries. A staff member in Authority A cannot see Authority B's portal through any shared URL, and the two tenants share no request path at runtime.

Bilingual or Multilingual National Service#

A national service with statutory bilingual obligations configures the portal for both official languages. Members whose preferred language is set in their profile access the portal under the appropriate locale prefix and read all navigation and interface text in that language without any redirects or separate deployments.

Regional Low-Latency Access#

A rural constituent accesses the portal from a region with high latency to the central data centre. The static portal shell is served from the edge node nearest to them. Only authenticated API calls travel to the platform origin. The page opens in the time it takes the device to render a local response, not in the time it takes to round-trip across the network.

Integration#

Platform API: The edge layer queries the platform's GraphQL API to resolve the request host to an organisation identity on a cold cache miss. All subsequent API traffic from the portal also passes through the edge proxy, which attaches verified tenant identity to every request before it reaches the platform.

Authentication service: Authentication traffic is forwarded through the portal's edge proxy to the platform authentication service. Sessions are bound to the tenant identifier inserted by the edge, not to any tenant value asserted by the client.

Representative Portal module: The elected-member workflows described in the Representative Portal module are served through the Tenant-Isolated Portal Edge. The portal shell, CORS handling, tenant resolution, and proxying are provided by this module; the member-specific pages and data views are the Representative Portal's concern.

Citizen Portal module: Citizen-facing surfaces, query submission, case tracking, survey completion, and service-specific record views, share the same deployment codebase and edge layer.

Edge key-value cache: The per-host tenant context cache lives in a dedicated edge key-value store with a time-to-live tuned to the rate at which tenant configuration changes. A forced invalidation path is available for platform administrators who need to propagate a branding change immediately.

Notifications: Outbound notifications to portal users (email, SMS, push) are generated by the platform and carry the tenant's brand identity, so the recipient sees a coherent brand across the portal and the messages that refer back to it.

GraphQL: Portal clients query the platform exclusively through the tenant-bound API proxy. The platform exposes its data model over a typed GraphQL schema. All queries and mutations are validated against the authenticated tenant identity before execution.

Open Standards#

• OAuth 2.0 and OpenID Connect (OIDC): citizen and representative authentication uses the OAuth 2.0 authorisation framework (RFC 6749) with OpenID Connect Core 1.0 for identity tokens; the Authorisation Code flow with PKCE (RFC 7636) is enforced for all interactive sign-ins.
• JSON Web Tokens (JWT): RFC 7519; session and service-to-service tokens are signed JWTs; the tenant identity claim is cryptographically bound to the issuing auth service and cannot be substituted by the client.
• FIDO2 / WebAuthn: W3C Web Authentication (WebAuthn) Level 2 and FIDO2 CTAP2; passwordless and hardware-key authentication for portal members where tenants enable it.
• TLS 1.3: RFC 8446; all portal traffic is TLS 1.3 at the edge and between the edge and platform origins.
• HTTP Strict Transport Security (HSTS): RFC 6797; Strict-Transport-Security with a year-long max-age on all production portal hosts.
• Content Security Policy Level 3: W3C CSP3; applied to every HTML response at the edge to restrict script, style, and frame sources to tenant-approved origins.
• CORS (Fetch Living Standard): WHATWG Fetch specification cross-origin resource sharing protocol; origin echo against a per-tenant allowlist with credentials never paired with a wildcard origin.
• Referrer-Policy: W3C Referrer Policy; strict-origin-when-cross-origin applied to all portal HTML responses.
• OWASP Secure Headers: X-Frame-Options and X-Content-Type-Options applied per OWASP Secure Headers Project guidance.
• WCAG 2.2 AA: W3C Web Content Accessibility Guidelines 2.2 Level AA; the portal shell meets AA across all tenant deployments. Level AAA is targeted for primary surfaces where achievable without trade-offs (for example, colour contrast ratios on brand backgrounds).
• BCP 47 language tags (RFC 5646): locale identifiers in URL paths and content metadata use BCP 47 tags (en, cy, ga, fr, and so on), ensuring interoperability with browser Accept-Language negotiation and third-party translation tooling.
• JSON-LD: W3C JSON-LD 1.1; structured tenant metadata exposed through the portal shell is serialised as JSON-LD so partner tooling can consume and link it without proprietary parsing.
• EU GDPR: tenant member data is handled under EU General Data Protection Regulation obligations; consent records and data-subject preferences are stored per tenant and surfaced through the portal's account management views.

Security and Compliance#

Every portal deployment enforces per-tenant data isolation at the network layer: the edge worker attaches verified tenant identity headers to every outbound request, and the platform rejects any API call that does not carry a valid, in-scope tenant identity. No request path allows one tenant's session to read or write data belonging to another tenant.

Security headers (CSP3, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) are generated at the edge and cannot be overridden or omitted by a misconfigured origin service. CORS policy is derived from the tenant's own configuration, not from a shared platform default. Credentials are never transmitted to cross-origin destinations that are not explicitly allowlisted by the tenant.

Passwordless authentication using FIDO2/WebAuthn is available to tenants who require phishing-resistant login for elected members or privileged citizen accounts.

Last Reviewed: 2026-04-17 / Last Updated: 2026-04-17