portal认证技巧（Portal认证原理）

Portal认证通常又称Web认证，用户上网时，必须在Portal认证页面进行认证，如果未认证成功，仅可以访问特定的网络资源，认证成功后，才可以访问其他网络资源。

Portal认证具有以下优点：

• 简单方便，客户端不需要安装额外的软件，直接在Web页面上认证。
• 便于运营，可以在Portal页面上进行业务拓展，如广告推送、企业宣传等。
• 技术成熟，被广泛应用于运营商、连锁快餐、酒店、学校等网络。
• 部署位置灵活，可以在接入层或关键数据的入口作访问控制。
• 用户管理灵活，可基于用户名与VLAN/IP地址/MAC地址的组合对用户进行认证。

Portal认证系统主要包括四个基本要素：客户端、接入设备、Portal服务器与认证服务器。

图1 Portal认证系统组网图

• 客户端：安装有运行HTTP/HTTPS协议的浏览器的主机。
• 接入设备：交换机、路由器等接入设备的统称，主要有三方面的作用。

1. 在认证之前，将认证网段内用户的所有HTTP/HTTPS请求都重定向到Portal服务器。
2. 在认证过程中，与Portal服务器、认证服务器交互，完成对用户身份认证、授权与计费的功能。
3. 在认证通过后，允许用户访问被管理员授权的网络资源。

• Portal服务器：接收客户端认证请求的服务器系统，提供免费门户服务和认证界面，与接入设备交互客户端的认证信息。
• 认证服务器：与接入设备进行交互，完成对用户的认证、授权与计费。

根据网络中实施Portal认证的网络层次来分，Portal认证方式分为两种：二层认证方式和三层认证方式。

• 当客户端与接入设备之间为二层网络时，接入设备可以学习到客户端的MAC地址，则接入设备可以利用IP地址和MAC地址来识别用户，此时可配置Portal认证为二层认证方式。
• 当客户端与接入设备之间包含三层网络时，接入设备不能获取到认证客户端的MAC地址，只能以IP地址作为用户的唯一标识，此时需要将Portal认证配置为三层认证方式。

在二层认证方式下，用户上线时的报文交互流程如图2所示。

图2 Portal认证流程图

1. 在认证之前客户端与接入设备之间建立起预连接，即客户端用户在认证成功之前在接入设备上已建立用户在线表项，并且只有部分网络访问权限。
2. 客户端发起HTTP连接请求。
3. 接入设备收到HTTP连接请求报文时，如果是访问Portal服务器或免认证网络资源，则接入设备允许其通过；如果是访问其它地址，则接入设备将其URL地址重定向到Portal认证页面。
4. 客户端根据获得的URL地址向Portal服务器发起HTTP连接请求。
5. Portal服务器向客户端返回Portal认证页面。
6. 用户在Portal认证页面输入用户名和密码后，客户端向Portal服务器发起Portal认证请求。
7. （可选）Portal服务器收到Portal认证请求后，如果Portal服务器与接入设备之间采用CHAP认证，则Portal服务器向接入设备发起Portal挑战字请求报文（REQ_CHALLENGE）；如果Portal服务器与接入设备之间采用PAP认证，则接入设备直接进行第9步。
8. （可选）接入设备向Portal服务器回应Portal挑战字应答报文（ACK_CHALLENGE）。
9. Portal服务器将用户输入的用户名和密码封装在Portal认证请求报文（REQ_AUTH）中，并发送给接入设备。
10. 接入设备根据获取到的用户名和密码，向RADIUS服务器发送RADIUS认证请求（ACCESS-Request）。
11. RADIUS服务器对用户名和密码进行认证。如果认证成功，则RADIUS服务器向接入设备发送认证接受报文（ACCESS-ACCEPT）；如果认证失败，则RADIUS服务器返回认证拒绝报文（ACCESS-REJECT）。由于RADIUS协议合并了认证和授权的过程，因此认证接受报文中也包含了用户的授权信息。
12. 接入设备根据接收到的认证结果接入/拒绝用户。如果允许用户接入，则接入设备向RADIUS服务器发送计费开始请求报文（ACCOUNTING-REQUEST）。
13. RADIUS服务器返回计费开始响应报文（ACCOUNTING-RESPONSE），并开始计费，将用户加入自身在线用户列表。
14. 接入设备向Portal服务器返回Portal认证结果（ACK_AUTH），并将用户加入自身在线用户列表。
15. Portal服务器向客户端发送认证结果报文，通知客户端认证成功，并将用户加入自身在线用户列表。
16. Portal服务器向接入设备发送认证应答确认（AFF_ACK_AUTH）。

对于三层认证方式，客户端与接入设备之间没有建立预连接过程，其余报文处理流程跟二层认证完全一致。

MAC优先的Portal认证是指用户进行Portal认证成功后，在一定时间（认证服务器上配置的MAC地址有效时间）内断开网络重新连接，能够直接通过MAC认证接入，无需输入用户名密码重新进行Portal认证。具体认证流程如图3所示

图3 认证流程图

配置MAC优先Portal认证后，客户端用户首次认证时，接入设备会把客户端的MAC地址发到RADIUS服务器进行认证，但由于RADIUS服务器未查找到MAC地址信息，导致认证失败，触发客户端用户进行Portal认证。

认证成功后，RADIUS服务器会自动保存客户端的MAC地址。当客户端下线后重新尝试接入网络时，接入设备会把客户端的MAC地址发到RADIUS服务器进行认证。

• 如果客户端的MAC地址还保存在RADIUS服务器，则RADIUS服务器校验用户名和密码（用户名和密码均为MAC地址）后，直接进行授权，用户授权后即可以直接访问网络，不需要再次输入用户名密码进行认证。
• 如果客户端的MAC地址在RADIUS服务器已经过期，则RADIUS服务器会删除保存的客户端MAC地址。MAC地址认证失败之后，接入设备会向客户端用户推送Portal认证页面。客户端用户输入帐号和密码完成身份认证。

认证用于确认尝试接入网络的用户身份是否合法，而授权则用于指定身份合法的用户所能拥有的网络访问权限，即用户能够访问哪些资源。授权最基础也是最常使用的参数是ACL和UCL组，此处以RADIUS授权进行说明

ACL

用户认证成功后，认证服务器将指定ACL授权给用户，则设备会根据该ACL对用户报文进行控制。

• 如果用户报文匹配到该ACL中动作为permit的规则，则允许其通过。
• 如果用户报文匹配到该ACL中动作为deny的规则，则将其丢弃。

RADIUS服务器授权ACL方法:RADIUS服务器通过RADIUS标准属性Filter-Id将ACL ID授权给用户。为使授权的ACL生效，需要提前在设备上配置相应的ACL及规则。

用户组

用户组指具有相同角色、相同权限等属性的一组用户（终端）的集合。由于ACL资源有限，当每用户需要的授权ACL较多时，无法达到上线授权的用户数规格。通常情况下虽然用户数很大，但是用户权限的分类比较少的，所以可以使用用户组，每一组用户复用ACL，以利用有限的ACL支持较大规格的用户进行ACL授权。

用户组可以在RADIUS服务器上配置，也可以在设备端配置（需在AAA域下应用）。如果用户希望使用RADIUS服务器下发的用户组授权，需要保证RADIUS服务器上下发的用户组在设备上已经配置（不需在AAA域下应用）。RADIUS服务器下发的用户组授权优先级高于设备端配置的用户组授权，当服务器下发的用户组授权失败后，用户会采用设备端配置的用户组授权。

RADIUS服务器下发用户组授权的方式和下发ACL ID的方式一样，都是用11号标准属性Filter-Id来携带，属性值填充用户组名称。11号属性将优先被当成ACL编号处理。当设备上不存在该ACL编号的时候，则当成用户组处理。

free-rule

用户认证成功之前，为满足用户基本的网络访问需求，需要用户认证成功前就能获取部分网络访问权限。可在free-rule模板中配置free-rule规则，满足用户的认证成功前的网络访问需求。

当用户已下线，而接入设备、RADIUS服务器和Portal服务器未感知到该用户已下线时，会产生以下问题：

