- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- 關於我們
Portal技術白皮書
關鍵詞：Portal，CAMS，安全，認證
摘 要：Portal認證也叫Web認證，即通過HTTP頁麵接受用戶輸入的用戶名和密碼，對用戶進行認證。本文檔主要介紹了Portal認證的基本流程和典型組網應用。
縮略語：
縮略語 | 英文全名 | 中文解釋 |
AAA | Authentication, Authorization, Accounting | 認證/授權/計費 |
ACL | Access Control List | 訪問控製列表 |
BAS | Broad Access Server | 寬帶接入服務器 |
CAMS | Comprehensive Access Management Server | 綜合訪問管理服務器 |
HTTP | Hypertext Transfer Protocol | 超文本傳輸協議 |
RADIUS | Remote Access Dial in User Service | 遠程認證撥號用戶服務 |
目 錄
Portal在英語中是入口的意思。Portal認證通常也稱為Web認證，一般將Portal認證網站稱為門戶網站。
未認證用戶上網時，設備強製用戶登錄到特定站點，用戶可以免費訪問其中的服務。當用戶需要使用互聯網中的其它信息時，必須在門戶網站進行認證，隻有認證通過後才可以使用互聯網資源。
在傳統的組網環境中，用戶隻要能接入局域網設備，就可以訪問網絡中的設備或資源，為加強網絡資源的安全控製和運營管理，很多情況下需要對用戶的訪問進行控製。例如，在一些公共場合、小區或公司的網絡接入點，提供接入服務的供應商希望隻允許付費的合法用戶接入，所以供應商為每個用戶提供一個接入網絡的賬號和密碼。另外，一些企業會提供一些內部關鍵資源給外部用戶訪問，並且希望經過有效認證的用戶才可以訪問這些資源。
現有的802.1x和PPPoE等訪問控製方式，都需要客戶端的配合，並且隻能在接入層對用戶的訪問進行控製。
Portal認證技術則提供一種靈活的訪問控製方式，不需要安裝客戶端，就可以在接入層以及需要保護的關鍵數據入口處實施訪問控製。
與現有的802.1x、PPPoE等認證技術相比，Portal認證技術具有以下優勢：
l 不需要部署客戶端，直接使用WEB頁麵認證，使用方便；
l 可以定製“VLAN+端口+IP地址池”粒度級別的個性化認證頁麵，同時可以在Portal頁麵上開展廣告業務、服務選擇和信息發布等內容，進行業務拓展，實現IP網絡的運營；
l 關注對用戶的管理，可基於用戶名與VLAN ID/IP/MAC的捆綁識別來認證，並采用Portal server和Portal client之間，BAS和Portal client之間定期發送握手報文的方式來進行斷網檢測；
l 二次地址方式可以實現靈活的地址分配策略和計費策略，且能節省公網IP地址；
l 三層認證方式可以跨越網絡層對用戶作認證，可以在企業網絡出口或關鍵數據的入口作訪問控製。
如圖1 所示，Portal認證過程涉及到了認證客戶端（Portal client），Portal服務器（Portal server），BAS和AAA服務器四個基本要素。
圖1 Portal係統組成示意圖
l Portal client：Portal組網中發起認證請求的客戶端係統，為運行HTTP協議的瀏覽器。
l Portal server：Portal組網中接受客戶端認證請求的服務端係統，提供免費門戶服務和基於WEB認證的界麵，與BAS設備交互認證客戶端的身份信息。
l BAS：寬帶接入服務器，用於向Portal server重定向HTTP認證請求，並且與Portal server、AAA服務器交互完成用戶的認證/授權/計費功能。
l AAA服務器：認證/授權/計費服務器，與BAS進行交互，對用戶進行認證/授權/計費。
以上四個基本要素的交互過程為：
(1) 未認證用戶訪問網絡時，在IE地址欄中輸入一個互聯網的地址，那麼此HTTP請求在經過BAS設備時會被重定向到Portal server的Web認證主頁上；
(2) 用戶在認證主頁/認證對話框中輸入認證信息後提交，Portal server會將用戶的認證信息傳遞給BAS；
(3) 然後BAS與AAA服務器通信進行用戶認證和計費；
(4) 認證通過後，BAS會打開用戶與互聯網的通路，允許用戶訪問互聯網。
Portal協議包括Portal接入和Portal認證兩部分，協議框架如圖2 所示：
圖2 Portal協議框架
Portal接入協議描述了Portal client和Portal server之間的協議交互，主要內容包括：
(1) Portal client通過HTTP協議向Portal server提交認證信息。
(2) Portal server通過HTTP協議向Portal client推出認證成功或者認證失敗頁麵。
(3) Portal server與Portal client之間通過握手檢測用戶是否在線。
Portal認證協議描述了Portal server和BAS之間的協議交互，主要內容包括：
(1) Portal認證協議采用了非嚴格意義上的Client/Server結構，大部分消息采用Request/Response進行交互。同時還定義了一種Notify報文，提供Portal sever和BAS設備之間的消息通道。
(2) Portal認證協議承載在UDP報文上。
(3) Portal server使用本地的特定UDP端口監聽BAS設備發送的非響應類報文，並向BAS設備特定的端口發送所有報文。BAS使用本地的特定的UDP端口監聽Portal server發送的所有報文，並向Portal server的特定端口發送非響應類報文。響應類報文的目的端口號使用對應的請求報文的源端口號。
Portal認證有兩種認證方式：二層認證方式和三層認證方式。二層認證方式又包括直接認證方式和二次地址方式。
二次認證方式下，Portal client與BAS直連，或它們之間隻有二層設備存在。
l 直接認證方式
用戶通過手工配置或DHCP獲取的一個公網IP地址進行認證，在認證通過之前，隻能訪問Portal服務器以及設定的免費訪問地址，認證通過後可使用此IP地址訪問外部網絡。
直接認證流程簡單，但由於限製了Portal client隻能與BAS通過二層交換設備互連，降低了組網的靈活性。
l 二次地址方式
用戶通過DHCP獲取一個私網IP地址進行認證，在認證通過之前，隻能訪問Portal服務器以及設定的免費訪問地址，認證通過後，釋放原有私網IP地址，使用重新分配的公網IP地址訪問外部網絡。
二次地址方式流程較為複雜，認證通過之前用戶可使用私網IP地址，節省了公網IP地址，但組網方式不靈活。
這種認證方式允許Portal client和BAS之間跨接三層轉發設備，組網方式靈活。因為三層認證流程與直接認證方式相同，下麵將僅對直接認證方式的認證流程和二次地址方式的認證流程做詳細描述。
圖3 Portal直接認證方式認證流程圖
下麵認證流程以CHAP認證為例，對於PAP認證方式，步驟（2）、（3）、（4）可以省略。
(1) Portal client通過HTTP協議觸發認證請求。
(2) Portal sever收到認證請求後，首先向BAS設備發送Challenge請求報文，並啟動定時器等待BAS設備的響應。如果在一定時間內沒有收到BAS設備的回應報文，則重傳此報文，若到達最大重傳次數仍沒有回應，則通知Portal client認證失敗。
(3) BAS設備收到Challenge請求報文後，檢查報文的合法性，對合法的報文進行響應。
(4) Portal server收到Challenge請求報文的響應報文後，根據CHAP算法，計算CHAP-PASSWORD，然後向BAS設備發送請求認證報文，並啟動定時器等待BAS設備的響應。如果在規定的時間內沒有收到BAS設備的回應報文，Portal server會重發一定次數的認證請求報文，當達到最大重傳次數時仍沒有回應，則通知用戶認證失敗。
(5) BAS設備收到請求認證報文後，首先進行合法性檢查，對合法的報文進行認證處理，即根據認證方式（CHAP）構造RADIUS認證請求報文發給RADIUS server，然後開啟定時器等待RADIUS server的認證回應。如果在規定的時間內RADIUS server無響應，則BAS設備向RADIUS server重發一定次數的認證請求報文，當達到最大重傳次數時仍沒有回應，則認為本次認證失敗。
(6) BAS設備根據認證的結果向Portal sever發送認證請求響應報文。
(7) Portal server根據認證請求響應報文表示的認證結果（成功，失敗）通知Portal client是否認證成功。
圖4 Portal二次地址方式認證流程圖
(1) Portal client通過HTTP協議觸發認證請求。
(2) Portal sever收到認證請求後，首先向BAS設備發送Challenge請求報文，並啟動定時器等待BAS設備的響應。
(3) BAS設備收到Challenge請求報文後，檢查報文的合法性，對合法的報文進行響應。
(4) Portal sever向BAS發送請求認證報文，並啟動定時器等待BAS設備的回應。
(5) BAS設備與RADIUS server之間進行RADIUS協議報文的交互。
(6) BAS設備根據認證的結果以及定時器的信息向Portal server發送請求認證響應報文，同時在報文中增加控製信息。若認證成功，則控製信息表示要求Portal server通知Portal client釋放IP，並重新申請IP地址。
(7) Portal server向Portal client發送認證通過報文，收到該報文後，Portal client釋放原私網IP地址，並申請新的公網IP地址。
(8) BAS設備通過Portal client發送的免費ARP報文可以檢測到Portal client的IP地址的狀態，一旦檢測到Portal client的IP地址成功更換成公網IP地址，就向Portal server發送用戶IP地址更換的通知報文，並開啟定時器等待地址更新回應報文。
(9) Portal server在收到BAS的用戶IP地址更換通知，以及客戶端的IP地址更新通知後，向BAS發送確認報文，並向客戶端進行地址更新確認。如果隻收到一方的報文，Portal server認為用戶IP地址沒有更新。
(10) BAS收到的確認報文中攜帶標識地址切換是否成功的信息，若該信息表示地址切換成功，則BAS向RADIUS server發送計費請求，請求上線；如果表示地址切換失敗，則BAS會向Portal server發送報文來強製用戶下線。
Portal用戶下線流程包括兩種方式：由Portal client發起的主動下線和由Portal server或BAS發起的強製下線。
具體步驟如下：
(1) Portal用戶通過HTTP協議發起下線請求。
(2) Portal server發送請求下線報文後，開啟定時器等待BAS設備的回應，如果BAS設備在規定的時間內沒有回應，則Portal server一直重發下線請求。報文的重傳次數可以根據網絡的實際情況調整。
(3) 當BAS設備收到Portal server的下線請求後，向Portal server發送請求下線回應報文，同時向RADIUS sever發送停止計費報文。
一般來說，下線不存在成功和失敗的說法，用戶要選擇下線，肯定是要允許的，所以Portal server收到用戶的下線請求後，會通知Portal client下線成功，而不需要等待BAS設備對下線的確認。
當管理員通過命令行切斷連接，或BAS設備主動探測發現用戶已經離線，以及BAS設備接入用戶的接口被拔出、接口板被拔出等事件發生時，BAS設備需要通知Portal server強製用戶下線。具體步驟如下：
(1) BAS設備向Portal server發送用戶被強製下線的通知報文來告知Portal client已經下線。
(2) Portal server收到通知報文後，向BAS設備發送確認報文來確認，同時通知Portal client網絡連接已中斷。
由於Portal server可能會因網絡問題等原因收不到BAS的通知報文，從而無法得知用戶已下線的消息。因此BAS設備會向Portal server重複發送通知報文有限次數。若有限次數的重複過程結束之後，BAS設備仍然未收到Portal server的確認，那麼BAS設備會停止發送通知報文。雖然BAS發起的通知過程失敗了，但由於Portal server和Portal client之間存在心跳檢測機製，最終Portal server也可得知用戶已下線。
圖5 Portal二層組網方案
在用戶接入的二層BAS設備上部署Portal，可以實現對內部網絡接入的Portal認證用戶進行認證和計費。CAMS平台需要部署Portal業務組件。
圖6 Portal三層組網方案
在企業入口的BAS設備上部署Portal，可以對外部網絡中訪問企業網內部關鍵業務區域的用戶進行認證和計費，也可以對企業內部網絡中訪問Internet的用戶進行認證和計費。這種組網方式下，部署Portal的設備和用戶之間可以跨越三層交換設備。
RFC 2865：Remote Authentication Dial In User Service (RADIUS)
Copyright ©2008 杭州華三通信技術有限公司 版權所有，保留一切權利。
非經本公司書麵許可，任何單位和個人不得擅自摘抄、複製本文檔內容的部分或全部，並不得以任何形式傳播。
本文檔中的信息可能變動，恕不另行通知。
