10.3 Authentication Portal, User-Aware Policies & AuthPoint MFA

10.3 Authentication Portal, User-Aware Policies & AuthPoint MFA

Quick Answer: When transparent Single Sign-On cannot identify an endpoint, Fireware OS provides the Firebox Authentication Portal—a secure captive web portal operating on TCP port 4100 (https://<Firebox-IP>:4100/). Unauthenticated web traffic can be automatically redirected to this portal. Authenticated sessions are governed by an Inactivity Timeout (default 20 minutes) and an absolute Session Timeout (default 8 hours). Security engineers leverage these authenticated identities to build User-Aware and Group-Aware Firewall Policies, replacing static subnets in the policy From list with Active Directory security groups. To enforce Zero Trust security, WatchGuard AuthPoint delivers cloud-managed Multi-Factor Authentication (MFA) featuring patented Mobile Device DNA (which prevents authenticator cloning), supporting mobile push notifications, time-based one-time passwords (TOTP), and offline QR code authentication for Mobile VPNs and management access.

---

The Firebox Authentication Portal (Captive Web Portal)

In environments with guest wireless networks, unmanaged Contractor/BYOD devices, Linux systems, or non-domain endpoints where Single Sign-On (SSO) cannot operate, Fireware OS provides interactive, browser-based authentication via the Firebox Authentication Portal.

+-----------------------------------------------------------------------------------------+
|                        FIREBOX CAPTIVE PORTAL REDIRECTION                               |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   1. User opens browser and requests: http://www.example.com                            |
|             │                                                                           |
|             ▼                                                                           |
|   ┌─────────────────────────────────────────────────────────────────────────────────┐   |
|   │ Firebox evaluates packet against HTTP/HTTPS Policy                              │   |
|   │ • Policy requires authentication in 'From' list (e.g., 'Finance-Dept')          │   |
|   │ • User IP (10.0.3.77) is currently UNAUTHENTICATED                             │   |
|   └────────────────────────────────────────┬────────────────────────────────────────┘   |
|                                            │                                            |
|                                            ▼                                            |
|   2. Firebox intercepts TCP connection and injects HTTP 302 Redirect:                   |
|      Location: https://10.0.3.1:4100/                                                   |
|             │                                                                           |
|             ▼                                                                           |
|   3. User browser establishes TLS handshake to Firebox on TCP Port 4100                 |
|             │                                                                           |
|             ▼                                                                           |
|   4. User presents credentials (Username, Password, Domain selection)                   |
|             │                                                                           |
|             ▼                                                                           |
|   5. Firebox authenticates user against selected backend (Firebox-DB, AD, RADIUS)       |
|             │                                                                           |
|             ▼                                                                           |
|   6. Portal displays 'Login Successful' window; user browses to requested website       |
+-----------------------------------------------------------------------------------------+

Operational Characteristics of the Authentication Portal

• Port and Protocol: Operates strictly over HTTPS on TCP port 4100 (URL structure: https://<Firebox-Interface-IP>:4100/ or using a configured FQDN such as https://firebox.corp.local:4100/).
• Automatic Redirection: When an unauthenticated client initiates an outbound web connection (HTTP on port 80 or HTTPS on port 443 with Content Inspection), and that connection matches an internal policy that requires user or group authentication, the Firebox intercepts the request and issues an HTTP redirect to the portal on port 4100.
• Authentication Domain Selection: The portal web interface presents fields for Username, Password, and a drop-down menu for Authentication Server. If the user belongs to the Default Authentication Server domain, they need not touch the drop-down menu; if they belong to a secondary domain (such as local Firebox-DB or a partner domain), they select it from the menu.
• TLS Certificate Considerations: When users connect to https://<Firebox-IP>:4100/, the Firebox serves its internal Web Server Certificate. If the default self-signed Firebox certificate is active, client browsers will display an untrusted certificate warning screen. In enterprise deployments, administrators eliminate this warning by importing a valid third-party or enterprise PKI SSL/TLS certificate into Fireware (System > Certificates) bound to the Web Server role.

---

Session Lifecycle Management: Inactivity vs. Absolute Timeouts

Once authenticated via either the captive portal or Single Sign-On, the user's active session is governed by two independent timers configured under Setup > Authentication > Authentication Settings.

+-----------------------------------------------------------------------------------------+
|                        AUTHENTICATION SESSION EXPIRATION TIMERS                         |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   Session Start (00:00)                                                                 |
|         │                                                                               |
|         ├─────────────────────────────────────────┐                                     |
|         │ Active Network Traffic Flowing          │ Client Ceases Traffic (Walks Away)  |
|         │                                         │                                     |
|         ▼                                         ▼                                     |
|   Inactivity Timer Reset to 0               Inactivity Timer Ticking...                 |
|         │                                         │                                     |
|         │                                         ├──> Reaches 20 min (Default)         |
|         │                                         │          │                          |
|         │                                         │          ▼                          |
|         │                                         │    SESSION TERMINATED               |
|         │                                         │    (Idle User Logged Out)           |
|         │                                                                               |
|         ▼                                                                               |
|   Elapsed Time Reaches 8 Hours (Default Session Limit)                                  |
|         │                                                                               |
|         ▼                                                                               |
|   ABSOLUTE SESSION EXPIRATION (Hard Disconnect)                                         |
|   • User forced to re-authenticate regardless of active data transfers                  |
+-----------------------------------------------------------------------------------------+

The Two Session Timers

1. Inactivity Timeout (Idle Limit):
   • Measures the elapsed duration during which no network packets are sent or received by the authenticated IP address.
   • Default value: 20 minutes (configurable from 1 to 1440 minutes).
   • Purpose: If an employee shuts down their laptop, disconnects from Wi-Fi, or leaves their desk without logging out, the Firebox automatically revokes their authenticated session, preventing subsequent users on that IP from inheriting unauthorized access.
2. Session Timeout (Absolute Limit):
   • Measures the total elapsed lifetime of the authentication session, regardless of how actively the user transmits data.
   • Default value: 8 hours / 480 minutes (configurable from 1 to 1440 minutes).
   • Purpose: Enforces periodic credential re-validation. Even if a user continuously streams media or runs background database syncs, when the session limit expires, Fireware tears down the session mapping and forces re-authentication, preventing permanent zombie sessions.
3. Simultaneous Logins Restriction:
   • Administrators can configure Fireware to permit or restrict concurrent logins for the same user account from multiple different IP addresses. In high-security environments, restricting simultaneous logins prevents credential sharing among users.

---

Constructing User-Aware & Group-Aware Firewall Policies

In standard Fireware policies, the From list contains IP addresses, subnets, interface aliases (e.g., Any-Trusted), or FQDN host objects. In a User-Aware Policy, these network-layer objects are replaced with, or constrained by, specific user accounts or directory security groups.

+-----------------------------------------------------------------------------------------+
|                        USER-AWARE FIREWALL POLICY EVALUATION                            |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   Incoming Packet: Source IP 10.0.1.42 ──> Destination: Internal Database (TCP 3306)    |
|                                                                                         |
|   POLICY LIST EVALUATION (Top to Bottom):                                               |
|   ┌─────────────────────────────────────────────────────────────────────────────────┐   |
|   │ Policy 1: 'DB-Admin-Access'                                                     │   |
|   │ • Service: MySQL (TCP 3306)                                                     │   |
|   │ • From: Database-Admins@ad.example.com (Active Directory Group)                  │   |
|   │ • To: 10.0.5.25 (Database Cluster)                                              │   |
|   │ • Action: ALLOW                                                                 │   |
|   └────────────────────────────────────────┬────────────────────────────────────────┘   |
|                                            │                                            |
|        ┌───────────────────────────────────┴───────────────────────────────────┐        |
|        ▼                                                                       ▼        |
|   [ Authenticated User on 10.0.1.42: ]                           [ Authenticated User: ]|
|   User: 'asmith'                                                 User: 'jdoe'           |
|   Groups: Domain Users, Database-Admins                          Groups: Marketing      |
|        │                                                                       │        |
|        ▼                                                                       ▼        |
|   MATCHES POLICY 1 ──> ALLOWED                                   NO MATCH ──> Denied or |
|                                                                  Evaluates Next Policy  |
+-----------------------------------------------------------------------------------------+

Step-by-Step Policy Construction

1. Define the Group Object in Fireware:
   • Navigate to Setup > Authentication > Users and Groups.
   • Click Add and select Group.
   • Enter the exact name of the group as it exists in the backend directory (e.g., Finance-Department). Group names are case-sensitive and must match Active Directory or RADIUS exactly.
   • Select the associated Authentication Server (e.g., ad.example.com or Firebox-DB).
2. Incorporate the Group into Policy Rules:
   • Open the target firewall policy in Policy Manager or Web UI (e.g., HTTPS-Finance-Only).
   • In the From section, delete generic aliases such as Any-Trusted or subnet blocks.
   • Click Add, select User / Group, and select Finance-Department@ad.example.com.
3. Policy Order & Precedence:
   • When Auto-Order is enabled, Fireware places user-specific and group-specific policies above broad network-layer policies (such as generic Outgoing or broad Any-Trusted to Any-External rules).
   • If a packet arrives from an unauthenticated IP, and the first matching policy requires group authentication, Fireware drops the packet (or redirects web browsers to port 4100). The packet does not fall through to lower, broader permit rules unless the administrator manually misorders policies.

---

WatchGuard AuthPoint Multi-Factor Authentication (MFA)

Passphrases alone represent the single most exploited vulnerability in enterprise cybersecurity. Phishing, credential stuffing, and keystroke logging render static passwords insufficient for securing remote access and administrative interfaces. WatchGuard AuthPoint is a comprehensive, cloud-managed Multi-Factor Authentication (MFA) solution designed to enforce Zero Trust identity validation.

+-----------------------------------------------------------------------------------------+
|                         WATCHGUARD AUTHPOINT MFA ARCHITECTURE                           |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   1. User initiates login to Mobile VPN / Web UI / Cloud SaaS                           |
|             │                                                                           |
|             ▼                                                                           |
|   2. Firebox / AuthPoint Gateway receives username & password; validates credentials    |
|             │                                                                           |
|             ▼                                                                           |
|   3. AuthPoint Cloud service triggers MFA Challenge                                     |
|             │                                                                           |
|             ├───────────────────────────┬───────────────────────────┐                   |
|             ▼                           ▼                           ▼                   |
|   [ PUSH NOTIFICATION ]         [ TIME-BASED OTP ]         [ SECURE OFFLINE QR ]        |
|   User receives push on         User opens app and         Screen displays secure       |
|   AuthPoint Mobile App;         types 6-digit TOTP         animated QR code; user scans |
|   taps 'APPROVE'                code into prompt           with phone, types response   |
|             │                           │                           │                   |
|             └───────────────────────────┼───────────────────────────┘                   |
|                                         │                                               |
|                                         ▼                                               |
|   4. Mobile Device DNA verification confirms hardware integrity                         |
|             │                                                                           |
|             ▼                                                                           |
|   5. AuthPoint Cloud authorizes transaction; Firebox establishes session                |
+-----------------------------------------------------------------------------------------+

The Three Factors & AuthPoint Authentication Methods

AuthPoint satisfies the three fundamental principles of identity authentication:

• Something you know: Traditional Active Directory or Firebox-DB password.
• Something you have: The user's enrolled physical mobile smartphone running the AuthPoint app or a third-party OATH-compliant hardware token.
• Something you are: Biometric fingerprint or facial recognition required to unlock the AuthPoint application on the mobile device.

The Three Supported Authentication Methods

1. Push Notifications: The user receives an out-of-band push alert on their iOS or Android device showing the application name, geographic location, and IP address of the login attempt. The user approves the access with a single tap.
2. Time-Based One-Time Password (TOTP): The AuthPoint app generates a dynamic 6-digit cryptographic code that changes every 30 seconds. Works completely offline when cellular service is unavailable.
3. Secure Offline QR Code Authentication: For workstations or laptops completely isolated from the internet (e.g., air-gapped SCADA environments or travelers on airplanes without Wi-Fi), the login screen displays an encrypted, animated QR code. The user opens the AuthPoint app, scans the QR code using their phone camera, and the app calculates a unique cryptographic response code to enter into the login screen.

Mobile Device DNA: Thwarting Authenticator Cloning

A catastrophic flaw in legacy software authenticator apps is token cloning: if an attacker backs up a victim's smartphone or steals the authenticator seed file, they can duplicate the software token onto a second device and generate valid OTPs.

• WatchGuard AuthPoint eliminates this threat through patented Mobile Device DNA.
• When the user provisions their AuthPoint app, the app collects unique hardware and firmware identifiers from the mobile device (such as CPU serials, hardware UUIDs, and OS build hashes) and binds the cryptographic encryption key to that specific physical device.
• If an attacker copies the seed file to an identical phone or virtual emulator, the hardware DNA does not match, the token fails to compute valid responses, and the login attempt is instantly blocked.

AuthPoint Gateway & Firebox Integration Points

The AuthPoint Gateway is a lightweight software service installed on-premises inside the corporate network. It bridges local network infrastructure with the WatchGuard Cloud AuthPoint identity service:

• RADIUS Integration: Operates as a RADIUS target for Firebox Mobile VPN with SSL, Mobile VPN with IKEv2, and Mobile VPN with L2TP. When a remote user dials into the VPN, the Firebox forwards authentication to the AuthPoint Gateway, triggering a push notification to the user's smartphone.
• Securing Administrative Management: The Firebox can be configured to require AuthPoint MFA for administrative access to the Fireware Web UI (TCP port 8080) and Command Line Interface (TCP port 4118), preventing compromised administrator passwords from yielding device control.
• SAML 2.0 Identity Provider (IdP): AuthPoint functions as a full SAML 2.0 IdP, providing Single Sign-On and multi-factor protection for enterprise cloud platforms such as Microsoft 365, Salesforce, Amazon Web Services (AWS), and Google Workspace.

---

Technical Comparison: Authentication Methods

The following table compares the operational characteristics, user experience, and deployment scope of WatchGuard authentication technologies: