CN102694779B

CN102694779B - Combination attestation system and authentication method

Info

Publication number: CN102694779B
Application number: CN201110072463.5A
Authority: CN
Inventors: 张孟旺; 田甜
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2011-03-24
Filing date: 2011-03-24
Publication date: 2017-03-29
Anticipated expiration: 2031-03-24
Also published as: CN102694779A; WO2012126299A1

Abstract

The invention discloses a kind of combination attestation system, including SSO frameworks and OpenID frameworks, realize merging intercommunication between SSO frameworks and OpenID frameworks by the OP shared in AS the and OpenID frameworks in SSO frameworks.The present invention discloses a kind of authentication method for being applied to above-mentioned Verification System, after the service request for receiving UE, carrying OpenID certification requests redirect UE to OP to RP；OP returns undelegated response to UE, it is desirable to which UE is authenticated using the initial session certification SIP Digest mechanism in SSO frameworks after the HTTP for receiving UE obtains request；UE realizes SIP Digest by SSO frameworks in unrealized SIP Digest certifications；OP obtains the authorization message of UE after SIP Digest, according to the authorization message of UE, completes the OpenID certifications to UE, and produces authentication assertion according to authentication result；Authentication assertion is sent to into RP.The present invention can extend application scenarios for UE in SSO frameworks, with using existing more rich WEB service.

Description

Combined authentication system and authentication method

Technical Field

The present invention relates to a Single Sign On (SSO) framework and OpenID framework fusion technology, and in particular, to an SSO framework and OpenID framework fusion system and an authentication method applied to the fusion system.

Background

Currently, the third Generation Partnership Project (3 GPP) organization proposes a function of a unified IMS terminal to implement SSO of an IMS terminal access Application Server (AS) using a Session Initiation Protocol (SIP) Digest (Digest) authentication mechanism in a non-Universal Integrated Circuit Card (UICC) environment, wherein the function can be implemented by an SSO architecture designed in SSO _ APS. The SSO architecture is typically composed of a unified IP Multimedia Subsystem (IMS) Subscriber, a Home Subscriber Server (HSS), an AS, and an identity authentication provider entity (IdP). User Equipment (UE) is connected with the IdP through an SSob interface; the UE is connected with the AS through an SSOa interface; the IdP is connected to the HSS via a SSOh interface. The IdP is used for interactively verifying the identity with the UE by using SIP Digest and authenticating the AS, and the shared key between the IdP and the user is K₀(ii) a The HSS stores the signing file for describing the user information and has the function of generating authentication information. AS provides a network for UEAnd services the business.

In the implementation scheme of the SSO architecture in the SSO _ APS, aiming at a situation that an operator does not deploy GBA, and in a scenario that an IMS terminal does not have a UICC, a session initiation protocol digest (sip digest) authentication mechanism is used to authenticate a UE, so AS to implement an SSO function of the AS by the IMS terminal, specifically implemented AS follows:

an IMS terminal (UE) sends an HTTP service request to an AS, an application server AS responds a 401 unauthorized HTTPS response to the UE and requires the UE terminal to go to an authentication center for identity authentication; meanwhile, the response contains AS identity information encrypted by an AS and an IdP shared key; the UE terminal sends HTTP request information to the authentication center IdP to request the IdP to carry out identity authentication on the UE terminal. Simultaneously, the message carries the identity identification 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 judges whether the K corresponding to the UE exists or not₀If the key exists, the UE is authenticated, the SIP Digest mechanism does not need to be used again for authentication, and subsequent steps are directly executed by skipping the authentication; if the IdP judges that the K of the corresponding UE does not exist₀If so, the IdP obtains the SIPDigest authentication vector and the UE information content from the HSS based on the IMS identity identification information; IdP generates a random number nonce and stores the nonce and hash function value H downloaded from HSS (a 1); the IdP sends 401 an authentication challenge to the UE using the SIP Digest mechanism; the UE generates a random number cnonce and generates H (a1), which in turn generates a key K₀Calculating a response value response by using the parameters; the UE sends a response to the IdP for the challenge, and the IdP completes authentication of the UE and generates a shared secret key K₀(ii) a IdP again generates a random number nonce1, using nonce1 and K₀Generating a shared key encryption K₁IdP utilizes a secret key K₀Encrypting nonce1, encrypting K with shared key of IdP and AS₁And UE authentication result, the IdP sends 200OK message to the UE, including K₀Encrypting information such as nonce1 and the like to indicate that the UE authentication is successful; k for encrypting shared key of AS and IdP by the IdP at the same time₁And redirecting the authentication result of the UE to the AS; the UE decrypts to obtain nonce1 and generates a shared secretKey K₁(ii) a AS decrypts the information to obtain the authentication result and the secret key K of the UE₁(ii) a At this time, the UE and the AS have a shared secret key K therebetween₁So that both subsequent communications can utilize K₁Encryption is carried out to ensure the communication safety between the two.

In addition, OpenID also defines its own architecture and specification for realizing access to Web services, and its architecture mainly includes three entities: UE, OpenID identity Provider (OP), service dependent Provider (RP).

The OpenID framework utilizes that each terminal user has a user identifier distributed when registering in an OpenID Provider, when UE accesses an OpenID-supporting service dependence Provider (RP), the user identifier is only required to be input, and the RP standardizes the identifier; then, the RP obtains an end point Uniform Resource Locator (URL) of the OP by utilizing a discovery mechanism and the identifier; the association between the RP and the OP is carried out, so that a shared key is established between the OP and the RP, the key enables the OP to mark a subsequent message, so that the RP identifies the subsequent message, the association process is optional, and when the OP and the RP are in different Mobile Network Operator (MNO) networks, the shared key generated by the process is very important for the safe transmission of the message; the RP requests the OP to authenticate the UE; the OP determines whether the UE is authorized to execute OpenID authentication and expect to be authorized to use according to the authorization information of the UE, completes the authentication process of the OpenID user according to the authorization information of the UE, generates authentication assertion according to the authentication result and returns the authentication assertion to the RP; the RP performs an acknowledgement operation on the assertion to decide whether to provide service for the UE.

In an SSO architecture in an SSO _ APS, a final AS obtains a shared key and terminal authentication result authorization information, and simultaneously an OpenID architecture supports Web services and provides a unique identity identifier for each UE; if the two architectures can be intercommunicated, the original safety can not be reduced, the simplicity of terminal operation can be increased, and the application scene of the terminal can be expanded so as to use the existing various WEB services.

At present, 3GPP specification 33.924 defines a scenario in which a GBA architecture and an OpenID architecture implement interworking, that is, a Network Application Function (NAF) and an OP are entities. The method is characterized in 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 be added with the GBA function. When the UE accesses each RP, authentication is firstly passed on the OP/NAF, and the bootstrap process between the UE and a Bootstrap Server Function (BSF) is required for the authentication to be passed on the OP/NAF.

For a unified IMS terminal in a non-UICC environment, it cannot use a GBA architecture for authentication, and for this type of IMS terminal, an architecture that uses an SIP Digest mechanism to implement an SSO function is designed in an SSO _ APS, and there is a need to solve the problem that the SSO architecture and an OpenID architecture cannot be fused and intercommunicated, so that this type of IMS terminal supports an OpenID mechanism, and further obtains various WEB services.

Disclosure of Invention

In view of the above, the present invention provides a combined authentication system and an authentication method, which can integrate the SSO framework and the OpenID framework to provide a richer WEB service for the UE.

In order to achieve the purpose, the technical scheme of the invention is realized as follows:

a combined authentication system comprises an SSO architecture and an OpenID architecture, wherein the SSO architecture and the OpenID architecture are integrated and communicated by sharing an Application Server (AS) in the SSO architecture and an OpenID identity providing entity (OP) in the OpenID architecture.

Preferably, the OpenID architecture further includes a service dependent provider RP; wherein,

the RP is used for carrying an OpenID authentication request to redirect the UE to the OP after receiving a service request of an IP multimedia service subsystem IMS user equipment UE;

the OP is used for returning an unauthorized response to the UE after receiving the UE hypertext transfer protocol (HTTP) acquisition request, and requesting the UE to authenticate by using an initial session summary authentication (SIP) Digest mechanism in the SSO architecture;

the UE is used for realizing SIP Digest authentication through the SSO architecture when the SIP Digest authentication is not realized;

the OP is further used for acquiring authorization information of the UE after SIP Digest authentication, completing OpenID authentication of the UE according to the authorization information of the UE, and generating authentication assertion according to an authentication result; sending the authentication assertion to the RP;

the RP is further configured to provide service to the UE when the assertion is confirmed to be correct.

Preferably, the RP is further configured to, after receiving a service request of the UE, obtain address information of the OP and discover the OP end URL based on the identification information of the UE carried in the service request, and complete authentication of the UE through the URL.

Preferably, before the information interaction between the RP and the OP, a key for communication security protection is further negotiated.

Preferably, the SSO architecture further includes a home subscriber server HSS and an identity authentication provider entity IdP; wherein,

the AS is used for requesting the UE to perform de-authentication on the IdP, wherein the request authentication information flow comprises the identification information of the UE and the AS;

the IdP is used for authenticating the AS according to the identification information of the AS, storing an AS authentication result, and acquiring an SIP Digest authentication vector and the information content of the UE from the HSS to generate a random number nonce when the UE is confirmed not to be authenticated by the SIP Digest; sending an authentication challenge to the UE;

the UE is used for generating a random number cnonce and generating a hash function value so as to generate a shared secret key K₀In parallel toThe IdP reply response;

the IdP is used for completing the authentication of the UE after receiving the response of the UE and generating K₀(ii) a And, again generating a random number nonce1, using nonce1 and K₀Generating a secret key K₁And use of K₀Encrypts the nonce1 and other information and utilizes the shared key pair K between AS and IdP₁And after encrypting the authentication result of the UE, the IdP sends a 200OK message to the UE, wherein the 200OK message comprises K₀Encrypting information such as nonce1 and the like to indicate that the UE authentication is successful; at the same time, 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 generate K after obtaining the 200OK message₁Enabling the UE and the AS to have a shared secret key K₁。

An authentication method is applied to a system with SSO architecture and OpenID architecture integrated, wherein the SSO architecture and the OpenID architecture are integrated and intercommunicated by sharing an AS in the SSO architecture and an OP in the OpenID architecture; the method further comprises the following steps:

after receiving a service request of IMS UE, the RP carries an OpenID authentication request to redirect the UE to 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 use an initial session authentication SIP Digest mechanism in the SSO architecture for authentication;

when the SIP Digest authentication is not realized by the UE, the SIP Digest authentication is realized through the SSO architecture;

the OP acquires authorization information of the UE after SIP Digest authentication, completes OpenID authentication of the UE according to the authorization information of the UE, and generates authentication assertion according to an authentication result; sending the authentication assertion to the RP;

and the RP provides service for the UE when confirming that the assertion is correct.

Preferably, the method further comprises:

and after receiving the service request of the UE, the RP obtains the address information of the OP and discovers the URL of the OP end point based on the identification information of the UE carried in the service request, and completes the authentication of the UE through the URL.

Preferably, the method further comprises:

and negotiating a secret key for communication security protection before the information interaction between the RP and the OP.

Preferably, when the SIP Digest authentication is not implemented, the UE implements SIP Digest authentication through the SSO framework, and the implementing of SIP Digest authentication includes:

the AS requests the UE to authenticate to the authentication center IdP, and a request authentication information flow contains identification information of the UE and the AS;

the IdP authenticates the AS according to the identification information of the AS, stores an AS authentication result, and obtains an SIP Digest authentication vector, the information content of the UE and a hash function value from an HSS to generate a random number nonce when the UE is confirmed not to be authenticated by the SIP Digest; sending an authentication challenge to the UE;

the UE generates a random number cnonce and a hash function value, and further generates a shared secret key K₀And replying a response to the IdP;

the IdP completes the authentication of the UE after receiving the response of the UE and generates K₀(ii) a And, again generating a random number nonce1, using nonce1 and K₀Generating a secret key K₁And use of K₀Encrypts the nonce1 and other information and utilizes the shared key pair K between AS and IdP₁And after encrypting the authentication result of the UE, the IdP sends a 200OK message to the UE, wherein the 200OK message comprises K₀Encrypting information such as nonce1 and the like to indicate that the UE authentication is successful; while the IdP redirects the utilization K₀And the shared secret key between the AS and the IdP is encryptedLogging to the AS;

the UE generates K after obtaining the 200OK message₁Enabling the UE and the AS to have a shared secret key K₁。

In the invention, the SSO architecture and the OpenID architecture are fused by sharing the AS in the SSO architecture and the OP in the OpenID architecture, so that when UE initiates a service request to the OpenID architecture, the OpenID architecture triggers the UE to initiate the SIP Digest of the SSO architecture, and the UE user is enhanced to be supervised, and meanwhile, richer WEB services are provided for the user under the SSO architecture.

Drawings

FIG. 1 is a schematic diagram of a composition structure of a SSO architecture and OpenID architecture converged system 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 invention is that the SSO architecture and the OpenID architecture are fused by sharing the AS in the SSO architecture and the OP in the OpenID architecture, so that when UE initiates a service request to the OpenID architecture, the OpenID architecture triggers the UE to initiate the SIP Digest of the SSO architecture, and the UE user is supervised strongly and simultaneously more abundant WEB services are provided for the user under the SSO architecture.

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail below with reference to the accompanying drawings by way of examples.

Fig. 1 is a schematic diagram of a composition structure of a system in which an SSO architecture and an OpenID architecture are merged according to the present invention, and AS shown in fig. 1, the present invention provides a combined authentication and authentication architecture to implement intercommunication between an SSO architecture and an OpenID architecture in an SSO _ APS, so AS to satisfy a requirement that a unified IMS terminal in a UICCless environment implements an SSO function for an application server by using the combined authentication architecture, where a UE is an IMS terminal, an OpenID provider entity (OP) and an application server entity on the SSO architecture in the SSO _ APS are an entity, that is, an OP/AS, an RP corresponds to a final application server of an OpenID of the merged system to be accessed by the IMS terminal, and an IdP is a user authentication center, thereby completing authentication for the UE in the SSO architecture in the SSO _ APS. In the invention, each network element in the SSO architecture and the OpenID architecture basically keeps the original function and structure, and the OP and the AS are fused with great change. Since the functions that can be implemented by the network elements are all the prior art, the functions and specific structures of the network elements are not described herein again. The present invention only explains how the UE in the above-mentioned convergence system implements authentication.

Fig. 2 is a flowchart of an authentication method applied to the system shown in fig. 1, and as shown in fig. 2, the authentication method of the present invention specifically includes the following steps:

step 1, a User sends a User-supported identifier (User-supported identifier) to an RP through a browser of UE, and initiates a service request.

Step 2, the RP initializes User-Supplied Identifier, obtains an address of the OP and a URL (Uniform resource locator) of a discovery OP endpoint based on the User provider Identifier, and the UE wants to complete authentication using the URL.

And 3, establishing a shared key between the RP and the OP by using a Diffie-hellman key exchange protocol, wherein the purpose of the shared key establishment is to ensure that the OP can encrypt subsequent messages, and the RP can confirm the received messages (the key is an optional attribute and is not an operation necessary for intercommunication). This negotiation of keys is necessary if both OP and RP are located within the control domains of different Mobile Network Operators (MNOs).

And 4, the RP carries an authentication request of the OpenID to redirect the browser of the UE to the OP. And the RP inserts the User-Supplied Identifier in the step 1 into the OpenID.

And 5, immediately following the redirection, the UE sends an HTTP GET request to the OP.

Step 6, the OP/AS initializes the UE authentication and responds 401 to an unauthorized HTTPS response, the HTTPS response message contains an authentication message header carrying challenge information, and the UE authenticates with the server by using an SIP Digest mechanism; meanwhile, the response message carries OP/AS and encrypted OP/AS identity (OP/AS _ encrypted) of the IdP shared key, namely EK_o，i(OP/AS _ credit). Possession of a shared secret K between an OP/AS and an IdP using existing mechanisms_o，iDue to the K_o，iThe acquisition belongs to the prior art, and the implementation details of the acquisition are not repeated in the invention.

Step 7, if the UE does not have a valid secret key K₀If the identity authentication request message is available, the UE sends an HTTP request message to the IdP to perform the identity authentication process on the UE, and the HTTP request message carries the identity (U _ credit) and the EK of the UE_o，i(OP/AS_credential)。

Step 8, EK is decrypted by IdP_o，i(OP/AS _ credit), obtaining OP/AS ID, authenticating OP/AS based on the OP/AS ID, and generating and storing OP/AS authentication result OP/AS _ Auth. Meanwhile, the IdP firstly checks whether there is a UE and IdP shared key K corresponding to the IdP based on the received UE identity identifier U _ critical₀If K is₀If so, directly jumping to the step 15, otherwise, executing the step 9.

And 9, the IdP sends an authentication request to the HSS, and searches and downloads a corresponding SIP Digest authentication vector (SD-AV) and user configuration information from the HSS based on the U _ credit. The SD-AV comprises U _ creattial, realm (realm), quality assurance (qop), authentication algorithm (algorithm) and H (A1), wherein H (A1) is a hash function value consisting of U _ creattial, realm and password (password). In a multi-HSS environment, the IdP may obtain a corresponding HSS address storing the subscriber information by querying a subscription relationship location Function (SLF), and find the corresponding HSS.

IdP generates a random number nonce and stores H (a1) downloaded from HSS for the U _ credit with the nonce, step 10.

And 11, the IdP sends 401 an unauthenticated challenge message to the UE, wherein the 401 unauthenticated challenge message comprises U _ credit, realm, qop, algorithmm and nonce.

Step 12. when receiving the 401 unauthenticated challenge message, the UE generates random numbers cnonce and H (a 1); then generates the UE and the IdP shared key K by using the cnonce, the H (A1) and the like₀. The response value is calculated by a one-way hash function F. response ═ F (H (a1), cnonce, nonce, qop, nonce-count). The UE uses cnonce for network authentication and to avoid plain text attacks ("chosen challenge"). The nonce-count is a counter, and will be incremented by 1 every time the user uses the nonce to calculate the response, and the probability of the replay attack can be reduced by using the nonce-count to participate in the response calculation.

And step 13, the UE sends a response to the IdP aiming at the challenge message in the step 11, wherein the response message comprises cnonce, nonce, response, realm, U _ createntry, qop, algorithm, Digest-url and nonce-count.

Step 14, when the response message of the previous step is received, the IdP checks the nonce value in the response message by using the stored nonce value, if the check is correct, the IdP calculates Xresponse by using the parameters cnnce, nonce-count, qop and the like in the received response message and the nonce and H (a1) originally stored in the IdP, compares the calculated Xresponse with the received response value, and if the comparison result of the two values is the same, the UE passes the authentication; otherwise, the UE fails to authenticate, and the IdP stores the authentication result related information UE _ Auth of the UE. If the UE authentication is successful, the IdP generates a shared secret key K by using H (A1), cnonce and the like₀。

Step 15.IdP regenerating random number nonce 1; then use K₀And nonce1, etc. to generate the key K₁(ii) a Shared secret key K₀Encrypting the nonce1 to generate EK₀(nonce 1); sharing a secret key K with an OP/AS and an IdP_o，iEncryption K₁And UE _ Auth generates EK_o，i(K₁，UE_Auth)。

Step 16, the IdP sends 200OK message to the UE, which contains K₀Encrypting information such as nonce1 and the like to indicate that the UE authentication is successful; meanwhile, the IdP redirects the UE to the OP/AS; the redirection message carries EK_o，i(K₁，UE_Auth)。

Step 17.UE decrypts EK₀(nonce1), obtaining a nonce1 value while utilizing K₀And nonce1, etc. to generate the key K₁。

Step 18, the message sent by the IdP is redirected to the OP/AS, and the EK is carried in the redirected message_o，i(K₁，UE_Auth)。

Step 19.OP/AS receives the redirected message, decrypts EK by using shared secret key_o，i(K₁UE _ Auth), obtain K₁And UE _ Auth; the OP/AS acquires the relevant authorization information of the UE according to the UE _ Auth, and determines whether the UE is authorized to execute OpenID authentication and expect to be authorized for use according to the authorization information; it is also possible to know from UE _ Auth the message about the type of information that is allowed to be shared with the RP. OP/AS shares secret key K with both UE and OP/AS according to authorization information of UE₁The active SSOa completes the authentication process for the OpenID user and generates an authentication assertion according to the authentication result.

And 20, the OP/AS redirects the browser to the return address of the OpenID, namely the OP/AS redirects the browser of the UE to return to the RP, wherein the redirection response message carries either an assertion that the authentication is approved or an assertion that the authentication fails. The redirect response message header contains a series of fields that define authentication assertion information, perhaps cryptographically protected by a key between the OP/AS and the RP. This key protection mechanism is especially important when both OP/AS and RP are located in different MNO networks.

Step 21, the RP confirms the received assertion; i.e. to check whether the authentication is approved. The authentication identity of the UE is provided in a response message to the RP. If both OP/AS and RP establish a shared key at step 3, this key is now used to acknowledge the message from OP/AS. If both the assertion and the information confirmation are successful, the UE will get service of the RP.

