The Technical Foundation of Operator-side Real-Name Authentication: End-to-End Link of Portal & Cloud Audit

In the past, operators had a clear role in venue real-name authentication: providing broadband access and networking solutions without undertaking real-name verification or log retention. Operators designed the networks for hotels, industrial parks and office buildings, delivered and maintained optical modems and lines. Portal authentication, real-name verification and internet access logs were always the venue’s own responsibility — they purchased hardware, deployed systems and took full charge. The division of responsibilities and engineering interfaces were well-defined: operators ensured network connectivity, while venues managed user identity and online activities.

This boundary has blurred since the issuance of Order No.176. The Measures for Cyberspace Security Supervision and Inspection by Public Security Organs, which took effect on October 1, 2026, lists public internet access service providers as regulated entities. Article 7 focuses on inspections: whether user registration data and internet access logs are legally recorded and retained. Inspections have evolved from on-site file reviews to online patrols combined with remote vulnerability scanning and penetration testing. When public security remote scans find a venue’s Wi-Fi lacking Portal authentication and traceable logs, the first question raised is always: Who built this network? Who owns and maintains the optical modems?

I. Inherent Limitations of Operator Optical Modems: Only Pipes, No Authentication or Auditing

Within the operator’s triple-play FTTH architecture, optical modems integrate voice, broadband and IPTV services. Guests or employees can connect directly to the internet via the modem’s built-in Wi-Fi. There is no Portal redirection, no real-name verification, no session logging, nor 180-day log storage. For venues with operator-built networks, these modems are operator-owned and operator-maintained — yet they were never designed to support Portal authentication or auditing.

This is not a design flaw; it stems from product positioning. Optical modems are broadband access devices dedicated to photoelectric conversion and Layer 2 forwarding. Managed via TR069, they are built for operators to remotely push WAN configurations, Wi-Fi parameters and firmware upgrades, not for venue-side user identity verification and traffic auditing. The built-in Wi-Fi has limited coverage and poor wall-penetration performance, with no centralized management APIs; each device requires standalone configuration.

Operators need an engineering solution that overlays Portal authentication and log auditing onto existing optical modem infrastructure — without replacing modems or rewiring the network.

II. Core Technical Points: From Portal Authentication to Session Logging

1. Authentication Layer: Engineering Essentials for Portal Workflow

User experience directly determines connection success rates. HTTP induced redirection is the mainstream implementation, but HTTPS sites cannot auto-jump. The fix: configure a whitelist of trusted domain names so visitors can land on the authentication page with one click. Three authentication channels must be supported:

• SMS verification via mobile number (domestic standard);
• Document scanning (passport, Mainland Travel Permit for Hong Kong, Macao and Taiwan for foreign visitors);
• One-click WeChat login (reusing existing real-name records).

Once authenticated, access permissions are issued, and a four-tuple record (account + terminal MAC + IP + online time) is generated. This four-tuple forms the foundation of all subsequent traceability.

2. Log Layer: Binding Authentication Records with Traffic Logs

The major flaw of legacy separated authentication and auditing systems is disconnected data. The engineering solution: the gateway creates a session table immediately upon successful authentication. All subsequent traffic logs are bound to the user identity via a unique Session ID.

The compliance benchmark: input a mobile phone number, and the system can pull the user’s full online activity history without manual data splicing across separate systems. A broken link means non-compliance.

III. AINOPOL Implementation Path: Cloud Portal + Cloud Audit, Plug-and-Play with Operator Optical Modems

AINOPOL’s solution solves the core contradiction for operator-hosted networks: venues already have deployed optical modems. A full hardware replacement is cost-prohibitive, and operators cannot afford to deploy a dedicated authentication gateway plus log server for every single venue.

Cloud Portal: Plug-in Authentication Layer Overlaid on Optical Modems

AINOPOL Cloud Portal connects to existing optical modems as a plug-in module, preserving all original broadband forwarding and photoelectric conversion functions. It pushes customized Portal pages, supports multi-channel verification (SMS, document scanning, WeChat login), and writes the four-tuple data into the cloud platform. The optical modem keeps doing what it was built for — data forwarding; Cloud Portal fills the missing identity verification entry.

Cloud Audit: Session-Based Log Aggregation in the Cloud, No On-Premise Servers Required

Session IDs generated during authentication bind all subsequent traffic logs in the cloud. Logs are automatically retained for no less than 180 days, covering mobile number/ID number, MAC address, IP, online time, visited URLs and uplink/downlink traffic. No local log servers are needed at each venue, nor do operators need to build independent auditing systems per site.

Search by mobile number or time frame, and the system outputs the complete online record linked to the user, eliminating cross-system data assembly.

With Order No.176 expanding compliance liability to network builders, AINOPOL’s lightweight Cloud Portal + Cloud Audit solution supplements real-name verification and session auditing without swapping out optical modems or altering cabling. It creates a closed loop between identity data and access logs to meet regulatory requirements for log retention and traceability. The cloud deployment cuts renovation and O&M costs, enabling operators to upgrade from pure broadband pipe providers to full-service enterprise networking suppliers, while helping venues solidify wireless network security.

FAQ

Q1: What modules make up the technical architecture for venue real-name authentication?
A1: Four core components: end-user Portal redirection, RADIUS AAA interaction, session-level binding between authentication records and traffic logs, and data submission to public security interfaces. The core requirement is session-level correlation between user identity and online behavior.

Q2: Can authentication and logging run on two separate devices?
A2: Technically feasible yet highly risky. Without underlying Session ID binding, traceability breaks easily, leading to failed compliance inspections. It is recommended to unify both functions within one single platform from the same vendor.

Q3: How to implement real-name authentication for foreign visitors?
A3: The authentication platform must support passport and Mainland Travel Permit scanning. Document records are bound to the corresponding session logs and retained for audit purposes.