• RADIUS服务器仍会对该用户进行计费，造成误计费。
• 存在非法用户仿冒合法用户IP地址和MAC地址接入网络的风险。
• 占用设备用户规格，当已下线用户数量过多的情况下，可能会导致其他用户无法接入网络。

因此，接入设备要能够及时感知到用户已下线，删除该用户表项，并通知RADIUS服务器停止对该用户进行计费。

用户下线分为客户端主动下线、接入设备控制用户下线、认证服务器强制用户下线和Portal服务器强制用户下线。

客户端主动下线

由用户发起的主动下线，例如用户点击注销按钮，客户端向Portal服务器发送用户注销请求。具体下线流程如图4所示：

图4 客户端主动下线流程图

1. 客户端向Portal服务器发送用户注销请求。
2. Portal服务器向客户端发送用户注销响应，并向接入设备发送用户下线通知报文（REQ_LOGOUT）。
3. 接入设备向RADIUS服务器发送停止计费请求报文（ACCOUNTING-REQUEST），并将用户下线。同时向Portal服务器发送用户下线响应报文（ACK_LOGOUT）。Portal服务器收到用户下线响应后，将用户下线。
4. RADIUS服务器返回停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。

接入设备控制用户下线

接入设备控制用户下线有两种方式：

• 在接入设备上执行命令cut access-user强制指定用户下线。
• 在接入设备上配置用户探测功能，用于探测用户是否在线。当用户在指定的时间内无响应，则认为用户下线，删除用户表项。

以下线探测的下线流程为例，具体下线流程如图5所示，:

图5 用户下线探测流程图

1. 下线探测过程。接入设备获取到客户端IP地址，启动下线探测定时器，周期为time-length。在T时间内（T = time-length/3）收到客户端报文，接入设备认为用户在线，并且在T时刻会重置下线探测定时器。在T时间内未收到客户端报文时，接入设备每隔T时间向客户端发送ARP请求报文，如果连续两次没有收到客户端的ARP请求的应答报文或其他报文，接入设备认为用户已下线。
2. 接入设备向Portal服务器发送用户下线通知（NTF_LOGOUT），并将用户下线。同时，接入设备向RADIUS服务器发送停止计费请求报文（ACCOUNTING-REQUEST）。
3. Portal服务器向接入设备发送用户下线响应报文（AFF_ACK_LOGOUT），并将用户下线。RADIUS服务器向接入设备发送停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。

认证服务器强制用户下线

服务器强制用户下线有以下方式：

• RADIUS服务器可通过DM报文（Disconnect Message）强制用户下线。DM是指用户离线报文，即由RADIUS服务器端主动发起的强迫用户下线的报文。
• RADIUS服务器通过授权RADIUS标准属性Session-Timeout和Termination-Action。其中，Session-Timeout为用户在线时长定时器，Termination-Action属性值为0表示将用户下线。当用户在线的时长达到定时器指定的数值时，设备会将用户下线。

以RADIUS服务器通过DM报文强制用户下线为例，具体下线流程如图6所示：

图6 认证服务器强制用户下线流程图

1. RADIUS服务器向接入设备发送用户下线请求（DM Request）。
2. 接入设备向Portal服务器发送下线通知（NTF_LOGOUT），并将用户下线。同时，接入设备向RADIUS服务器发送下线响应（DM ACK）及停止计费请求报文（ACCOUNTING-REQUEST）。
3. Portal服务器向接入设备发送用户下线响应报文（AFF_ACK_LOGOUT），并将用户下线。RADIUS服务器向接入设备发送停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。

Portal服务器强制用户下线

当管理员注销用户或Portal服务器主动探测发现用户已经离线等事件发生时，Portal服务器将用户下线，并向接入设备发送下线通知。具体下线流程如图7所示。

图7 Portal服务器强制用户下线流程图

1. Portal服务器向接入设备发送用户下线通知报文（REQ_LOGOUT）。
2. 接入设备向RADIUS服务器发送停止计费请求报文（ACCOUNTING-REQUEST），并将用户下线。同时，接入设备向Portal服务器发送用户下线响应报文（ACK_LOGOUT）。
3. Portal服务器收到用户下线响应后，将用户下线。
4. RADIUS服务器返回停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。