If any one of the steps 1 to 21 fails to be executed, the whole process is stopped.

In the process that the UE accesses the RP application server, if the UE encounters an unexpected network disconnection condition, when the UE does not finish the service access process between the UE and the RP, the UE needs to restart the service request process when the UE accesses the application server after the network is recovered; when the UE finishes the service access process, if the life cycle of the Cookie and the shared key is not reached when the network is recovered, the shared key and the Cookie can be continuously utilized between the UE and the RP after the network is recovered to obtain the application service, otherwise, the shared key process needs to be regenerated. After the UE accesses the RP application server, if the UE is actively powered off or powered off, the user needs to complete the entire execution flow again.

In the present invention, any conventional key generation method can be used as the key generation method, and the present invention is not limited to the key generation method used.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention.

Claims

1. A combined authentication system comprises a single sign-on (SSO) framework and an OpenID framework, and is characterized in that the SSO framework and the OpenID framework are fused and communicated by sharing an Application Server (AS) in the SSO framework and an OpenID identity providing entity (OP) in the OpenID framework;

establishing a shared key between the OP and the RP by using a Diffie-hellman key exchange protocol;

the SSO architecture also comprises a Home Subscriber Server (HSS) and an identity authentication provider entity (IdP); wherein,

the AS is used for requesting the UE to authenticate the IdP, and the request authentication information flow comprises the identification information of the UE and the AS;

the UE is used for generating a random number cnonce and generating a hash function value so as to generate a shared secret key K₀And replying a response to the IdP;

the IdP is used for completing the authentication of the UE after receiving the response of the UE and generating K₀(ii) a And, again generating a random number nonce1, using nonce1 and K₀Generating a secret key K₁And use of K₀Encrypts nonce1 and utilizes the shared key pair K between AS and IdP₁And after encrypting the authentication result of the UE, sending a 200OK message to the UE, wherein the 200OK message comprises K₀Encrypt nonce1 information; redirecting the information encrypted by the shared key between the AS and the IdP to the AS;

2. The system of claim 1, wherein the OpenID architecture further comprises a service dependent provider, RP; wherein,

the OP is used for returning an unauthorized response to the UE after receiving the UE hypertext transfer protocol (HTTP) acquisition request, and requesting the UE to authenticate by using an initial session authentication (SIP) Digest mechanism in the SSO architecture;

3. The system of claim 2, wherein the RP is further configured to, after receiving a service request of the UE, obtain address information of the OP and discover the OP endpoint uniform resource locator URL based on the identity information of the UE carried in the service request, and complete authentication of the UE through the URL.

4. The system of claim 2, wherein the RP and the OP further negotiate a key for communication security protection before performing information interaction.

5. An authentication method is applied to a system with a converged SSO architecture and an OpenID architecture, wherein the SSO architecture and the OpenID architecture realize converged intercommunication by sharing an AS in the SSO architecture and an OP in the OpenID architecture; establishing a shared key between the OP and the RP by using a Diffie-hellman key exchange protocol;

the method further comprises the following steps:

the RP provides service for the UE when confirming that the assertion is correct;

when the SIP Digest authentication is not realized by the UE, the SIP Digest authentication is realized through the SSO architecture, and the method comprises the following steps:

the AS requests the UE to IdP authentication, and the request authentication information flow comprises the identification information of the UE and the AS;

the IdP authenticates the AS according to the identification information of the AS, stores an AS authentication result, and acquires an SIP Digest authentication vector and the information content of the UE from an HSS to generate a random number nonce when the UE is confirmed not to be authenticated by the SIP Digest; sending an authentication challenge to the UE;

the IdP completes the authentication of the UE after receiving the response of the UE and generates K₀(ii) a And, again generating a random number nonce1, using nonce1 and K₀Generating a secret key K₁And use of K₀Encrypts the random number nonce1 and utilizes the shared key pair K between AS and IdP₁And after encrypting the authentication result of the UE, the IdP sends a 200OK message to the UE, wherein the 200OK message comprises K₀Encrypt nonce1 information; redirecting the information encrypted by the shared key between the AS and the IdP to the AS;

6. The method of claim 5, further comprising:

7. The method of claim 5, further comprising: