專利名稱：管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信領(lǐng)域，尤其涉及一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的 方法和系纟充。
背景技術(shù)：
SNMP (Simple Network Management Protocol,簡單網(wǎng)絡(luò)管理協(xié)議) 的網(wǎng)絡(luò)管理模型由管理站、被管設(shè)備、管理信息庫和管理協(xié)議四部分組成。 SNMP的網(wǎng)絡(luò)管理包含兩個基本過程1、 管理站通過管理協(xié)議對被管設(shè)備中的管理信息庫進(jìn)行讀、寫操作；2、 被管設(shè)備通過管理協(xié)議將其管理信息庫中的狀態(tài)信息反饋給管理站。 管理站在通過管理協(xié)議對被管設(shè)備進(jìn)行讀寫操作時，需要對發(fā)起操作的用戶進(jìn)行身份認(rèn)證和訪問控制授權(quán)，以確保用戶操作的合法性?，F(xiàn)有技術(shù)中 一種管理協(xié)議中對用戶進(jìn)行身份認(rèn)證的方法為管理協(xié)議 SNMPv3自身提供用戶認(rèn)證技術(shù)。SNMPv3的USM ( User-based Security Model,基于用戶的安全模型)提供身份認(rèn)證、報文加密和時戳檢查， SNMPv3報文頭攜帶用戶名、認(rèn)證信息等USM所需的參數(shù)。發(fā)送端用戶在發(fā) 送報文時，通過SNMPv3內(nèi)置的認(rèn)證算法計算報文的認(rèn)證信息，并將獲得的 認(rèn)證信息填充到報文頭部。接收端用戶接收到所述報文后，使用相同的認(rèn)證 算法計算報文的認(rèn)證信息，并與報文中攜帶的原始認(rèn)證信息進(jìn)行比較，如果 比較結(jié)果為相同，則說明對上述發(fā)送端用戶的認(rèn)證通過。 上述現(xiàn)有技術(shù)的方法的缺點為1、 該方法是一個SNMPv3專用的驗證機(jī)制，該機(jī)制不能很好地同目前已 經(jīng)存在的協(xié)議和設(shè)施進(jìn)行互操作，不符合當(dāng)前的技術(shù)發(fā)展趨勢。2、 該方法采用管理協(xié)議內(nèi)置的認(rèn)證方式，該認(rèn)證方式是固定的，可擴(kuò)展 性不好，不能方便地支持新的認(rèn)證方法?，F(xiàn)有技術(shù)中另 一種管理協(xié)議中對用戶進(jìn)行身份認(rèn)證的方法為在Netconf (Network Configuration Protocol,基于XML的網(wǎng)纟備配置協(xié)、i義)的SSH (Secure Shell,安全外殼)承栽中，直接使用了SSH的用戶驗證方式，SSH 協(xié)議分為三個部分。Netconf/SSH客戶端首先使用SSH傳輸協(xié)議建立SSH傳 輸連接，然后運行SSH用戶驗證協(xié)議，驗證Netconf協(xié)議的用戶，然后客戶端 啟動SSH連接服務(wù)，后續(xù)的Netconf報文都承載在SSH連接服務(wù)中。上述現(xiàn)有技術(shù)的方法的缺點為該方法借用SSH協(xié)議內(nèi)置的用戶驗證機(jī) 制來驗證Netconf用戶，而SSH用戶和Netconf用戶可能存在不匹配的情況， 比如當(dāng)一個SSH連接上承載有多個用戶的數(shù)據(jù)，采用該方法對用戶進(jìn)行驗 證就很不合適，除非對NETCONF協(xié)議做較大修改。因此，該方法的適用范圍 不廣泛。發(fā)明內(nèi)容本發(fā)明實施例提供一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法和系統(tǒng)。從而 可以解決現(xiàn)有管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法可擴(kuò)展性不好、適用范圍不 廣泛的缺點。本發(fā)明實施例是通過以下技術(shù)方案實現(xiàn)的一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，包括管理站將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè)備，向被 管設(shè)備發(fā)送用戶認(rèn)證信息；被管設(shè)備根據(jù)接收到的所述用戶認(rèn)證信息，通過所述認(rèn)證協(xié)議或驗證服務(wù)器對用戶進(jìn)行認(rèn)證，將攜帶認(rèn)證結(jié)果的認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議 中并返回給管理站。一種管理協(xié)議中對用盧進(jìn)行認(rèn)證的系統(tǒng)，包括管理站用于將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè) 備，向被管設(shè)備發(fā)送用戶認(rèn)證信息；接收被管設(shè)備返回的封裝于管理協(xié)議中 的認(rèn)證協(xié)議應(yīng)答消息；被管設(shè)備用于根據(jù)所述管理站發(fā)送的所述用戶認(rèn)證信息，通過所述認(rèn) 證協(xié)議對用戶進(jìn)行認(rèn)證，將認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中并返回給管 理站。一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的系統(tǒng)，包括管理站用于將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè) 備，向被管設(shè)備發(fā)送用戶認(rèn)證信息；接收被管設(shè)備返回的封裝于管理協(xié)議中 的認(rèn)證協(xié)議應(yīng)答消息；被管設(shè)備用于將所述管理站發(fā)送過來的用戶認(rèn)證信息封裝于認(rèn)證授權(quán) 計費AAA協(xié)議中，并發(fā)送給后端驗證服務(wù)器；將后端驗證服務(wù)器返回的認(rèn)證 結(jié)果轉(zhuǎn)換為認(rèn)證協(xié)議應(yīng)答消息，并封裝于管理協(xié)議中返回給管理站；后端驗證服務(wù)器用于接受所述被管設(shè)備發(fā)送的用戶認(rèn)證信息，根據(jù)該 用戶認(rèn)i正信息對用戶進(jìn)行iU正，向被管設(shè)備返回認(rèn)i正結(jié)果。由上述本發(fā)明實施例提供的技術(shù)方案可以看出，本發(fā)明實施例通過將認(rèn) 證協(xié)議消息封裝到管理協(xié)議中，通過認(rèn)證協(xié)議或驗證服務(wù)器對用戶進(jìn)行認(rèn) 證。由于認(rèn)證協(xié)議可以方便地擴(kuò)展新的認(rèn)證方法，從而提供了 一種擴(kuò)展性好 的管理協(xié)議中用戶認(rèn)證的方法和系統(tǒng)，擴(kuò)展豐富了管理協(xié)議的認(rèn)證方法。


圖1為本發(fā)明實施例1所述方法的處理流程圖； 圖2為本發(fā)明實施例2所述方法的處理流程圖； 圖3為本發(fā)明實施例1所述系統(tǒng)的結(jié)構(gòu)示意圖； 圖4為本發(fā)明實施例2所述系統(tǒng)的結(jié)構(gòu)示意圖。
具體實施方式
本發(fā)明實施例提供了 一種對用戶進(jìn)行認(rèn)證的方法和系統(tǒng)。本發(fā)明實施例 對應(yīng)的軟件可以存儲在一個計算機(jī)可讀取存儲介質(zhì)中。本發(fā)明實施例將認(rèn)證協(xié)議消息封裝到管理協(xié)議中，并在管理協(xié)議中攜帶 對用戶進(jìn)行認(rèn)證所需要的各種信息，被管設(shè)備通過認(rèn)證協(xié)議或后端驗證服務(wù) 器提供的認(rèn)證方法，對用戶進(jìn)行認(rèn)證。上述管理協(xié)議指SNMP、 Netconf等網(wǎng)絡(luò)管理協(xié)議，上述認(rèn)證協(xié)議包括 EAP等認(rèn)證協(xié)議。在管理協(xié)議中封裝EAP (Extensible Authentication Protocol,可擴(kuò)展認(rèn)證協(xié)議)認(rèn)證消息的方法與具體的管理協(xié)議相關(guān)，下面以Netconf和SNMP協(xié) 議為例加以i兌明。管理協(xié)議以Netconf協(xié)議為例，在Netconf中封裝EAP認(rèn)證消息的具體處理過程為首先在Netconf中增加一種新的操作identify,該操作identify用于用戶身份 認(rèn)證，其基本格式如下<rpc message-id="101"xmlns="um:ietf:params:xml:ns:netconf:base:1.0"><identify><! -- parameters ...—> </identify> </rpc>上述操作identify的基本格式中的parameters指該一個或多個參數(shù)，這些 參數(shù)通過XML (Extensible mark-up language,可擴(kuò)展標(biāo)記語言)標(biāo)記來表 示，本發(fā)明實施例用上述XML標(biāo)記來封裝EAP認(rèn)證消息，其格式定義如下<eap><! — EAP Packet —> 〃將EAP認(rèn)證消息封裝在XML標(biāo)記"eap"中 </eap>在上述操作identify中封裝EAP認(rèn)證消息的消息格式如下<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <identify> <e3p> <! — EAP Packet —></63p><! —other parameters--> 〃其他參數(shù)，將來擴(kuò)展用</identify> </rpc>對上述操作identify的應(yīng)答消息格式如下 <rpc-reply message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"> <eap><! -- EAP Response Packet —>〃EAP應(yīng)答消息 </63p><! 一 other parameters—> 〃其他參數(shù)，將來擴(kuò)展用</rpc-reply>對于身份認(rèn)證通過的用戶，在進(jìn)行后續(xù)的管理操作時，需要在管理操作 中攜帶用戶身份信息，目前，而Netconf尚沒有相關(guān)定義。本發(fā)明定義一種新 的XML標(biāo)記identity，用于在Netconf操作中攜帶用戶或用戶組標(biāo)記，XML標(biāo)記 identity的格式如下<identity><!-用戶或用戶組ID--> 〃用戶或用戶組標(biāo)識 <! - other contents —>〃與用戶或用戶組相關(guān)的其他信息 </identity>在Netconf刪除操作中使用上述XML標(biāo)記identity的示例如下<rpc message-id="101"xmlns urn:ietf:params:xml:ns:netconf:base:1 ()"> <delete-config> <identity><!—用戶或用戶組ID—> 〃用戶或用戶組標(biāo)識<! 一 other contents —> 〃與用戶或用戶組相關(guān)的其他信息</identity> <target><startup/> </target> </delete-config> </rpc>管理協(xié)議以SNMP協(xié)議為例，在SNMP中封裝EAP認(rèn)證消息的具體處理過程為首先在SNMP中增加一種用于用戶身份認(rèn)證的報文類型ldentify-PDU,下 面以SNMPv3為例說明這種新的報文類型ldentify-PDU的格式，該報文類型 Identify-PDU的格式如下述表1所示。表1:SNMPv3報文頭PDU類型max-bindingsEAP封裝消總在上述表1所示的格式中，SNMPv3文頭的具體格式由SNMPv3協(xié)議定 義；PDU ( Protocol Data Unit,協(xié)議數(shù)據(jù)單元)類型中新增一種類型ldentify-PDU; max-bindings在SNMPv3中的原意是指報文中的綁定數(shù)量，這里用來 指示EAP封裝消息的長度，EAP封裝消息用來表示具體的EAP認(rèn)證消息，其 具體格式由EAP協(xié)議定義。上述SNMPv3報文頭中可以包含用戶或用戶組標(biāo)識信息，用于身份認(rèn)證 通過的用戶進(jìn)行后續(xù)的管理操作時使用。在實際應(yīng)用中，可以使用SNMP現(xiàn)有的某種報文，比如GetRequest-PDU (獲取請求報文)來進(jìn)行用戶身份認(rèn)證，并在變量綁定列表中封裝EAP認(rèn)證消息，即用SNMP協(xié)議類型為OCTET STRING (八位字節(jié)串)的變量綁定來 封裝EAP認(rèn)證消息，由于OCTET STRING變量類型的最大長度是65535，而 EAP認(rèn)證消息的長度可能超過該限制，因此封裝時需要一個或多個變量綁 定。該方案的優(yōu)點是沿用SNMP標(biāo)準(zhǔn)中定義的報文格式。還可以采用AVP (Attribute Value Pairs -屬性值對)的方式來將EAP認(rèn) 證消息封裝在管理協(xié)議中，每個AVP包括類型、長度和數(shù)據(jù)三個字段，其中 類型用于標(biāo)識后面的數(shù)據(jù)是EAP認(rèn)證協(xié)議信息，長度字段標(biāo)識數(shù)據(jù)字段的長 度，數(shù)據(jù)字段用于封裝EAP認(rèn)證消息，根據(jù)EAP認(rèn)證消息的內(nèi)容大小，可以 將EAP認(rèn)證消息封裝于一個或多個AVP中，然后在管理協(xié)議上承載AVP。以EAP為例，本發(fā)明實施例1所述方法的處理流程如圖1所示，具體包括 如下步驟步驟11、管理站向被管設(shè)備發(fā)送針對某個用戶的認(rèn)證啟動請求NM EAP-Start消息，該NM EAP-Start消息被封裝到NM ( Management Protocol,管理協(xié)議)中，在圖1所示的處理流程中，管理站和被管設(shè)備之間通信時互相傳遞 的EAP認(rèn)證消息被封裝到NM中。步驟12、被管設(shè)備接收到上述NM EAP-Start消息后，向管理站發(fā)送獲取 身份標(biāo)識請求NM EAP-Request/ldentity消息。步驟13、管理站向被管設(shè)備返回攜帶MylD (用戶身份標(biāo)識)的獲取身份 標(biāo)識響應(yīng)NM EAP-Response/ldentity (MylD)消息。步驟14、被管設(shè)備向管理站發(fā)送認(rèn)證質(zhì)詢EAP-Request/OTP Challenge EAP消息，這里以O(shè)TP ( —次性密碼)認(rèn)證方式為例，在實際應(yīng)用中也可以 采用EAP支持的其他認(rèn)證方式。步驟15、管理站向被管設(shè)備返回攜帶質(zhì)詢口令OTPpw的NM EAP-Response/OTP認(rèn)證響應(yīng)消息。步驟16、被管設(shè)備進(jìn)行用戶身份認(rèn)證。被管設(shè)備根據(jù)獲得的MylD和 OTPpw進(jìn)行用戶身份認(rèn)證，在認(rèn)證成功后，被管設(shè)備向管理站返回接受訪問 應(yīng)答NM EAP-Success EAP認(rèn)證消息，之后，被認(rèn)證通過的用戶即可執(zhí)行后 續(xù)管理搡作。當(dāng)上述認(rèn)證失敗，則執(zhí)行步驟16'。步驟16'、被管設(shè)備進(jìn)行用戶身份認(rèn)證失敗，被管設(shè)備向管理站返回拒絕 訪問應(yīng)答NM EAP-Failure EAP認(rèn)證消息，上述用戶將無權(quán)執(zhí)行后續(xù)管理搡 作。以EAP為例，本發(fā)明實施例2所述方法的處理流程如圖2所示，包括如下 步驟步驟21、管理站向被管設(shè)備發(fā)送認(rèn)證啟動請求NM EAP-Start消息，該 NM EAP-Start消息被封裝到NM (Management Protocol,管理協(xié)議)中， NM指SNMP、 NETCONF等網(wǎng)絡(luò)管理協(xié)議。在圖2所示的處理流程中，管理站 和被管設(shè)備之間通信時互相傳遞的EAP認(rèn)證消息被封裝到NM中。步驟22、被管設(shè)備接收到上述NM EAP-Start消息后，向管理站發(fā)送荻取 身份標(biāo)識請求NM EAP-Request/ldentity消息。步驟23、管理站向被管設(shè)備返回攜帶MylD (用戶身份標(biāo)識)的獲取身份 標(biāo)識響應(yīng)NM EAP-Response/ldentity (MylD)消息。步驟24、被管設(shè)備將MylD用AAA協(xié)議的EAP-Message屬性封裝，并向 后端驗證服務(wù)器發(fā)送攜帶封裝后的MylD的訪問請求RADIUS Access-Request/EAP-Message/EAP-Response/(MylD) EAP認(rèn)證消息。后端驗證服 務(wù)器指Diameter 、 Radius等AAA ( Authentication Authorization and Accounting,認(rèn)證授權(quán)計費協(xié)議)服務(wù)器。在圖2所示的處理流程中，被管設(shè)備和后端驗證服務(wù)器通信時互相傳遞的EAP認(rèn)證消息中攜帶的信息由AAA協(xié)議的EAP-Message屬性封裝。具體封裝 方法由AAA協(xié)議定義。現(xiàn)有的AAA協(xié)議中已經(jīng)定義了封裝EAP認(rèn)證消息的方法。步驟25、后端驗證服務(wù)器接收到上述Access-Request EAP消息后，將認(rèn) 證方式封裝在AAA協(xié)議的EAP-Message屬性中，然后向被管設(shè)備發(fā)送認(rèn)證質(zhì) 詢RADIUS Access-Challenge/EAP-Message/EAP-Request/OTP ChallengeEAP消息。在圖2所示的處理流程中，以O(shè)TP認(rèn)證方式為例，在實際應(yīng)用中也 可以采用EAP或后端驗證服務(wù)器支持的其他認(rèn)證方式。步驟26、被管設(shè)備向管理站發(fā)送認(rèn)證質(zhì)詢NM EAP-Request/OTP Challenge EAP消息，這里仍然以O(shè)TP認(rèn)證方式為例，在實際應(yīng)用中可以采 用EAP或后端驗證服務(wù)器支持的其他認(rèn)證方式。步驟27、管理站向被管設(shè)備返回攜帶質(zhì)詢口令OTPpw的NM EAP-Response/OTP認(rèn)證響應(yīng)消息。步驟28、被管設(shè)備將OTPpw封裝到AAA協(xié)議的EAP-Message屬性中， 并向后端驗證服務(wù)器發(fā)送攜帶封裝后的OTPpw的RADIUS Access-Request/EAP-Message/EAP-Response/OTP訪問請求EAP消息。步驟29、后端驗證服務(wù)器接收到上述攜帶封裝后的OTPpw的訪問請求 EAP認(rèn)證消息后，根據(jù)獲得的MylD和OTPpw進(jìn)行用戶身份認(rèn)證，在認(rèn)證成功 后，向被管設(shè)備返回接受訪問應(yīng)答RADIUS Access-Acc印t/EAP-Message/EAP-Success EAP消息，被管設(shè)備向管理站返回接受訪問應(yīng)答NM EAP-Success EAPiU正消息，之后，被認(rèn)證通過的用戶即可^l行后續(xù)管理搡 作。當(dāng)上述認(rèn)證失敗，則執(zhí)行步驟29'。步驟29'、后端驗證服務(wù)器進(jìn)行用戶身份認(rèn)證失敗，后端驗證服務(wù)器向被 管設(shè)備返回拒絕訪問應(yīng)答RADIUS Access-Reject/EAP-Message/EAP-FailureEAP消息，被管設(shè)備向管理站返回拒絕訪問應(yīng)答NM EAP-Failure EAP消息。 上述用戶將無權(quán)執(zhí)行后續(xù)管理操作。對應(yīng)上述實施例1所述的處理流程，本發(fā)明實施例1所述系統(tǒng)的結(jié)構(gòu)如圖3 所示，包括管理站、被管設(shè)備。管理站管理站將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè) 備，向被管設(shè)備發(fā)送用戶身份標(biāo)識、認(rèn)證方式等用戶認(rèn)證信息；接收被管設(shè) 備返回的封裝于管理協(xié)議中的認(rèn)證協(xié)議應(yīng)答消息；被管設(shè)備根據(jù)管理站發(fā)送的所述用戶認(rèn)證信息，通過所述認(rèn)證協(xié)議對 用戶進(jìn)行認(rèn)證，將認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中并返回給管理站。對應(yīng)上述實施例2所述的處理流程，本發(fā)明實施例2所述系統(tǒng)的結(jié)構(gòu)如圖4 所示，包括管理站、被管設(shè)備和后端驗證服務(wù)器。管理站將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè)備，向 被管設(shè)備發(fā)送用戶身份標(biāo)識、認(rèn)證方式等用戶認(rèn)證信息；接收被管設(shè)備返回 的封裝于管理協(xié)議中的認(rèn)證協(xié)議應(yīng)答消息；被管設(shè)備將管理站發(fā)送過來的用戶認(rèn)證信息封裝于認(rèn)證授權(quán)計費AAA 協(xié)議中，并發(fā)送給后端驗證服務(wù)器；將后端驗證服務(wù)器返回的認(rèn)證結(jié)果轉(zhuǎn)換 為認(rèn)證協(xié)議應(yīng)答消息，并封裝于管理協(xié)議中返回給管理站；后端驗證服務(wù)器接受被管設(shè)備發(fā)送的用戶認(rèn)證信息，根據(jù)該用戶認(rèn)證 信息對用戶進(jìn)行認(rèn)證，向被管設(shè)備返回認(rèn)證結(jié)果。綜上所述，本發(fā)明實施例將EAP協(xié)議與管理協(xié)議結(jié)合起來，由于EAP協(xié) 議可以擴(kuò)展新的i人證方法，從而可以方便地擴(kuò)展管理協(xié)議的認(rèn)證方法。本發(fā)明實施例所述方法和系統(tǒng)可以與AAA系鄉(xiāng)充有扭J也結(jié)合在一起，適用范圍比較 廣泛。本發(fā)明實施例提供了一種擴(kuò)展性好的、使用范圍比較廣泛的用戶認(rèn)證 的方法和系統(tǒng)。擴(kuò)展豐富了管理協(xié)議的認(rèn)證方法。以上所述，僅為本發(fā)明實施例較佳的具體實施方式
，但本發(fā)明實施例的 保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明實施例揭 露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明實施例的保 護(hù)范圍之內(nèi)。因此，本發(fā)明實施例的保護(hù)范圍應(yīng)該以權(quán)利要求的保護(hù)范圍為 準(zhǔn)。
權(quán)利要求
1. 一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在于，包括管理站將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè)備，向被管設(shè)備發(fā)送用戶認(rèn)證信息；被管設(shè)備根據(jù)接收到的所述用戶認(rèn)證信息，通過所述認(rèn)證協(xié)議或驗證服務(wù)器對用戶進(jìn)行認(rèn)證，將攜帶認(rèn)證結(jié)果的認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中并返回給管理站。
2、 根據(jù)權(quán)利要求1所述的管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在 于，所述管理協(xié)議包括基于可擴(kuò)展標(biāo)記語言XML的網(wǎng)絡(luò)配置協(xié)議Netconf或 簡單網(wǎng)絡(luò)管理協(xié)議SNMP;所述認(rèn)證協(xié)議包括可擴(kuò)展認(rèn)證協(xié)議EAP。
3、 根據(jù)權(quán)利要求2所述的管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在 于，將所述的認(rèn)證協(xié)議請求消息或認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中具體 包括在Netconf中增加用于用戶身份認(rèn)證的操作類型和用于封裝EAP認(rèn)證消息 的XML標(biāo)記，將EAP認(rèn)證消息封裝于所述封裝EAP認(rèn)證消息的XML標(biāo)記中， 將所述封裝EAP認(rèn)證消息的XML標(biāo)記設(shè)置于所述用于用戶身份認(rèn)證的操作類 型的操作中。
4、 根據(jù)權(quán)利要求3所述的管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在 于，將所述的認(rèn)證協(xié)議請求消息或認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中還包 括設(shè)置攜帶用戶或用戶組標(biāo)識的XML標(biāo)記，將用戶或用戶組標(biāo)識設(shè)置于所 述攜帶用戶或用戶組標(biāo)識的XML標(biāo)記中，將所述攜帶用戶或用戶組標(biāo)識的 XML標(biāo)記設(shè)置于Netcon付乘作中。
5、 根據(jù)權(quán)利要求2所述的管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在于，將所述的認(rèn)證協(xié)議請求消息或認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中具體 包括在SNMP中增加用于用戶身份認(rèn)證的報文類型，將EAP認(rèn)證消息封裝于 所述用于用戶身份認(rèn)證的報文類型的報文中。
6、 根據(jù)權(quán)利要求5所述的管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在 于，將所述的認(rèn)證協(xié)議請求消息或認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中還包 括在所述用于用戶身份認(rèn)證的報文類型的報文的頭部設(shè)置用戶或用戶組標(biāo)識信息。
7、 根據(jù)權(quán)利要求2所述的管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在 于，將所述的認(rèn)證協(xié)議請求消息或認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中具體 包括將EAP認(rèn)證消息封裝于SNMP報文的變量綁定列表中。
8、 根據(jù)權(quán)利要求2所述的管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法，其特征在 于，將所述的認(rèn)證協(xié)議請求消息或認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中具體 包括使用屬性值對AVP的方式將EAP認(rèn)證消息封裝于所述管理協(xié)議中。
9、 一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的系統(tǒng)，其特征在于，包括管理站用于將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè) 備，向被管設(shè)備發(fā)送用戶認(rèn)證信息；接收被管設(shè)備返回的封裝于管理協(xié)議中 的認(rèn)證協(xié)議應(yīng)答消息；被管設(shè)備用于根據(jù)所述管理站發(fā)送的所述用戶認(rèn)證信息，通過所述認(rèn) 證協(xié)議對用戶進(jìn)行認(rèn)證，將認(rèn)證協(xié)議應(yīng)答消息封裝于管理協(xié)議中并返回給管理站。
10、 一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的系統(tǒng)，其特征在于，包括管理站用于將認(rèn)證協(xié)議請求消息封裝于管理協(xié)議中并發(fā)送給被管設(shè) 備，向被管設(shè)備發(fā)送用戶認(rèn)證信息；接收被管設(shè)備返回的封裝于管理協(xié)議中 的認(rèn)證協(xié)議應(yīng)答消 息^被管設(shè)備用于將所述管理站發(fā)送過來的用戶iU正信息封裝于認(rèn)證授權(quán) 計費AAA協(xié)議中，并發(fā)送給后端驗證服務(wù)器；將后端驗證服務(wù)器返回的認(rèn)證 結(jié)果轉(zhuǎn)換為認(rèn)證協(xié)議應(yīng)答消息，并封裝于管理協(xié)議中返回給管理站；后端驗證服務(wù)器用于接受所述被管設(shè)備發(fā)送的用戶認(rèn)證信息，根據(jù)該 用戶認(rèn)證信息對用戶進(jìn)行認(rèn)證，向被管設(shè)備返回認(rèn)證結(jié)果。
全文摘要
本發(fā)明實施例提供了一種管理協(xié)議中對用戶進(jìn)行認(rèn)證的方法和系統(tǒng)，該方法主要包括管理站將認(rèn)證協(xié)議消息封裝于管理協(xié)議中并發(fā)送給被管設(shè)備，向被管設(shè)備發(fā)送用戶認(rèn)證信息；被管設(shè)備根據(jù)接收到的所述用戶認(rèn)證信息，通過所述認(rèn)證協(xié)議或驗證服務(wù)器對用戶進(jìn)行認(rèn)證，將攜帶認(rèn)證結(jié)果的認(rèn)證協(xié)議消息封裝于管理協(xié)議中并返回給管理站。該系統(tǒng)主要包括管理站和被管設(shè)備；或者，管理站、被管設(shè)備和后端驗證服務(wù)器。利用本發(fā)明，從而提供了一種擴(kuò)展性好的、適用范圍比較廣泛的管理協(xié)議中用戶認(rèn)證的方法和系統(tǒng)。
文檔編號H04L9/32GK101237443SQ200710002829
公開日2008年8月6日 申請日期2007年2月1日 優(yōu)先權(quán)日2007年2月1日
發(fā)明者苗福友, 馬宇智 申請人:華為技術(shù)有限公司