專利名稱：基于瘦AP架構的Portal認證方法
技術領域：
本發(fā)明涉及一種Portal認證方法，具體地，涉及一種基于瘦AP架構的 Portal認證方法。
背景技術：
Portal是一種基于web的應用程序，它主要提供個性化、單點登錄、不同 來源的內(nèi)容整合以及存放信息系統(tǒng)的表示層。Portal認證通常也稱為Web認 證， 一般將Portal認證網(wǎng)站稱為門戶網(wǎng)站。
當未認證用戶上網(wǎng)時，接入設備強制用戶通過WEB方式登錄到指定站點， 用戶只能免費訪問指定站點的服務，當用戶在門戶網(wǎng)站通過認證后才可以使 用互聯(lián)網(wǎng)資源。如果用戶主動訪問已知的Portal認證網(wǎng)站，輸入用戶名和密 碼進行認證，這種開始Portal認證的方式稱作主動認證。如果用戶試圖通過 HTTP訪問指定站點以外其他站點，將被強制訪問Portal認證網(wǎng)站進行Portal 認證，這種方式稱作強制認i正。
圖1示出的是傳統(tǒng)的有線Portal認證架構網(wǎng)絡的示意圖。如圖1所示， 用戶機101-1、 101-2和101-3有線連接到接入設備100。接入設備可以是已 知的任何接入設備。接入設備100通過網(wǎng)絡與Portal服務器102和Radius服 務器連接。在傳統(tǒng)Portal認證架構中，接入設備100在邏輯上分為兩個模塊 Portal客戶端(Portal Client)和Radius客戶端(Radius Client)。其中，Portal客戶 端主要負責與Portal服務器通信，Radius客戶端主要負責與Radius服務器通 信，二者互相配合完成Portal認證。
Portal認證通常包括用戶上線流程、用戶主動下線流程和用戶異常下 線流程。圖2到圖4分別示出了 Portal認證中的用戶上線流程、用戶主動下 線流程和用戶異常下線流程。
在圖2中，用戶機(即，圖2中的客戶端)首先發(fā)起HTTP請求。此時， 駐留于接入設備中的Portal客戶端截獲到該請求，并回應客戶端HTTP重定 向指令。用戶機接收到重定向指令后，向重定向指令攜帶的網(wǎng)址發(fā)起新的訪問請求。Portal服務器接收到該請求之后返回認證頁面。用戶在該認證頁面上 填寫諸如用戶名、密碼的認證信息，并向Portal服務器提交認證。Portal服務 器接收到認證信息后，從中提取用戶名、密碼等信息并通知Portal客戶端。 Portal客戶端接收到信息后通知駐留于接入設備上的Radius客戶端發(fā)起認證。 隨后，Radius客戶端向Radius服務器(即，圖2中的AAA服務器)發(fā)起Radius 認證請求。在認證成功之后，Radius服務器通知Radius客戶端iU正成功。Radius 客戶端將此消息通知Portal客戶端。最后，Portal客戶端分別將認證成功的消 息通知用戶機和Portal服務器。通過以上操作，完成了用戶的Portal認證的 上線認證過程。
圖2中，在Portal服務器的用戶上線認證成功之后，Portal服務器會推送 給用戶認證成功頁面(見圖2的步驟12)。該頁面包含"下線"按鈕，當用 戶點擊此按鈕時，則用戶機啟動用戶主動下線認證流程，如圖3所示。
如果用戶未點擊"下線"按鈕而直接關閉瀏覽器(或關機)，或則長時間 未訪問網(wǎng)絡，則用戶機確認用戶異常下線，用戶機啟動異常下線認證流程。
圖3和圖4的流程對于本領域的技術人員來說是已知的，因此不再進行 詳細描述。
近年來，隨著無線通信技術的發(fā)展，發(fā)展了基于瘦無線接入點(AP)架構 的無線接入系統(tǒng)。瘦AP架構是相對于傳統(tǒng)的"胖AP"架構的一種無線接入 點架構。瘦AP的傳輸機制相當于有線網(wǎng)絡中的集線器，在無線局域網(wǎng)中不 停地接收和傳送數(shù)據(jù)，任何一臺裝有無線網(wǎng)卡的設備均可通過AP來分享資 源。理論上，當網(wǎng)絡中增加一個無線AP之后，即可成倍地擴展網(wǎng)絡覆蓋直 徑，還可使網(wǎng)絡中容納更多的網(wǎng)絡設備。與傳統(tǒng)的胖"AP"不同，瘦AP通 過網(wǎng)絡與接入控制設備(AC,例如，無線控制器或無線交換機)連接，由AC 控制用戶通過AP傳輸?shù)臄?shù)據(jù)，從而降低了 AP的功能復雜度。
圖5是示出在基于瘦AP架構下的現(xiàn)有無線Portal認證系統(tǒng)的網(wǎng)絡圖。 在圖5中，無線AP (以下簡稱為AP)與用戶無線連接。無線接入控制器(以 下簡稱為AC)作為接入設備其上駐留了 Portal客戶端和Radius客戶端，分別 與Portal服務器和Radius服務器連接。AP通過網(wǎng)絡與AC連接，并可將用戶 數(shù)據(jù)發(fā)送到AC并由AC將數(shù)據(jù)轉發(fā)到外部的Portal服務器和Radius服務器 以進行Portal認證。這樣，以無線AP、無線AC和連接無線AP、無線AC 的網(wǎng)絡為基礎構成了 WLAN接入系統(tǒng)。在基于瘦AP架構的WLAN下，無線Portal認證過程與圖2-圖4中示出的認證過程類似。
圖6-圖8分別示出了在無線Portal認證架構中的用戶上線認證流程、用 戶主動下線流程和用戶異常下線流程。從圖6-圖8可以看出，除了增加了 AP 連接在AC和無線用戶之間之外，其過程與圖2-圖4示出的過程基本相同。
然而，在現(xiàn)有技術的瘦AP架構的本地轉發(fā)模式下，如果業(yè)務流不經(jīng)過 AC,則現(xiàn)有技術方案無法完成Portal認證。圖9示出了瘦AP架構的本地轉 發(fā)模式。在圖9中，無線用戶STA1和STA2的數(shù)據(jù)經(jīng)由無線4妄入點API和 AP2和路由器Router-A、 Router-B或Router-C直接轉發(fā)到外部互聯(lián)網(wǎng)，而沒 有將數(shù)據(jù)通過AC,如圖9中的數(shù)據(jù)流901和902所示。由于數(shù)據(jù)沒有通過 AC,因此駐留在AC上的Portal客戶端和Radius客戶端無法接收到該數(shù)據(jù)并 對用戶進行Portal認證。
另外，在現(xiàn)有的瘦AP架構下的Portal認證方法中，駐留在AC上的Portal 客戶端需要監(jiān)聽用戶的HTTP訪問，判斷用戶狀態(tài)，如果用戶沒有經(jīng)過認證， 則Portal客戶端截獲此HTTP訪問，并作為回應使用戶進行HTTP重定向， 即，使用戶重定向到Portal服務器。如果用戶的數(shù)量較大，則Portal客戶端 必須頻繁地監(jiān)聽和截獲用戶的HTTP訪問，從而將極大地消耗AC的性能。 通常，現(xiàn)有無線Portal認證方法將消耗AC大約1/3的性能。

發(fā)明內(nèi)容
本發(fā)明的示例性實施例克服了上述的缺點。本發(fā)明的示例性實施例旨在 提出一種基于瘦無線接入點(AP)架構的本地轉發(fā)模式的Portal認證方法，該 方法允許用戶的業(yè)務流不經(jīng)過無線接入控制器(AC)而直接轉發(fā)，并且同時能 夠降低AC的性能消耗，提高AC的效率。
根據(jù)本發(fā)明的一方面，提供了一種基于瘦無線接入點AP架構的Portal 認證方法，其特征在于，Portal客戶端被劃分為駐留于AP上的第一Portal客 戶端和駐留于無線接入控制器AC上的第二 Portal客戶端，所述方法包括以 下步驟第一 Portal客戶端截獲用戶的HTTP訪問，確定是否需要對用戶進 行Portal認證；如果第一 Portal客戶端確定需要對用戶進行Portal認證，則通 知第二 Portal客戶端用戶準備發(fā)起Portal認證；第二 Portal客戶端從Portal 服務器接收用戶的用戶名和密碼，并將用戶信息通知Radius客戶端以請求 Radius客戶端發(fā)起認證；在從Radius客戶端獲得認證結果后，第二 Portal客
6戶端更新用戶認證狀態(tài)，并將認證結果通知第一 Portal客戶端和Portal服務 器；第一 Portal客戶端更新用戶認證狀態(tài)。
根據(jù)本發(fā)明的另一方面，還提供了一種基于瘦無線接入點AP架構的 Portal認證方法，其特征在于，Portal客戶端被劃分為駐留于AP的第一 Portal 客戶端和駐留于無線接入控制器AC的第二 Portal客戶端，所述方法包括以 下步驟第二 Portal客戶端從Portal服務器接收到用戶下線的通知，更新用 戶認證狀態(tài)為下線；第二 Portal客戶端請求Radius客戶端確認用戶下線成功， 并從Radius客戶端收到下線成功的通知；第二 Portal客戶端通知第一 Portal 客戶端用戶下線成功，第一 Portal客戶端更新用戶認證狀態(tài)為下線。
根據(jù)本發(fā)明的另一方面，還提供了一種基于瘦無線接入點AP架構的 Portal認證方法，其特征在于，Portal客戶端駐留于AP的第一 Portal客戶端 和駐留于無線接入控制器AC的第二 Portal客戶端，所述方法包括以下步驟 第一 Portal客戶端檢測到用戶異常下線，更新用戶認證狀態(tài)為下線；第一 Portal 客戶端通知第二 Portal客戶端用戶異常下線；第二 Portal客戶端通知Radius 客戶端用戶異常下線并從Radius客戶端接收用戶下線成功的通知；第二Portal 客戶端通知Portal服務器用戶異常下線。


通過下面結合附圖對實施例的詳細描述，本發(fā)明的上述和/或其他方面將 會變得清楚和更容易理解，其中
圖1是示出傳統(tǒng)的有線Portal認證系統(tǒng)的網(wǎng)絡的示意圖2是示出傳統(tǒng)的有線Portal認證方法的用戶上線流程的示圖3是示出傳統(tǒng)的有線Portal認證方法的用戶主動下線流程的示圖5是示出在基于瘦AP架構的現(xiàn)有Portal認證系統(tǒng)的網(wǎng)絡圖6是示出基于瘦AP架構的現(xiàn)有Portal認證方法的用戶上線流程的示
圖7是示出基于瘦AP架構的現(xiàn)有Portal認證方法的用戶主動下線流程 的示圖8是示出基于瘦AP架構的現(xiàn)有Portal認證方法的異常下線流程的示
圖；圖9示出了瘦AP架構的本地轉發(fā)模式；
圖IO是示出根據(jù)本發(fā)明的基于瘦AP架構的Portal認證系統(tǒng)的網(wǎng)絡圖11是示出#4居本發(fā)明實施例的基于瘦AP架構的Portal認證方法的用 戶上線流程的示圖12是示出根據(jù)本發(fā)明實施例的基于瘦AP架構的Portal認證方法的用 戶主動下線流程的示圖13是示出根據(jù)本發(fā)明實施例的基于瘦AP架構的Portal認證方法的異 常下線流程的示圖。
具體實施例方式
下面將參照附圖iO-圖13描述根據(jù)本發(fā)明的Portal認證方法的各種流程。 圖IO是示出根據(jù)本發(fā)明的基于瘦AP架構的Portal認證系統(tǒng)的網(wǎng)絡圖。 無線用戶通過AP接入WLAN接入系統(tǒng)，AP通過網(wǎng)絡和路由器R與AC連 接。AC通過路由R與WLAN外部的Portal服務器和Radius服務器進行通信。 與圖5示出的Portal認證系統(tǒng)不同的是，圖10中的認證系統(tǒng)的無線局域網(wǎng) WLAN可以在執(zhí)行圖9的本地轉發(fā)功能的同時進行Portal認證，即，將來自 無線用戶的業(yè)務數(shù)據(jù)通過無線AP和路由器R直接轉發(fā)到外部網(wǎng)絡而不經(jīng)過 AC，同時實現(xiàn)Portal認證。為了在本地轉發(fā)模式下執(zhí)行Portal認證，本發(fā)明 在邏輯上將Portal客戶端分為兩部分， 一部分駐留在AP上，主要負責完成用 戶的HTTP訪問重定向、用戶異常下線;險測功能(以下稱為第一 Portal客戶 端)；另一部分駐留在AC上，主要負責完成與Portal服務器、Radius服務器 的通信(以下稱為第二 Portal客戶端)。通過在AP與AC之間傳輸控制數(shù)據(jù) 使AP上的第一 Portal客戶端和第二 Portal客戶端協(xié)作完成原有的Portal客戶 端的功能，從而在本地轉發(fā)模式下也能實現(xiàn)Portal認證，并降低了 AC的性 能消誶毛。
接下來，將參照圖11-13描述根據(jù)本發(fā)明實施例的Portal認證方法的各
種流程。
圖11是示出根據(jù)本發(fā)明實施例的基于瘦AP架構的Portal認證方法的用 戶上線流程的示圖。
在步驟1101,用戶隨意訪問一個HTTP站點，此時，無線客戶端將HTTP 請求發(fā)送到與之連接的AP。接下來，在步驟1102,駐留于AP的第一 Portal客戶端截獲到用戶的HTTP訪問后，查看本地用戶狀態(tài)數(shù)據(jù)庫以確定用戶是 否已經(jīng)通過Portal認證。如果用戶已經(jīng)通過Portal認證，則放行，轉發(fā)此HTTP 訪問；如果用戶未通過Portal認證，且用戶的HTTP訪問是到已配置好的Portal 服務器，則放行，轉發(fā)此HTTP訪問；否則，如果用戶未通過Portal認證且 用戶的HTTP訪問不是到已配置好的Portal服務器，則不允許訪問網(wǎng)絡，丟 棄用戶此HTTP訪問，同時回應用戶HTTP重定向指令，4吏用戶重定向到配 置好的Portal服務器網(wǎng)址，強制用戶進行Portal認證。
接下來，在步驟1103，第一Portal客戶端通知第二客戶端Portal客戶端 此用戶準備發(fā)起Portal認證。此時，第二 Portal客戶端可設定用戶認證超時 定時器。此步驟目的是在以后的步驟中檢查Portal服務器的通知是否超時， 將在以后進行具體的描述。
在步驟1104，用戶從第一 Portal客戶端收到HTTP重定向指令后，向重 定向指令攜帶的網(wǎng)址的portal服務器發(fā)起HTTP請求。
在Portal服務器接收到用戶發(fā)起的HTTP請求之后，在步驟1105， Portal
服務器回應用戶請求的認證頁面。
在步驟1106，用戶輸入諸如用戶名、密碼的用戶信息，發(fā)起認證。 在步驟1107, Portal服務器收到用戶的認證請求后，提取出用戶信息， 并將用戶信息通知第二 Portal客戶端。此時，如果在步驟1103中設置的用戶 認證定時器超時，則第二 Portal客戶端丟棄此通知或者通知Portal服務器認 證超時。
在步驟1108，第二Portal客戶端將用戶信息(包括用戶名、密碼、用戶 MAC地址等二層信息、用戶IP地址等三層信息等)通知同樣駐留于AC中 的Radius客戶端，請求Radius客戶端發(fā)起認證。
隨后，在步驟1109， Radius客戶端向Radius服務器發(fā)起Radius認證請 求。在步驟1110， Radius服務器接收到該請求后進行Radius認證，然后向 Radius客戶端返回iU正結果。
在步驟llll， Radius客戶端通知第二 Portal客戶端認證結果，如果認證 成功，則第二Portal客戶端更新用戶認證狀態(tài)。
接下來，在步驟1112，第二 Portal客戶端通知第一 Portal客戶端認證結 果，第一Portal客戶端更新用戶認證狀態(tài)。
在步驟1113，第二 Portal客戶端通知Portal服務器認證結果。
9在步驟1114， Portal服務器通知用戶認證結果。 以上步驟中，步驟1112可以與步驟1113互換。
在步驟1103與步驟1112中，第一 Portal客戶端與第二 Portal客戶端之 間采用的通訊機制不做限定。
圖12是示出根據(jù)本發(fā)明實施例的基于瘦AP架構的Portal認證方法的用 戶主動下線流程的示圖。
首先，在步驟1201，用戶點擊頁面中的"下線"按鈕，向Portal服務器 發(fā)起主動下線請求。
在步驟1202， Portal服務器收到用戶下線請求后，通知第二 Portal客戶 端用戶請求下線。
在步驟1203,第二 Portal客戶端將用戶認證狀態(tài)更新為"下線"，并將
用戶下線消息通知給Radius客戶端。
在步驟1204, Radius客戶端通知Radius服務器用戶下線，停止計費。 在步驟1205， Radius服務器確認用戶下線后，通知Radius客戶端用戶下
線成功。
在步驟1206, Radius客戶端通知第二Portal客戶端用戶下線成功。 在步驟1207,第二 Portal客戶端通知第一 Portal客戶端用戶下線，隨后 第一 Portal客戶端將用戶認證狀態(tài)更新為下線。
在步驟1208，第二 Portal客戶端通知Portal服務器用戶下線成功。 在步驟1209, Portal服務器通知用戶下線成功。
以上步驟中，步驟1207可以與步驟1208互換順序，步驟1207可以在步 驟1202與步驟1203之間執(zhí)行，或者，步驟1207還可以在步驟1203與步驟 1204之間執(zhí)行。
根據(jù)本發(fā)明的實施例，步驟1207中的第一 Portal客戶端與第二 Portal客 戶端之間的通訊機制不做限定。具體地，如果第一 Portal客戶端與第二 Portal 客戶端是一個進程中的兩個線程，則第一 Portal客戶端和第二 Portal客戶端 可以采用函數(shù)調用的方式進行通訊，也可以采用進程間通訊方式來進行通訊。 如果第一 Portal客戶端和第二 Portal客戶端是兩個進程，則第一 Portal客戶端 與第二 Portal客戶端可以采用進程間通訊方式進行通訊，例如，共享內(nèi)存、 消息、socket等進程間通訊方式可作為第一 Portal客戶端與第二 Portal客戶端 之間的通訊方式。通訊協(xié)議可由AP廠家自行定義。圖13是示出根據(jù)本發(fā)明實施例的基于瘦AP架構的Portal認證方法的異 常下線流程的示圖。
在步驟1301，第一 Portal客戶端檢測到用戶異常下線(即，用戶關機或 關閉瀏覽器而沒有經(jīng)過主動下線流程)，更新用戶認證狀態(tài)為下線。
在步驟1302,第一Portal客戶端通知第二Portal客戶端用戶異常下線。
在步驟1303 ，第二 Portal客戶端通知同樣駐留于AC上的Radius客戶端 用戶異常下線。
在步驟1304， Radius客戶端通知Radius服務器用戶異常下線，停止計費。 在步驟1305, Radius服務器確認用戶下線，并通知Radius客戶端用戶下 線成功。
在步驟1306， Radius客戶端通知第二 Portal客戶端用戶下線成功。 最后，在步驟1307，第二 Portal客戶端通知Portal服務器用戶異常下線。 以上步驟中，步驟1307可以在步驟1302與步驟1303之間執(zhí)行。步驟 1301中，第一 Portal客戶端檢測用戶異常下線的機制可以是本領域技術人員 已知的任何檢測方法。在步驟1302中的第一 Portal客戶端與第二 Portal客戶 端之間的通訊機制不做限定。
以上參照附圖對根據(jù)本發(fā)明的Portal認證方法的流程進行了描述。根據(jù) 本發(fā)明的Portal認證方法至少可以帶來以下有益效果支持在瘦AP架構的本 地轉發(fā)模式中的Portal認證，允許用戶的業(yè)務流不經(jīng)過AC，從而將AC的性 能壓力分散到各個AP之上，降低了AC的負擔，消除了由于AC性能的瓶頸 引起的Portal認證效率的降低。
雖然已經(jīng)參照本發(fā)明的若干示例性實施例示出和描述了本發(fā)明，但是本 領域的技術人員將理解，在不脫離權利要求及其等同物限定的本發(fā)明的精神 和范圍的情況下，可以在形式和細節(jié)上做出各種改變。
權利要求
1、一種基于瘦無線接入點AP架構的Portal認證方法，其特征在于，Portal客戶端被劃分為駐留于AP上的第一Portal客戶端和駐留于無線接入控制器AC上的第二Portal客戶端，所述方法包括以下步驟(a)第一Portal客戶端截獲用戶的HTTP訪問，確定是否需要對用戶進行Portal認證；(b)如果第一Portal客戶端確定需要對用戶進行Portal認證，則通知第二Portal客戶端用戶準備發(fā)起Portal認證；(c)第二Portal客戶端從Portal服務器接收用戶的用戶名和密碼，并將用戶信息通知Radius客戶端以請求Radius客戶端發(fā)起認證；(d)在從Radius客戶端獲得認證結果后，第二Portal客戶端更新用戶認證狀態(tài)，并將認證結果通知第一Portal客戶端和Portal服務器；(e)第一Portal客戶端更新用戶認證狀態(tài)。
2、 一種基于瘦無線接入點AP架構的Portal認證方法，其特征在于，Portal 客戶端被劃分為駐留于AP的第一 Portal客戶端和駐留于無線接入控制器AC 的第二Portal客戶端，所述方法包括以下步驟(a) 第二 Portal客戶端從Portal服務器接收到用戶下線的通知，更新用戶 認證狀態(tài)為下線；(b) 第二 Portal客戶端請求Radius客戶端確認用戶下線成功，并從Radius 客戶端收到下線成功的通知；(c) 第二 Portal客戶端通知第一 Portal客戶端用戶下線成功，第一 Portal 客戶端更新用戶認證狀態(tài)為下線。
3、 如權利要求2所述的Portal認證方法，其特征在于步驟(c)和步驟(b) 的順序相反。
4、 一種基于瘦無線接入點AP架構的Portal認證方法，其特征在于，Portal 客戶端駐留于AP的第一 Portal客戶端和駐留于無線接入控制器AC的第二 Portal客戶端，所述方法包括以下步驟(a) 第一 Portal客戶端檢測到用戶異常下線，更新用戶認證狀態(tài)為下線；(b) 第一 Portal客戶端通知第二 Portal客戶端用戶異常下線；(c) 第二Portal客戶端通知Radius客戶端用戶異常下線并從Radius客戶端接收用戶下線成功的通知；(d)第二 Portal客戶端通知Portal服務器用戶異常下線。
5、 如權利要求4所述的Portal認證方法，其中，所述步驟(d)位于步驟(b) 與步驟(c)之間。
6、 一種基于痩無線接入點AP架構的Portal認i正系統(tǒng)，包括Portal客戶 端、Radius客戶端、Portal服務器和Radius服務器，其特征在于Portal客戶 端被劃分為駐留于AP上的第一 Portal客戶端和駐留于無線接入控制器AC上 的第二Portal客戶端，其中，第一 Portal客戶端用于完成用戶的HTTP訪問重定向和用戶異常下線檢 測功能，第二 Portal客戶端用于與Portal服務器和Radius服務器通信，第一 Portal客戶端與第二 Portal客戶端之間以預定的通信方式和通信協(xié)議通信以進 行協(xié)同工作。
全文摘要
提供了一種基于瘦AP架構的Portal認證方法，其特征在于，Portal客戶端被劃分為駐留于AP上的第一Portal客戶端和駐留于無線接入控制器AC上的第二Portal客戶端，其中，第一Portal客戶端負責完成用戶的HTTP訪問重定向、用戶異常下線檢測功能，第二Portal客戶端主要負責完成與Portal服務器、Radius服務器的通信。通過在AP與AC之間進行通信使AP上的第一Portal客戶端和第二Portal客戶端協(xié)作完成原有的Portal客戶端的功能，從而在本地轉發(fā)模式下也能實現(xiàn)Portal認證，并降低了AC的性能消耗。
文檔編號H04W12/00GK101631312SQ20091016708
公開日2010年1月20日 申請日期2009年8月19日 優(yōu)先權日2009年8月19日
發(fā)明者劉靖非, 范成龍 申請人:北京傲天動聯(lián)技術有限公司