What the System Writes After Authentication: Generation of the 4-Tuple and Session ID

Since the adoption of Ministry of Public Security Order No.176, many venue operators have discovered a hidden compliance pitfall. The Portal page pops up normally and guests connect successfully, yet inspectors cannot pull up a user’s full internet history when searching by mobile number.

The root cause is not missing authentication, but what data the system writes the moment verification succeeds.
For guests, clicking “Agree & Authenticate” means internet access is granted. For the system, this is only the start of a data record. The data written right after authentication determines whether internet activity can be traced back to a specific person. This step is often dismissed as a minor implementation detail, yet most traceability failures occur here.

Two Core Data Sets Written Upon Successful Authentication

1. Authentication records: Who the user is, which verification channel was used, the timestamp, and the terminal device used. This answers the question: Is this the real person?
2. Session identifier: A unique serial number tied to this online session for correlating all subsequent traffic logs. This answers the question: Which traffic belongs to this user?

Neither record can be omitted. Without both, the access logs become untraceable raw data with no associated user identity.

The most common engineering mistake: only saving authentication records. You have complete login logs and full traffic logs, yet the two datasets cannot be matched. The result: you can view access records, but not identify the user behind them.

4-Tuple: Binding User, Terminal, IP and Time Together

The 4-tuple written after authentication binds four critical attributes of a single internet session:
Account ID (mobile number / ID number), terminal MAC address, terminal IP address, login timestamp.

Only when all four items are grouped together can the system confirm: Who used which device, at what time, from which IP address to go online.

Why store them as a single group instead of four separate records?
IP addresses change dynamically, MAC addresses can be modified, and multiple users may go online at overlapping times. In hotel environments, an IP address is immediately reassigned to the next guest after checkout. If you rely solely on IP for correlation, two different guests’ logs will be mixed together.

The 4-tuple locks the network occupancy strictly within a fixed time window. The exact fields follow the interface specification of the integrated version, but traceability breaks if any one of the four items is missing.

Session ID: The Link Between Authentication Records and Traffic Logs

Cloud Audit correlates Session ID with access logs entirely on the cloud.
Key point: no local log server is deployed on-site. All traffic logs are uploaded to the cloud and matched against authentication records via Session ID.

Three items to verify during integration:

1. Whether the Session ID is generated on the authentication side or the log collection side;
2. Whether the same Session ID is reused when the user reconnects Wi-Fi or stays online across midnight;
3. How long the correlation between authentication records and traffic logs is retained after the session ends.

The third point is frequently overlooked. If authentication records are retained but the correlation relationship expires, the log data becomes useless for traceability.

What Happens When Writing Fails: Authentication Succeeds but Data Is Not Saved

This is a hidden fault with zero impact on user experience: guests browse the internet normally, yet the backend fails to persist session data.

Three typical root causes:

1. Traffic forwarding is executed before database writing; process crashes mid-way lead to lost records.
2. High concurrent check-ins overload the write queue, causing delayed data persistence.
3. The terminal disconnects before the write operation completes.

Troubleshooting suggestion: Compare the hourly count of successful authentications against the number of sessions successfully written to the database. Abnormal deviations indicate data loss. Do not wait until an inspection to discover log gaps.

Deployment Split by Scenarios

Carrier-managed Networks

Data writing is handled by the Cloud Portal plug-in.
The plug-in connects to existing ONTs without modifying the original broadband forwarding functions. It delivers Portal pages, runs multi-channel verification (SMS, ID documents including passports & Mainland Travel Permits for HK/Mac/TW residents, and WeChat login), and writes the 4-tuple data. All records and correlations are stored on the cloud; no extra log storage hardware is needed on the premises.

Self-built Networks

The same capability runs on the Dream Gateway under AINOPOL’s Integrated Access & Security Solution. Authentication, local log retention and security protection are consolidated on a single device.

The only difference between the two scenarios is the deployment carrier; the data structure remains identical, so the same field checklist can be used for cross-scenario troubleshooting.

Four Acceptance Checkpoints Before Delivery

1. List all four fields of the 4-tuple explicitly in the interface document, without vague phrasing such as “and other fields”.
2. Document the Session ID generator, reuse rules and correlation retention period in the technical agreement.
3. Test the hourly comparison between successful authentications and persisted sessions during acceptance.
4. Configure separate alarms for authentication failures and write failures, instead of merging them into a generic “authentication error” alert.

FAQ

Q1: What key data is written after Portal authentication?
A1: A 4-tuple consisting of account ID (mobile number/ID number), terminal MAC, terminal IP and login time, plus a Session ID for log correlation. Exact fields shall follow the official interface specification.

Q2: How are authentication records matched with traffic logs?
A2: Correlation is achieved on the cloud via Session ID. Traffic logs are aggregated remotely and aligned with authentication data without local log servers on-site.

Q3: Will historical session data be lost after replacing the ONT or terminal device?
A3: Cloud-stored logs remain intact and are managed centrally. Device replacement does not require log migration. New authentication and data writing will still be executed by the Cloud Portal plug-in per policy.