Portal技术白皮书
Copyright © 2019 新华三技术有限公司 版权所有,保留一切权利。
非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。
除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。
本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。
Portal认证通过Web页面接受用户输入的用户名和密码,对用户进行身份认证,以达到对用户访问进行控制的目的。
在传统的组网环境中,用户只要能接入局域网设备,就可以访问网络中的设备或资源,为加强网络资源的安全控制和运营管理,很多情况下需要对用户的访问进行控制。例如,在小区或公司的网络接入点,提供接入服务的供应商希望只允许付费的合法用户接入。另外,一些企业会提供一些内部关键资源给外部用户访问,希望经过有效认证的用户才可以访问这些资源。
现有的802.1X和PPPoE等访问控制方式,都需要客户端的配合,并且只能在接入层对用户的访问进行控制。Portal认证技术则提供一种灵活的访问控制方式,不需要安装客户端,就可以在接入层以及需要保护的关键数据入口处实施访问控制。
与现有的802.1X、PPPoE等认证技术相比,Portal认证技术具有以下优势:
· 用户侧可以不安装客户端软件,直接使用Web页面认证,使用方便。
· 可以为运营商提供方便的管理功能和业务拓展功能,例如运营商可以在认证页面上开展广告、社区服务、信息发布等个性化的业务。
· 支持多种组网型态,例如二次地址分配认证方式可以实现灵活的地址分配策略且能节省公网IP地址,可跨三层认证方式可以跨网段对用户作认证。
如图1所示,Portal系统通常由如下实体组成:认证客户端、接入设备、Portal认证服务器、Portal Web服务器、AAA服务器和安全策略服务器。
图1 Portal系统组成示意图
用户终端的客户端系统,为运行HTTP/HTTPS协议的浏览器或运行Portal客户端的主机。对用户终端的安全性检测是通过认证客户端和安全策略服务器之间的信息交流完成的。目前,Portal客户端仅支持H3C iNode客户端。
提供接入服务的设备,主要有三方面的作用:
· 在认证之前,将用户的所有HTTP/HTTPS请求都重定向到Portal Web服务器。
· 在认证过程中,与Portal认证服务器、AAA服务器交互,完成身份认证/授权/计费的功能。
· 在认证通过后,允许用户访问被授权的互联网资源。
包括Portal Web服务器和Portal认证服务器。
· Portal Web服务器负责向客户端提供Web认证页面,并将客户端的认证信息(用户名、密码等)提交给Portal认证服务器。
· Portal认证服务器用于接收认证客户端认证请求的服务器端系统,与接入设备交互认证客户端的认证信息。
Portal Web服务器通常与Portal认证服务器是一体的,也可以是独立的服务器端系统。下文描述中,除非必要,否则不区分Portal Web服务器和Portal认证服务器,统称为Portal服务器。
与接入设备进行交互,完成对用户的认证、授权和计费。目前RADIUS(Remote Authentication Dial-In User Service,远程认证拨号用户服务)服务器可支持对Portal用户进行认证、授权和计费,以及LDAP(Lightweight Directory Access Protocol,轻量级目录访问协议)服务器可支持对Portal用户进行认证。
与认证客户端、接入设备进行交互,完成对用户的安全检测,并对用户进行安全授权操作。仅运行认证客户端的主机支持与安全策略服务器交互。
Portal系统中各基本要素的交互过程如下:
(1) 当未认证用户使用浏览器进行Portal认证时,可以通过浏览器访问任一互联网地址,接入设备会将此HTTP或HTTPS请求重定向到Portal Web服务器的Web认证主页上,用户也可以主动登录Portal Web服务器的Web认证主页。当未认证用户使用iNode客户端进行Portal认证时,可直接打开客户端,输入认证信息。
(2) 用户在认证主页/认证对话框中输入认证信息后提交,Portal Web服务器会将用户的认证信息传递给Portal认证服务器,由Portal认证服务器处理并转发给接入设备。
(3) 接入设备与AAA服务器交互进行用户的认证、授权和计费。
(4) 认证通过后,如果未对用户采用安全策略,则接入设备会打开用户与互联网的通路,允许用户访问互联网;如果使用iNode客户端进行认证,并对用户采用了安全策略,则客户端、接入设备与安全策略服务器交互,对用户的安全检测通过之后,安全策略服务器根据用户的安全性授权用户访问非受限资源。
Portal协议包括Portal接入和Portal认证两部分,协议框架如图2所示:
图2 Portal协议框架示意图
Portal接入协议描述了认证客户端和Portal服务器之间的协议交互过程,主要内容包括:
(1) 认证客户端通过HTTP/HTTPS协议向Portal服务器提交认证信息。
(2) Portal服务器通过HTTPHTTPS协议向认证客户端推出认证成功或者认证失败页面。
(3) Portal服务器与认证客户端之间通过握手机制检测用户是否在线。
Portal认证协议描述了Portal服务器和接入设备之间的协议交互,主要内容包括:
(1) Portal认证协议采用了非严格意义上的Client/Server结构,大部分消息采用Request/Response进行交互。同时还定义了一种Notify报文,提供Portal服务器和接入设备之间的消息通道。
(2) Portal认证协议承载在UDP报文上。
(3) Portal服务器使用本地的特定UDP端口监听接入设备发送的非响应类报文,并向接入设备特定的端口发送所有Portal报文。接入设备使用本地的特定的UDP端口监听Portal服务器发送的所有报文,并向Portal服务器的特定端口发送非响应类报文。响应类报文的目的端口号使用对应的请求报文的源端口号。
Portal支持三种认证方式:直接认证方式、二次地址分配认证方式和可跨三层认证方式。直接认证方式和二次地址分配认证方式下,认证客户端和接入设备之间没有三层转发设备;可跨三层认证方式下,认证客户端和接入设备之间可以(但不必须)跨接三层转发设备。
用户在认证前通过手工配置或DHCP直接获取一个IP地址,只能访问Portal Web服务器,以及设定的免认证地址;认证通过后即可访问网络资源。认证流程相对简单。
用户在认证前通过DHCP获取一个私网IP地址,只能访问Portal Web服务器,以及设定的免认证地址;认证通过后,用户会申请到一个公网IP地址,即可访问网络资源。该认证方式解决了IP地址规划和分配问题,对未认证通过的用户不分配公网IP地址。例如运营商对于小区宽带用户只在访问小区外部资源时才分配公网IP。目前,仅H3C iNode客户端支持该认证方式。需要注意的是,IPv6 Portal认证不支持二次地址分配方式。
和直接认证方式基本相同,但是这种认证方式允许认证用户和接入设备之间跨越三层转发设备。
对于以上三种认证方式,IP地址都是用户的唯一标识。接入设备基于用户的IP地址下发ACL对接口上通过认证的用户报文转发进行控制。由于直接认证和二次地址分配认证下的接入设备与用户之间未跨越三层转发设备,因此接口可以学习到用户的MAC地址,接入设备可以利用学习到MAC地址增强对用户报文转发的控制力度。
直接认证和可跨三层Portal认证流程相同。二次地址分配认证流程因为有两次地址分配过程,所以其认证流程和另外两种认证方式有所不同。
CHAP/PAP认证方式下,直接认证和可跨三层认证的流程,如图3所示:
图3 直接认证/可跨三层Portal认证流程图
直接认证/可跨三层Portal认证流程:
(2) Portal用户通过HTTP/HTTPS协议访问外部网络。HTTP/HTTPS报文经过接入设备时,对于访问Portal Web服务器或设定的免认证地址的HTTP/HTTPS报文,接入设备允许其通过;对于访问其它地址的HTTP/HTTPS报文,接入设备将其重定向到Portal Web服务器。Portal Web服务器提供Web页面供用户输入用户名和密码。
(3) Portal Web服务器将用户输入的信息提交给Portal认证服务器进行认证。
(4) Portal认证服务器与接入设备之间进行CHAP(Challenge Handshake Authentication Protocol,质询握手认证协议)认证交互。若采用PAP(Password Authentication Protocol,密码认证协议)认证则直接进入下一步骤。采用哪种认证交互方式由Portal认证服务器决定。
(5) Portal认证服务器将用户输入的用户名和密码组装成认证请求报文发往接入设备,同时开启定时器等待认证应答报文。
(6) 接入设备与RADIUS服务器之间进行RADIUS协议报文的交互。
(7) 接入设备向Portal认证服务器发送认证应答报文,表示认证成功或者认证失败。
(8) Portal认证服务器向客户端发送认证成功或认证失败报文,通知客户端认证成功(上线)或失败。
(9) 若认证成功,Portal认证服务器还会向接入设备发送认证应答确认。若是iNode客户端,则还需要进行以下安全扩展功能的步骤,否则Portal认证过程结束,用户上线。
(10) 客户端和安全策略服务器之间进行安全信息交互。安全策略服务器检测客户端的安全性是否合格,包括是否安装防病毒软件、是否更新病毒库、是否安装了非法软件、是否更新操作系统补丁等。
(11) 安全策略服务器根据安全检查结果授权用户访问指定的网络资源,授权信息保存到接入设备中,接入设备将使用该信息控制用户的访问。
步骤(9)、(10)为Portal认证安全扩展功能的交互过程。
CHAP/PAP认证方式下,二次地址分配认证的流程,如图4所示:
二次地址分配认证流程:
(1)~(7)同直接/可跨三层Portal认证中步骤(1)~(7)。
(8) 客户端收到认证通过报文后,通过DHCP获得新的公网IP地址,并通知Portal认证服务器用户已获得新IP地址。
(9) Portal认证服务器通知接入设备客户端获得新公网IP地址。
(10) 接入设备通过DHCP模块得知用户IP地址变化后,通告Portal认证服务器已检测到用户IP变化。
(11) 当Portal认证服务器接收到客户端以及接入设备发送的关于用户IP变化的通告后,通知客户端上线成功。
(12) Portal认证服务器向接入设备发送IP变化确认报文。
(13) 客户端和安全策略服务器之间进行安全信息交互。安全策略服务器检测客户端的安全性是否合格,包括是否安装防病毒软件、是否更新病毒库、是否安装了非法软件、是否更新操作系统补丁等。
(14) 安全策略服务器根据用户的安全性授权用户访问指定的网络资源,授权信息保存到接入设备中,接入设备将使用该信息控制用户的访问。
步骤(13)、(14)为Portal认证扩展功能的交互过程。
Portal用户下线流程包括两种方式:由认证客户端发起的主动下线和由Portal服务器或接入设备发起的强制下线。
Portal用户主动下线的步骤如下:
(1) Portal用户通过HTTP或HTTPS协议发起下线请求。
(2) Portal服务器接收到用户下线请求后,向用户接入的设备发送请求下线报文,并开启定时器等待接入设备的回应。如果接入设备在规定的时间内没有回应,则Portal服务器重发下线请求,Portal服务器上可以根据网络实际情况配置报文重传次数。
(3) 当接入设备收到Portal服务器的下线请求后,向Portal服务器发送请求下线回应报文,同时向RADIUS服务器发送计费停止请求报文。
Portal服务器收到用户的下线请求后,是否必须收到接入设备发送的请求下线回应报文,才会通知认证客户端下线成功,与Portal服务器类型有关,请以Portal服务器实际情况为准。
以下情况发生时,接入设备需要通知Portal服务器强制用户下线:
· 管理员配置portal delete-user命令强制用户下线。
· 接入设备主动探测到用户已经下线。
· 接入设备接入用户的接口被拔出、接口板被拔出等事件发生。
具体步骤如下:
(1) 接入设备向Portal服务器发送用户被强制下线的通知报文来告知认证客户端已经下线。
(2) Portal服务器收到通知报文后,向接入设备发送确认报文来确认,同时通知认证客户端网络连接已中断。
Portal服务器可能会因网络问题等原因收不到接入设备的通知报文,从而无法得知用户已下线的消息。因此,接入设备会向Portal服务器重复发送有限次数的通知报文,如果接入设备仍然未收到Portal服务器的确认,接入设备则会停止发送通知报文。虽然接入设备发起的通知过程失败,由于Portal服务器和认证客户端之间存在心跳检测机制,最终Portal服务器也能得知用户已下线。
在用户接入的二层接入设备上部署Portal,可以实现对接入内部网络的Portal认证用户进行认证和计费。
图5 Portal直接/二次地址分配认证组网方案
部署Portal的设备和用户之间跨越三层交换设备,可以实现对访问企业网内部关键业务区域的外部网络中的用户进行认证、授权和计费,也可以对企业内部网络中访问Internet的用户进行认证、授权和计费。
图6 Portal可跨三层认证组网方案
RFC 2865:Remote Authentication Dial In User Service (RADIUS)