WO2012126299A1 - 组合认证***及认证方法 - Google Patents

组合认证***及认证方法 Download PDF

Info

Publication number
WO2012126299A1
WO2012126299A1 PCT/CN2012/071198 CN2012071198W WO2012126299A1 WO 2012126299 A1 WO2012126299 A1 WO 2012126299A1 CN 2012071198 W CN2012071198 W CN 2012071198W WO 2012126299 A1 WO2012126299 A1 WO 2012126299A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
architecture
idp
information
sso
Prior art date
Application number
PCT/CN2012/071198
Other languages
English (en)
French (fr)
Inventor
张孟旺
田甜
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2012126299A1 publication Critical patent/WO2012126299A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless

Definitions

  • the present invention relates to a single sign-on (SSO) architecture and an OpenID architecture fusion technology, and more particularly to an SSO architecture and an OpenID architecture fusion system, and an authentication method applied to the fusion system.
  • SSO single sign-on
  • the terminal uses the SIP (Session Initiation Protocol) digest authentication mechanism to implement the SSO function of the IMS terminal accessing the application server (AS, Application Server).
  • SIP Session Initiation Protocol
  • AS Application Server
  • SSO architecture designed in the SSO_APS can implement the function.
  • the SSO architecture is usually composed of a unified IMS user, a Home Subscriber Server (HSS), an AS, and an Identity Authentication Provider Entity (MP).
  • the user equipment (UE, User Equipment) is connected to the IdP through the SSOb interface; the UE and the AS are connected through the SSOa interface; the IdP and the HSS are connected through the SSOh interface.
  • the IdP is used to authenticate the identity with the UE using the SIP Digest, and authenticates the AS, and the shared key between the IdP and the user is.
  • the HSS stores a subscription file for describing user information, and the HSS also has the function of generating authentication information.
  • the AS provides network service services for the UE.
  • the operator is not deployed with the Generic Bootstrapping Architecture (GBA), and the IMS terminal does not have a Universal Integrated Circuit Card (UICC).
  • the UE is authenticated by the SIP Digest authentication mechanism.
  • the SSO function of the IMS terminal to the AS is as follows:
  • the IMS terminal sends a Hypertext Transfer Protocol (HTTP) service request to the AS, and the application server AS responds to the UE with a 401 Unauthorized Hypertext Transfer Protocol Secure (HTTPS) response requesting the UE.
  • HTTP Hypertext Transfer Protocol
  • the terminal goes to the authentication center to perform identity authentication.
  • the response includes the AS identity information encrypted by the AS and the authentication center MP shared key.
  • the UE terminal sends an HTTP request message to the authentication center IdP, requesting the IdP to perform identity authentication on the UE terminal.
  • the message carries the identity of the UE terminal and the encrypted AS identity information.
  • the IdP authenticates the AS according to the obtained AS private identity identifier, stores the authentication result, and determines whether there is a corresponding UE.
  • the IdP determines that there is no Ko corresponding to the UE, the IdP is based on the IMS identity information.
  • the HSS obtains the SIP Digest authentication vector and the UE information content; the IdP generates a random number nonce, and stores the nonce and the hash function value H (A1) downloaded from the HSS; IdP sends a 401 authentication challenge to the UE using the SIP Digest mechanism; The number cnonce and the generated H (A1), which in turn generate the key.
  • the UE sends a response to the IdP for the challenge, the IdP completes the authentication of the UE, and generates the shared key Ko; the IdP again generates the random number nonce 1 , using the nonce 1 and .
  • the shared key encryption is generated.
  • the IdP encrypts the information such as noncel with the key Ko, and uses the IdP and the AS to share the key encryption and the UE authentication result.
  • the IdP sends a 200 OK message to the UE, and if the 200 OK message includes the information such as the Ko encryption noncel.
  • the UE indicates that the UE is successfully authenticated; the IdP encrypts the AS and the IdP shared key and redirects the authentication result of the UE to the AS; the UE decrypts the noncel and generates the shared key; and the AS decrypts the information to obtain the UE.
  • the authentication result and the key; at this time, the shared key i is shared between the UE and the AS, so that subsequent communication between the two can be encrypted to ensure communication security between the two.
  • OpenID also defines its own architecture and specifications for accessing Web services. Its architecture mainly includes three entities: UE, OpenID Identity Providing Entity (OP, OpenID Provider), and Service Dependent Provider (RP).
  • UE OpenID Identity Providing Entity
  • OP OpenID Provider
  • RP Service Dependent Provider
  • the OpenID architecture utilizes a user identifier that is distributed when each end user has registered with the OpenID Provider.
  • the user identifier only needs to be input, and the RP pairs the identifier. Standardization; then the RP uses the discovery mechanism, and the identifier obtains the OP's Uniform I Universal Resource Locator; the association between the RP and the OP, so that a shared key is established between the OP and the RP. The key causes the OP to mark subsequent messages, so that the RP identifies subsequent messages.
  • the association process is optional. When the OP and the RP are in different mobile network operator (MNO, Mobile Network Operator) networks, the process is generated.
  • MNO Mobile Network Operator
  • the shared key is important for secure transmission of the message; the RP requests the OP to authenticate the UE; the OP establishes whether it is authorized to perform OpenID authentication and is expected to be authorized to use according to the authorization information of the UE, and the OP is based on the authorization information of the UE. , complete the authentication process for the OpenID user, and generate an authentication assertion based on the authentication result and return it to the RP; RP pair The assertion performs a confirmation operation to determine whether to provide services for the UE.
  • the final AS obtains the shared key and the terminal authentication result authorization information
  • the OpenID architecture supports the Web service, and provides each UE with a unique identity identifier; if the two architectures can achieve interworking, both It does not reduce the original security, but also increases the simplicity of the terminal operation, and can extend the application scenario of the terminal, so as to use the existing various WEB services.
  • the 3GPP specification 33.924 defines a scenario in which the GBA architecture and the OpenID architecture implement interworking, that is, a network application function (NAF, Network Application Function) and an OP are entities. Its characteristics are that the Ub and Zn interface functions of the original GBA architecture are basically unchanged, and the OP and UE of the OpenID architecture need to add GBA functions.
  • the UE accesses each RP, it first passes the authentication on the OP/NAF, and the authentication process on the OP/NAF requires the UE and the Bootstrapping Server Function (BSF) to perform the boot process.
  • BSF Bootstrapping Server Function
  • the main purpose of the present invention is to provide a combined authentication system and an authentication method, which can integrate the SSO architecture and the OpenlD architecture to provide a richer WEB service for the UE.
  • a combined authentication system includes an SSO architecture and an OpenlD architecture.
  • the SSO architecture and the OpenlD architecture implement interworking between the application server AS in the shared SSO architecture and the OpenlD identity providing entity OP in the OpenlD architecture.
  • the OpenlD architecture further includes a service dependent provider RP; wherein the RP is configured to: after receiving the service request of the IP multimedia service subsystem IMS user equipment UE, carry the OpenlD authentication request to redirect the UE To the OP;
  • the OP is configured to: after receiving the UE hypertext transfer protocol HTTP acquisition request, return an unauthorized response to the UE, requesting the UE to use the initial session digest authentication SIP Digest mechanism in the SSO architecture. Certification
  • the UE is configured to implement SIP Digest authentication by using the SSO architecture when the SIP Digest authentication is not implemented.
  • the OP is further configured to: obtain the authorization information of the UE after the SIP Digest authentication, complete OpenlD authentication to the UE according to the authorization information of the UE, and generate an authentication assertion according to the authentication result; send the authentication assertion Giving the RP;
  • the RP is further configured to provide the UE with a service when the assertion is correct.
  • the RP is further configured to: after receiving the service request of the UE, based on The identifier information of the UE carried in the service request obtains the address information of the OP and discovers the OP endpoint URL, and completes the authentication of the UE by using the URL.
  • the key for communication security protection is further negotiated before the information exchange between the RP and the OP.
  • the SSO architecture further includes a home subscriber server HSS and an identity authentication provider entity IdP;
  • the AS is configured to request the UE to perform the IdP de-authentication, where the request authentication information flow includes identifier information of the UE and the AS;
  • the IdP is configured to authenticate the AS according to the identifier information of the AS, and store the AS authentication result, and obtain the SIP Digest authentication vector and the UE from the HSS when the UE is confirmed not to have SIP Digest authentication.
  • Information content generating a random number nonce; sending an authentication challenge to the UE;
  • the UE is configured to generate a random number cnonce and generate a hash function value, thereby generating a shared key Ko, and replying to the IdP response;
  • the IdP is configured to complete the authentication of the UE after receiving the response of the UE, and generate the IdP. And, again, generate a random number of nonce 1 , using noncel and .
  • the IdP sends a 200 OK message to the UE, and the 200 OK message includes. Encrypting information such as noncel, indicating that the UE is successfully authenticated; and the IdP redirects the information encrypted by the shared key between the AS and the IdP to the AS;
  • the UE is further configured to: after obtaining the 200 OK message, generate, to have a shared key Ki between the UE and the AS.
  • An authentication method is applied to a system in which an SSO architecture and an OpenID architecture are integrated, wherein the SSO architecture and the OpenID architecture implement convergence and interworking by sharing an AS in an SSO architecture and an OP in an OpenID architecture; include: After receiving the service request of the IMS UE, the RP carries an OpenID authentication request to redirect the UE to the OP;
  • the OP After receiving the HTTP acquisition request of the UE, the OP returns an unauthorized response to the UE, and requires the UE to perform authentication by using an initial session authentication SIP Digest mechanism in the SSO architecture.
  • the UE implements SIP Digest authentication through the SSO architecture when the SIP Digest authentication is not implemented.
  • the RP confirms that the assertion is correct when the UE is served.
  • the method further includes:
  • the RP After receiving the service request of the UE, the RP obtains the address information of the OP and discovers the OP endpoint URL based on the identifier information of the UE carried in the service request, and completes the location by using the URL.
  • the authentication of the UE After receiving the service request of the UE, the RP obtains the address information of the OP and discovers the OP endpoint URL based on the identifier information of the UE carried in the service request, and completes the location by using the URL. The authentication of the UE.
  • the method further includes:
  • the UE implements SIP Digest authentication by using the SSO architecture when the SIP Digest authentication is not implemented, as follows:
  • the AS will request the UE to authenticate to the authentication center IdP, and request the authentication information flow to include the identification information of the UE and the AS.
  • the IdP authenticates the AS according to the identifier information of the AS, and stores the AS authentication result, and obtains the SIP Digest authentication vector, the information content of the UE, and the information from the HSS when the UE is not authenticated by the SIP Digest.
  • a hash function value generating a random number nonce; sending an authentication challenge to the UE;
  • the UE generates a random number cnonce and generates a hash function value, thereby generating a shared key Ko, and replies to the IdP response;
  • the IdP After receiving the response of the UE, the IdP completes the authentication of the UE, and generates a Ko and, again, generates a random number noncel, using noncel and . Generate the key i and use .
  • the IdP After the information such as noncel is encrypted, and the shared key pair between the AS and the IdP is used and the authentication result of the UE is encrypted, the IdP sends a 200 OK message to the UE, and the 200 OK message includes.
  • the information such as noncel is encrypted, indicating that the UE is successfully authenticated; and the IdP redirects the use.
  • the UE After obtaining the 200 OK message, the UE generates a shared key between the UE and the AS.
  • the SSO architecture and the OpenID architecture are implemented by sharing the AS in the SSO architecture and the OP in the OpenID architecture, so that when the UE initiates a service request to the OpenID architecture, the OpenID architecture triggers the SIP initiated by the UE to the SSO architecture.
  • Digest while strengthening the supervision of UE users, also provides a richer WEB service for users under the SSO architecture. DRAWINGS
  • FIG. 1 is a schematic structural diagram of a system for integrating a SSO architecture and an OpenID architecture according to the present invention
  • FIG. 2 is a flowchart of an authentication method applied to the system shown in FIG. 1. detailed description
  • the basic idea of the present invention is that the SSO architecture and the OpenID architecture are implemented by sharing the AS in the SSO architecture and the OP in the OpenID architecture, so that when the UE initiates a service request to the OpenID architecture, the OpenID architecture triggers the UE to initiate the SSO.
  • the SIP Digest of the architecture provides a richer WEB service for users under the SSO architecture while strengthening the supervision of UE users.
  • FIG. 1 is a schematic structural diagram of a system in which an SSO architecture and an OpenID architecture are merged according to the present invention.
  • the present invention proposes a combined authentication and authentication architecture to implement interworking between an SSO architecture and an OpenID architecture in SSO_APS, and to satisfy UlCCless.
  • the unified IMS terminal in the environment uses the combined authentication architecture to implement the SSO function on the application server, wherein the UE is an IMS terminal, and the application server entity on the SSO architecture in the OpenID provider entity (OP) and the SSO_APS is an entity, that is, an OP.
  • OP OpenID provider entity
  • the RP corresponds to the final application server of the OpenID of the converged system to be accessed by the IMS terminal
  • the IdP is the user authentication center
  • the authentication of the UE in the SSO architecture in the SSO_APS is completed.
  • the network elements in the SSO architecture and the OpenID architecture basically maintain the original functions and structures, and the change is greater in the integration of the OP and the AS.
  • the functions that can be implemented by the foregoing network elements are all in the prior art, and the functions and specific structures of the network elements are not described herein.
  • the present invention only describes how the UE implements authentication in the above-described converged system.
  • FIG. 2 is a flowchart of an authentication method applied to the system shown in FIG. 1. As shown in FIG. 2, the authentication method of the present invention specifically includes the following steps:
  • Step 1 The user sends the user provider identifier (User-supplied) through the UE's browser.
  • Identifier sends a service request to the RP.
  • Step 2 The RP initializes the User-Supplied Identifier, obtains an OP address and a Uniform I Universal Resource Locator based on the user provider identifier, and the UE wants to use the URL to complete the authentication.
  • Step 3 A shared key is established between the RP and the OP by using a Diffie-hdlman key exchange protocol.
  • the shared key is established so that the OP can encrypt subsequent messages, and the RP can confirm the received message (this key is optional) Attributes, not the necessary operations for interworking).
  • the negotiation key is necessary if both the OP and the RP are located in the control domain of a different mobile network operator (MNO, Mobile Network Operator).
  • MNO Mobile Network Operator
  • Step 4 The RP carries the OpenID authentication request to redirect the UE's browser to the OP. RP will The User-Supplied Identifier received in step 1 is inserted into the openid. claimed_id and openid.identity fields in the OpenID authentication request message.
  • Step 5 Following the redirection, the UE sends an HTTP GET request to the OP.
  • Step 6 The OP/AS initializes the UE authentication, and responds to the 401 unauthorised HTTPS response.
  • the HTTPS response message includes an authentication message header carrying the challenge information, and the UE uses the SIP Digest mechanism to authenticate with the server.
  • the shared key K is shared between OP/AS and IdP using existing mechanisms. i, since the acquisition of the Ko'i belongs to the prior art, the present invention will not repeat the implementation details of obtaining it.
  • Step 7 If the UE does not have a valid key Ko available, the UE sends an HTTP request message to the IdP to perform an identity authentication process for the UE, and the HTTP request message carries the identity identifier (U_credential) and the EK of the UE. ,i ( OP/AS_credential ).
  • Step 8 IdP decrypts E. , i ( OP / AS_credential ), obtains the OP/AS identity, authenticates the OP/AS based on the OP/AS identity, and generates and stores the OP/AS authentication result OP/AS_Auth.
  • the IdP first checks whether there is a UE and IdP shared key Ko corresponding thereto according to the received UE identity identifier U_credential. If yes, skip to step 15 otherwise, otherwise go to step 9.
  • Step 9 The IdP sends an authentication request to the HSS. Based on the U_credential, the IdP to the HSS finds and downloads the corresponding SIP Digest authentication vector (SD-AV) and user configuration information.
  • SD-AV includes U_credential, realm, Qop, algorithm, and H(A1), where H(A1) is a hash function value consisting of U_credentiaK realm and password (assword).
  • the IdP can obtain the HSS address corresponding to the stored user information by querying the Subscription Locator Function (SLF) to find the corresponding HSS.
  • SPF Subscription Locator Function
  • Step 10 IdP generates a random number nonce, and will target the U_credential from the HSS
  • the downloaded H (Al) is stored with the nonce.
  • Step 11 The IdP sends a 401 unauthenticated challenge message to the UE, where the 401 unauthenticated challenge message includes U_credential, realm, qop, algorithm, and nonce.
  • Step 13 The UE sends a response message response to the IdP for the challenge message in step 11, where the response message includes cnonce, nonce, response, realm, U_credential, qop, algorithm, Digest-url, and nonce-count.
  • Step 14 After receiving the response message in step 13, the IdP uses the stored nonce value to check the nonce value in the response message. If the check is correct, the IdP uses the parameters cnonce, nonce-count in the received response message. Qop and the original 4 nonce and H(Al) in the IdP calculate Xresponse, compare the calculated Xresponse with the received response value, if the comparison result is the same, the UE passes the authentication; otherwise, the UE authentication fails, IdP The authentication result related information UE_Auth of the UE is stored. If the UE authentication is successful, IdP uses H (Al ) and cnonce to generate a shared key K.
  • Step 15 IdP regenerates the random number noncel; then utilizes. And noncel, etc. generate key ⁇ i; shared key.
  • the encryption operation of information such as noncel generates E 3 ⁇ 4 (noncel ); the key K is shared by OP/AS and IdP.
  • i encryption and UE_Auth generate E. ,i ( ⁇ , UE_Auth ) 0
  • Step 16 the IdP sends a 200 OK message to the UE, where the 200 OK message includes information such as Ko encryption noncel, indicating that the UE is successfully authenticated; and the IdP redirects the UE to the OP/AS; Carry E in the message. ,i ( Ki , UE_Auth ).
  • Step 17 The UE decrypts EKo (noncel), obtains a noncel value, and generates a key ⁇ by using and noncel.
  • Step 18 The message sent by the IdP is redirected to the OP/AS, and the redirected message carries ⁇ , ⁇ (K UE_Auth ).
  • Step 19 After receiving the redirected message, the OP/AS decrypts E by using the shared key. , i ( i , UE_Auth ), obtain and UE_Auth; the OP/AS learns the relevant authorization information of the UE according to the UE_Auth, and the OP/AS establishes according to the authorization information whether the UE is authorized to perform OpenID authentication and is expected to be authorized to use; A message about the type of information is learned from UE_Auth, which is allowed to be shared with the RP. Based on the authorization information of the UE, the OP/AS completes the authentication process for the OpenID user by using the SSOa shared by the UE and the OP/AS, and generates an authentication assertion according to the authentication result.
  • Step 20 The OP/AS redirects the browser to the return address of the OpenID, that is, the OP/AS redirects the browser of the UE to return to the RP, where the redirected response message carries the assertion that the authentication is approved, or the authentication fails. Assertion.
  • the redirect response message header contains a series of fields that define authentication assertion information, which are also protected by key encryption between the OP/AS and the RP. This key protection mechanism is especially important when both OP/AS and RP are on different MNO networks.
  • Step 21 The RP confirms the received assertion; that is, checks whether the authentication is approved.
  • the UE's authentication identity is provided in a response message to the RP. If both OP/AS and RP establish a shared key in step 3, then the key is now used to acknowledge the message from the OP/AS. If the assertion is positive for both the assertion and the information acknowledgement, then the UE will get the service of the RP.
  • the UE accessing the RP application server In the process of the UE accessing the RP application server, if the UE encounters an unexpected network disconnection, when the UE still The access service process between the UE and the RP is not completed. When the UE needs to access the application server after the network is restored, the request service process needs to be restarted. When the UE has completed the access service process, if the network recovery time does not reach the life of the cookie and the shared key. After the network is restored, the UE and the RP can continue to use the shared key and the cookie to obtain the application service. Otherwise, the shared key process needs to be regenerated. After the UE accesses the RP application server, if the user encounters a special situation such as the user actively shutting down the UE or powering off, the user needs to complete the entire execution process again.
  • a special situation such as the user actively shutting down the UE or powering off
  • the above-described key generation method may be any of the existing key generation methods, and the present invention is not limited to the key generation method employed.
  • the present invention achieves convergence by sharing the AS in the SSO architecture and the OP in the OpenID architecture through the SSO architecture and the OpenID architecture.
  • the OpenID architecture triggers the SIP Digest initiated by the UE to the SSO architecture. While strengthening the supervision of UE users, it also provides a richer WEB service for users under the SSO architecture.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

组合认证***及认证方法 技术领域
本发明涉及单点登录( SSO, Single Sign On )架构及 OpenID架构融合 技术, 尤其涉及一种 SSO架构及 OpenID架构融合***, 及应用于该融合 ***中的认证方法。 背景技术
目前第三代合作伙伴计戈1 J ( 3 GPP, 3rd Generation Partnership Project ) 组织提出了在非通用集成电路卡( UICC, Universal Integrated Circuit Card ) 环境下的统一 IP多媒体子***( IMS , IP Multimedia Subsystem )终端利用 会话初始协议 ( SIP, Session Initiation Protocol )摘要 ( Digest )认证机制实 现 IMS终端访问应用服务器(AS, Application Server ) 的 SSO的功能, 其 中, 通过在 SSO_APS中设计的 SSO架构可以实现该功能。 SSO架构通常 由统一 IMS用户、 归属用户服务器(HSS, Home Subscriber Server ), AS 和身份鉴权认证提供者实体( MP )构成。 用户设备 ( UE, User Equipment ) 与 IdP通过 SSOb接口连接; UE与 AS通过 SSOa接口连接; IdP与 HSS 通过 SSOh接口连接。 IdP用于与 UE利用 SIP Digest进行交互验证身份, 并且对 AS进行认证, IdP与用户之间的共享密钥为 。; HSS中存储用于描 述用户信息的签约文件, 同时 HSS还兼有产生鉴权信息的功能。 AS为 UE 提供网络服务业务。
在该 SSO_APS中的 SSO架构的实现方案中, 针对的是运营商未部署 通用认证机制 ( GBA, Generic Bootstrapping Architecture )的†青况, 同时 IMS 终端不具有通用集成电路卡(UICC, Universal Integrated Circuit Card )的场 景下, 利用会话初始协议摘要(SIP Digest )认证机制对 UE进行认证, 实 现该 IMS终端对 AS的 SSO功能, 具体实现如下:
IMS终端( UE )向 AS发送超文本传输协议 ( HTTP, Hypertext Transfer Protocol )服务请求, 应用服务器 AS向 UE回应一个 401未授权的超文本 传输安全协议(HTTPS , Hypertext Transfer Protocol Secure )响应, 要求 UE 终端去认证中心进行身份认证; 同时在该响应中包含由 AS和认证中心 MP 共享密钥加密的 AS身份信息; UE终端向认证中心 IdP发送 HTTP请求消 息, 请求 IdP对 UE终端进行身份认证。 同时该消息中携带 UE终端的身份 标识和加密的 AS身份信息; IdP依据获得到的 AS私有身份标识符对该 AS 进行认证, 存储认证结果, 同时判断是否存在对应 UE的 。, 若存在该密 钥则该 UE已认证过, 不需要再次利用 SIP Digest机制进行认证, 跳过该认 证直接执行后续步驟; 若 IdP判断不存在对应 UE的 Ko, 则 IdP基于 IMS 身份标识信息从 HSS取得 SIP Digest认证向量以及 UE信息内容; IdP产生 随机数 nonce, 并且存储该 nonce和从 HSS下载的哈希函数值 H ( A1 ); IdP 使用 SIP Digest机制向 UE发送 401认证挑战; UE产生随机数 cnonce和生 成 H ( A1 ), 进而产生密钥 。, 并利用参数计算响应值 response; UE针对 挑战向 IdP发送响应, IdP完成对 UE的认证, 并产生共享密钥 Ko; IdP再 次产生随机数 nonce 1 , 利用 nonce 1和 。产生共享密钥加密 , IdP利用密 钥 Ko加密 noncel等信息,利用 IdP和 AS共享密钥加密 和 UE认证结果, 所述 IdP向所述 UE发送 200OK消息,若 200OK消息中包含 Ko加密 noncel 等信息, 则表明所述 UE认证成功; 同时所述 IdP将 AS和 IdP共享密钥加 密的 和对 UE的认证结果重定向到 AS ; UE解密获得 noncel , 并产生共 享密钥 ; AS解密信息, 获得 UE的认证结果和密钥 ; 此时 UE和 AS 之间拥有共享密钥 i , 从而两者后续的通信可以利用 进行加密, 保证两 者之间的通信安全。
另外, OpenID也定义了自身架构和规范,用于实现对 Web业务的访问, 其架构主要包括三个实体: UE、 OpenID 身份提供实体 ( OP , OpenID Provider ), 服务依赖提供商 (RP )。
该 OpenID架构是利用每个终端用户都有在 OpenID Provider处注册时 分发的用户标识符, 当 UE访问支持 OpenID的服务依赖提供商 RP时, 只 需将该用户标识符输入, RP对该标识符进行标准化; 接着 RP利用发现机 制 , 以及标识符获得 OP的终点统一资源定位符 ( URL, Uniform I Universal Resource Locator ); RP和 OP之间进行关联,使得 OP和 RP之间建立共享 密钥, 该密钥使得 OP标记后续的消息, 使得 RP识别后续的消息, 该关联 过程是可选的,当 OP和 RP两者处于不同的移动网络运营商(MNO, Mobile Network Operator ) 网络时, 该过程产生的共享密钥对消息的安全传输是 4艮 重要的; RP请求 OP对该 UE进行认证; OP根据 UE的授权信息确立是否 其被授权执行 OpenID认证和期望被授权使用, OP依据 UE的授权信息, 完成对 OpenID 用户的认证过程, 并且根据认证结果产生认证断言返回给 RP; RP对该断言进行确认操作, 来决定是否为该 UE提供服务。
在 SSO_APS中 SSO架构中最终 AS获得共享密钥和终端认证结果授权 信息, 同时 OpenID架构支持 Web业务,并且为每个 UE提供唯一的身份标 识符; 若这两种架构之间能够实现互通, 既不会降低原有的安全性, 还可 以增加终端操作的简便性, 并能扩展终端的应用场景, 以便使用已有的多 种多样的 WEB业务。
目前 3GPP规范 33.924中定义了 GBA架构和 OpenID架构实现互通的 场景, 即网络应用功能( NAF, Network Application Function )和 OP为实 体。 其特点是原 GBA架构的 Ub和 Zn接口功能基本不变, OpenID架构的 OP和 UE需增加 GBA功能。 UE访问每个 RP时 , 首先在 OP/NAF上通过 鉴权认证, 而要在 OP/NAF上通过鉴权认证, 需要 UE和引导服务器功能 ( BSF, Bootstrapping Server Function )之间进行引导过程。 对于在非 UICC环境下的统一 IMS终端,其不能使用 GBA架构进行鉴 权认证,针对该类 IMS终端, 在 SSO_APS中设计了利用 SIP Digest机制实 现 SSO功能的架构, 目前亟需解决 SSO架构和 OpenlD架构之间不能融合 互通的问题, 使得该类 IMS终端支持 OpenlD机制, 进而获得多种多样的 WEB业务。 发明内容
有鉴于此, 本发明的主要目的在于提供一种组合认证***及认证方法, 能使 SSO架构及 OpenlD架构融合为 UE提供更丰富的 WEB业务。
为达到上述目的, 本发明的技术方案是这样实现的:
一种组合认证***, 包括 SSO架构及 OpenlD架构, 所述 SSO架构及 OpenlD架构之间通过共用 SSO架构中的应用服务器 AS和 OpenlD架构中 的 OpenlD身份提供实体 OP而实现融合互通。
优选地, 所述 OpenlD架构中还包括服务依赖提供商 RP; 其中, 所述 RP用于, 在接收到 IP多媒体业务子*** IMS用户设备 UE的服 务请求后, 携带 OpenlD认证请求重定向所述 UE到所述 OP;
所述 OP用于, 在接收到所述 UE超文本传输协议 HTTP获取请求后, 向所述 UE返回未授权的响应, 要求所述 UE使用所述 SSO架构中的初始 会话摘要认证 SIP Digest机制进行认证;
所述 UE用于, 在未实现所述 SIP Digest认证时, 通过所述 SSO架构 实现 SIP Digest认证;
所述 OP进一步用于, 获取 SIP Digest认证后所述 UE的授权信息, 根 据所述 UE的授权信息, 完成对所述 UE的 OpenlD认证, 并根据认证结果 产生认证断言; 将所述认证断言发送给所述 RP;
所述 RP进一步用于, 确认所述断言正确时为所述 UE提供服务。
优选地, 所述 RP进一步用于, 在接收到所述 UE的服务请求后, 基于 所述服务请求中携带的所述 UE的标识信息获得所述 OP的地址信息和发现 所述 OP终点 URL, 通过所述 URL完成对所述 UE的认证。
优选地, 所述 RP和所述 OP进行信息交互前, 进一步协商用于通信安 全保护的密钥。
优选地,所述 SSO架构中还包括归属用户服务器 HSS和身份鉴权认证 提供者实体 IdP; 其中,
所述 AS , 用于请求所述 UE到所述 IdP去认证, 其中请求认证信息流 中包含 UE和 AS的标识信息;
所述 IdP, 用于根据所述 AS的标识信息对该 AS进行认证, 并存储 AS 认证结果,并在确认所述 UE未经 SIP Digest认证时,从 HSS取得 SIP Digest 认证向量和所述 UE的信息内容, 产生随机数 nonce; 向所述 UE发送认证 挑战;
所述 UE, 用于产生随机数 cnonce和生成哈希函数值, 进而生成共享 密钥 Ko , 并向所述 IdP回复响应;
所述 IdP, 用于接收到所述 UE的响应后完成对所述 UE的认证, 并生 成 。; 以及, 再次产生随机数 nonce 1 , 利用 noncel和 。生成密钥 i , 并 利用 Ko加密 noncel等信息, 并利用 AS与 IdP之间的共享密钥对 和对 UE的认证结果进行加密后, 所述 IdP向所述 UE发送 200OK消息, 200OK 消息包含 。加密 noncel等信息, 表明所述 UE认证成功; 同时所述 IdP重 定向该利用 AS与 IdP之间的共享密钥加密后的信息到所述 AS;
所述 UE进一步用于, 在获得所述的 200OK消息后, 生成 , 使所述 UE和所述 AS之间拥有共享密钥 Ki。
一种认证方法, 应用于 SSO架构及 OpenID架构融合的***中, 其中, 所述 SSO架构及 OpenID架构之间通过共用 SSO架构中的 AS和 OpenID 架构中的 OP而实现融合互通; 所述方法还包括: 所述 RP在接收到 IMS UE的服务请求后, 携带 OpenID认证请求重定 向所述 UE到所述 OP;
所述 OP在接收到所述 UE的 HTTP获取请求后, 向所述 UE返回未授 权的响应, 要求所述 UE使用所述 SSO架构中的初始会话认证 SIP Digest 机制进行认证;
所述 UE在未实现所述 SIP Digest认证时,通过所述 SSO架构实现 SIP Digest认证;
所述 OP获取 SIP Digest认证后所述 UE的授权信息, 根据所述 UE的 授权信息,完成对所述 UE的 OpenID认证,并根据认证结果产生认证断言; 将所述认证断言发送给所述 RP;
所述 RP确认所述断言正确时为所述 UE提供服务。
优选地, 所述方法还包括:
所述 RP在接收到所述 UE的服务请求后, 基于所述服务请求中携带的 所述 UE的标识信息获得所述 OP的地址信息和发现所述 OP终点 URL,通 过所述 URL完成对所述 UE的认证。
优选地, 所述方法还包括:
所述 RP和所述 OP进行信息交互前, 协商用于通信安全保护的密钥。 优选地, 所述 UE在未实现所述 SIP Digest认证时, 通过所述 SSO架 构实现 SIP Digest认证, 为:
所述 AS将请求所述 UE到所述认证中心 IdP去认证, 请求认证信息流 中包含 UE和 AS的标识信息;
所述 IdP根据所述 AS的标识信息对该 AS进行认证, 并存储 AS认证 结果, 并在确认所述 UE未经 SIP Digest认证时, 从 HSS取得 SIP Digest 认证向量、 所述 UE的信息内容以及哈希函数值, 产生随机数 nonce; 向所 述 UE发送认证挑战; 所述 UE产生随机数 cnonce和生成哈希函数值,进而生成共享密钥 Ko , 并向所述 IdP回复响应;
所述 IdP接收到所述 UE的响应后完成对所述 UE的认证, 并生成 Ko 以及, 再次产生随机数 noncel , 利用 noncel和 。生成密钥 i , 并利用 。 加密 noncel等信息, 并利用 AS与 IdP之间的共享密钥对 和对 UE的认 证结果进行加密后, 所述 IdP向所述 UE发送 200OK消息, 200OK消息包 含 。加密 noncel等信息, 表明所述 UE认证成功; 同时所述 IdP重定向该 利用 。及 AS与 IdP之间的共享密钥加密后的信息到所述 AS;
所述 UE在获得所述的 200OK消息后,生成 使所述 UE和所述 AS 之间拥有共享密钥 。
本发明中, SSO架构及 OpenID架构之间通过共用 SSO架构中的 AS 和 OpenID架构中的 OP而实现融合,这样, UE向 OpenID架构发起业务请 求时, OpenID架构将触发 UE发起到 SSO架构的 SIP Digest, 在对 UE用 户加强监管的同时, 也为 SSO架构下的用户提供了更为丰富的 WEB业务。 附图说明
图 1为本发明 SSO架构及 OpenID架构融合的***的组成结构示意图; 图 2为应用于图 1所示***的认证方法流程图。 具体实施方式
本发明的基本思想是, SSO架构及 OpenID架构之间通过共用 SSO架 构中的 AS和 OpenID架构中的 OP而实现融合, 这样, UE向 OpenID架构 发起业务请求时, OpenID架构将触发 UE发起到 SSO架构的 SIP Digest, 在对 UE用户加强监管的同时, 也为 SSO架构下的用户提供了更为丰富的 WEB业务。
为使本发明的目的、 技术方案和优点更加清楚明白, 以下举实施例并 参照附图, 对本发明进一步详细说明。
图 1为本发明 SSO架构及 OpenID架构融合的***的组成结构示意图, 如图 1 所示, 本发明提出了一种组合鉴权认证架构, 以实现 SSO_APS 中 SSO架构和 OpenID架构的互通, 满足 UlCCless环境下的统一 IMS终端利 用该组合鉴权架构实现对应用服务器的 SSO功能, 其中, UE为 IMS终端, OpenID提供商实体(OP )和 SSO_APS中 SSO架构上的应用服务器实体为 一个实体, 即 OP/AS , RP对应于 IMS终端要访问的融合***的 OpenID的 最终应用服务器, IdP为用户认证中心, 完成 SSO_APS 中 SSO架构中对 UE的认证。 本发明中, SSO架构及 OpenID架构中的各网元基本保持了原 有的功能及结构, 变动较大的是 OP和 AS进行了融合。 由于上述各网元所 能实现的功能均为现有技术, 这里不再赘述各网元的功能及具体结构。 本 发明仅对上述融合***中 UE如何实现认证进行说明。
图 2为应用于图 1所示***的认证方法流程图, 如图 2所示, 本发明 的认证方法具体包括以下步驟:
步驟 1 , 用户通过 UE的浏览器发送用户提供方标识符(User-supplied
Identifier )给 RP, 发起业务请求。
步驟 2, RP初始化 User-Supplied Identifier, 基于该用户提供方标识符 获得 OP的地址和发现 OP终点统一资源定位符 ( URL, Uniform I Universal Resource Locator ), 并且, UE希望使用该 URL完成认证。
步驟 3 , RP和 OP之间利用 Diffie-hdlman密钥交换协议建立共享密钥, 该共享密钥建立的目的是使得 OP可以加密后续的消息, RP可以证实所接 收消息(此密钥是可选的属性, 不是互通必须的操作)。 若 OP和 RP两者 位于不同的移动网络运营商(MNO, Mobile Network Operator )的控制域内 时, 则该协商密钥是必要的。
步驟 4, RP携带 OpenID的认证请求重定向 UE的浏览器到 OP。 RP将 步驟 1中接收的 User-Supplied Identifier***到 OpenID认证请求消息中的 openid. claimed—id和 openid.identity字段中。
步驟 5, 紧随着该重定向, UE向 OP发送 HTTP GET请求。
步驟 6, OP/AS初始化 UE认证, 并且回应 401未授权的 HTTPS响应, 在该 HTTPS响应消息中包含携带有挑战信息的认证消息头, UE使用 SIP Digest机制与服务器进行认证; 同时该响应消息中携带有 OP/AS和 IdP共 享密钥加密的 OP/AS 身份标识 ( OP/AS_credential ) , 即 E 。,i ( OP/AS_credential )。 OP/AS和 IdP之间利用现有机制拥有共享密钥 K。,i , 由于该 Ko'i的获得属于现有技术, 本发明不再赘述获取其的实现细节。
步驟 7 , 如果 UE没有有效的密钥 Ko可用, 那么 UE向 IdP发送 HTTP 请求消息以进行对 UE的身份认证过程, 同时该 HTTP请求消息中携带 UE 的身份标识 ( U_credential )和 EK。,i ( OP/AS_credential )。
步驟 8, IdP解密 E 。,i ( OP/AS_credential ), 获得 OP/AS身份标识, 基 于该 OP/AS 身份标识对 OP/AS 进行认证, 产生并存储 OP/AS认证结果 OP/AS_Auth。 同时, IdP根据所接收到的 UE身份标识符 U_credential, 首 先检查是否存在与其对应的 UE与 IdP共享密钥 Ko , 若 存在, 则直接跳 转到步驟 15 , 否则执行步驟 9。
步驟 9, IdP向 HSS发送认证请求, 基于 U_credential, IdP到 HSS中 查找并下载对应的 SIP Digest认证向量(SD-AV )和用户配置信息。 SD-AV 中包括 U_credential、领域 ( realm )、质量保证 ( qop )、认证算法 ( algorithm ) 和 H ( A1 ), 其中 H ( A1 )是由 U_credentiaK realm和密码 ( assword )组 成的哈希函数值。 在多 HSS环境下, IdP可以通过询问订购关系定位功能 ( SLF, Subscription Locator Function )获得对应的存储用户信息的 HSS地 址, 找到该对应的 HSS。
步驟 10, IdP产生随机数 nonce, 并将针对该 U_credential的、 从 HSS 下载的 H ( Al ) 与该 nonce—起存储。
步驟 11 , IdP向 UE发送 401未认证挑战消息, 该 401未认证挑战消息 中包含 U_credential、 realm、 qop, algorithm和 nonce。
步驟 12, 当收到该 401未认证 4 战消息时, UE产生随机数 cnonce和 H ( A1 ); 然后再利用 cnonce和 H ( Al )等产生 UE和 IdP共享密钥 K 通 过单向哈希函数 F计算 response值。 response=F ( H ( Al ), cnonce, nonce, qop, nonce-count )。 UE用 cnonce进行网络认证和避免屯文本攻击 ( "chosen plaintext" )。 nonce-count是计数器,用户每使用与 nonce计算一次 response, nonce-count 4寻增力口 1, 使用 nonce-count参与 response计算, 可以降氐重放 攻击的可能性。
步驟 13 , UE针对步驟 11中的挑战消息向 IdP发送响应消息 response, 该响应消息中包含 cnonce、 nonce、 response , realm、 U_credential、 qop, algorithm, Digest-url和 nonce-count„
步驟 14, 接收到步驟 13中的响应消息后, IdP利用存储的 nonce值对 响应消息中的 nonce值进行检验, 若检验正确, 则 IdP利用接收到的响应消 息内的参数 cnonce、 nonce-count、 qop等和原存 4诸在 IdP内的 nonce及 H( Al ) 计算 Xresponse, 将计算的 Xresponse与接收到的 response值进行比较, 若 两者比较结果相同则 UE认证通过; 否则 UE认证失败, IdP存储 UE的认 证结果相关信息 UE_Auth。 若 UE认证成功, 则 IdP利用 H ( Al )和 cnonce 等产生共享密钥 K
步驟 15 , IdP再产生随机数 noncel ; 然后利用 。和 noncel等产生密钥 ^i;共享密钥 。对 noncel等信息进行加密操作产生 E ¾( noncel );用 OP/AS 和 IdP共享密钥 K。,i加密 和 UE_Auth产生 E 。,i ( Κι , UE_Auth )0
步驟 16, IdP向 UE发送 200OK消息, 该 200OK消息中包含 Ko加密 noncel等信息, 表明 UE认证成功; 同时 IdP重定向 UE到 OP/AS; 该重定 向的消息中携带 E 。,i ( Ki , UE_Auth )。
步驟 17 , UE解密 EKo ( noncel ), 获得 noncel值同时利用 和 noncel 等产生密钥 ι。
步驟 18 , IdP发送的消息被重定向到 OP/AS , 该被重定向消息中携带 ΕΚο,ϊ ( K UE_Auth )。
步驟 19 , OP/AS收到该被重定向消息后,利用共享密钥解密 E 。,i ( i , UE_Auth ), 获得 和 UE_Auth; OP/AS依据 UE_Auth, 获知该 UE的相关 授权信息, OP/AS根据授权信息确立是否该 UE被授权执行 OpenID认证和 期望被授权使用; 同时也可能从 UE_Auth获知关于信息类型的消息, 该信 息类型允许与 RP共享。 OP/AS依据 UE的授权信息, 利用 UE和 OP/AS 两者共享密钥 作用的 SSOa 完成对 OpenID用户的认证过程, 并且根据 认证结果产生认证断言。
步驟 20, OP/AS重定向浏览器到 OpenID的返回地址, 即 OP/AS重定 向 UE的浏览器返回到 RP, 其中该重定向的响应消息中要么携带认证被批 准的断言, 要么携带认证失败的断言。 在该重定向响应消息头包含一系列 定义认证断言信息的字段, 这些字段也被 OP/AS和 RP之间的密钥加密保 护。这种密钥保护机制对 OP/AS和 RP两者位于不同的 MNO网络时尤其重 要。
步驟 21 , RP确认接收到的断言; 即检验认证是否被赞成。 UE的认证 身份在发给 RP的响应消息中被提供。如果 OP/AS和 RP两者在步驟 3时建 立了共享密钥, 那么该密钥现在被用来确认来自 OP/AS的消息。 如果断言 为肯定断言和信息确认都成功, 那么 UE将获得 RP的服务。
需要说明的是,若上述步驟 1~步驟 21中任一步驟执行失败, 则整个过 程停止执行。
在 UE访问 RP应用服务器的过程中, 若遭遇意外断网情况, 当 UE还 未完成 UE和 RP之间访问服务过程, 在当网络恢复后 UE要访问应用服务 器则需要重新开始请求服务过程; 当 UE已经完成访问服务过程,若恢复网 络用时未到达 Cookie和共享密钥的生命周期, 则网络恢复后 UE和 RP之 间可以继续利用该共享密钥和 Cookie进行应用服务的获取, 否则需要重新 产生共享密钥过程。 在 UE访问 RP应用服务器后, 若遭遇用户主动关闭注 销 UE或断电等特殊情况, 则用户需要重新完成整个执行流程。
本发明中, 上述的密钥生成方式可以采用现有的任一种密钥生成方法, 本发明并不限定所采用的密钥生成方法。
以上所述, 仅为本发明的较佳实施例而已, 并非用于限定本发明的保 护范围。
工业实用性
本发明通过 SSO架构及 OpenID架构共用 SSO架构中的 AS和 OpenID 架构中的 OP而实现融合,这样, UE向 OpenID架构发起业务请求时, OpenID 架构将触发 UE发起到 SSO架构的 SIP Digest, 在对 UE用户加强监管的同 时, 也为 SSO架构下的用户提供了更为丰富的 WEB业务。

Claims

权利要求书
1、 一种组合认证***, 包括单点登录 SSO架构及 OpenlD架构, 其特 征在于, 所述 SSO架构及 OpenlD架构之间通过共用 SSO架构中的应用服 务器 AS和 OpenlD架构中的 OpenlD身份提供实体 OP而实现融合互通。
2、 根据权利要求 1所述的***, 其特征在于, 所述 OpenlD架构中还 包括服务依赖提供商 RP; 其中,
所述 RP用于, 在接收到 IP多媒体业务子*** IMS用户设备 UE的服 务请求后, 携带 OpenlD认证请求重定向所述 UE到所述 OP;
所述 OP用于, 在接收到所述 UE超文本传输协议 HTTP获取请求后, 向所述 UE返回未授权的响应, 要求所述 UE使用所述 SSO架构中的初始 会话认证 SIP Digest机制进行认证;
所述 UE用于, 在未实现所述 SIP Digest认证时, 通过所述 SSO架构 实现 SIP Digest认证;
所述 OP进一步用于, 获取 SIP Digest认证后所述 UE的授权信息, 根 据所述 UE的授权信息, 完成对所述 UE的 OpenlD认证, 并根据认证结果 产生认证断言; 将所述认证断言发送给所述 RP;
所述 RP进一步用于, 确认所述断言正确时为所述 UE提供服务。
3、 根据权利要求 2所述的***, 其特征在于, 所述 RP进一步用于, 在接收到所述 UE的服务请求后,基于所述服务请求中携带的所述 UE的标 识信息获得所述 OP的地址信息和发现所述 OP终点统一资源定位符 URL, 通过所述 URL完成对所述 UE的认证。
4、 根据权利要求 2所述的***, 其特征在于, 所述 RP和所述 OP进 行信息交互前, 进一步协商用于通信安全保护的密钥。
5、根据权利要求 1所述的***, 其特征在于, 所述 SSO架构中还包括 归属用户服务器 HSS和身份鉴权认证提供者实体 IdP; 其中, 所述 AS , 用于请求所述 UE到所述 IdP进行认证, 请求认证信息流中 包含 UE和 AS的标识信息;
所述 IdP, 用于根据所述 AS的标识信息对该 AS进行认证, 并存储 AS 认证结果,并在确认所述 UE未经 SIP Digest认证时,从 HSS取得 SIP Digest 认证向量和所述 UE的信息内容, 产生随机数 nonce; 向所述 UE发送认证 挑战;
所述 UE, 用于产生随机数 cnonce和生成哈希函数值, 进而生成共享 密钥 , 并向所述 IdP回复响应;
所述 IdP, 用于接收到所述 UE的响应后完成对所述 UE的认证, 并生 成 。; 以及, 再次产生随机数 nonce 1 , 利用 noncel和 。生成密钥 i , 并 利用 Ko加密 noncel , 并利用 AS与 IdP之间的共享密钥对 和对 UE的认 证结果进行加密后, 向所述 UE发送 200OK消息, 所述 200OK消息包含 Ko加密 noncel信息; 以及, 重定向该利用 AS与 IdP之间的共享密钥加密 后的信息到所述 AS ;
所述 UE进一步用于, 在获得所述的 200OK消息后, 生成 , 使所述 UE和所述 AS之间拥有共享密钥 Ki。
6、 一种认证方法, 其特征在于, 应用于 SSO架构及 OpenID架构融合 的***中, 其中, 所述 SSO架构及 OpenID架构之间通过共用 SSO架构中 的 AS和 OpenID架构中的 OP而实现融合互通; 所述方法还包括:
所述 RP在接收到 IMS UE的服务请求后, 携带 OpenID认证请求重定 向所述 UE到所述 OP;
所述 OP在接收到所述 UE的 HTTP获取请求后, 向所述 UE返回未授 权的响应, 要求所述 UE使用所述 SSO架构中的初始会话认证 SIP Digest 机制进行认证;
所述 UE在未实现所述 SIP Digest认证时,通过所述 SSO架构实现 SIP Digest认证;
所述 OP获取 SIP Digest认证后所述 UE的授权信息, 根据所述 UE的 授权信息,完成对所述 UE的 OpenID认证,并根据认证结果产生认证断言; 将所述认证断言发送给所述 RP;
所述 RP确认所述断言正确时为所述 UE提供服务。
7、 根据权利要求 6所述的方法, 其特征在于, 所述方法还包括: 所述 RP在接收到所述 UE的服务请求后, 基于所述服务请求中携带的 所述 UE的标识信息获得所述 OP的地址信息和发现所述 OP终点 URL,通 过所述 URL完成对所述 UE的认证。
8、 根据权利要求 6所述的方法, 其特征在于, 所述方法还包括: 所述 RP和所述 OP进行信息交互前, 协商用于通信安全保护的密钥。
9、 根据权利要求 6所述的方法, 其特征在于, 所述 UE在未实现所述 SIP Digest认证时, 通过所述 SSO架构实现 SIP Digest认证, 为:
所述 AS请求所述 UE到所述 IdP认证, 该请求认证信息流中包含 UE 和 AS的标识信息;
所述 IdP根据所述 AS的标识信息对该 AS进行认证, 并存储 AS认证 结果, 并在确认所述 UE未经 SIP Digest认证时, 从 HSS取得 SIP Digest 认证向量和所述 UE的信息内容, 产生随机数 nonce; 向所述 UE发送认证 挑战;
所述 UE产生随机数 cnonce和生成哈希函数值,进而生成共享密钥 Ko , 并向所述 IdP回复响应;
所述 IdP接收到所述 UE的响应后完成对所述 UE的认证, 并生成 Ko 以及, 再次产生随机数 noncel , 利用 noncel和 。生成密钥 i , 并利用 。 加密随机数 noncel , 并利用 AS与 IdP之间的共享密钥对 和对 UE的认 证结果进行加密后, 所述 IdP向所述 UE发送 200OK消息, 所述 200OK消 息包含 。加密 noncel信息; 以及, 重定向该利用 AS与 IdP之间的共享密 钥加密后的信息到所述 AS;
所述 UE在获得所述的 200OK消息后,生成 使所述 UE和所述 AS 之间拥有共享密钥 。
PCT/CN2012/071198 2011-03-24 2012-02-16 组合认证***及认证方法 WO2012126299A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110072463.5 2011-03-24
CN201110072463.5A CN102694779B (zh) 2011-03-24 2011-03-24 组合认证***及认证方法

Publications (1)

Publication Number Publication Date
WO2012126299A1 true WO2012126299A1 (zh) 2012-09-27

Family

ID=46860066

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/071198 WO2012126299A1 (zh) 2011-03-24 2012-02-16 组合认证***及认证方法

Country Status (2)

Country Link
CN (1) CN102694779B (zh)
WO (1) WO2012126299A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110021086A (zh) * 2018-10-29 2019-07-16 深圳市微开互联科技有限公司 一种基于openid的临时授权开启门禁的方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107548051A (zh) * 2016-06-29 2018-01-05 中兴通讯股份有限公司 业务处理方法、网络应用功能实体和通用认证架构***
CN110035035B (zh) * 2018-01-12 2021-09-17 北京新媒传信科技有限公司 一种单点登录的二次认证方法及***
CN108664803B (zh) * 2018-04-04 2022-03-22 中国电子科技集团公司第三十研究所 一种基于密码的文档内容细粒度访问控制***

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101552673A (zh) * 2009-04-30 2009-10-07 用友软件股份有限公司 使用OpenID账号登录单点登录***的方法
WO2010028691A1 (en) * 2008-09-12 2010-03-18 Nokia Siemens Networks Oy Methods, apparatuses and computer program product for obtaining user credentials for an application from an identity management system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8613058B2 (en) * 2007-05-31 2013-12-17 At&T Intellectual Property I, L.P. Systems, methods and computer program products for providing additional authentication beyond user equipment authentication in an IMS network
CN101771676B (zh) * 2008-12-31 2013-04-24 华为技术有限公司 一种跨域授权的设置、鉴权方法、相关装置及***

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010028691A1 (en) * 2008-09-12 2010-03-18 Nokia Siemens Networks Oy Methods, apparatuses and computer program product for obtaining user credentials for an application from an identity management system
CN101552673A (zh) * 2009-04-30 2009-10-07 用友软件股份有限公司 使用OpenID账号登录单点登录***的方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Single Sign On Application Security for Common IMS - based on SIP Digest (Release 11)", 3GPP TR 33.914 V0.3.0, January 2011 (2011-01-01), pages 4 - 5,14-15,25-27 *
ZTE CORPORATION. ET AL.: "Interworking message flow with OpenID", 3GPP TSG SA WG3 (SECURITY) MEETING #63, S3-110434, April 2011 (2011-04-01), CHENGDU, CHINA *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110021086A (zh) * 2018-10-29 2019-07-16 深圳市微开互联科技有限公司 一种基于openid的临时授权开启门禁的方法

