本發(fā)明涉及通信技術領域，特別涉及一種用戶接入方法和用戶接入系統。

背景技術：

互聯網提供的資源和服務的數量非常巨大且增長迅猛，已成為人們獲取信息和服務的主要渠道。然而網絡用戶隱私安全形勢愈加嚴峻，弱口令、“拖庫”、“撞庫”等安全隱患日益凸顯，互聯網服務提供商也多次遭到黑客的惡意攻擊。如何建設安全且便捷的身份認證系統，合理、有效地把控互聯網接入入口，成為廣大服務提供商以及用戶共同關注的焦點。

現有互聯網用戶接入系統并存了兩類身份認證方法：自主認證和第三方認證。自主認證是由服務提供商自行建立用戶身份管理系統，對用戶身份進行匹配和合法性驗證，最常用的就是賬戶名+密碼的驗證方法。近年來，為了進一步降低用戶信息泄露、提高認證便捷性，以Apple ID、QQ、微信、微博、郵箱以及短信驗證碼等登錄方式為代表的第三方認證方法逐漸流行。服務提供商將用戶身份認證請求直接發(fā)給第三方平臺，由第三方認證系統根據用戶提供的賬號進行身份驗證，當用戶名和密碼均正確且匹配或者用戶接收并輸入正確的短信驗證碼，則認為用戶身份合法，認證成功。

然而現有認證方式重點集中在安全性和便捷性的提升，卻忽略了接入認證的通用性。隨著互聯網全球化的深入，受政府政策以及技術差異等約束，用戶和服務提供商在全球互聯進程卻始終受阻。按照用戶接入服務提供商歸屬地以及接入請求發(fā)生地的歸屬，全球互聯場景主要包括四類：(1)用戶在本國訪問本國服務提供商；(2)用戶在國外訪問本國服務提供商；(3)用戶在國內訪問外國服務提供商；(4)用戶在國外訪問外國服務提供商?，F有技術主要適用于第一類應用場景，一旦涉及到服務提供商和接入發(fā)生地有一方在國外的場景現有技術便存在局限性。例如，在第二類場景中，首先需要保證第三方認證系統能夠允許接入請求發(fā)生地的安全網關，并且所有認證信息一旦通過外網進行跨國互傳，安全隱患更為明顯。在第三和第四類場景中，用戶請求接入的是外國服務提供商，通常需要用戶在外國服務提供商處進行信息注冊，這一方面涉及到用戶信息外泄的隱患，同時由于注冊過程中通常涉及到信息的交互(比如郵件確認)，因而同樣面臨網絡互傳安全性降低以及互傳方式需要得到交互雙方短信網關許可的難題。

綜上所述，現有技術在全球互聯場景中不僅存在應用上的局限性，安全性也會降低。

技術實現要素：

本發(fā)明旨在至少解決現有技術中存在的技術問題之一，提出了一種用戶接入方法和用戶接入系統。

為實現上述目的，本發(fā)明提供了一種用戶接入方法，包括：

步驟S1、服務提供商接收用戶的接入請求信息，所述接入請求信息包括：請求信息和所述用戶的身份信息；

步驟S2、所述服務提供商將所述接入請求信息封裝成認證請求信息，并將所述認證請求信息發(fā)送至所述服務提供商對應的本地接入運營商；

步驟S3、所述本地接入運營商根據所述認證請求信息中的所述身份信息，判斷所述本地接入運營商是否為所述用戶對應的歸屬運營商；

若判斷結果為否，則執(zhí)行步驟S4，若判斷結果為是，則執(zhí)行步驟S5；

步驟S4、所述本地接入運營商將所述認證請求信息轉發(fā)給所述歸屬運營商；

步驟S5、所述歸屬運營商根據所述認證請求信息中的身份信息對所述用戶進行身份認證，并將認證結果反饋給所述服務提供商；

步驟S6、所述服務提供商根據接收到的認證結果執(zhí)行同意用戶接入或拒絕用戶接入的操作。

可選地，所述身份信息為所述用戶的手機號。

可選地，所述步驟S3包括：

步驟S301、本地接入運營商根據ENUM電話號碼映射協議識別出所述手機號第1～3位數字作為國家碼，以獲取所述歸屬運營商的所屬區(qū)域；

步驟S302、所述本地接入運營商根據所述歸屬運營商的所屬區(qū)域內運營商號碼對應的碼表識別出用戶歸屬運營商對應的運營商ID；

步驟S303、所述本地接入運營根據所述歸屬運營商的所屬區(qū)域和運營商ID，判斷所述本地接入運營商是否為所述用戶對應的歸屬運營商；

其中，若所述本地接入運營的所屬區(qū)域和運營商ID與所述歸屬運營商的所屬區(qū)域和運營商ID均相同，則判斷出所述本地接入運營商是所述用戶對應的歸屬運營商；若所述本地接入運營的所屬區(qū)域與所述歸屬運營商的所屬區(qū)域相同，且所述本地接入運營的運營商ID與所述歸屬運營商的運營商ID不同，則判斷出所述本地接入運營商與所述歸屬運營商不同，但是兩者同區(qū)域；若所述本地接入運營的所屬區(qū)域與所述歸屬運營商的所屬區(qū)域不同，且所述本地接入運營的運營商ID與所述歸屬運營商的運營商ID不同，則判斷出所述本地接入運營商與所述歸屬運營商不同區(qū)域。

可選地，當步驟S3中判斷出所述本地接入運營商與所述歸屬運營商不同，但是兩者同區(qū)域時，則步驟S4具體包括：

步驟S401a、所述本地接入運營商將所述認證請求信息通過代理轉發(fā)機制，基于共同協議，由預定義的端口將所述認證請求信息發(fā)送至所述歸屬運營商；

當步驟S3中判斷出所述本地接入運營商與所述歸屬運營商不同區(qū)域時，

所述步驟S4具體包括：

步驟S401b、所述本地接入運營商將所述認證請求信息發(fā)送至其自身的所屬區(qū)域的第一安全網關；

步驟S402b、所述第一安全網關按照國際數據短信格式對所述認證請求信息進行二次封裝，并經過國際數據短信通道發(fā)送至所述歸屬運營商的所屬區(qū)域的第二安全網關；

步驟S403b、所述第二安全網關將接收到的短信數據進行解封，并將解封后得到的所述認證請求信息發(fā)送安全域內的優(yōu)先接入運營商；

步驟S404b、所述優(yōu)先接入運營商根據所述認證請求信息中的所述手機號，獲取所述歸屬運營商的運營商ID；

步驟S405b、所述優(yōu)先接入運營商判斷其自身的運營商ID與所述歸屬運營商的運營商ID是否相同；

若判斷結果為否，則執(zhí)行步驟S406；

步驟S406b、所述優(yōu)先接入運營將所述歸屬運營商的運營商ID和所述認證請求信息反饋至所述第二安全網關；

步驟S407b、所述第二安全網關根據接收到的所述歸屬運營商的運營商ID將所述認證請求信息發(fā)送至所述歸屬運營商。

可選地，當步驟S3中判斷出所述本地接入運營商與所述歸屬運營商不同，但是兩者同區(qū)域時，則步驟S5包括：

步驟S501a、所述歸屬運營商根據所述認證請求信息中的身份信息對所述用戶進行身份認證；

步驟S502a、所述歸屬運營商將認證結果反饋至所述本地接入運營商；

步驟S503a、所述本地接入運營商將所述認證結果反饋至所述服務提供商；

當步驟S3中判斷出所述本地接入運營商與所述歸屬運營商不同區(qū)域時，則步驟S5包括；

步驟S501b、所述歸屬運營商根據所述認證請求信息中的身份信息對所述用戶進行身份認證；

步驟S502b、所述歸屬運營商將認證結果反饋至所述第二安全網關；

步驟S503b、所述第二安全網關通過國際數據短信通道將所述認證結果反饋至所述第一安全網關；

步驟S504b、所述第一安全網關將所述認證結果反饋至所述本地接入運營商；

步驟S505b、所述本地接入運營商將所述認證結果反饋至所述服務提供商。

為實現上述目的，本發(fā)明還提供了一種用戶接入系統，包括：

服務提供商，用于接收用戶的接入請求信息，并將所述服務提供商將所述接入請求信息封裝成認證請求信息，并將所述認證請求信息發(fā)送至所述服務提供商對應的本地接入運營商，其中，所述接入請求信息包括：請求信息和所述用戶的身份信息；

所述本地接入運營商，用于根據所述認證請求信息中的所述身份信息，判斷所述本地接入運營商是否為所述用戶對應的歸屬運營商，并在判斷出所述本地接入運營商為所述用戶對應的歸屬運營商時，根據所述認證請求信息中的身份信息對所述用戶進行身份認證，以及在判斷出所述本地接入運營商不為所述用戶對應的歸屬運營商時，將所述認證請求信息轉發(fā)給所述歸屬運營商；

所述歸屬運營商，用于根據所述認證請求信息中的身份信息對所述用戶進行身份認證，并將認證結果反饋給所述服務提供商；

所述服務提供商，還用于根據接收到的認證結果執(zhí)行同意用戶接入或拒絕用戶接入的操作。

可選地，所述身份信息為所述用戶的手機號。

可選地，所述本地接入運營商包括：

獲取模塊，用于根據ENUM電話號碼映射協議識別出所述手機號第1～3位數字作為國家碼，以獲取所述歸屬運營商的所屬區(qū)域；

查詢模塊，用于根據所述歸屬運營商的所屬區(qū)域內運營商號碼對應的碼表識別出用戶歸屬運營商對應的運營商ID；

判斷模塊，用于根據所述歸屬運營商的所屬區(qū)域和運營商ID，判斷所述本地接入運營商是否為所述用戶對應的歸屬運營商；

其中，若所述本地接入運營的所屬區(qū)域和運營商ID與所述歸屬運營商的所屬區(qū)域和運營商ID均相同，則判斷出所述本地接入運營商是所述用戶對應的歸屬運營商；若所述本地接入運營的所屬區(qū)域與所述歸屬運營商的所屬區(qū)域相同，且所述本地接入運營的運營商ID與所述歸屬運營商的運營商ID不同，則判斷出所述本地接入運營商與所述歸屬運營商不同，但是兩者同區(qū)域；若所述本地接入運營的所屬區(qū)域與所述歸屬運營商的所屬區(qū)域不同，且所述本地接入運營的運營商ID與所述歸屬運營商的運營商ID不同，則判斷出所述本地接入運營商與所述歸屬運營商不同區(qū)域。

可選地，所述本地接入運營商還包括：

第一發(fā)送模塊，用于當所述判斷模塊判斷出所述本地接入運營商與所述歸屬運營商不同，但是兩者同區(qū)域時，將所述認證請求信息通過代理轉發(fā)機制，基于共同協議，由預定義的端口將所述認證請求信息發(fā)送至所述歸屬運營商；

第二發(fā)送模塊，用于當所述判斷模塊判斷出所述本地接入運營商與所述歸屬運營商不同區(qū)域時，將所述認證請求信息發(fā)送至其自身的所屬區(qū)域的第一安全網關；

所述用戶接入系統還包括：

所述第一安全網關，用于按照國際數據短信格式對所述認證請求信息進行二次封裝，并經過國際數據短信通道發(fā)送至所述歸屬運營商的所屬區(qū)域的第二安全網關；

所述第二安全網關，用于將接收到的短信數據進行解封，并將解封后得到的所述認證請求信息發(fā)送安全域內的優(yōu)先接入運營商；

所述優(yōu)先接入運營商，用于根據所述認證請求信息中的所述手機號，獲取所述歸屬運營商的運營商ID，并判斷其自身的運營商ID與所述歸屬運營商的運營商ID是否相同；

其中，若判斷結果為否，則所述優(yōu)先接入運營將所述歸屬運營商的運營商ID和所述認證請求信息反饋至所述第二安全網關，所述第二安全網關根據接收到的所述歸屬運營商的運營商ID將所述認證請求信息發(fā)送至所述歸屬運營商。

可選地，當所述本地接入運營判斷出本地接入運營商與歸屬運營商不同，但是兩者同區(qū)域時，所述歸屬運營商還用于在根據所述認證請求信息中的所述身份信息對用戶進行身份認證之后，將認證結果反饋至本地接入運營商；所述本地接入運營商還用于將認證結果反饋至服務提供商；

當本地接入運營判斷出本地接入運營商與歸屬運營商不同區(qū)域時，所述歸屬運營商還用于在根據所述認證請求信息中的身份信息對用戶進行身份認證之后，將認證結果反饋至所述第二安全網關，所述第二安全網關還用于通過國際數據短信通道將認證結果反饋至所述第一安全網關；所述第一安全網關還用將認證結果反饋至所述本地接入運營商；所述本地接入運營商還用于將認證結果反饋至所述服務提供商。

本發(fā)明具有以下有益效果：

本發(fā)明提供了一種用戶接入方法和用戶接入系統，包括：步驟S1、服務提供商接收用戶的接入請求信息，接入請求信息包括：請求信息和用戶的身份信息；步驟S2、服務提供商將接入請求信息封裝成認證請求信息，并將認證請求信息發(fā)送至服務提供商對應的本地接入運營商；步驟S3、本地接入運營商根據認證請求信息中的身份信息，判斷本地接入運營商是否為用戶對應的歸屬運營商，若判斷結果為否，則執(zhí)行步驟S4，若判斷結果為是，則執(zhí)行步驟S5；步驟S4、本地接入運營商將認證請求信息轉發(fā)給歸屬運營商；步驟S5、歸屬運營商根據認證請求信息中的身份信息對用戶進行身份認證，并將認證結果反饋給服務提供商；步驟S6、服務提供商根據接收到的認證結果執(zhí)行同意用戶接入或拒絕用戶接入。本發(fā)明的技術方案提供的用戶接入方法具有較高的通用性，能夠安全覆蓋面向全球互聯用戶的所有類型的接入場景。

附圖說明

圖1為本發(fā)明實施例一提供的一種用戶接入方法的流程圖；

圖2為本發(fā)明實施例二提供的一種用戶接入系統的機構示意圖。

具體實施方式

為使本領域的技術人員更好地理解本發(fā)明的技術方案，下面結合附圖對本發(fā)明提供的一種用戶接入方法和用戶接入系統進行詳細描述。

需要說明的是，在本發(fā)明中，面向全球互聯的用戶接入模型主要包括三類參與主體，用戶(user)、運營商(Mobile Network Operator,簡稱MNO)和服務提供商(Service Provider,簡稱SP)。按照用戶的接入SP的歸屬地以及接入請求發(fā)生地屬性，面向全球互聯的接入場景總共包括四類：(1)用戶在本國訪問本國SP；(2)用戶在國外訪問本國SP；(3)用戶在國內訪問外國SP；(4)用戶在國外訪問外國SP。

本發(fā)明提供的用戶接入方法可滿足上述四種場景下的安全接入。

實施例一

圖1為本發(fā)明實施例一提供的一種用戶接入方法的流程圖，如圖1所示，包括：

步驟S1、服務提供商接收用戶的接入請求信息。

用戶在訪問服務提供商接時，需要向對應的服務提供商發(fā)送接入請求信息，其中該接入請求信息包括：請求信息(例如，請求時間)和用戶的身份信息，其中，用戶的身份信息為認證系統中用戶身份的唯一標識，可選地，用戶的身份信息為用戶的手機號。

在本實施例中，將用戶手機號碼作為用戶身份唯一標識，通過全球運營商之間的互聯互通，實現全球用戶與全球SP的安全接入，主要出于以下兩方面對普適性、便攜性以及安全性的考慮：

目前幾乎全球大多數互聯網用戶均有至少一個手機號碼，并且在全球大多數國家的手機號已經實現實名制管理，加之運營商大多受國家監(jiān)管。因此以手機號作為用戶身份標識相較于用戶名方式監(jiān)管性更強，相較于QQ、微博等第三方認證方式在全球范圍內普適性更高。由此可見，以運營商作為全球互通的第三方認證平臺，以手機號碼作為用戶接入憑證，既簡化了用戶對賬戶名的記憶流程，又保證了用戶身份在全球范圍內的可信度。

步驟S2、服務提供商將接入請求信息封裝成認證請求信息，并將認證請求信息發(fā)送至服務提供商對應的本地接入運營商。

服務提供商將用戶的接入請求、服務提供商的相關信息、本地接入運營商的相關信息等，封裝成認證請求信息發(fā)送至服務提供商對應的本地接入運營商。該認證請求信息具體包括用戶手機號、請求時間、業(yè)務ID、業(yè)務類型碼、接入運營商ID等。其中，業(yè)務ID是指服務提供商對應的ID標識，業(yè)務類型碼是指服務提供商對應的業(yè)務類型，接入運營商ID是指為服務提供商進行優(yōu)先尋址的運營商，通常由服務提供商根據合作情況以及用戶規(guī)模分布指定。

步驟S3、本地接入運營商根據認證請求信息中的身份信息，判斷本地接入運營商是否為用戶對應的歸屬運營商。

可選地，步驟S3包括：

步驟S301、本地接入運營商根據ENUM電話號碼映射協議識別出手機號第1～3位數字作為國家碼，以獲取歸屬運營商的所屬區(qū)域。

需要說明的是，全球運營商按地域劃分為不同的安全域(即所屬區(qū)域)，每個安全域內共享一個安全網關，負責對外域數據的過濾轉發(fā)。

步驟S302、本地接入運營商根據歸屬運營商的所屬區(qū)域內運營商號碼對應的碼表識別出用戶歸屬運營商對應的運營商ID。

步驟S303、本地接入運營根據歸屬運營商的所屬區(qū)域和運營商ID，判斷本地接入運營商是否為用戶對應的歸屬運營商。

在上述步驟S303中，具體可能出現三種情況，分別是：其一，本接入運營商與歸屬運營商相同；其二，本接入運營商與歸屬運營商相同不同，但同區(qū)域；其三，本接入運營商與歸屬運營商不同，且區(qū)域不同。

具體地，若本地接入運營的所屬區(qū)域和運營商ID與歸屬運營商的所屬區(qū)域和運營商ID均相同，則判斷出本地接入運營商是用戶對應的歸屬運營商；若本地接入運營的所屬區(qū)域與歸屬運營商的所屬區(qū)域相同，且本地接入運營的運營商ID與歸屬運營商的運營商ID不同，則判斷出本地接入運營商與歸屬運營商不同，但是兩者同區(qū)域；若本地接入運營的所屬區(qū)域與歸屬運營商的所屬區(qū)域不同，且本地接入運營的運營商ID與歸屬運營商的運營商ID不同，則判斷出本地接入運營商與歸屬運營商不同區(qū)域。

在本發(fā)明中，考慮到號碼信息屬于運營商私有資源，原則上運營商間無法做到號碼信息的共享，但是同一區(qū)域內關于號碼歸屬運營商的規(guī)律還是相對明顯的。同時，考慮到在尋址特別是跨域尋址過程中對手機號碼全位數尋址的工作量大且無意義，因此，本發(fā)明將整個基于手機號的尋址過程設計為區(qū)域尋址以及運營商歸屬尋址兩個步驟。首先，根據國際通用的ENUM(E.164Number URI Mapping)電話號碼映射協議識別出手機號第1～3位數字作為國家碼以判定認證請求中用戶所對應的歸屬運營商的所屬區(qū)域。然后，根據歸屬運營商的所屬區(qū)域內運營商號碼對應的碼表識別出該歸屬運營商對應的運營商ID。例如，“+86”屬于中國區(qū)域(區(qū)域尋址)，以“186”、“185”、“130”開頭號碼為聯通，以“135”至“138”開頭的號碼為移動，以“189”、“180”開頭的號碼為電信(運營商歸屬尋址)。

在步驟S3中，當判斷出本接入運營商與歸屬運營商相同時，則執(zhí)行步驟S5；當判斷出本接入運營商與歸屬運營商不同時，則執(zhí)行步驟S4。

步驟S4、本地接入運營商將認證請求信息轉發(fā)給歸屬運營商。

當步驟S3中判斷出本地接入運營商與歸屬運營商不同，但是兩者同區(qū)域時，則步驟S4具體包括：

步驟S401a、本地接入運營商將認證請求信息通過代理轉發(fā)機制，基于共同協議，由預定義的端口將認證請求信息發(fā)送至歸屬運營商。

本實施例中可選地，同歸屬區(qū)域中的不同運營商之間的通信協議采用OAuth2.0協議。

當步驟S3中判斷出本地接入運營商與歸屬運營商不同，且區(qū)域不同時，步驟S4具體包括：

步驟S401b、本地接入運營商將認證請求信息發(fā)送至其自身的所屬區(qū)域的第一安全網關。

步驟S402b、第一安全網關按照國際數據短信格式對認證請求信息進行二次封裝，并經過國際數據短信通道發(fā)送至歸屬運營商的所屬區(qū)域的第二安全網關。

在本實施例中，運營商可以利用短信網關進行用戶身份信息的傳遞，相較于開放的互聯網環(huán)境，大大降低了用戶信息泄露的風險

步驟S403b、第二安全網關將接收到的短信數據進行解封，并將解封后得到的認證請求信息發(fā)送安全域內的優(yōu)先接入運營商。

其中，該優(yōu)先接入運營商可以是隨機指派的運營商，也可以根據用戶規(guī)模指派的運營商。

步驟S404b、優(yōu)先接入運營商根據認證請求信息中的手機號，獲取歸屬運營商的運營商ID。

需要說明的是，在步驟S404b中優(yōu)先接入運營商根據認證請求信息中的手機號獲取歸屬運營商的運營商ID的過程，可采用上述步驟S301(區(qū)域尋址)和步驟S302中(運營商歸屬尋址)所示的過程，從而提升尋址速度。

步驟S405b、優(yōu)先接入運營商判斷其自身的運營商ID與歸屬運營商的運營商ID是否相同。

若判斷結果為是，則說明優(yōu)先接入運營商即為歸屬運營商，此時執(zhí)行步驟S5。若判斷結果為否，則說明優(yōu)先接入運營商不為歸屬運營商，此時執(zhí)行步驟S406b。

步驟S406b、優(yōu)先接入運營將歸屬運營商的運營商ID和認證請求信息反饋至第二安全網關。

考慮服務提供商與跨域運營商之間缺少信任基礎，為了安全性保障需要采用重定向機制進行交互。即優(yōu)先接入運營判斷出其自身不為歸屬運營商后，則會將歸屬運營商的運營商ID和認證請求信息反饋至第二安全網關。

步驟S407b、第二安全網關根據接收到的歸屬運營商的運營商ID將認證請求信息發(fā)送至歸屬運營商。

步驟S5、歸屬運營商根據認證請求信息中的身份信息對用戶進行身份認證，并將認證結果反饋給服務提供商。

在步驟S5中，歸屬運營商可根據實際情況，例如用戶終端類型、SP業(yè)務級別、用戶級別、SIM卡品種等因素，提供不同類型認證服務。以基于SIM卡應用的認證為例，認證平臺向終端卡應用下發(fā)數據短信，用戶在手機彈窗中點擊確認、輸入PIN碼、輸入密碼或者指紋識別等信息，如果輸入信息SIM卡中存儲的身份信息匹配即認證成功，否則可能出現各種類型的認證錯誤或者認證失敗。

在本實施例中，可選地，認證結果的可包括如下幾種情況：

00：認證成功。

01：認證失敗。

02：用戶ID不存在。

03：參數錯誤。

04：請求超時。

05：用戶ID未開通。

06：系統標識不存在。

需要說明的是，認證結果包括上述7種不同狀態(tài)的情況僅起到示例性作用，其不會對本發(fā)明的技術方案產生限制。本領域技術人員應該知曉的是，可根據實際需要對上述認證結果所包含的情況進行相應調整。

當步驟S3中判斷出本地接入運營商與歸屬運營商相同時，歸屬運營商在對用戶進行身份認證之后，直接將認證結果反饋給服務提供商。

當步驟S3中判斷出本地接入運營商與歸屬運營商不同，但是兩者同區(qū)域時，則步驟S5具體包括：

步驟S501a、歸屬運營商根據認證請求信息中的身份信息對用戶進行身份認證。

需要說明的是，在現有技術中，利用運營商的卡號資源已經開發(fā)了非常成熟且安全級別很高的認證系統，如短信驗證碼、SIM卡彈窗認證、USSID等，并且結合終端技術可以開展各種多類型的認證方式，包括指紋認證、人臉認證等。從而可以提供多類型的認證方式，對認證安全性和便攜性進行權衡。具體驗證過程，此處不再詳細描述。

步驟S502a、歸屬運營商將認證結果反饋至本地接入運營商。

步驟S503a、本地接入運營商將認證結果反饋至服務提供商。

由上述步驟S501a～步驟S503a可見，本地接入運營商與歸屬運營商不同且兩者同區(qū)域時，歸屬運營商的回傳路徑即為：歸屬運營商→本接入運營商→服務提供商。

當步驟S3中判斷出本地接入運營商與歸屬運營商不同區(qū)域時，則步驟S5包括：

步驟S501b、歸屬運營商根據認證請求信息中的身份信息對用戶進行身份認證。

步驟S502b、歸屬運營商將認證結果反饋至第二安全網關。

步驟S503b、第二安全網關通過國際數據短信通道將認證結果反饋至第一安全網關。

步驟S504b、第一安全網關將認證結果反饋至本地接入運營商。

步驟S505b、本地接入運營商將認證結果反饋至服務提供商。

由上述步驟S501b～步驟S505b可見，本地接入運營商與歸屬運營商不同且兩者不同區(qū)域時，歸屬運營商的回傳路徑即為：歸屬運營商→第二安全網關→第一安全網關→本接入運營商→服務提供商。

步驟S6、服務提供商根據接收到的認證結果執(zhí)行同意用戶接入或拒絕用戶接入。

以上述認證結果包括上述7種不同狀態(tài)的情況為例。

當認證結果為“認證成功”時，則用戶身份真實且可信，用戶可以訪問業(yè)務平臺(服務提供商的業(yè)務平臺)。

當認證結果為“認證失敗”時，則業(yè)務平臺提示用戶登錄失敗，可重新發(fā)送請求。

當認證結果為“用戶ID不存在”時，則業(yè)務平臺提示用戶ID錯誤，拒絕用戶接入。

當認證結果為“參數錯誤”時，則業(yè)務平臺修改參數后重新提交驗證請求，拒絕用戶接入。

當認證結果為“請求超時”時，則認證過程中用戶端在指定時限內未做出應有反應，業(yè)務平臺拒絕用戶接入。

當認證結果為“用戶ID未開通”時，則歸屬運營商中沒有用戶信息，業(yè)務平臺拒絕用戶接入。

當認證結果為“系統標識不存在”時，則歸屬運營商中沒有該業(yè)務平臺信息，業(yè)務平臺拒絕用戶接入。

本實施例中以手機號碼作為用戶身份唯一標識，在全球范圍內具有很高的普適性，并且運營商受到國家部門的監(jiān)管，既簡化了用戶接入流程，又保證了用戶身份在全球范圍內的可信度。與此同時，利用SIM卡能力以及終端技術提供多類型高安全級別認證服務，認證安全性和便捷性得到有效保障。另外，用戶關鍵信息通過短信網關傳遞，相較于開放的互聯網環(huán)境，大大降低了用戶信息泄露的風險。

本發(fā)明將全球運營商按地域劃分為不同的安全域，每個安全域內共享一個安全網關負責對外域數據的過濾轉發(fā)，在處理同域內運營商間的認證交互采用代理轉發(fā)機制，跨域間的交互采用的重定向的機制。兩種機制的配合，在盡可能保證安全性和便捷性的前提下實現了全球運營商之間的互聯互通，從而覆蓋了所有類型面向全球互聯的用戶接入場景。并且服務提供商只與最可信的接入運營商單點式交互，減少了服務提供商接口開發(fā)的成本，更方便對接入控制的一點式管理。

需要補充說明的是，本實施例中將用戶的手機號作為用戶的身份信息的情況為本發(fā)明的優(yōu)選實施方式，其不會對本發(fā)明的技術方案產生限制。本領域技術人員應該知曉的是，但凡能夠作為用戶身份的唯一標識的信息均可作為身份信息，例如：用戶的郵箱號、用戶的身份證ID(例如：美國的社會安全號碼、中國的居民身份證號)、自定義的身份ID。

當采用用戶的郵箱號作為身份信息時，本地接入運營商可先根據郵箱號的后綴以獲取歸屬運營商的所屬區(qū)域(例如：163.com、126.com、xxx.cn所屬區(qū)域為中國，netzero.net、cs.com均所屬區(qū)域為美國)，若該郵箱號對應的歸屬運營商與本地接入運營商屬于相同區(qū)域，則本地接入運營商根據預先設置好的郵箱號-運營商ID對應對應表查詢出該郵箱號對應的歸屬運營商的運營商ID，并將認證請求信息發(fā)送給歸屬運營商以進行認證。若該郵箱號對應的歸屬運營商與本地接入運營商屬于不同區(qū)域，則本地接入運營商將認證請求信息發(fā)送給對應區(qū)域中的優(yōu)先接入運營商，并由優(yōu)先接入運營商確認郵箱號對應的歸屬運營商的運營商ID，同時將認證請求信息發(fā)送給歸屬運營商以進行認證。需要說明的是，在采用郵箱號作為身份信息時，需要用戶預先將郵箱號在相應的運營商處進行注冊，且各區(qū)域的優(yōu)先接入運營商(本地接入運營商)存儲有所屬區(qū)域內郵箱號與運營商ID的對應關系表。

當采用用戶的身份證ID作為身份信息，則本地接入運營商通過號碼的位數和形式可以識別出所屬的國家，然后轉入所屬區(qū)域的本地接入運營商，本地接入運營商根據預先設置好的身份證ID-運營商ID對應關系表查詢出歸屬運營商的運營商ID，并將認證請求信息發(fā)送給歸屬運營商以進行認證。

當采用用戶自定義的身份ID作為身份信息時，需要用戶在向服務提供商輸入身份信息時自己選擇歸屬運營商，例如，可以做個二級菜單，選擇歸屬運營商的區(qū)域，然后選擇運營商名稱。這樣用戶可以用自定義的身份ID登錄，服務提供商和本地接入運營商會把認證請求信息轉發(fā)至歸屬運營商(用戶需提前在歸屬運營商處對身份ID進行了注冊)，歸屬運營商基于接收到的身份ID可對用戶進行認證。

在本實施例中，用戶的身份信息可由服務提供商自動獲取，也可由用戶自行輸入。此外，對于其他可適用的身份信息，此處不再一一舉例說明。

實施例二

圖2為本發(fā)明實施例二提供的一種用戶接入系統的機構示意圖，如圖2所示，該用戶接入系統用于實現上述實施例一中的用戶接入方法，該用戶接入系統包括：

服務提供商，用于接收用戶的接入請求信息，并將服務提供商將接入請求信息封裝成認證請求信息，并將認證請求信息發(fā)送至服務提供商對應的本地接入運營商，其中，接入請求信息包括：請求信息和用戶的身份信息。

本地接入運營商，用于根據認證請求信息中的身份信息，判斷本地接入運營商是否為用戶對應的歸屬運營商，并在判斷出本地接入運營商為用戶對應的歸屬運營商時，根據認證請求信息中的身份信息對用戶進行身份認證，以及在判斷出本地接入運營商不為用戶對應的歸屬運營商時，將認證請求信息轉發(fā)給歸屬運營商。

歸屬運營商，用于根據認證請求信息中的身份信息對用戶進行身份認證，并將認證結果反饋給服務提供商。

服務提供商，還用于根據接收到的認證結果執(zhí)行同意用戶接入或拒絕用戶接入。

可選地，身份信息為用戶的手機號。

需要說明的是，本實施例中的服務提供商用于執(zhí)行上述實施例一中的步驟S1、步驟S2和步驟S6，本實施例中的本地接入運營商用于執(zhí)行上述實施例3和步驟S4，歸屬運營商用于執(zhí)行上述實施例一中的步驟S5，具體內容可參見上述實施例一中的描述，此處不再贅述。

此外，附圖中本地接入運營商與歸屬運營商為兩個獨立結構的情況，僅起到示例性作用，本領域技術人員應該知曉的是，本實施例中本地接入運營商和歸屬運營商也可能為同一運營商。

可選地，本地接入運營商包括：獲取模塊、查詢模塊和判斷模塊。

其中，獲取模塊用于根據ENUM電話號碼映射協議識別出手機號第1～3位數字作為國家碼，以獲取歸屬運營商的所屬區(qū)域；

查詢模塊，用于根據歸屬運營商的所屬區(qū)域內運營商號碼對應的碼表識別出用戶歸屬運營商對應的運營商ID；

判斷模塊用于根據歸屬運營商的所屬區(qū)域和運營商ID，判斷本地接入運營商是否為用戶對應的歸屬運營商；其中，若本地接入運營的所屬區(qū)域和運營商ID與歸屬運營商的所屬區(qū)域和運營商ID均相同，則判斷出本地接入運營商是用戶對應的歸屬運營商；若本地接入運營的所屬區(qū)域與歸屬運營商的所屬區(qū)域相同，且本地接入運營的運營商ID與歸屬運營商的運營商ID不同，則判斷出本地接入運營商與歸屬運營商不同，但是兩者同區(qū)域；若本地接入運營的所屬區(qū)域與歸屬運營商的所屬區(qū)域不同，且本地接入運營的運營商ID與歸屬運營商的運營商ID不同，則判斷出本地接入運營商與歸屬運營商不同區(qū)域。

進一步可選地，本地接入運營商還包括：第一發(fā)送模塊和第二發(fā)送模塊。

其中，第一發(fā)送模塊用于當判斷模塊判斷出本地接入運營商與歸屬運營商不同，但是兩者同區(qū)域時，將認證請求信息通過代理轉發(fā)機制，基于共同協議，由預定義的端口將認證請求信息發(fā)送至歸屬運營商。

第二發(fā)送模塊用于當判斷模塊判斷出本地接入運營商與歸屬運營商不同區(qū)域時，將認證請求信息發(fā)送至其自身的所屬區(qū)域的第一安全網關。

用戶接入系統還包括：第一安全網關和第二安全網關。

其中，第一安全網關，用于按照國際數據短信格式對認證請求信息進行二次封裝，并經過國際數據短信通道發(fā)送至歸屬運營商的所屬區(qū)域的第二安全網關。

第二安全網關，用于將接收到的短信數據進行解封，并將解封后得到的認證請求信息發(fā)送安全域內的優(yōu)先接入運營商。

優(yōu)先接入運營商，用于根據認證請求信息中的手機號，獲取歸屬運營商的運營商ID，并判斷其自身的運營商ID與歸屬運營商的運營商ID是否相同；其中，若判斷結果為否，則優(yōu)先接入運營將歸屬運營商的運營商ID和認證請求信息反饋至第二安全網關，第二安全網關根據接收到的歸屬運營商的運營商ID將認證請求信息發(fā)送至歸屬運營商。

需要說明的是，附圖中優(yōu)先接入運營商與歸屬運營商為兩個獨立結構的情況，僅起到示例性作用，本領域技術人員應該知曉的是，本實施例中優(yōu)先接入運營商和歸屬運營商也可能為同一運營商。

此外，本實施例中的本地接入運營商、優(yōu)先接入運營商和歸屬運營商具有相同的結構。

本實施例中的獲取模塊用于執(zhí)行上述實施例一中的步驟S301，本實施例中的查詢模塊用于執(zhí)行上述實施例一中的步驟S302，本實施例中的判斷模塊用于執(zhí)行上述實施例一中的步驟S303，第一發(fā)送模塊用于執(zhí)行上述實施例一中的步驟S401a，第二發(fā)送模塊用于執(zhí)行上述實施例一中的步驟S401b，第一安全網關用于執(zhí)行上述實施例一中的步驟S402b，第二安全網關用于執(zhí)行上述實施例一中的步驟S403b，具體內容可參見上述實施例一中的描述，此處不再贅述。

在本實施例中，當本地接入運營判斷出本地接入運營商與歸屬運營商不同，但是兩者同區(qū)域時，則在歸屬運營商根據認證請求信息中的身份信息對用戶進行身份認證之后，歸屬運營商還用于將認證結果反饋至本地接入運營商。本地接入運營商還用于將認證結果反饋至服務提供商。

在本實施例中，當本地接入運營判斷出本地接入運營商與歸屬運營商不同區(qū)域時，則在歸屬運營商根據認證請求信息中的身份信息對用戶進行身份認證之后，歸屬運營商還用于將認證結果反饋至第二安全網關，第二安全網關還用于通過國際數據短信通道將認證結果反饋至第一安全網關，第一安全網關還用將認證結果反饋至本地接入運營商，本地接入運營商還用于將認證結果反饋至服務提供商。

上述歸屬運營商將認證結果反饋至服務提供商的過程，可參見上述實施例一中對步驟S502a～步驟S503a，以及步驟S502b～步驟S505b的相應描述，此處不再贅述。

可以理解的是，以上實施方式僅僅是為了說明本發(fā)明的原理而采用的示例性實施方式，然而本發(fā)明并不局限于此。對于本領域內的普通技術人員而言，在不脫離本發(fā)明的精神和實質的情況下，可以做出各種變型和改進，這些變型和改進也視為本發(fā)明的保護范圍。