CN113127821A - Identity authentication method and device, electronic equipment and storage medium - Google Patents
Identity authentication method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN113127821A CN113127821A CN201911411315.4A CN201911411315A CN113127821A CN 113127821 A CN113127821 A CN 113127821A CN 201911411315 A CN201911411315 A CN 201911411315A CN 113127821 A CN113127821 A CN 113127821A
- Authority
- CN
- China
- Prior art keywords
- idp
- protocol
- identity
- authentication
- authentication request
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 42
- 238000012795 verification Methods 0.000 claims description 14
- 108010029660 Intrinsically Disordered Proteins Proteins 0.000 claims description 7
- 102100037845 Isocitrate dehydrogenase [NADP], mitochondrial Human genes 0.000 claims description 7
- 238000006243 chemical reaction Methods 0.000 claims description 5
- 238000011161 development Methods 0.000 abstract description 7
- 238000004891 communication Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000007726 management method Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/45—Structures or tools for the administration of authentication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The embodiment of the application provides an identity authentication method, an identity authentication device, electronic equipment and a storage medium, wherein the method comprises the following steps: receiving an identity authentication request based on a first protocol sent by a terminal; converting an authentication request based on a first protocol into an authentication request based on a second protocol, wherein the first protocol is different from the second protocol; and sending an identity authentication request based on a second protocol to a second IDP, wherein the second IDP is used for matching the identity information of the target account with the pre-stored identity information to obtain an identity authentication result, and allowing the target account to log in the first SP when the identity authentication result is that the authentication is passed. The technical scheme provided by the embodiment of the application can avoid the situation that the application service needs to be configured with different IDP systems and adapts to SSO protocols adopted by different IDP systems, and the development complexity of the application service is reduced.
Description
Technical Field
The embodiment of the application relates to the technical field of authority management, in particular to an identity authentication method, an identity authentication device, electronic equipment and a storage medium.
Background
A Software As A Service (SAAS) platform is a platform for running SAAS Software, which is generally integrated with multiple application Services (SPs) and provides the multiple SPs to different tenants.
In the related art, each tenant is provided with a corresponding Identity provider (IDP) system, and when an employee of the tenant accesses an SP, Identity authentication needs to be completed in the IDP system.
In the related art, in order to support employees of different tenants to access a certain SP, the SP needs to configure different IDP systems and adapt to Single Sign On (SSO) standard protocols adopted by the different IDP systems, which is relatively high in complexity.
Disclosure of Invention
The embodiment of the application provides an identity authentication method, an identity authentication device, an electronic device and a storage medium, which can be used for solving the problems that in the related art, an SP needs to be configured with different IDP systems and adapts to SSO protocols adopted by the different IDP systems, and the complexity is high. The technical scheme is as follows:
in a first aspect, an embodiment of the present application provides an identity authentication method, where the method is applied to a first IDP, and the method includes:
receiving an identity authentication request based on a first protocol, which is sent by a terminal, wherein the identity authentication request carries identity information of a target account;
converting the authentication request based on the first protocol into an authentication request based on a second protocol, wherein the first protocol is different from the second protocol;
and sending the identity authentication request based on the second protocol to a second IDP, wherein the second IDP is used for matching the identity information of the target account with the pre-stored identity information to obtain an identity authentication result, and allowing the target account to log in to the first SP when the identity authentication result is that the authentication is passed.
In a second aspect, an embodiment of the present application provides an identity authentication apparatus, which is applied to a first identity provider IDP, and includes:
the first receiving module is used for receiving an identity authentication request based on a first protocol, which is sent by a terminal, wherein the identity authentication request carries identity information of a target account;
a protocol conversion module, configured to convert the authentication request based on the first protocol into an authentication request based on a second protocol, where the first protocol is different from the second protocol;
and the first sending module is used for sending the identity authentication request based on the second protocol to a second IDP, the second IDP is used for matching the identity information of the target account with the pre-stored identity information to obtain an identity authentication result, and the target account is allowed to log in the first application service SP when the identity authentication result is that the authentication is passed.
In a third aspect, an electronic device is provided, which includes a processor and a memory, where the memory stores at least one instruction, and the instruction is loaded and executed by the processor to implement the rights management method according to the first aspect.
In a fourth aspect, a computer-readable storage medium is provided, in which at least one instruction is stored, the instruction being loaded and executed by a processor to implement the rights management method according to the first aspect.
The beneficial effects brought by the technical scheme provided by the embodiment of the application at least comprise:
by additionally arranging an intermediate IDP (namely a first IDP) between the application service and a tenant IDP (namely a second IDP), when the identity authentication requirement exists, the identity information of a target account is not directly sent to the tenant IDP for authentication, but is firstly sent to the first IDP, the first IDP converts an identity authentication request which is not supported by the second IDP and is based on a first protocol into an identity authentication request which is supported by the second IDP and is based on a second protocol, and then the identity authentication request based on the second protocol is sent to the second IDP for authentication, so that the situation that the application service needs to be configured with different IDP systems and is adapted to SSO protocols adopted by different IDP systems can be avoided, and the development complexity of the application service is reduced.
Drawings
FIG. 1 is a schematic illustration of an implementation environment shown in an exemplary embodiment of the present application;
FIG. 2 is a flow chart illustrating a method of identity verification according to an exemplary embodiment of the present application;
FIG. 3 is a flow chart of an authentication method shown in another exemplary embodiment of the present application;
FIG. 4 is a schematic diagram illustrating an interface for identity verification according to an exemplary embodiment of the present application;
fig. 5 is a block diagram illustrating the structure of an authentication apparatus according to an exemplary embodiment of the present application;
fig. 6 is a block diagram illustrating an electronic device according to an exemplary embodiment of the present application.
Detailed Description
To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
Referring to fig. 1, a schematic diagram of an implementation environment provided by an embodiment of the present application is shown. The implementation environment includes a terminal 11, a first IDP12, and a second IDP 13.
The terminal 11 may be a personal computer, a smart phone, a tablet computer, or the like. A browser is installed in the terminal 11, and employees of tenants can access a plurality of SPs provided by the SAAS platform through the browser.
First IDP12 is an IDP provided by the SAAS platform vendor, which may also be referred to as a "SAAS IDP". The system is used for carrying out identity verification on the user account logged in to the SP. The first IDP12 may be one server, a server cluster composed of multiple servers, or a cloud computing service center.
The second IDP13 is an IDP provided by a tenant, which may also be referred to as a tenant IDP, and the tenant refers to a client of the SAAS platform. The second IDP13 may be one server, a server cluster formed by multiple servers, or a cloud computing service center.
The number of the second IDP13 may be one or more, and the number of the second IDP13 is not limited in the embodiments of the present application. In addition, it should be noted that the number of second IDPs 13 may be dynamically changed. For example, as tenants are increased or decreased, the number of second IDPs 13 is increased or decreased accordingly.
The communication connection between the terminal 11 and the first IDP12 may be established through a wireless network or a wired network. The first IDP12 and the second IDP13 may also establish a communication connection through a wireless network or a wired network.
Optionally, the wireless or wired networks described above use standard communication techniques and/or protocols. The Network is typically the internet, but may be any other Network including, but not limited to, a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a mobile, wireline or wireless Network, a private Network, or any combination of virtual private networks. In some embodiments, data exchanged over a network is represented using techniques and/or formats including Hypertext Mark-up Language (HTML), Extensible Markup Language (XML), and the like. All or some of the links may also be encrypted using conventional encryption techniques such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet Protocol Security (IPsec). In other embodiments, custom and/or dedicated data communication techniques may also be used in place of, or in addition to, the data communication techniques described above.
According to the technical scheme provided by the embodiment of the application, an intermediate IDP (namely a first IDP) is additionally arranged between the application service and a tenant IDP (namely a second IDP), when the identity authentication requirement exists, the identity information of the target account is not directly sent to the tenant IDP for authentication, but is sent to the first IDP first, the first IDP converts the identity authentication request based on the first protocol and not supported by the second IDP into the identity authentication request based on the second protocol and supported by the second IDP, and then the identity authentication request based on the second protocol is sent to the second IDP for authentication, so that the situation that the application service needs to be configured with different IDP systems, the application service adapts to SSO protocols adopted by different IDP systems is avoided, and the development complexity of the application service is reduced.
Referring to fig. 2, a flowchart of an authentication method provided in an embodiment of the present application is shown, where the method can be applied to the first IDP in the embodiment shown in fig. 1. The method comprises the following steps:
The first protocol is any one of protocols supported by the first SP, and may be a Security Assertion Markup Language (SAML) protocol, an open identification number attachment (OpenID Connect, oid) protocol, or the like.
The identity authentication request is used for verifying whether the identity of the target account is legal or not. The identity authentication request carries the identity information of the target account. The target account may be any one of the accounts provided by the tenant. The identity information of the target account may include an account identifier and an account password of the target account. The account identification is used to uniquely identify the user account, which may be the account name of the target account. The account password may be a combination of various characters (numbers, letters, symbols), a gesture password, or biometric information (e.g., fingerprint information, face information, iris information, etc.) of a user to which the target account belongs, which is not limited in this embodiment of the present application.
Step 202, the authentication request based on the first protocol is converted into the authentication request based on the second protocol.
The second protocol is any one supported by the second IDP, which may be a SAML protocol, an OIDC protocol, or the like. The first protocol is different from the second protocol. The identity authentication information based on the second protocol also carries the identity information of the target account.
In the embodiment of the application, by adding the first IDP and performing conversion between different protocols by the IDP, the situation that the application service needs to be configured with different IDP systems and adapts to the SSO protocols adopted by the different IDP systems can be avoided, and the development complexity of the application service is reduced.
Step 203, sending an authentication request based on the second protocol to the second IDP.
And the second IDP is used for matching the identity information of the target account with the pre-stored identity information to obtain an identity authentication result, and allowing the target account to log in the first SP when the identity authentication result is that the authentication is passed.
Optionally, before step 203, the first IDP may also detect whether the second IDP supports the first protocol. Specifically, the first IDP stores a protocol list supported by the second IDP, and after receiving the authentication request based on the first protocol, the first IDP determines the first protocol first, and then searches whether the first protocol exists in the protocol list supported by the second IDP. If the protocol list supported by the second IDP has the first protocol, the second IDP supports the first protocol; if the first protocol does not exist in the protocol list supported by the second IDP, the second IDP does not support the first protocol.
After detecting that the second IDP supports the first protocol, the first IDP directly sends an authentication request based on the first protocol to the second IDP; after detecting that the second IDP does not support the first protocol, the first IDP converts the authentication request based on the first protocol into the authentication request based on the second protocol, and then sends the authentication request based on the second protocol to the second IDP.
To sum up, in the technical solution provided in the embodiment of the present application, by adding an intermediate IDP (i.e., a first IDP) between an application service and a tenant IDP (i.e., a second IDP), when there is an authentication requirement, the identity information of a target account is not directly sent to the tenant IDP for authentication, but is first sent to the first IDP, and the first IDP converts an authentication request based on a first protocol, which is not supported by the second IDP, into an authentication request based on a second protocol, which is supported by the second IDP, and then sends the authentication request based on the second protocol to the second IDP for authentication, thereby avoiding a situation that the application service needs to configure different IDP systems, adapting to SSO protocols adopted by different IDP systems, and reducing development complexity of the application service.
Referring to fig. 3, a flow chart of an authentication method according to an embodiment of the present application is shown. The method comprises the following steps:
in step 301, the terminal sends a first access request corresponding to a first SP to a first IDP.
The first access request is for requesting access to a landing page of the first SP. The first access request carries a parameter value specifying a parameter. The parameter value of the specified parameter is used to indicate a second IDP for verifying the identity information. The SAAS platform defines different IDPs corresponding to different parameter values of the specified parameter. When identity authentication needs to be performed on a certain IDP, the parameter value of the designated parameter corresponding to the IDP is obtained and added to the first access request. Optionally, the specified parameter is idp _ hit. Optionally, the first access request further carries a Uniform Resource Locator (URL) of the first SP.
Optionally, when receiving an access instruction corresponding to the URL of the first SP, the terminal adds a parameter value of a specified parameter at a specified position of the URL of the first SP, and sends a first access request to the first IDP, where the first access request carries the URL of the first SP and the parameter value of the specified parameter.
Specifically, the terminal displays a browser page including an input box for inputting a URL, and when the terminal receives the URL input in the input box or receives a trigger instruction corresponding to the access control after pulling down a URL selected in a menu bar in the input box, the terminal receives an access instruction corresponding to the URL of the first SP. Or the browser page displays a jump control of a login page of the first SP, and the terminal receives an access instruction corresponding to the URL of the first SP after receiving the trigger corresponding to the jump control.
Referring collectively to fig. 4, a schematic interface diagram illustrating authentication according to an embodiment of the present application is shown. The terminal 11 displays a browser page 41, the browser page includes a jump control 411 of the patent management service, the user triggers the jump control 411, at this time, the terminal sends a first access request to the first IDP12, and the first access request carries the URL "http: \ \ patent \123 "412 and the parameter value" idphenint ═ t1 "413 for the specified parameter.
In step 302, the first IDP determines a second IDP according to the parameter values of the specified parameters.
Optionally, the first IDP searches for an IDP corresponding to the parameter value of the specified parameter in the preset corresponding relationship, to obtain a second IDP. The preset corresponding relationship comprises the corresponding relationship between different parameter values of the designated parameter and different IDPs. The preset correspondence may be set on the first IDP in advance by a person skilled in the art. For example, when adding an IDP, the relevant technician sets a parameter value corresponding to the IDP and adds the parameter value to the preset corresponding relationship. The adaptation of the application service is not required in the process, so the application service is unaware of it.
For example, the preset correspondence relationship may refer to the following table-1.
TABLE-1
| IDP of tenant 1 | IDP of tenant 2 | IDP of tenant 3 | |
| Idp_hint | T1 | T2 | T3 |
Step 303, the first IDP forwards the first access request to the second IDP.
Accordingly, the second IDP receives the first access request sent by the first IDP. And when the second IDP receives the first access request, searching login page data of the second IDP according to the URL carried in the first access request, and sending the login page data of the second IDP to the first IDP as a feedback result.
Referring collectively to fig. 4, the first IDP12 forwards the first access request to the second IDP 13.
And step 304, the second IDP sends login page data to the terminal according to the first access request.
The landing page data refers to landing page data of the second IDP. Referring to fig. 4 in conjunction, the second IDP13 sends login page data to the terminal 11.
Accordingly, the terminal receives the login page data sent by the second IDP.
And 305, displaying the login page by the terminal according to the login page data.
And the terminal displays the login page of the second IDP according to the login page data in the feedback result. Optionally, the login page of the second IDP includes a first input entry for inputting an account and a second input entry for inputting a password.
With reference to fig. 4, the terminal 11 displays the login page 42 of the second IDP according to the received feedback result of the login page data carrying the second IDP.
Step 306, the terminal receives the identity information of the target account inputted on the login page.
The identity information of the target account includes the account name and password of the target account.
The account name of the target account may be determined as follows: in one possible implementation manner, the terminal receives an account name input by a user at the first input entrance. In another possible implementation manner, the terminal receives an account name selected by the user in the drop-down menu bar of the first input entry. In another possible implementation manner, the terminal acquires and displays the account name of the first input entry by default.
The password may be determined as follows: in one possible implementation, the terminal receives a password input by the user at the second input entry. In another possible implementation manner, the terminal acquires the password displayed by default in the second input entry. In another possible implementation manner, after receiving the trigger instruction corresponding to the second input entry, the terminal starts to acquire the biometric information of the user as the password. Specifically, the terminal can also gather fingerprint information through the fingerprint module through camera collection face information or iris information, and this application embodiment does not limit to this.
In addition, it should be noted that the target account may be a dedicated account provided by the tenant, or may also be a social account used by an employee of the tenant, which is not limited in this embodiment of the present application. When the target account is a social account, the second IDP is an IDP provided by a social software provider.
In step 307, the terminal sends an authentication request based on the first protocol to the first IDP.
And carrying the identity information of the target account on the basis of the identity authentication request of the first protocol. Alternatively, the terminal may send an authentication request based on the first protocol to the first IDP after the user completes the input of the identity information. Optionally, the login page displayed by the terminal further includes a confirmation control, and the terminal sends an authentication request based on the first protocol to the first IDP after receiving a trigger signal corresponding to the confirmation control.
In step 308, the first IDP converts the authentication request based on the first protocol into an authentication request based on the second protocol.
Step 309, the first IDP sends an authentication request based on the second protocol to the second IDP.
Accordingly, the second IDP receives the second protocol based authentication request sent by the first IDP.
In step 310, the second IDP matches the identity information of the target account with the pre-stored identity information to obtain an identity authentication result.
The identity authentication result comprises authentication passing and authentication failing. And when the identity authentication result is that the authentication is passed, allowing the target account to log in to the first SP. And when the identity authentication result is that the authentication is not passed, the target account is not allowed to log in the first SP.
And the terminal compares the password of the target account with the pre-stored password to obtain an identity authentication result. When the password is a combination of various characters or a gesture password, the second IDP determines that the authentication result is passed when detecting that the password of the target account is the same as the pre-stored password, and determines that the authentication result is failed when detecting that the password of the target account is not the same as the pre-stored password. When the password is the biological characteristic information, the second IDP determines that the authentication result is passed when detecting that the similarity between the password of the target account and the pre-stored password is greater than or equal to the preset similarity, and determines that the authentication result is failed when detecting that the similarity between the password of the target account and the pre-stored password is less than the preset similarity.
Optionally, when the second IDP verifies that the authentication result is that the authentication is passed, the target account may be verified for the second time by using the dynamic verification code. The dynamic verification code can be sent to a mailbox or a mobile phone number bound by the target account. Specifically, the second IDP sends the dynamic verification code to the first IDP, the first IDP sends the dynamic verification code to the second terminal, the terminal displays an input box for inputting the dynamic verification code after receiving the dynamic verification code, receives the dynamic verification code input in the input box, and allows the target account to log in to the first SP when detecting that the input dynamic verification code is consistent with the dynamic verification code sent by the second IDP.
To sum up, in the technical solution provided in this embodiment of the present application, by adding an intermediate IDP between the application service and the tenant IDP, when there is an authentication requirement, the identity information of the target account is not directly sent to the tenant IDP for authentication, but is first sent to the first IDP, and the first IDP converts an authentication request based on a first protocol that is not supported by the second IDP into an authentication request based on a second protocol that is supported by the second IDP, and then sends the authentication request based on the second protocol to the second IDP for authentication, which can avoid the situation that the application service needs to configure different IDP systems to adapt to SSO protocols adopted by different IDP systems, and reduce the development complexity of the application service.
And when the second IDP determines that the identity authentication result is that the authentication is passed, returning a pass token to the terminal through the first IDP, wherein the pass token is carried by the interaction data between the subsequent terminal and the second IDP when the terminal accesses the first SP, and the second IDP allows the access to the first SP when detecting the existence of the pass token. In an optional embodiment provided based on the embodiment shown in fig. 2, after step 203, the identity verification method further includes:
and step 401, receiving a pass token sent by the second IDP when the authentication result is determined to be that the authentication is passed.
And when the second IDP determines that the authentication result is authentication pass, generating a pass token, and then sending the pass token to the first IDP.
Step 402, the pass token is sent to the terminal.
Accordingly, the terminal receives the pass token sent by the first IDP.
Optionally, before sending the pass token to the terminal, the first IDP may detect whether the pass token is a protocol supported by the first SP. If yes, directly sending a pass token to the terminal; if not, the pass token is firstly converted into a protocol supported by the first SP, and then the pass token is sent to the terminal.
And step 403, receiving a second access request corresponding to a second SP sent by the terminal.
The second access request carries a pass token. The step 301 may be referred to for explanation of receiving the second access request, which is not described herein. Optionally, the terminal first detects whether a pass token is present. And if the access request exists, sending a second access request carrying the pass token to the first IDP, and if the access request does not exist, sending a second access request carrying the parameter value of the specified parameter to the first IDP.
Step 404, sending a second access request to the second IDP.
And the second IDP is used for allowing the target account to log in the second SP when the second access request carrying the pass token is detected. In the embodiment of the application, after the target account logs in to the first SP, when the subsequent target account logs in to other SPs provided by the SAAS platform, the SP can be directly logged in and accessed without performing identity authentication, so that the number of sessions between the terminal and the second SP can be reduced, and communication resources can be saved.
To sum up, according to the technical solution provided in the embodiment of the present application, after the target account logs in to the first SP, if the target account needs to access the second SP, the access request carrying the pass token is sent to the first IDP, so that the target account can access the second SP without performing authentication, thereby reducing the number of sessions between the terminal and the second SP, and saving communication resources.
In the following, embodiments of the apparatus of the present application are described, and for portions of the embodiments of the apparatus not described in detail, reference may be made to technical details disclosed in the above-mentioned method embodiments.
Referring to fig. 5, a block diagram of an authentication apparatus provided in an exemplary embodiment of the present application is shown. The authentication means may be implemented as all or part of the terminal by software, hardware or a combination of both. The identity authentication device includes: a first receiving module 501, a protocol conversion module 502 and a first transmitting module 503.
A first receiving module 501, configured to receive an authentication request based on a first protocol sent by a terminal, where the authentication request carries identity information of a target account.
A protocol conversion module 502, configured to convert the authentication request based on the first protocol into an authentication request based on a second protocol, where the first protocol is different from the second protocol.
A first sending module 503, configured to send the second protocol-based authentication request to a second IDP, where the second IDP is configured to match the identity information of the target account with pre-stored identity information to obtain an authentication result, and allow the target account to log in to the first SP when the authentication result is that the authentication is passed.
To sum up, in the technical solution provided in this embodiment of the present application, by adding an intermediate IDP between the application service and the tenant IDP, when there is an authentication requirement, the identity information of the target account is not directly sent to the tenant IDP for authentication, but is first sent to the first IDP, and the first IDP converts an authentication request based on a first protocol that is not supported by the second IDP into an authentication request based on a second protocol that is supported by the second IDP, and then sends the authentication request based on the second protocol to the second IDP for authentication, which can avoid the situation that the application service needs to configure different IDP systems to adapt to SSO protocols adopted by different IDP systems, and reduce the development complexity of the application service.
In an alternative embodiment provided on the basis of the embodiment shown in fig. 5, the apparatus further comprises: a determining module, a second receiving module and a second sending module (not shown in the figure).
The first receiving module 501 is configured to receive a first access request corresponding to the first SP, where the first access request carries a parameter value of a specified parameter.
And the determining module is used for determining the second IDP according to the specified parameter value of the specified parameter.
The first sending module 503 is configured to forward the first access request to the second IDP, where the second IDP is configured to send login page data to the terminal according to the first access request, and the terminal is configured to display a login page according to the login page data, and send the first protocol-based authentication request to the first IDP after receiving the identity information of the target account input on the login page.
Optionally, the determining module is configured to search for an IDP corresponding to the parameter value of the specified parameter in a preset corresponding relationship to obtain the second IDP, where the preset corresponding relationship includes corresponding relationships between different parameter values of the specified parameter and different IDPs.
In an alternative embodiment provided on the basis of the embodiment shown in figure 5,
and the second receiving module is configured to receive a pass token sent by the second IDP when the identity authentication result is determined to be that the authentication passes.
And the second sending module is used for sending the pass token to the terminal.
The first receiving module 501 is configured to receive a second access request corresponding to a second SP, where the second access request carries the pass token, and the second access request is sent by the terminal;
the first sending module 503 is configured to send the second access request to the second IDP, where the second IDP is configured to allow the target account to log in to the second SP when detecting that the second access request carries the pass token.
In an alternative embodiment provided on the basis of the embodiment shown in fig. 5, the apparatus further comprises: a detection module (not shown in the figures).
The detecting module is configured to detect whether the second IDP supports the first protocol.
The first sending module 503 is configured to:
when detecting that the second IDP supports the first protocol, sending the identity authentication request based on the first protocol to the second IDP;
when detecting that the second IDP does not support the first protocol, sending the second protocol-based authentication request to the second IDP.
It should be noted that, when the apparatus provided in the foregoing embodiment implements the functions thereof, only the division of the functional modules is illustrated, and in practical applications, the functions may be distributed by different functional modules according to needs, that is, the internal structure of the apparatus may be divided into different functional modules to implement all or part of the functions described above. In addition, the apparatus and method embodiments provided by the above embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments for details, which are not described herein again.
Referring to fig. 6, a schematic structural diagram of a server according to an embodiment of the present application is shown. Specifically, the method comprises the following steps: the server 600 includes a Central Processing Unit (CPU) 601, a system Memory 604 including a Random Access Memory (RAM) 602 and a Read-Only Memory (ROM) 603, and a system bus 605 connecting the system Memory 604 and the CPU 601. The server 600 also includes a basic Input/output (I/O) system 606, which facilitates the transfer of information between devices within the computer, and a mass storage device 607, which stores an operating system 613, application programs 614, and other program modules 615.
The basic input/output system 606 includes a display 606 for displaying information and an input device 609 such as a mouse, keyboard, etc. for a user to input information. Wherein the display 606 and the input device 609 are connected to the central processing unit 601 through an input output controller 610 connected to the system bus 605. The basic input/output system 606 may also include an input/output controller 610 for receiving and processing input from a number of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, input/output controller 610 may also provide output to a display screen, a printer, or other type of output device.
The mass storage device 607 is connected to the central processing unit 601 through a mass storage controller (not shown) connected to the system bus 605. The mass storage device 607 and its associated computer-readable media provide non-volatile storage for the server 600. That is, the mass storage device 607 may include a computer-readable medium (not shown) such as a hard disk.
Without loss of generality, the computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes RAM, ROM, Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash Memory or other solid state Memory technology, high density Digital Video Disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Of course, those skilled in the art will appreciate that the computer storage media is not limited to the foregoing. The system memory 604 and mass storage device 607 described above may be collectively referred to as memory.
The server 600 may also operate in accordance with various embodiments of the present application by connecting to remote computers over a network, such as the internet. That is, the server 600 may be connected to the network 612 through the network interface unit 611 connected to the system bus 605, or may be connected to other types of networks or remote computer systems (not shown) using the network interface unit 611.
The memory further includes one or more programs, the one or more programs are stored in the memory, and the one or more programs include steps executed by the server for performing the authentication method provided by the embodiment of the present application.
In an exemplary embodiment, a computer-readable storage medium is further provided, where at least one instruction is stored in the computer-readable storage medium, and the at least one instruction is loaded and executed by a processor of a terminal to implement the rights management method in the above-described method embodiments.
Alternatively, the computer readable storage medium may be a ROM, a RAM, a magnetic tape, a floppy disk, an optical data storage device, and the like.
In an exemplary embodiment, a computer program product is also provided, which, when executed, is adapted to implement the authentication method provided in the above-described method embodiments.
It should be understood that reference to "a plurality" herein means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. As used herein, the terms "first," "second," and the like, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
The above description is only exemplary of the present application and should not be taken as limiting the present application, and any modifications, equivalents, improvements and the like that are made within the spirit and principle of the present application should be included in the protection scope of the present application.
Claims (10)
1. An identity verification method applied to a first identity provider (IDP), the method comprising:
receiving an identity authentication request based on a first protocol, which is sent by a terminal, wherein the identity authentication request carries identity information of a target account;
converting the authentication request based on the first protocol into an authentication request based on a second protocol, wherein the first protocol is different from the second protocol;
and sending the identity authentication request based on the second protocol to a second IDP, wherein the second IDP is used for matching the identity information of the target account with the pre-stored identity information to obtain an identity authentication result, and allowing the target account to log in to the first application service SP when the identity authentication result is that the authentication is passed.
2. The method according to claim 1, wherein before receiving the authentication request based on the first protocol sent by the terminal, the method further comprises:
receiving a first access request corresponding to the first SP sent by the terminal, wherein the first access request carries parameter values of specified parameters;
determining the second IDP according to the parameter value of the specified parameter;
and forwarding the first access request to the second IDP, wherein the second IDP is used for sending login page data to the terminal according to the first access request, the terminal is used for displaying a login page according to the login page data, and sending the identity authentication request based on the first protocol to the first IDP after receiving the identity information of the target account input on the login page.
3. The method of claim 2, wherein the determining the second IDP according to the parameter value of the specified parameter comprises:
and searching the IDP corresponding to the parameter value of the designated parameter in a preset corresponding relation to obtain the second IDP, wherein the preset corresponding relation comprises corresponding relations between different parameter values of the designated parameter and different IDPs.
4. The method according to any of claims 1 to 3, wherein after sending the second protocol-based authentication request to the second IDP, further comprising:
receiving a pass token sent by the second IDP when the identity authentication result is determined to be authentication passing;
sending the pass token to the terminal;
receiving a second access request corresponding to a second SP (service provider) sent by the terminal, wherein the second access request carries the pass token;
and sending the second access request to the second IDP, wherein the second IDP is used for allowing the target account to log in to the second SP when the second access request is detected to carry the pass token.
5. The method according to any of claims 1 to 3, wherein before converting the authentication request based on the first protocol into the authentication request based on the second protocol, further comprising:
detecting whether the second IDP supports the first protocol;
when detecting that the second IDP supports the first protocol, sending the identity authentication request based on the first protocol to the second IDP;
when detecting that the second IDP does not support the first protocol, sending the second protocol-based authentication request to the second IDP.
6. An identity authentication apparatus, wherein the apparatus is applied to a first identity provider (IDP), the apparatus comprising:
the first receiving module is used for receiving an identity authentication request based on a first protocol, which is sent by a terminal, wherein the identity authentication request carries identity information of a target account;
a protocol conversion module, configured to convert the authentication request based on the first protocol into an authentication request based on a second protocol, where the first protocol is different from the second protocol;
and the first sending module is used for sending the identity authentication request based on the second protocol to a second IDP, the second IDP is used for matching the identity information of the target account with the pre-stored identity information to obtain an identity authentication result, and the target account is allowed to log in the first application service SP when the identity authentication result is that the authentication is passed.
7. The apparatus of claim 6, further comprising:
the first receiving module is configured to receive a first access request corresponding to the first SP, where the first access request carries a parameter value of a specified parameter;
a determining module, configured to determine the second IDP according to a specified parameter value of the specified parameter;
the first sending module is configured to forward the first access request to the second IDP, where the second IDP is configured to send login page data to the terminal according to the first access request, and the terminal is configured to display a login page according to the login page data, and send the first protocol-based authentication request to the first IDP after receiving the identity information of the target account input on the login page.
8. The apparatus of claim 7, wherein the determining module is configured to find the IDP corresponding to the parameter value of the specified parameter in a preset corresponding relationship to obtain the second IDP, and the preset corresponding relationship comprises a corresponding relationship between different parameter values of the specified parameter and different IDPs.
9. An electronic device, comprising a processor and a memory, the memory storing at least one instruction that is loaded and executed by the processor to implement the authentication method according to any one of claims 1 to 5.
10. A computer-readable storage medium having stored therein at least one instruction, which is loaded and executed by a processor to implement the authentication method according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911411315.4A CN113127821A (en) | 2019-12-31 | 2019-12-31 | Identity authentication method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911411315.4A CN113127821A (en) | 2019-12-31 | 2019-12-31 | Identity authentication method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113127821A true CN113127821A (en) | 2021-07-16 |
Family
ID=76770147
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911411315.4A Pending CN113127821A (en) | 2019-12-31 | 2019-12-31 | Identity authentication method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113127821A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114499930A (en) * | 2021-12-13 | 2022-05-13 | 奇安信科技集团股份有限公司 | Method and device for processing multi-protocol single sign-on request |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101014198A (en) * | 2007-02-14 | 2007-08-08 | 华为技术有限公司 | Gateway service control point apparatus and international roaming realizing method |
| CN101730984A (en) * | 2007-04-20 | 2010-06-09 | 泰克莱克公司 | Methods, systems, and computer program products for providing fault-tolerant service interaction and mediation function in a communications network |
| CN101998360A (en) * | 2009-08-11 | 2011-03-30 | 中兴通讯股份有限公司 | Method for building identity management trusting and identity provider and service provider |
| CN102457378A (en) * | 2010-10-15 | 2012-05-16 | 洛克威尔自动控制技术股份有限公司 | Security model for industrial devices |
| CN102638454A (en) * | 2012-03-14 | 2012-08-15 | 武汉理工大学 | Plug-in type SSO (single signon) integration method oriented to HTTP (hypertext transfer protocol) identity authentication protocol |
| CN102763111A (en) * | 2010-01-22 | 2012-10-31 | 交互数字专利控股公司 | Method and apparatus for trusted federated identity management and data access authorization |
| CN105262751A (en) * | 2015-10-27 | 2016-01-20 | 上海斐讯数据通信技术有限公司 | Safety login method and device |
| US20180131685A1 (en) * | 2016-11-04 | 2018-05-10 | Netskope, Inc. | Non-intrusive security enforcement for federated single sign-on (sso) |
| CN108337260A (en) * | 2016-05-11 | 2018-07-27 | 甲骨文国际公司 | Multi-tenant identity and data security management cloud service |
| CN109314704A (en) * | 2016-09-14 | 2019-02-05 | 甲骨文国际公司 | Function is nullified for multi-tenant identity and the single-sign-on and single-point of data safety management cloud service |
-
2019
- 2019-12-31 CN CN201911411315.4A patent/CN113127821A/en active Pending
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101014198A (en) * | 2007-02-14 | 2007-08-08 | 华为技术有限公司 | Gateway service control point apparatus and international roaming realizing method |
| CN101730984A (en) * | 2007-04-20 | 2010-06-09 | 泰克莱克公司 | Methods, systems, and computer program products for providing fault-tolerant service interaction and mediation function in a communications network |
| CN101874383A (en) * | 2007-04-20 | 2010-10-27 | 泰克莱克公司 | Systems, methods, and computer program products for providing service interaction and mediation in a communications network |
| CN101998360A (en) * | 2009-08-11 | 2011-03-30 | 中兴通讯股份有限公司 | Method for building identity management trusting and identity provider and service provider |
| CN102763111A (en) * | 2010-01-22 | 2012-10-31 | 交互数字专利控股公司 | Method and apparatus for trusted federated identity management and data access authorization |
| CN102457378A (en) * | 2010-10-15 | 2012-05-16 | 洛克威尔自动控制技术股份有限公司 | Security model for industrial devices |
| CN102638454A (en) * | 2012-03-14 | 2012-08-15 | 武汉理工大学 | Plug-in type SSO (single signon) integration method oriented to HTTP (hypertext transfer protocol) identity authentication protocol |
| CN105262751A (en) * | 2015-10-27 | 2016-01-20 | 上海斐讯数据通信技术有限公司 | Safety login method and device |
| CN108337260A (en) * | 2016-05-11 | 2018-07-27 | 甲骨文国际公司 | Multi-tenant identity and data security management cloud service |
| CN109314704A (en) * | 2016-09-14 | 2019-02-05 | 甲骨文国际公司 | Function is nullified for multi-tenant identity and the single-sign-on and single-point of data safety management cloud service |
| CN109639687A (en) * | 2016-09-14 | 2019-04-16 | 甲骨文国际公司 | For providing system, method and the medium of identity based on cloud and access management |
| US20180131685A1 (en) * | 2016-11-04 | 2018-05-10 | Netskope, Inc. | Non-intrusive security enforcement for federated single sign-on (sso) |
Non-Patent Citations (1)
| Title |
|---|
| 张振峰: "基于身份的可验证加密签名协议的安全性分析", 《计算机学报》, vol. 29, no. 9, pages 1688 - 1693 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114499930A (en) * | 2021-12-13 | 2022-05-13 | 奇安信科技集团股份有限公司 | Method and device for processing multi-protocol single sign-on request |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6847187B2 (en) | Image-based CAPTCHA challenge | |
| US11706218B2 (en) | Systems and methods for controlling sign-on to web applications | |
| CN108475312B (en) | Single sign-on method for device security shell | |
| EP3794794B1 (en) | Method and system of providing secure access to a cloud service in a cloud computing environment | |
| US10382426B2 (en) | Authentication context transfer for accessing computing resources via single sign-on with single use access tokens | |
| US9525684B1 (en) | Device-specific tokens for authentication | |
| US10009767B2 (en) | Account login method, apparatus, and system | |
| US8938789B2 (en) | Information processing system, method for controlling information processing system, and storage medium | |
| US20150310194A1 (en) | Authentication Using Device ID | |
| US8892885B2 (en) | System and method for delivering a challenge response in an authentication protocol | |
| US20130019300A1 (en) | System, control method therefor, service providing apparatus, relay apparatus and computer-readable medium | |
| JP5988699B2 (en) | Cooperation system, its cooperation method, information processing system, and its program. | |
| CN111556006A (en) | Third-party application system login method, device, terminal and SSO service platform | |
| US10601809B2 (en) | System and method for providing a certificate by way of a browser extension | |
| US11151239B2 (en) | Single sign-on management for multiple independent identity providers | |
| CN112838951B (en) | Operation and maintenance method, device and system of terminal equipment and storage medium | |
| US9355269B2 (en) | Method and system for managing uniquely identifiable bookmarklets | |
| CN115022047B (en) | Account login method and device based on multi-cloud gateway, computer equipment and medium | |
| US20180039771A1 (en) | Method of and server for authorizing execution of an application on an electronic device | |
| CN104158856A (en) | Local API calling method dispense with preset of secure session | |
| CN111241504B (en) | Identity verification method, device, electronic equipment and storage medium | |
| CN113127821A (en) | Identity authentication method and device, electronic equipment and storage medium | |
| US10735399B2 (en) | System, service providing apparatus, control method for system, and storage medium | |
| US20200137037A1 (en) | Endpoint security | |
| US20210243174A1 (en) | Auto-Form Fill Based Website Authentication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |