web認(rèn)證流程及常見問題分析

web認(rèn)證流程及常見問題分析2010.12.16junkyGOWhat’sWEB認(rèn)證認(rèn)證技術(shù)是AAA〔認(rèn)證，授權(quán)，計費(fèi)〕的初始步驟，AAA一般包括用戶終端、AAAClient、AAAServer和計費(fèi)軟件四個環(huán)節(jié)。用戶終端與AAAClient之間的通信方式通常稱為認(rèn)證方式。目前的主要技術(shù)有以下三種：PPPoE、Web＋Portal、IEEE802.1x。三種方式的技術(shù)優(yōu)缺點(diǎn)PPPoE 優(yōu)點(diǎn)：是傳統(tǒng)PSTN窄帶撥號接入技術(shù)在以太網(wǎng)接入技術(shù)的延伸和原有窄帶網(wǎng)絡(luò)用戶接入認(rèn)證體系一致最終用戶相比照較容易接收 缺點(diǎn)：PPP協(xié)議和Ethernet技術(shù)本質(zhì)上存在差異，PPP協(xié)議需要被再次封裝到以太幀中，所以封裝效率很低PPPoE在發(fā)現(xiàn)階段會產(chǎn)生大量的播送流量，對網(wǎng)絡(luò)性能產(chǎn)生很大的影響組播業(yè)務(wù)開展困難，而視頻業(yè)務(wù)大局部是基于組播的需要運(yùn)營商提供客戶終端軟件，維護(hù)工作量過大PPPoE認(rèn)證一般需要外置BAS，認(rèn)證完成后，業(yè)務(wù)數(shù)據(jù)流也必須經(jīng)過BAS設(shè)備，容易造成單點(diǎn)瓶頸和故障，而且該設(shè)備通常非常昂貴WEB+Portal 優(yōu)點(diǎn)：不需要特殊的客戶端軟件，降低網(wǎng)絡(luò)維護(hù)工作量可以提供Portal等業(yè)務(wù)認(rèn)證 缺點(diǎn)：WEB承載在7層協(xié)議上，對于設(shè)備的要求較高，建網(wǎng)本錢高用戶連接性差，不容易檢測用戶離線，基于時間的計費(fèi)較難實(shí)現(xiàn)易用性不夠好，用戶在訪問網(wǎng)絡(luò)前，不管是TELNET、FTP還是其它業(yè)務(wù)，必須使用瀏覽器進(jìn)行WEB認(rèn)證IP地址的分配在用戶認(rèn)證前，如果用戶不是上網(wǎng)用戶，那么會造成地址的浪費(fèi)，而且不便于多ISP的支持8021X優(yōu)點(diǎn)：802.1x協(xié)議為二層協(xié)議，不需要到達(dá)三層，而且接入層交換機(jī)無需支持802.1q的VLAN，對設(shè)備的整體性能要求不高，可以有效降低建網(wǎng)本錢通過組播實(shí)現(xiàn)，解決其他認(rèn)證協(xié)議播送問題，對組播業(yè)務(wù)的支持性好。業(yè)務(wù)報文直接承載在正常的二層報文上；用戶通過認(rèn)證后，業(yè)務(wù)流和認(rèn)證流實(shí)現(xiàn)別離，對后續(xù)的數(shù)據(jù)包處理沒有特殊要求缺點(diǎn)：需要特定客戶端軟件網(wǎng)絡(luò)現(xiàn)有樓道交換機(jī)的問題：由于802.1x是比較新的二層協(xié)議，要求樓道交換機(jī)支持認(rèn)證報文透傳或完成認(rèn)證過程，因此在全面采用該協(xié)議的過程中，存在對已經(jīng)在網(wǎng)上的用戶交換機(jī)的升級處理問題IP地址分配和網(wǎng)絡(luò)平安問題：802.1x協(xié)議是一個2層協(xié)議，只負(fù)責(zé)完成對用戶端口的認(rèn)證控制，對于完成端口認(rèn)證后，用戶進(jìn)入三層IP網(wǎng)絡(luò)后，需要繼續(xù)解決用戶IP地址分配、三層網(wǎng)絡(luò)平安等問題，因此，單靠以太網(wǎng)交換機(jī)＋802.1x，無法全面解決城域網(wǎng)以太接入的可運(yùn)營、可管理以及接入平安性等方面的問題計費(fèi)問題：802.1x協(xié)議可以根據(jù)用戶完成認(rèn)證和離線間的時間進(jìn)行時長計費(fèi)，不能對流量進(jìn)行統(tǒng)計，因此無法開展基于流量的計費(fèi)或滿足用戶永遠(yuǎn)在線的要求綜合比較GOWEB+Portal認(rèn)證流程WEB認(rèn)證流程用戶開始局部流程描述用戶無線成功鏈接瘦AP用戶DHCP獲取IP地址，地址一般由AC分配用戶HTTP請求上網(wǎng)，AC推送PortalURL，攜帶ssid、userip、ACname等信息PortalServer返回請求頁面與PortalServer交互流程流程描述

與Portal交互流程，有CHAP和PAP兩種用戶上線CHAP認(rèn)證流程用戶訪問網(wǎng)站，經(jīng)過AC重定向到PortalServer，PortalServer推送認(rèn)證頁面用戶填入用戶名、密碼，提交頁面，向PortalServer發(fā)起連接請求PortalServer向AC請求ChallengeAC分配Challenge給PortalServer

PortalServer向AC發(fā)起認(rèn)證請求而后AC進(jìn)行RADIUS認(rèn)證，獲得RADIUS認(rèn)證結(jié)果AC向PortalServer送認(rèn)證結(jié)果PortalServer將認(rèn)證結(jié)果填入頁面，和門戶網(wǎng)站一起推送給客戶PortalServer回應(yīng)確認(rèn)收到認(rèn)證結(jié)果的報文用戶上線PAP認(rèn)證流程用戶訪問網(wǎng)站，經(jīng)過AC重定向到PortalServer，PortalServer推送認(rèn)證頁面用戶填入用戶名、密碼，提交頁面，向PortalServer發(fā)起連接請求PortalServer向AC發(fā)起認(rèn)證請求而后AC進(jìn)行RADIUS認(rèn)證，獲得RADIUS認(rèn)證結(jié)果AC向PortalServer送認(rèn)證結(jié)果PortalServer將認(rèn)證結(jié)果填入頁面，和門戶網(wǎng)站一起推送給客戶PortalServer回應(yīng)確認(rèn)收到認(rèn)證結(jié)果的報文與RadiusServer交互流程流程描述與Portal效勞器認(rèn)證流程成功結(jié)束后由Portal效勞器發(fā)起認(rèn)證請求AC接收到認(rèn)證請求報文后向Radius效勞器發(fā)送認(rèn)證請求報文Radius效勞器返回認(rèn)證響應(yīng)AC返回認(rèn)證結(jié)果給Portal效勞器?！惨约跋嚓P(guān)業(yè)務(wù)屬性〕Portal效勞器根據(jù)認(rèn)證結(jié)果，推送認(rèn)證結(jié)果頁面Portal效勞器回應(yīng)AC收到認(rèn)證結(jié)果報文。如果認(rèn)證失敗，那么流程到此結(jié)束。認(rèn)證如果成功，AC發(fā)起計費(fèi)開始請求給RADIUS用戶認(rèn)證效勞器RADIUS回應(yīng)計費(fèi)開始響應(yīng)報文，并將響應(yīng)信息返回給AC。用戶上線完畢，開始上網(wǎng)在用戶上網(wǎng)過程中，為了保護(hù)用戶計費(fèi)信息，每隔一段時間AC就向RADIUS用戶認(rèn)證效勞器報一個實(shí)時計費(fèi)信息，包括當(dāng)前用戶上網(wǎng)總時長，以及用戶總流量信息RADIUS計費(fèi)效勞器回應(yīng)實(shí)時計費(fèi)確認(rèn)報文給AC當(dāng)AC收到下線請求時，向RADIUS用戶認(rèn)證效勞器發(fā)計費(fèi)結(jié)束報文RADIUS計費(fèi)效勞器回應(yīng)AC的計費(fèi)結(jié)束報文正常下線流程流程描述當(dāng)用戶需要下線時，可以點(diǎn)擊認(rèn)證結(jié)果頁面上的下線機(jī)制，向Portal效勞器發(fā)起 一個下線請求Portal效勞器向AC發(fā)起下線請求AC返回下線結(jié)果給Portal效勞器Portal效勞器根據(jù)下線結(jié)果，推送含有對應(yīng)的信息的頁面給用戶當(dāng)AC收到下線請求時，向RADIUS用戶認(rèn)證效勞器發(fā)計費(fèi)結(jié)束報文RADIUS用戶認(rèn)證效勞器回應(yīng)AC的計費(fèi)結(jié)束報文異常下線流程流程描述AC偵測到用戶下線，向Portal效勞器發(fā)出下線請求Portal效勞器回應(yīng)下線成功當(dāng)AC收到下線請求時，向中央RADIUS計費(fèi)效勞器發(fā)計費(fèi)結(jié)束報文中央RADIUS計費(fèi)效勞器回應(yīng)AC的計費(fèi)結(jié)束報文用戶強(qiáng)制下線流程流程描述AC偵測到用戶的本次連接最大允許接入時間結(jié)束，向Portal效勞器發(fā)出下線請求Portal效勞器回應(yīng)下線成功,并向用戶推送下線結(jié)果頁面當(dāng)AC收到下線請求時，向中央RADIUS計費(fèi)效勞器發(fā)計費(fèi)結(jié)束報文中央RADIUS計費(fèi)效勞器回應(yīng)AC的計費(fèi)結(jié)束報文DM消息強(qiáng)制下線流程流程描述Radius向AC下發(fā)Disconnect-Request消息AC向Portal效勞器發(fā)出下線請求Portal效勞器回應(yīng)下線成功,并向用戶推送下線結(jié)果頁面AC向Radius回應(yīng)Disconnect-ACK下線成功AC向中央RADIUS計費(fèi)效勞器發(fā)計費(fèi)結(jié)束報文中央RADIUS計費(fèi)效勞器回應(yīng)AC的計費(fèi)結(jié)束報文如AC踢用戶下線失敗，那么向Radius回應(yīng)Disconnect-NAKWEB認(rèn)證流程報文分析上線流程報文報文描述4號報文是PortalServertoAC(RequestChallenge:0x01)5號報文是ACtoPortalServer(ACKChallenge:0x02)6號報文是PortalServertoAC(RequestAuth:0x03)7號報文是ACtoRadiusServer(AccessRequest)8號報文是RadiusServertoAC(AccessAccept)9號報文是ACtoRadiusServer(AccountingRequestStart)10號報文是ACtoPortalServer(ACKAuth:0x04)11號報文是PortalServertoAC(AFFACKAuth:0x07)12號報文是RadiusServertoAC(AccountingResponse)下線流程報文報文描述80號報文是PortalServertoAC(RequestLogout:0x05)81號報文是ACtoPortalServer(ACKLogout:0x06)82號報文是ACtoRadiusServer(AccountingRequestStop)83號報文是RadiusServertoAC(AccountingResponse)中間計費(fèi)報文報文描述38號報文是ACtoRadiusServer(AccountingRequestStatus)39號報文是RadiusServertoAC(AccountingResponse)GO常見問題分析Portal頁面無法推出

通常Portal頁面推不出一般是由AC、Portal效勞器地址配置不正確引起AC的Portal效勞器地址確認(rèn)參加到認(rèn)證前白名單中？URL中的UserIP是否在PortalServer的地址池中？WlanACname是否正確？認(rèn)證失敗引起RadiusServer返回認(rèn)證被拒絕的情況有很多：

認(rèn)證請求報文中參數(shù)不正確用戶名是否正確NAS_IP_ADDRESS,AC的外網(wǎng)IPCALLED_STATION_ID,用