Also Published As

Publication number Publication date
CN102694779A (zh) 2012-09-26
CN102694779B (zh) 2017-03-29

Similar Documents

Publication Publication Date Title
EP1811744B1 (en) Method, system and centre for authenticating in End-to-End communications based on a mobile network
KR102021213B1 (ko) 엔드 투 엔드 서비스 계층 인증
CN101455053B (zh) 对应用进行认证
JP4643657B2 (ja) 通信システムにおけるユーザ認証及び認可
KR101309426B1 (ko) 모바일 네트워크에서 재귀 인증을 위한 방법 및 시스템
CN107147611B (zh) 传输层安全tls建链的方法、用户设备、服务器和***
US20090063851A1 (en) Establishing communications
KR101343039B1 (ko) 인증 시스템, 방법 및 장치
JP2012523614A (ja) ネットワーク事業者によって提供されるアイデンティティ管理サービス
WO2012058896A1 (zh) 单点登录方法及***
US20110035592A1 (en) Authentication method selection using a home enhanced node b profile
WO2011020274A1 (zh) 一种有线局域网的安全访问控制方法及其***
WO2007028328A1 (fr) Procede, systeme et dispositif de negociation a propos d'une cle de chiffrement partagee par equipement utilisateur et equipement externe
JP5342818B2 (ja) 管理装置、登録通信端末、非登録通信端末、ネットワークシステム、管理方法、通信方法、及びコンピュータプログラム。
WO2012126299A1 (zh) 组合认证***及认证方法
WO2013004104A1 (zh) 单点登录方法及***
WO2012000313A1 (zh) 一种家庭网关认证方法和***
WO2013127342A2 (zh) 一种ims单点登录组合鉴权方法和***
TWI755951B (zh) 通訊系統及通訊方法
KR20140095050A (ko) 이동 통신 시스템에서 단일 사용자 승인을 지원하는 관리 방법 및 장치
WO2013064040A1 (zh) 一种ims单点登录的组合鉴权方法及***
WO2009086769A1 (zh) 一种网络服务的协商方法和***
EP4381685A1 (en) Establishment of forward secrecy during digest authentication
WO2011017851A1 (zh) 客户端安全访问消息存储服务器的方法和相关设备
WO2012129985A1 (zh) 单点登录方法及***

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12760207

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12760207

Country of ref document: EP

Kind code of ref document: A1