1.1  單點登錄原理與技術實現(xiàn)比較

1.1.1  單點登錄原理

單點登錄（SSO）是指一個用戶身份只需進行一次鑒權(quán)便可以訪問所有經(jīng)授權(quán)的資源，而不需要多次認證。SSO機制能夠減少人為錯誤，同時提高整個系統(tǒng)的安全性。雖然SSO很有價值，但是它的實現(xiàn)并不容易，因為到目前為止還沒有一種用戶身份驗證的統(tǒng)一標準。IBM WebSphere Portal服務器提供了各種手段使SSO的實現(xiàn)簡單化、安全化、有效化。

創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于網(wǎng)站制作、網(wǎng)站設計、雁塔網(wǎng)絡推廣、微信小程序開發(fā)、雁塔網(wǎng)絡營銷、雁塔企業(yè)策劃、雁塔品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學生創(chuàng)業(yè)者提供雁塔建站搭建服務，24小時服務熱線：13518219792，官方網(wǎng)址：aaarwkj.com

通常會有外置代理和內(nèi)置代理兩種方法。

1．外置代理

在有些情況下，可以使用一種類似中介的代理進程，該進程處于用戶和應用程序之間，如圖1-1所示。當用戶被應用程序要求提供×××明時，代理進程從用戶資料庫中得到用戶的信用狀，并送給應用程序。信用狀相當于一個令牌，它只有用戶的身份信息，而沒有用戶的密碼憑證。換句話說，使用外置代理實現(xiàn)單點登錄，被集成的Web應用系統(tǒng)是不再驗證該用戶在Web應用系統(tǒng)中的密碼的。它認為，只要你是Portal的合法用戶并且成功登錄了Portal，你只需告訴我你的身份跟角色，我就認為你是該Web系統(tǒng)中可以使用授權(quán)信息的合法用戶了。

圖1-1  門戶服務器進行身份驗證過程——Web應用沒有提供Authentication API的情況

 ①用戶登錄到門戶服務器，身份驗證服務對用戶進行身份驗證。

 ②驗證通過，建立用戶信用狀，并請求建立用戶默認桌面。

 ③代理程序使用用戶信用狀，并發(fā)送請求給目錄服務，要求得到Web應用的用戶名和口令。

 ④得到用戶名和權(quán)限信息。

 ⑤代理程序使用它們進入Web應用并依據(jù)權(quán)限信息得到應用數(shù)據(jù)。

 ⑥代理程序?qū)⒌玫降臄?shù)據(jù)格式化后生成用戶默認桌面，應用程序的內(nèi)容以門戶Channel的形式展現(xiàn)。

 ⑦將生成的桌面?zhèn)魉徒o用戶。

上面的情況適用于Web應用沒有提供Authentication API的情況，對于提供Authentication API的Web應用（如Lotus Notes），則多出來一步，即第4步：鑒權(quán)。用戶在Web應用中的用戶名和密碼必須事先通過加密存儲機制存儲到Portal平臺，此時代理程序建立的信用狀同時包含了此用戶在該Web應用系統(tǒng)中的密碼。代理程序攜帶此用戶的用戶名和密碼調(diào)用Web驗證服務實現(xiàn)認證過程，認證完成后，至于此用戶在該Web系統(tǒng)中到底有哪些權(quán)限，這就由接下來的Web系統(tǒng)去執(zhí)行了，因為此時此用戶已經(jīng)通過調(diào)用驗證服務的手段成功登錄了該Web應用系統(tǒng)。如圖1-2所示。

圖1-2  門戶服務器進行身份驗證過程——Web應用提供Authentication API的情況

 ①用戶登錄門戶服務器。

 ②請求建立用戶默認桌面。

 ③代理程序使用Portal Token并批準使用Web應用的Authentication API進行用戶身份驗證。所使用的用戶名與登錄門戶服務器時使用的一樣，或者是一個映射值，映射表應存放在門戶服務器的Profile中。

 ④進行用戶鑒權(quán)。

 ⑤鑒權(quán)成功。

 ⑥代理程序使用Web應用API 獲取數(shù)據(jù)。

 ⑦代理程序?qū)⒌玫降臄?shù)據(jù)格式化后生成用戶默認桌面，應用程序的內(nèi)容以門戶Channel的形式展現(xiàn)。

 ⑧將生成的桌面?zhèn)魉徒o用戶。

上面所提到的代理程序，可以通過IBM WebSphere Portal提供的API編寫的 Servlet程序?qū)崿F(xiàn)。這個 Servlet 程序?qū)⒂脩舻男庞脿顐鬟f給應用程序，并將用戶重定向到應用的主頁面。 

外置代理的優(yōu)點：

— 啟動投資相對較少。

缺點：

— 不利于系統(tǒng)管理和維護。

— 對系統(tǒng)總體性能有影響。

— 不支持跨域的SSO。

2．內(nèi)置代理

內(nèi)置代理方法是指利用策略管理軟件，即Identity 服務器軟件。策略管理軟件的工作原理是，在Web服務器上安插一個代理模塊（Agent Module），該模塊與 Identity 服務器共同負責用戶身份驗證和授權(quán)信息。

要將策略管理軟件與Portal 服務器進行集成，可以將策略代理模塊安裝在內(nèi)嵌于Portal服務器中的Web服務器上，并使用Portal服務器提供的API，基于策略管理軟件的Session創(chuàng)建過程生成一個有效的Portal 服務器Session。這樣，用戶可以在策略管理系統(tǒng)的控制下訪問任何Web應用。

內(nèi)置代理的優(yōu)點：

— 通過Identity服務器及其Web代理模塊可以安全、有效地控制用戶身份驗證和資源訪問。

— 提供集中的訪問控制管理，增強大型復雜應用系統(tǒng)的可管理性和效率。

— 為系統(tǒng)開發(fā)人員提供一種簡單的方法對集中化的目錄資源進行訪問，易于擴展。

— 通過Extranet Web Agents，可以無縫地集成Web應用。

— 具有支持百萬級用戶的良好系統(tǒng)擴展性。

— 保護投資。

— 支持跨域的SSO。

從邏輯概念上看，Identity服務器作為企業(yè)核心的應用訪問控制器，而Portal服務器則是一個內(nèi)容聚合器，聚合由Identity服務器保護的應用。同時，Portal服務器還作為企業(yè)內(nèi)部安全的應用訪問轉(zhuǎn)送器。使用內(nèi)置代理實現(xiàn)Portal與Web應用系統(tǒng)的原理及過程如下，我們分12個步驟來介紹。

 ①用戶訪問門戶網(wǎng)關。

 ②門戶網(wǎng)關檢查當前IPS Session是否包含有效的Cookie，如果不包含（即Session還未建立），門戶網(wǎng)關則將信息包傳給門戶服務器的身份驗證模塊。

 ③服務器的身份驗證模塊將信息包轉(zhuǎn)發(fā)給Identity服務器的代理模塊。

 ④代理模塊給用戶發(fā)送一個經(jīng)過定制的登錄頁面（此頁面顯示使用Identity服務器進行身份驗證）。

 ⑤用戶輸入用戶名/口令（或其他身份信息），并返回給代理模塊。

 ⑥代理模塊將該信息發(fā)送給Identity 服務器。

 ⑦Identity服務器驗證用戶身份（查詢存儲用戶信息的目錄數(shù)據(jù)庫）。

 ⑧驗證成功，Identity服務器生成Identity Cookie（包含驗證成功等信息）,并發(fā)送給代理模塊。

 ⑨代理模塊存儲Identity Cookie，并調(diào)用門戶服務器的身份驗證模塊使Session有效（生成一個Portal Session）。

 ⑩門戶服務器的身份驗證模塊將Identity Session和Portal Session發(fā)送給用戶瀏覽器。

 ?門戶網(wǎng)關保存Portal Session，使用戶的Session生效。

 ?門戶網(wǎng)關給用戶發(fā)送門戶首頁。

一旦身份驗證流程完成，用戶不需要重新認證就可以訪問由門戶服務器及Identity服務器保護的任何資源和應用。

3．頁面流方式實現(xiàn)單點登錄

頁面流方式的單點登錄，指的是用戶成功登錄Portal后，在業(yè)務系統(tǒng)中用戶每調(diào)用一次Web系統(tǒng)的頁面，Web系統(tǒng)都要聯(lián)絡代理進行一次驗證。iDSAME產(chǎn)品就提供了這種功能，它是一種更加嚴格的訪問控制策略，用來保護企業(yè)核心、重要系統(tǒng)的數(shù)據(jù)和資源，具體實現(xiàn)是由iDSAME的Web代理以及相應的URL訪問策略來共同完成的。

Web代理安裝在受保護資源的機器上，當用戶訪問受保護的系統(tǒng)資源時，Web代理首先截獲請求，檢查訪問的是否是受保護資源，如果不是，則允許訪問；如果是，iDSAME則會根據(jù)用戶的Token檢查用戶能訪問還是不能訪問。與內(nèi)置代理、外置代理不同，使用該策略實現(xiàn)單點登錄會嚴重降低應用系統(tǒng)的性能，因為用戶每訪問一個頁面，都會引起一次鑒權(quán)的過程。通常，這種情況應用于企業(yè)的比較核心和重要的業(yè)務系統(tǒng)中。

4．交叉域單點登錄

交叉域單點登錄（Cross Domain SSO）是指實現(xiàn)單點登錄的幾個應用服務器在不同的域內(nèi)。在這種情況下要實現(xiàn)單點登錄，必須將其他域轉(zhuǎn)換到本地域，進行域名映射。交叉域單點登錄實現(xiàn)原理示意圖如圖1-3所示。

圖1-3  交叉域單點登錄實現(xiàn)原理示意圖

1.1.2  單點登錄的技術方案

針對集成的不同的應用系統(tǒng)，我們會提供不同的單點登錄解決方案，下面是實現(xiàn)單點登錄功能的常用技術方案。

1．LTPA（Lightweight Third-Party Authentication）令牌環(huán)技術

LTPA是一種令牌環(huán)，上面記錄了用戶的登錄信息和身份信息，它提供了基于Cookie的輕量級第三方認證機制（LTPA），當用戶發(fā)出對資源的請求時，首先必須向認證服務器認證。認證成功后，認證服務器代表用戶生成LTPA Cookie。作為認證標記服務的LTPA Cookie中包含用戶標識、密鑰和標記數(shù)據(jù)、緩沖區(qū)長度和到期信息，此信息使用認證服務器和應用系統(tǒng)之間共享的受密碼保護的密鑰加密。認證服務器在請求的HTTP頭中插入Cookie，該請求通過連接發(fā)送到應用系統(tǒng)，應用系統(tǒng)服務器接收請求、解密Cookie并基于Cookie中提供的標識信息認證用戶。

2．基于表單的單點登錄（Form-Based SSO）

基于表單的單點登錄（Form-Based SSO）功能，允許認證服務器將已認證的用戶透明地登錄到需要通過HTML表單認證的后臺系統(tǒng)中?；诒韱蔚膯吸c登錄實現(xiàn)原理示意圖如圖1-4所示。

圖1-4  基于表單的單點登錄實現(xiàn)原理示意圖

3．HTTP頭文件（HTTP Header）技術

利用HTTP Header這種認證方式，認證服務器可以把經(jīng)過認證的用戶身份信息（包括賬號、屬性信息等），通過HTTP Header傳給后臺的應用系統(tǒng)，后臺的應用系統(tǒng)可以從HTTP Header中把這些用戶信息截取出來，用來確認用戶身份，從而實現(xiàn)統(tǒng)一認證（單點登錄）的功能。這種統(tǒng)一認證的方式需要后臺的應用系統(tǒng)進行相應的修改，使它可以獲得HTTP Header中的用戶信息。

4．憑證保險庫（GSO-Lockbox）技術

GSO-Lockbox這種實現(xiàn)單點登錄的方式一般會和Form-Based SSO方式一起來使用，主要是考慮到每個人在各個系統(tǒng)中的用戶身份可能會不一致，利用這種方式可以解決這種問題。利用GSO-Lockbox，可以建立起用戶身份信息和后臺應用系統(tǒng)之間的對應關系。

在不同的產(chǎn)品中有各自的實現(xiàn)方式，例如，在IBM WebSphere Portal中叫做Credential Vault，也翻譯為“憑證保險庫”。憑證保險庫為實現(xiàn)單點登錄的每套應用系統(tǒng)創(chuàng)建一個憑證保險段，在每個憑證保險段里則為每個Web用戶創(chuàng)建一個憑證保險槽。槽是最小的憑證單位，用來存儲一個用戶在一套應用系統(tǒng)中的用戶名和密碼鍵值對（見表1-1）。

表1-1  GSO-Lockbox實現(xiàn)單點登錄的方式

以上幾種方式很難說誰最好，最佳實踐的做法是根據(jù)客戶的具體情況選用不同的解決方案，或幾種實現(xiàn)方案同時使用，依據(jù)不同的應用系統(tǒng)情況而定。但通常來說，應遵循如下幾個原則。

（1）對部署在WebSphere Application Server、WebLogic Server、SAP NetWeaver Application Server、Domino等服務器上能識別LTPA令牌環(huán)，且用戶目錄與Portal的用戶目錄為同一套，或者有一一對應關心的應用系統(tǒng)，與Portal實現(xiàn)單點登錄時，建議采用LTPA機制。

（2）對部署在WebSphere Application Server、WebLogic Server、SAP NetWeaver Application Server、Domino等服務器上，且用戶目錄與Portal的用戶目錄不是同一套，或者沒有一一對應的應用系統(tǒng)，與Portal實現(xiàn)單點登錄時，建議采用JAAS認證。

（3）用戶注冊表與Portal不一致，但應用系統(tǒng)中的用戶在Portal中都有對應的用戶時，不管其用戶名編排規(guī)則是否一致，皆建議采用憑證保險庫技術。

1.2  單點登錄在最佳項目實踐中的應用

使用單點登錄技術實現(xiàn)Portal系統(tǒng)與其他應用系統(tǒng)的單點登錄后，用戶只要成功登錄Portal，就可以無須再次登錄而直接進入應用系統(tǒng)，或者在Portal中直接使用應用系統(tǒng)中授權(quán)的應用或信息。在進行實際項目開發(fā)時，通常會設計如下幾種模式，作為單點登錄及單點登錄的擴展應用。

1.2.1  以列表的方式進入應用系統(tǒng)首頁

以列表的方式進入應用系統(tǒng)首頁，指的是提供一個展現(xiàn)應用系統(tǒng)列表的Portlet，上面列出了實現(xiàn)單點登錄的所有應用系統(tǒng)（見圖1-5）。點擊列表中的條目，可以直接在新的頁面中進入該應用系統(tǒng)，而無須再次登錄或者提供任何憑證。

圖1-5  以列表Portlet的方式應用單點登錄

1.2.2  直接進入各個應用系統(tǒng)的深度集成模式

很多時候，用戶需要進入到系統(tǒng)的某個深層次頁面，而不是從系統(tǒng)首頁一步步點擊。單點登錄的深度集成模式指的是通過不同的標簽直接進入到客戶想進去的頁面，如圖1-6所示。

圖1-6  點擊不同的標簽直接進入到應用系統(tǒng)的深度集成頁面

1.2.3  以應用導航的方式梳理后集成

很多客戶會有這樣的經(jīng)驗：當應用系統(tǒng)過多時，自己都忘記了發(fā)起某個業(yè)務或某個功能的頁面到底在哪套系統(tǒng)中。應用導航集成思路指的是，不是從應用系統(tǒng)的角度梳理深度集成的頁面，而是從用戶的業(yè)務應用角度來分析，將用戶經(jīng)常使用的功能頁面從業(yè)務的角度梳理、分類，并分門別類地展現(xiàn)到系統(tǒng)中。用戶只需知道要干什么就行了，而不必關心要執(zhí)行的這個頁面到底在哪套系統(tǒng)中。也就是說，讓用戶忘掉系統(tǒng)的存在。圖1-7所示是典型的應用導航圖。

圖1-7  典型的應用導航圖（應用導航允許用戶忘記系統(tǒng)的存在，只需知道要干什么就行了）

1.2.4  作為統(tǒng)一待辦調(diào)用任務處理界面時的通用驗證邏輯單元

單點登錄的最廣泛和深入的應用莫過于統(tǒng)一工作待辦了。把所有系統(tǒng)中每個用戶需要待辦的事項分門別類地按照業(yè)務域劃分出來，并集中展現(xiàn)到一個個欄目中，讓用戶原來需要登錄多套系統(tǒng)去處理的待辦事項，在一個欄目中就完成了，多方便??！圖1-8所示是將來自幾十套系統(tǒng)的待辦事項統(tǒng)一集成到一個欄目中，并按照9大業(yè)務域劃分的一個典型場景。

圖1-8  按照業(yè)務域在一個欄目中集中展現(xiàn)來自幾十套系統(tǒng)的待辦事項

1.3  單點登錄技術的開發(fā)/配置指南

單點登錄的實現(xiàn)技術還有很多，比如JAAS認證等，但在項目實踐中應用最多的就是LTPA令牌環(huán)和憑證保險庫技術。本節(jié)詳細介紹這兩種方案的開發(fā)/配置過程。

1.3.1  LTPA技術是如何實現(xiàn)

1.3.1.1　LTPA對于SSO的工作機制

LTPA機制適用于部署在WebSphere Application Server、WebLogic Server、SAP NetWeaver Application Server、Domino等服務器上，它能識別LTPA令牌環(huán)，以及用戶目錄與Portal的用戶目錄為同一套，或有一一對應關系的應用系統(tǒng)。本節(jié)以WebSphere Portal與Domino之間實現(xiàn)單點登錄為例，介紹LTPA機制是如何配置的。

LTPA（輕量級第三方認證）是一個令牌環(huán)，它是通過使用Domain Cookie而啟用的。這種經(jīng)過加密的會話Cookie被放置在用戶瀏覽器中，包含了一些信息，WebSphere或者Domino Application服務器可以加密這些信息，并使用這些信息來說明用戶已經(jīng)通過該Cookie所覆蓋的DNS（Domain Naming Service，域名服務）域中的認證。

LTPACookie 包含以下信息。

— Cookie名稱：總是設置為LtpaToken。

— 域：設置為Internet域，該域由參與單點登錄的所有服務器共享（例如：mycompany. com）。

— Cookie 到期：設置為當瀏覽器終止時刪除該Cookie。

— 安全：設置為開狀態(tài)，以強制使用安全套接字層（SSL）。LTPA配置有一個設置參數(shù)，使它創(chuàng)建只通過SSL發(fā)送的Cookie。

— Cookie值：被設置為LTPA標記。

LTPA標記是一個加密的字符串，它包含以下信息。

— 用戶數(shù)據(jù)：一般被設置為用戶 ID，但也可以是任何用于唯一標識用戶的用戶信息。

— 過期時間：與 Cookie 過期不同，這個字段用于強加一個時間限制，時間限制從登錄進來的那一刻算起，而不受瀏覽器活動或者不活動影響。這個時間限制是一個可設置的LTPA配置，在默認情況下為30分鐘。

1.3.1.2  如何配置Portal與Domino之間的SSO

Portal與Domino的SSO可以通過配置LTPA的方法來實現(xiàn)。通俗地講就是，用戶登錄Portal系統(tǒng)后，Portal系統(tǒng)會把用戶登錄信息加密成LTPA并存放到某一位置，當用戶繼續(xù)訪問Domino系統(tǒng)中的授權(quán)資源時，Domino系統(tǒng)會自動讀取該位置的LTPA，讀到并解密后拿到Domino系統(tǒng)中驗證，如果驗證通過，則顯示給用戶授權(quán)信息。所以要配置Portal與Domino之間的SSO非常容易，只要先將Domino系統(tǒng)服務器的LTPA導出并存為.key文件，然后導入Portal系統(tǒng)所在的服務器（WebShpere Application Server）中就可以了。

1.3.2  憑證保險庫技術是如何實現(xiàn)的

1.3.2.1  概述

WebSphere Portal提供了Credential Vault（憑證保險庫）功能，Credential Vault通過Basic Authentication Header將用戶名和密碼傳遞給后端應用程序。為了使Domino服務器接受通過這個頭部傳遞進來的憑證，必須將服務器會話驗證配置為Single-Server模式。在Multi-Server模式中，該服務器只接受通過LTPA機制傳遞的憑證。因此，為了與Domino應用程序一起使用用于SSO的Credential Vault，必須將Domino服務器會話驗證配置為Single-Server模式。

要使用Credential Vault，用戶需輸入一些憑證，輸入一次就夠了。隨后，這些憑證被存放在一個經(jīng)過加密的數(shù)據(jù)庫表中，每當用戶訪問該Portlet時，這些憑證便被傳遞給后端應用程序。要了解關于配置Credential Vault的細節(jié)，請參見WebSphere Portal InfoCenter。

1.3.2.2憑證保險庫實現(xiàn)SSO原理

下面以一個最簡單的SSO過程為例進行介紹。

 普通業(yè)務系統(tǒng)的登錄過程：系統(tǒng)首先提供一個頁面，讓我們輸入應用程序中的用戶信息。

用戶輸入用戶名和密碼后，單擊“登錄”按鈕，該頁面提交到form所對應的Action（check_login.jsp）進行處理，我們看check_login.jsp的代碼。

接下來提交到數(shù)據(jù)庫驗證用戶信息的合法性，如果合法，則定位到授權(quán)信息頁面；否則，重定位回到登錄頁面login.jsp。

在Portlet開發(fā)中是如何解決這個問題的？

其實起關鍵作用的還是check_login.jsp頁面，它需要獲得用戶名和密碼兩個鍵值，然后拿著這兩個參數(shù)到后臺數(shù)據(jù)庫去驗證。在常規(guī)的登錄方式中，這兩個參數(shù)是通過login.jsp獲得的。事實上，只要Portlet能為該頁面提供這兩個鍵值，也就實現(xiàn)了登錄的自動化。而Portlet要得到這兩個參數(shù)是非常簡單的，所以實現(xiàn)單點登錄也就非常簡單了。我們可以復制一個check_login.jsp文件，例如名為check_portal_login.jsp，這個頁面的兩個參數(shù)是Portlet提供的，剩下的事完全交給業(yè)務系統(tǒng)去處理，頁面流轉(zhuǎn)和全線控制都不用我們管了。

1.3.2.3開發(fā)Portlet實現(xiàn)SSO的方法

（1）JSP取值傳送URL

我們開發(fā)一個使用系統(tǒng)專用槽的Portlet，使用憑證保險庫的相關接口在PortletView.jsp中取出用戶存儲在憑證保險庫中的鍵值，然后以URL的方式傳送到iFrame內(nèi)。

PortletView.jsp的部分代碼如下：

如果用戶已經(jīng)在憑證保險庫中存儲了鍵值，那么該Portlet的View.jsp頁面被初始化時，iFrame中將顯示用戶成功登錄后的授權(quán)信息，也就是實現(xiàn)了SSO。

（2）Class取值寫Session，JSP取出并以URL傳送

我們在Portlet的控制類中取得用戶存儲在憑證保險庫中的鍵值對，并在PortletView的doview()方法中寫入Session。在Portlet的Ｖiwe.jsp中取出Session，然后像第一種方法一樣，以URL的方式傳送到目的代理。

（3）Class寫Session，單點登錄代理取Session

我們在Portlet的控制類中取得用戶存儲在憑證保險庫中的鍵值對，并在PortletView的doview()方法中寫入Session。而專為Portal開發(fā)的協(xié)助登錄頁面則會直接從Session中取出用戶憑證，具體的操作方法略過。

由于這幾種方法開發(fā)起來比較簡單，所以這里就一帶而過，不再詳細介紹了。

當前題目：企業(yè)門戶---單點登錄與企業(yè)應用系統(tǒng)集成
當前URL：http://aaarwkj.com/article44/jjgche.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、定制開發(fā)、全網(wǎng)營銷推廣、做網(wǎng)站、網(wǎng)站內(nèi)鏈、域名注冊

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)