CN102638454B - A plug-in single sign-on integration method for HTTP authentication protocol - Google Patents

Abstract

The invention relates to a plug-in single sign-on integration method for HTTP identity authentication protocol, the single sign-on system of the method includes a Web service component, a Web application component, a single sign-on HTTP plug-in, a security token processing page, a browser, Identity service system, master account database, and master-slave account binding database, among which the single sign-on HTTP plug-in is the key, which is inserted into the HTTP request and response processing of the Web service component using the HTTP identity authentication protocol based on the extension mechanism provided by the Web service component In the channel; when the user logs in to the identity service system, the plug-in uses the user's account name and password on the web application system to automatically complete the interaction with the HTTP authentication protocol of the web service component, so that the user does not need to enter the account name in the web application system , password to log in to the web application system, so as to achieve the purpose of single sign-on. Adopting the method of the present invention realizes single sign-on without changing the original security configuration and functions of the system.

Description

A plug-in single sign-on integration method for HTTP authentication protocol

technical field

The invention belongs to the technical field of identity authentication and access control of information security, in particular, it is a plug-in single sign-on integration method for HTTP identity authentication protocol.

Background technique

With the development of enterprise e-commerce and office informatization, more and more enterprises and organizations have established a large number of special-purpose information systems, collectively referred to as application systems, such as customer relationship management systems, ERP (Enterprise Resource Planning) systems, Financial system, office automation system, e-mail system, etc. While these numerous application systems bring convenience to people's production, management, and office, and improve production and work efficiency, they also bring some troubles to people. That is, each user must remember that he (or she) is in different The account name and password of the application system (also known as user name and password); these account names and passwords in different application systems may be the same or different; need to remember, use many different account names, The problem of password has: 1) the difficulty of account name, password management, as account name, password are too many to confuse easily, forget; In response to this problem, the so-called Single Sign On (SSO) requirements and technologies have emerged, that is, users only need to use one identity credential (such as an account name, password, or a digital certificate, etc.), After an online system completes online identity authentication (that is, login), it can access all other systems that can be accessed, without having to enter the account name, password or use digital certificates for identity authentication (that is, to log in again).

Most of the current various application systems adopt the client/server (Client/Server) mode, and some of them adopt the standard and general technology based on the browser (Browser) and Web server, that is, the Browser/Server mode (referred to as B /S mode), and some use non-standard or non-universal client/server technology (referred to as C/S mode). In the B/S mode system, the client browser and the Web server perform data interaction and transmission through the standard HyperText Transfer Protocol (HTTP): the browser transmits the service request (HTTP request) in HTTP format to the Web server, and the Web server The request is processed accordingly, and then the web server returns the processing result to the browser as a response in HTTP format (HTTP response), and finally the browser displays the returned result content according to the returned result data. An HTTP request consists of a request line (Request Line), multiple optional headers (Header) and an optional body (Body). From the request line and the "Host" header, an HTTP request URL ( UniformResource Locator); HTTP response consists of a status line (Status Line), multiple optional headers (Header) and an optional body (Body). Since the B/S mode adopts the common client such as a browser and a standard technical framework, it is easy to use and interoperate, and is the mainstream and trend of the current information system technology development, and it is also the technology adopted by the application system targeted by the present invention. The application system that adopts B/S mode or architecture is called Web application system.

The single sign-on technologies for B/S mode Web application systems are currently common: 1) based on Cookie; 2) based on security gateway; 3) based on Windows Kerberos; 4) based on single sign-on protocol (standard or Custom protocol): 5) Other schemes.

A cookie is information saved by the web server in the client browser (or in the client host) through an HTTP response. It can contain any content, but usually contains user session (Session) state information. A cookie has a scope, and its scope is composed of a domain name (Doma in Name) and a path (Path); if the host domain name part and path part of the HTTP request are within the scope of the cookie, the HTTP request submitted by the browser will include the server-side Cookies set. Cookie-based single sign-on requires that the "base" of the domain names of different information systems be the same. For example, if the domain names of two information systems are oa.example.com.cn and crm.example.com.cn, their "base" " are all example.com.cn, therefore, cookie-based single sign-on can be achieved, and IBM's LTPA (Lightweight Third Party Authentication) single sign-on technology is based on cookies.

The single sign-on based on the security gateway is to use a web reverse proxy (Reverse Proxy) that realizes the security control function as the gateway (that is, the gateway) for users to access different information systems and application systems deployed behind it. Users who authenticate (that is, successfully log in) can access the system deployed behind it through the security gateway, such as IBM's WebSEAL, which is such a security gateway. The biggest disadvantage of this single sign-on technology is that when the number of concurrent user visits is large, the security gateway is a performance bottleneck, and it is a potential single point of failure (Single Point of Failure).

The Web single sign-on technology based on Windows Kerberos is implemented through Kerberos authentication (Authentication) of Windows Active Directory (AD) combined with HTTPNegotiate protocol. The limitations of this technical solution are: 1) It needs to deploy WindowsAD or other Kerberos systems; 2) It requires all users to have accounts in the AD domain and the user host must log in to the AD domain; 3) It requires all Web information systems and application systems The HTTP Negotiate protocol is used for user identity authentication, and all Web information systems and application systems use AD domain user accounts to manage and control user access; 4) It is only suitable for information systems and application systems accessed through the intranet. Due to these special requirements, this limits the application of single sign-on solutions based on Windows Kerberos, because, no matter from the perspective of development technology or application environment, a large number of current Web information systems and application systems do not meet these conditions ( In other words, not all Web information systems and application systems meet these conditions).

The protocols for Web single sign-on currently mainly include Security Assertion Markup Language (SAML) and WS-Federation Passive Requestor Profile (WS-FPRP for short). Whether it is SAML or WS-FPRP, there is a system called Identity Provider (IdP for short) in its technical architecture to provide online identity authentication services (called identity service system), and users only need to (use a browser) in IdP to complete With one login (ie, online identity authentication), you can access other Web information systems in the IdP trust domain without further login (identity authentication) operations. However, for this single sign-on technical solution to be successfully applied, there are two key issues to be solved: one is how to solve the correspondence and conversion between user accounts in different systems, and the other is how to make the existing various information System, application system and single sign-on protocol integration. A more specific description of the first problem is as follows: various information systems and application systems involving single sign-on usually have their own user account management components and account databases, and these information systems and application systems are based on their own user accounts. In this way, the user account used by the user to log in and authenticate at the IdP may be different from the account in an information system or application system to be accessed (of course it may be the same) Therefore, when a user accesses an application system after completing identity authentication at the IdP, corresponding account correspondence and transformation are required, so that the user can log in and access the application system with his account (identity) in the application system.

A common solution to the first problem mentioned above is: the user uses a primary account to log in to the IdP. This primary account can be an existing application system account of the user, or an existing global account (such as account in Windows Active Directory), or a newly created global account; the user's master account is associated with the user's account (called a secondary account) in different information systems and application systems in a certain way in advance. It is called identity (account) association (Identity Federation or Account Federation) or identity (account) binding (Identity Binding or Account Binding); when a user uses his primary account to log in (identity authentication) in IdP, access a specific application system, its master account is mapped and transformed into the user’s slave account in the application system in a certain way, and then the user accesses the application system based on the slave account. The process of corresponding and transforming the master and slave accounts is called identity (account ) mapping (Identity Mapping or Account Mapping).

The second problem mentioned actually involves the integration technology of single sign-on, which is the most complex and difficult problem in current single sign-on applications. There are usually several solutions to this problem: (1) application system The operating platform itself supports the relevant single sign-on protocol (for example, the latest version of Oracle WebLogic Server supports the SAML protocol). Therefore, if the application system relies on the operating platform for login operations (user identity authentication), then by configuring the user By means of identity authentication, single sign-on can be realized through protocol interconnection; (2) realized by modifying the functions of the user login part of the application system, which may include modifying the relevant configuration of identity authentication, modifying the corresponding user login module, etc.; (3) Through the identity authentication extension mechanism provided by the operating platform, such as JAAS (Java Authentication and Authorization Service).

The first integration solution mentioned above is not applicable in any situation, because most of the current web operating platforms (web service components, servers) do not support the corresponding single sign-on protocol. For the second solution, it is not applicable in many cases, because enterprises and organizations may be unwilling or unable to adopt the second integration solution due to various reasons, for example, because they are worried that the system will be damaged after the system is modified. The stable operation of the system is affected, or the source code of the system no longer exists (for example, the original system developer is unwilling to provide relevant code, or has closed down, etc.). The third solution mentioned above is not suitable for all situations. First, this solution is usually only applicable to the situation where the application system relies on the Web operating platform (Web service component, Web server) for identity authentication (such as by Servlet Container User identity authentication) is not applicable to the situation where the application system itself performs user identity authentication; second, to use this mechanism to achieve single sign-on, it usually needs to change the previous identity authentication method of the platform, and sometimes enterprises and organizations due to various The reason is that you are unwilling to make this change (for example, because you are worried that this change will affect the operation of the system or be insecure); third, do all Web operating platforms provide an extension mechanism for identity authentication, or provide this extension mechanism in theory? , but in fact due to technical limitations, it is difficult for the extended identity authentication mechanism to achieve the same effect as the previous identity authentication mechanism. For example, for Microsoft IIS (Internet Information Services) Web server, its technical documentation points out that it can Interface) to extend the identity authentication function of IIS, but in fact this extension is limited. For example, the customized identity authentication mechanism can only be extended when IIS is configured as anonymous authentication (AnonymousAuthentication), and because Microsoft does not disclose IIS Internal technology, it is difficult to develop a single sign-on authentication mechanism with the same effect as IIS's own authentication mechanism based on the ISAPI extension mechanism. Similar problems may also be encountered for other web operating platforms.

In the actual application integration of single sign-on, the Web application system relies on the Web platform to use standard HTTP authentication protocols (such as HTTP Basic, Digest, NTLM, Negotiate) for user identity authentication, and the identity authentication method of the Web application system cannot be changed. A frequently encountered situation, for this situation, the present invention proposes another idea to solve the integration problem of the existing Web application system and single sign-on technology: without changing the original identification mechanism, configuration and function of the system Under the premise, single sign-on is realized through the HTTP plug-in (Plug-in) technology. That is to say, under this single sign-on integration solution, the identity authentication mechanism of the Web operating platform still operates and functions in its original way. The HTTP plug-in mentioned here refers to a software component inserted into the HTTP request and response processing channel of the Web operating platform based on the extension mechanism provided by the Web operating platform. Revise. Many web operating platforms provide this HTTP plug-in mechanism, such as ISAPI of Microsoft's IIS server, Native-Code API and Managed-CodeAPI after IIS7.0, Tomcat Valve, Authentication Filter of WebLogic, Servlet Filter of WebSphere, etc.

Contents of the invention

The purpose of the present invention is to propose a plug-in single sign-on integration for the HTTP identity authentication protocol for the situation that the Web application system authenticates the user based on the standard HTTP identity authentication protocol and the identity authentication security configuration cannot be modified or changed. method to overcome the deficiencies of existing single sign-on integration technologies.

In order to achieve the above object, the technical solution adopted in the present invention is:

A plug-in single sign-on integration method for HTTP identity authentication protocol, the single sign-on system of the method includes Web service components, Web application components, single sign-on HTTP plug-ins, security token processing pages, browsers, identity services System, master account database, master-slave account binding database, where:

Web service component: provide HTTP request reception, response transmission function, and other related support functions for Web application components, including: receiving service requests in HTTP format submitted by user browsers, and submitting them to Web application components for processing after corresponding preprocessing After that, the processing result returned by the Web application component is sent to the user's browser in the form of an HTTP response; based on the corresponding security configuration, the user is authenticated and access controlled; the user's HTTP session (Session) is maintained;

Web application component: Functional software that provides users with specific application services, such as OA, CRM, WebMail, etc. Its main function is to receive application service requests submitted by users through browsers through corresponding Web service components, and send The processing result is returned to the user's browser through the Web service component; the Web application component and the corresponding Web service component constitute a Web application system;

Single sign-on HTTP plug-in: Based on the extension mechanism provided by the Web service component, it is inserted into the HTTP request and response processing channel of the Web service component of the Web application system using the HTTP identity authentication protocol to realize the single sign-on function;

Security token processing page: a Web page deployed on the Web service component of the Web application system using the HTTP identity authentication protocol to specifically process the security token issued by the identity service system to prove the identity of the user; the security token processing page is deployed on The non-secure protection path (directory) of the Web service group, that is, users who submit HTTP requests to the processing page through the browser do not need to complete identity authentication;

Browser: The client side for the user to interact with the Web application system. Its main functions are: to transmit HTTP requests to the Web service components through the HTTP protocol, receive the HTTP responses returned by the Web service components, and display the content of the responses;

Identity service system: A system that provides online identity authentication services for users. Its functions include: authenticate users online based on user identity credentials, and send security tokens to prove user identity to the Web application system through the corresponding single sign-on protocol and browser. Card;

Master account database: stores the master account information of the user logging into the identity service system, including the account name and password of the master account, or information about the data certificate corresponding to the master account;

Master-slave account binding database: save the corresponding (binding) relationship between the user's master account and the user's slave account in the Web application system, as well as the password of the slave account.

Described Web service component can be HTTP Web server (as IIS), Web container (WebContainer, as Tomcat), J2EE application server (Application Server, as WebLogic, WebSphere); Described Web application system carries out identity to user by certain mode Authentication, some of the Web application systems use standard HTTP authentication protocols (such as HTTP Basic, HTTP Negotiate) to authenticate users through Web service components; when users access a protected page or resource of a Web application system, they need to use the The corresponding account in the web application system can only be authenticated; there may be multiple web application systems.

The plug-in mechanism adopted by the single-sign-on HTTP plug-in can intercept the request and response data of the HTTP identity authentication protocol (i.e., the HTTP request carrying the Authorization header and the HTTP response carrying the WWW-Authentication header); the single-sign-on HTTP plug-in It is configured to intercept all HTTP requests and responses on the deployed Web service components, or it is configured to intercept all HTTP requests and their responses submitted to the protected directory or path and submit them to the security token processing page HTTP requests for directories or paths and their responses.

The single sign-on HTTP plug-in has corresponding configuration information for setting information related to single sign-on, such as the user login address (URL) of the identity service system, the digital certificate signed by the security token, etc.; optionally, The configuration information includes the following content: 1) which web page directories or paths in the web application system where the single sign-on HTTP plug-in is located are protected by security; 2) which HTTP authentication protocol is used by the directories or paths protected by security or which (that is, multiple can be set), and related identity authentication protocol parameters (such as domain, realm, etc.); 3) whether the specific implementation of HTTP identity authentication used allows the client to actively issue authentication and authorization requests. The configuration information 3) is aimed at such a situation: some HTTP identity authentication protocols (such as HTTP Negotiate) allow the client browser to access the protected resource for the first time, before the Web server side returns a response prompt requiring identity authentication, That is, before the client browser receives an HTTP response with a response status code of "401" (prompting Unauthorized or Authentication required) and including the WWW-Authenticate header, the client browser actively initiates the identity authentication process, that is, actively submits the HTTP response containing The HTTP request in the Authorization header requests the server to authenticate the client user and authorize resource access; however, the specific protocol implementation of a certain web component may not support this method of the client actively initiating identity authentication. Configuration information is used to indicate this. The content 1) and 2) can usually be obtained from the Web service component through a certain method, such as API and configuration file reading, but if the request cannot be obtained, it can be set and obtained through the configuration information of the single sign-on HTTP plug-in.

The format of the security token issued by the identity service system depends on the single sign-on protocol used, and can be a SAML assertion (Assertion), or a WS-Federation security token (Security Token), or a custom security token ; The identity service system guarantees the security (originality, integrity) of the security token issued by the digital signature.

The identity credential used by the user for online identity authentication in the identity service system may be a common account name, password, digital certificate, or other electronic identity data capable of identifying and verifying the identity of the user. The account used by the user for identity authentication in the identity service system is called the main account. The master account database is a database for storing user master accounts and related information. The master account database may be an independent account database, or a user account database of an application system may be selected as the master account database. The secondary account refers to the user's account in a specific web application system; the user's main account and the secondary account in a certain web application system may be the same or different.

The single sign-on HTTP plug-in stores login (identity authentication) related information of each user, which is called user login information. The user login information includes:

1) Identity authentication protocol, that is, the HTTP identity authentication protocol currently used by Web service components for authenticating users;

2) The server side returns protocol data and parameters, that is, when the Web service component uses the HTTP identity authentication protocol to authenticate the client user, the protocol-related data and parameters returned to the client browser through the WWW-Authentucate response header, such as HTTP Identity authentication protocol instructions and Realm, Challenge (challenge code), key negotiation parameters, etc., wherein the HTTP identity authentication protocol instructions are also stored in the "identity authentication protocol" at the same time;

3) The protected URL to be accessed last time, that is, the URL of the protected Web page that the user expects to visit last time using the browser before the Web application system completes identity authentication;

4) The latest POST parameter. Before the user completes the identity authentication in the web application system, if the HTTP request method (Method) used when using the browser to access the securely protected web page last time is POST, the "last POST parameter" The value is the POST parameter corresponding to the HTTP request (that is, the Form form data submitted by POST), otherwise its value is empty (NULL);

5) User identity information, information that identifies and authenticates the user, including the user's primary account name, secondary account name, and secondary account password;

The various user login information mentioned above are stored in the form of character strings (for non-character data, stored in Base64 encoded format); the "user identity information" is encrypted and time-sensitive to prevent leaks and replay attacks; The "identity authentication protocol", "the last protected URL to be accessed", "the last POST parameter" and "user identity information" are stored in the cookie, and the action path of the cookie needs to include the settings set by the web service component at the same time. The secure path and the non-secure path where the security token processing page is located, that is, the cookie can be viewed regardless of the web page in the secure path or the non-secure security token processing page, or , save the relevant user login information in two different cookies at the same time, one of which is the path protected by security, and the other is the path where the security token processing page is not protected by security.

The single sign-on HTTP plug-in stores the relevant information in the user login information according to the following priority order according to the different data storage mechanisms provided by the Web service component to the HTTP plug-in:

1) If the Web service component provides the HTTP plug-in with a data storage location based on the TCP connection (Connection), then the single sign-on HTTP plug-in will save the "server-side return protocol data and parameters" in the data storage location based on the TCP connection, and save other The information is saved in the client browser through cookies; or,

2) If the Web service group provides the HTTP plug-in with a data storage location based on the HTTP session (Session), then the single sign-on HTTP plug-in will save the "server-side return protocol data and parameters" in the data storage location based on the HTTP session, and save other The information is saved in the client browser through cookies; or,

3) If the single sign-on HTTP plug-in has a custom-developed data storage location based on TCP connection or HTTP session, then the single-sign-on HTTP plug-in will save the "server-side return protocol data and parameters" in the custom-developed TCP connection or HTTP session-based The data storage location, save other information in the client browser through cookies;

otherwise,

4) The single sign-on HTTP plug-in saves all user login information in the client browser through cookies.

The data storage location based on the TCP connection refers to that the data storage location provided by the Web service component to the HTTP plug-in is associated with the TCP connection of the HTTP data transmission. If the TCP connection is different, the data storage location provided is different (such as IIS provides to the ISAPI Filter The data storage location based on the TCP connection); the data storage location based on the HTTP session refers to: as long as it is the same HTTP session, even if the TCP connection is different, the data storage location is still the same, that is, the data storage location has nothing to do with the TCP connection, but only with a specific This HTTP session data storage mechanism usually uses the specific identifier stored in the cookie to distinguish different sessions, and saves the session data in the Web server (component), such as the storage provided by the Java Web container to the Servlet Filter. This is the case for the Session object of the data.

For the "server-side return protocol data and parameters", the following content must be set in the configuration information of the single sign-on HTTP plug-in: For each HTTP identity authentication protocol used by the web application system, after the user identity authentication is successful, " The corresponding setting method for the value of "Protocol Data and Parameters Returned by the Server". The options for the setting method are: keep unchanged, set to NULL, or set to a space (Space).

When a user uses a browser to access a web application system that uses the HTTP authentication protocol to authenticate the user, the single sign-on HTTP plug-in intercepts the HTTP request, and then processes the HTTP request as follows:

A1. According to the relevant configuration information, determine whether the current HTTP request URL corresponds to a page protected by security or a page not protected by security. If it is protected by security, go to the next step; otherwise, let the HTTP request pass and complete This HTTP request processing;

A2. Check the "server-side return protocol data and parameters", if it is not set or its value is empty, then go to the next step; otherwise, go to step A6;

A3. Check the "user identity information", if it exists and is valid, then go to the next step; otherwise, let the HTTP request pass and complete the HTTP request processing;

A4. Obtain the HTTP authentication protocol currently used by the Web application system from the "identity authentication protocol" information stored in the cookie, and then determine whether the adopted HTTP authentication protocol allows the client to actively issue authentication and authorization requests according to the relevant configuration information , if not allowed, let the HTTP request pass through and complete the HTTP request processing; otherwise, continue;

A5. Obtain the data and parameters (such as realm parameters) required by the HTTP identity authentication protocol from the relevant configuration information, and generate the Authorization request header containing the identity authentication data submitted by the client for the first time according to the HTTP identity authentication protocol, and send the generated The header is added to the intercepted HTTP request, and then the modified HTTP request is passed to complete the HTTP request processing;

A6. If the value of "server-side return protocol data and parameters" is a space, let the HTTP request pass and complete the HTTP request processing; otherwise, continue;

A7. According to the HTTP authentication protocol and other data in "Server-side return protocol data and parameters", generate the Authorization request header of the HTTP authentication protocol at the current protocol stage, and add the generated header to the intercepted HTTP request , and then, let the modified HTTP request pass to complete the HTTP request processing.

The relevant configuration information described in the steps A1, A4, and A5 refers to the configuration information related to security access control, identity authentication, and single sign-on of the Web service component and/or single-sign-on HTTP plug-in; the single-sign-on HTTP plug-in Either query the relevant configuration information of the Web service component through the corresponding interface provided by the Web service component, or directly read the relevant configuration file.

The identity authentication process of the HTTP identity authentication protocol may require the client and the server to interact in multiple steps or stages through HTTP requests and responses, and the "current protocol stage" of the HTTP identity authentication protocol described in step A7 Refers to the current step or stage of the client according to the identity authentication protocol; the "current protocol stage" of the HTTP identity authentication protocol determines what the data content of the current Authorization header of the HTTP request is; the client can follow the protocol returned by the server Data and parameters to determine the current step or stage.

In the steps A5 and A7 of the HTTP request processing stage of the single sign-on HTTP plug-in, according to the difference of the HTTP identity authentication protocol, the corresponding Authorization request header of the HTTP identity authentication protocol in the corresponding protocol stage is generated in the following manner:

Situation 1.1. If the HTTP authentication protocol is HTTP Basic, decrypt the "user identity information" data from the cookie, obtain the user's secondary account name and password in the Web application system, and then form the Authorization header according to the requirements of the HTTP Basic protocol ;otherwise,

Situation 1.2. If the HTTP authentication protocol is HTTP Digest, then decrypt the "user identity information" data from the cookie, obtain the user's secondary account name and password in the web application system, and then according to the "server-side return protocol data and parameters" content, and the requirements of the HTTP Digest protocol, form the Authorization header; otherwise,

Situation 1.3. If the HTTP authentication protocol is HTTP NTLM, and the "server-side return protocol data and parameters" is not set or its value is empty or its value is the initial prompt for identity authentication, then generate NTLM Type 1 data, and then press The HTTP NTLM protocol requires to form the data in the Authorization header; otherwise, first decrypt the "user identity information" data from the cookie, obtain the user's secondary account name and password in the Web application system, and then use the secondary account name, password and Relevant data (that is, NTLM Type 2 data) stored in the "server-side return protocol data and parameters" generates NTLM Type 3 data, and then forms the Authorization header according to the HTTP NTLM protocol requirements; otherwise,

Situation 1.4. If the HTTP authentication protocol is HTTP Negotiate, then first decrypt the "user identity information" data from the cookie, and obtain the user's account name and password in the Web application system (that is, in the Kerberos system, such as Windows AD, account name, password), and then use the slave account name, password to call the corresponding Kerberos interface, connect Kerberos KDC (Key Distribution Center) Authentication Server (identity authentication server), obtain the user's TGT (Ticket-Granting Ticket), and then Then use the TGT to call GSS-API or an equivalent interface (such as Windows SSPI) to obtain the Spnego Token for the user to access the Web application system, and then use the obtained Spnego Token to form the Authorization header according to the requirements of the HTTP Negotiate protocol; otherwise,

Situation 1.5: If it is another valid HTTP identity authentication protocol, process it according to the relevant protocol; otherwise, guide the user browser to an error page.

After the single sign-on HTTP plug-in completes the relevant processing of the steps A2-7 in the HTTP request processing stage, before allowing the HTTP request to pass, the following processing operations need to be performed: If the URL of the current HTTP request is the same as the "recently The URL saved in "Protected URL" is the same and the method of the current HTTP request is GET and the value of the "last POST parameter" is not empty, then the method of the current HTTP request is changed to POST, and the data in the "last POST parameter" Added as a POST parameter to the current HTTP request.

After the single sign-on HTTP plug-in intercepts the HTTP response, the HTTP response is processed as follows:

B1. check the response status and header of the HTTP response, if the response status code is "401" (prompt Unauthorized or Authentication required) and include the WWW-Authenticate response header, then proceed to the next step; otherwise, proceed to B7;

B2. Check the "user identity information", if it exists and is valid, then go to the next step; otherwise, go to B6;

B3. Check the value of the WWW-Authenticate header of the current HTTP response, if it is an initial prompt for identity authentication and the corresponding HTTP request in response contains an Authorization header and the value of the Authorization header is indicated in the WWW-Authenticate header The identity credential data corresponding to the HTTP identity authentication protocol or the data after the identity credential data password calculation is then transferred to the next step; otherwise, it is transferred to step B5;

B4. Set "user identity information" to empty, set the value of "server-side return protocol data and parameters" to the value of the WWW-Authenticate header of the HTTP response, obtain the HTTP request URL corresponding to the current HTTP response, and use it as The value of the "protected URL to be accessed last time" is saved; if the method of the HTTP request corresponding to the current HTTP response is POST, then the POST parameter (ie Form form data) corresponding to the request is saved to the "last POST parameter" Otherwise, set the value of "Last POST parameter" to empty; then, change the response status code of the HTTP response to "302", remove the WWW-Authenticate response header, and replace the HTTP response body (Body) that may be included And the length indication of the response body is removed, the Location header is added to the response, and its value is set to the URL of the user agent login error page of the identity service system. The URL is appended with the system of the web application system where the single sign-on HTTP plug-in is located through the Query String mark, and finally, let the modified HTTP response pass to complete the processing of this HTTP response;

B5. Set the value of "server-side return protocol data and parameters" to the value of the WWW-Authenticate header of the HTTP response, obtain the HTTP request URL corresponding to the current HTTP response and use it as "the last protected URL to be accessed "; if the method of the HTTP request corresponding to the current HTTP response is POST, save the POST parameter corresponding to the request into the "last POST parameter", otherwise set the value of the "last POST parameter" to empty; Then, modify the response status code of the HTTP response to "302", remove the WWW-Authenticate response header, remove the possible HTTP response body (Body) and the length indication of the response body, and add the Location header to the response header , set its value to the HTTP request URL corresponding to the current HTTP response, and then pass the modified HTTP response to complete the processing of this HTTP response;

B6. The HTTP identity authentication protocol indicated in the WWW-Authenticate header is stored in the "identity authentication protocol" of the user login information, the "user identity information" is set to empty, and the "server end returns protocol data and Parameter" is set to the value of the WWW-Authenticate header of the HTTP response to obtain the HTTP request URL corresponding to the current HTTP response, and save it as the value of the "protected URL to be accessed last time"; if the current HTTP response corresponds to If the method of the HTTP request is POST, save the POST parameter corresponding to the request in the "last POST parameter", otherwise set the value of "last POST parameter" to empty; then, modify the response status code of the HTTP response If it is "302", remove the WWW-Authenticate response header, remove the possible HTTP response body (Body) and the length indication of the response body, and add the Location header to the response, whose value is the user login page URL of the identity service system , and the URL is appended with the system identifier of the web application system where the single sign-on HTTP plug-in is located through the Query String, and finally, the modified HTTP response is passed to complete the processing of this HTTP response;

B7. obtain the HTTP request URL corresponding to the current HTTP response, determine whether the HTTP request URL corresponds to a securely protected Web page according to relevant configuration information, if not, allow the HTTP response to pass through, and complete the processing of this HTTP response; otherwise, turn to into the next step;

B8. If the WWW-Authenticate response header is included in the HTTP response, then the WWW-Authenticate response header is removed; if the URL of the HTTP request corresponding to the current HTTP response is the same as "the last protected URL to be accessed", then Set the values of "Last protected URL to visit" and "Last POST parameter" to empty;

B9. According to the setting method of the value of "server-side return protocol data and parameters" set for the currently used HTTP identity authentication protocol in the configuration information of the single sign-on HTTP plug-in after the user identity authentication is successful, set " The server returns the value of "Protocol Data and Parameters", and then allows the modified HTTP response to pass to complete the processing of this HTTP response.

The value of the WWW-Authenticate header described in the step B3 is an initial prompt for identity authentication, which means that the value of the header is the value returned by the Web server for the first time before the user completes the identity authentication when accessing the protected page for the first time. Data in the WWW-Authenticate response header that requires authentication.

The identity credential data described in the step B3 refers to electronic data that can prove the identity of the user, such as account name, password (such as HTTP Basic), or a security token (such as the Spnego Token of HTTP Negotiate) that contains identity confirmation information. ); the data after the identity credential data password calculation refers to the identity credential, such as user/password, after certain password calculation (such as HASH calculation) to obtain data (such as HTTP NTLM via account name, password hash Operational Type3 data).

If the HTTP response intercepted by the single sign-on HTTP plug-in includes multiple WWW-Authenticate headers, the WWW-Authenticate header used in the step B3 and the values used in the steps B4, B5, and B6 are saved to The WWW-Authenticate header in the "server-side return protocol data and parameters" and the WWW-Authenticate header used to save the "identity authentication protocol" in the step B6 are selected according to predetermined rules corresponding to a certain HTTP The WWW-Authenticate header of the identity authentication protocol (for example, the WWW-Authenticate header selected according to the priority order from Negotiate, NTLM, Digest to Basic protocol), and the WWW-Authenticate header deleted in the steps B4, 5, 6, and 8 The Authenticate header includes all WWW-Authenticate headers.

The modified HTTP response described in steps B4, B5, B6, and B9 can be an HTTP response obtained after directly modifying the original HTTP response data structure in terms of data structure, or a new HTTP response The data structure on the newly generated HTTP response.

The relevant configuration information in the step B7 refers to the configuration information related to security access control, identity authentication and single sign-on of the Web service component and/or the single sign-on HTTP plug-in.

In the above steps, the status code of the HTTP response is modified or set to "302" and the Location header is added to the response, that is, the so-called HTTP redirection is performed to guide the browser to the page or Web site indicated by the Location.

The single sign-on HTTP plug-in obtains the relevant data in the request line, header and body of the HTTP request corresponding to the current HTTP response (such as request URL, Cookie, Authorization header, POST parameter wait):

Scenario 2.1: If the HTTP plug-in can directly access the relevant data header in the HTTP request, then obtain the relevant data directly from the request; otherwise,

Scenario 2.2: If the Web service component provides a data storage location based on a TCP connection, the single sign-on HTTP plug-in completes all relevant processing in the HTTP request processing stage, including converting the GET request into a POST request, and then allows the HTTP request to pass through Before, save the relevant data of the current HTTP request to the data storage location based on the TCP connection, which will be obtained by the single sign-on HTTP plug-in during the HTTP response processing stage; otherwise,

Scenario 2.3: If the Web service component provides a data storage location based on the HTTP session, the single sign-on HTTP plug-in completes all related processing in the HTTP request processing stage, including converting the GET request to the POST request, and then allows the HTTP request to pass through Before, save the relevant data of the current HTTP request to the data storage location based on the HTTP session, which will be obtained by the single sign-on HTTP plug-in during the HTTP response processing phase; otherwise,

Scenario 2.4: If the header of the HTTP response can be directly set during the HTTP request processing stage, the single sign-on HTTP plug-in completes all related processing in the HTTP request processing stage Before passing, the relevant data of the current HTTP request is passed to the single sign-on HTTP plug-in in the HTTP response processing stage through the custom HTTP response header. data, delete the custom header; otherwise,

Scenario 2.5: If the single sign-on HTTP plug-in has a custom-developed TCP connection or session-based data storage location, the single sign-on HTTP plug-in completes all related processing in the HTTP request processing stage, including converting the GET request to the POST request After that, before allowing the HTTP request to pass through, save the relevant data of the current HTTP request to the custom-developed data storage location based on the TCP connection or session, which will be obtained by the single sign-on HTTP plug-in during the HTTP response processing stage; otherwise,

Scenario 2.6: The single sign-on HTTP plug-in completes all relevant processing in the HTTP request processing stage, including converting the GET request to the POST request, and before allowing the HTTP request to pass through, the relevant data of the current HTTP request is passed through the thread (Thread) mechanism. Single sign-on HTTP plugin passed to the HTTP response processing stage.

In the above situations 2.2-2.6, after the single sign-on HTTP plug-in completes all relevant processing in the HTTP request processing stage, including converting the GET request to the POST request, before allowing the HTTP request to pass through, it only needs to The page's POST parameters (if any) are passed to the Single Sign-On HTTP plugin during the HTTP response processing phase.

When the user's browser is redirected to the user login of the identity service system by modifying or setting the status code of the HTTP response to "302" and setting the Location header of the HTTP response in the step B6 of the HTTP response processing stage by the single sign-on HTTP plug-in After the page, the identity service system handles the HTTP request as follows:

C1. Determine whether the Web application system that the user wants to access is a system that the identity service system trusts and provides services through the Web application system identifier carried in the Query String of the HTTP request URL. If not, return an error message; otherwise, go to the next step step;

C2. Determine whether the user has completed identity authentication in the identity service system before, and if so, go to the next step; otherwise, guide the user to the login page, and authenticate the user based on the user's main account. After the authentication is successful, go to the next step one step;

C3. Obtain the user's slave account name and password in the web application system to be accessed in the master-slave account binding database according to the user's master account and the web application system to be accessed by the user;

C4. Generate a security token for the user that includes its primary account name, secondary account name, and encrypted secondary account password, and digitally sign the relevant information, and then submit the user identity certification information containing the security token in the Form The method returns to the user's browser, and submits the user identification information including the security token to the security token processing page of the Web application system that the user needs to visit through the automatic POST submission (Submit) mode of the Form form.

After the security token processing page receives the user identity certification information including the security token issued by the identity service system and submitted by the user browser through the automatic POST form of the Form, it will process it as follows:

D1. Verify whether the security token is valid through a digital signature, if valid, go to the next step; otherwise, return an error message;

D2. Separate the user's primary account name, secondary account name, and password from the security token, decrypt the secondary account password, and then create a Set-Cookie header in the HTTP response to set the Cookie for storing "user identity information". The value contains the encrypted master account name and slave account name, password;

D3. Set the status code of the HTTP response to "302", create a Location header in the HTTP response, and set the value of the header to obtain "the last protected URL to be accessed" from the cookie, and then return HTTP response.

When the user browser is redirected to the user agent of the identity service system by modifying or setting the status code of the HTTP response to "302" and setting the Location header of the HTTP response in the step B4 of the HTTP response processing stage by the single sign-on HTTP plug-in After logging in to the URL of the error page, the identity service system processes the HTTP request as follows;

E1. Determine whether the Web application system that the user wants to access is a system that the identity service system trusts and provides services through the Web application system identifier carried in the HTTP request URL, if not, return an error message; otherwise, go to the next step;

E2. Prompt the user to input and submit the account name and password in the web application system to be accessed;

E3. After the user submits the account name and password, determine whether the user has logged into the identity service system to complete identity authentication, if so, then proceed to step E5; otherwise, proceed to the next step;

E4. Return to the user login page of the identity service system, and identify the user based on the user's main account, and proceed to the next step after the identification is successful;

E5. Based on the user's account name and password in the Web application system obtained in steps E2 and E3, update the user's account name and password in the corresponding Web application system in the master-slave account binding database;

E6. Generate a security token for the user that includes its primary account name, secondary account name, and encrypted secondary account password, and digitally sign the relevant information, and then submit the user identity certification information containing the security token in the Form The method returns to the user's browser, and submits the user identification information including the security token to the security token processing page of the Web application system that the user needs to visit through the automatic POST submission (Submit) mode of the Form form.

If the entire Web path (directory) of the Web application system is a path protected by security, and a path (directory) that is not protected by security cannot be set in or outside the path (directory) protected by security, then the security The token processing page is not an actual web page, but a virtual web page path; correspondingly, the single sign-on HTTP plug-in intercepts the HTTP request submitted to the security token processing page in the HTTP request processing stage, and completes The processing operation described in step D1, and then in the response processing stage of the HTTP request, intercept the HTTP response, and complete the processing operations described in steps D2 and D3.

If the user's access to the Web application system is carried out through a Web proxy (Proxy), and the Web proxy authenticates the user through the proxy mode of the HTTP identity authentication protocol, and the Web proxy is in its HTTP request and response processing channel The HTTP plug-in mechanism is provided, and the HTTP plug-in based on the plug-in mechanism can intercept the request and response data of the HTTP identity authentication protocol, then the method described in the present invention is also applicable when the following corresponding changes are made:

The Web service component refers to a Web proxy; the Web application component refers to the entire Web system behind the Web proxy (itself also includes one or more Web service components and Web application software); the Web proxy and the entire Web system thereafter The Web application system is constituted; the single sign-on HTTP plug-in is deployed on the Web proxy, and is configured to intercept all HTTP requests and responses on the deployed Web proxy; the HTTP response status code "401" becomes "407" (Proxy Authentication Required), the HTTP response header WWW-Authenticate becomes a Proxy-Authenticate header, and the HTTP request header Authorization becomes a Proxy-Authorization header.

The single sign-on integration method of the present invention is only aimed at the Web application system that uses the HTTP identity authentication protocol in the entire single sign-on system and the use of the HTTP identity authentication protocol cannot be replaced or changed; for other Web application systems, other Web application systems can be used. single sign-on integration method.

The innovation of the present invention is that: through the single sign-on HTTP plug-in, the Web application system that uses the HTTP identity authentication protocol (such as Basic, Digest, NTLM, Negotiate) to authenticate the user can be configured without changing the identity authentication. Implement single sign-on without modifying the application. It solves a common technical problem of single sign-on in practical application integration.

A feature of the present invention is: the user can still access the Web application system that adopts the Kerberos protocol (i.e. HTTP Negotiate protocol and uses Kerberos for identity authentication) even in the external network.

Description of drawings

FIG. 1 is a block diagram of the overall structure of the single sign-on system of the present invention.

Detailed ways

The present invention will be described in further detail below in conjunction with the accompanying drawings.

The present invention is a plug-in single sign-on integration method for the HTTP identity authentication protocol. The overall structure of the single sign-on system using this method is shown in Figure 1, including Web service components, Web application components, and single sign-on HTTP plug-ins. , a security token processing page, a browser, an identity service system, a master account database, and a master-slave account binding database, wherein the Web service component and the Web application component constitute the Web application system, and the functions of each component are described in the preceding content of the invention has been described in detail and will not be repeated here. Among the system components of the whole single sign-on system, the single sign-on HTTP plug-in, the security token processing page, the identity service system, the master account database, and the master-slave account binding database belong to the content to be realized by the present invention. Among the content, the single sign-on HTTP plug-in is the most critical and main part.

For the realization of the identity service system, various existing mature information system development technologies can be used, such as J2EE technology, ASP.NET technology, etc.; for the main account database, LDAP, relational database, or existing Windows Active Directory can be used Or an application system account database; for the master-slave account binding database, a relational database can be used. The master-slave account binding database only needs to save such information: 1) the user's master account name; 2) the user's slave account name and password in each authorized access application system corresponding to the master account.

The implementation of the single sign-on HTTP plug-in and the security token processing page depends on the Web service component to be deployed (but does not have to be the same as the development technology of the Web application component). For some common Web service components, the corresponding specific implementation schemes are described as follows.

If the Web service component is Windows IIS5, the single sign-on HTTP plug-in can be implemented based on ISAPI Filter, and the specific scheme is as follows.

The single sign-on HTTP plug-in uses the data storage location based on the TCP connection provided by ISAPI Filter, that is, the pFilterContext field in the input parameter pfc of the HTTP_FILTER_CONTEXT structure type passed by ISAPI to the ISAPI Entry-Point Function (Entry-Point Function) HttpFilterProc(...) , and save the "Server Return Protocol Data and Parameters". The single sign-on HTTP plug-in (registered through the entry point function GetFilterVersion(...)) responds to the SF_NOTIFY_READ_RAW_DATA and SF_NOTIFY_PREPROC_HEADERS notification events during the HTTP request processing stage, and completes the corresponding processing, including: decrypting user identity information and adding Authorization request headers The operation is carried out in response to the SF_NOTIFY_PREPROC_HEADERS notification event; convert the HTTP request of GET mode into the request of POST mode (when needed), and add the data in the "last POST parameter" as a POST parameter to the HTTP request body The operation is performed in response to the SF_NOTIFY_READ_RAW_DATA notification event; if the current HTTP request is in the POST mode (including HTTP requests converted from GET and POST), the single sign-on HTTP plug-in will save the POST parameters of the current request in the In the above pFilterContext field, it is obtained by the single sign-on HTTP plug-in during the response processing phase. The single sign-on HTTP plug-in can obtain the HTTP request line and various information in the request header through the callback function (callback function) provided by ISAPI Filter during the HTTP processing stage, such as request URL, Cookie, etc.

The single sign-on HTTP plug-in (registered by the notification event) responds to the SF_NOTIFY_SEND_RESPONSE, SF_NOTIFY_SEND_RAW_DATA, SF_NOTIFY_END_OF_NET_SESSION notification events during the HTTP response processing phase, and completes the corresponding processing, wherein: when responding to the SF_NOTIFY_SEND_RESPONSE, SF_NOTIFY_SEND_RAW_DATA notification events, complete the modification of the HTTP response ( Including modifying the status line, header and deleting the response body), saving user login information and other operations; when responding to the SF_NOTIFY_END_OF_NET_SESSION notification event, release the corresponding system resources. In fact, the modification of the HTTP response by the single sign-on HTTP plug-in in the HTTP response processing stage can not only complete part of the operations at the two notification event points of SF_NOTIFY_SEND_RESPONSE and SF_NOTIFY_SEND_RAW_DATA, but also complete all operations at the SF_NOTIFY_SEND_RAW_DATA notification event point, that is to say , you can not respond to the SF_NOTIFY_SEND_RESPONSE notification event. The single sign-on HTTP plug-in in the HTTP response processing stage can obtain the HTTP request line and various information of the request header through the callback function provided by ISAPI Filter, such as request URL, Cookie, etc., and modify the response to generate a new response; single point In the HTTP response processing stage, the login HTTP plug-in obtains the POST parameters saved by the single sign-on HTTP plug-in in the HTTP request processing stage from the pFilterContext field (that is, adopts the solution of scenario 2.2).

The security token processing page can be implemented based on ISAPI Extension. The security token processing page based on ISAPIExtension can process requests and generate responses by calling the callback function of ISAPI Extension. The security token processing page is located either in the unsecured directory (path), or in an unsecured subdirectory (subpath) within the secured directory (path). The single sign-on HTTP plug-in and the security token processing page obtain the relevant security configuration information of IIS based on the Administration API of IIS, such as the protected directory (path), the authentication protocol used, and so on.

If the web service component is Windows IIS6, then either configure IIS6 to work in IIS5 mode, and then use the IIS5 single sign-on HTTP plug-in described above; or, implement the single sign-on HTTP plug-in as follows:

The single sign-on HTTP plug-in uses the same method as in IIS5 to save "server-side return protocol data and parameters". The single sign-on HTTP plug-in only responds to the SF_NOTIFY_PREPROC_HEADERS notification event during the HTTP request processing stage, except for converting the GET method into a POST method and saving the POST parameters of the POST method in the pFilterContext field, other operations processed The implementation is the same as in IIS5. The implementation of the single sign-on HTTP plug-in in the HTTP corresponding processing stage is the same as that in IIS5 except that the POST parameters of the POST method are not saved. The implementation of the security token handling page is the same as in IIS5.

When the single sign-on HTTP plug-in in IIS6 adopts a non-IIS5 implementation, there will be a problem in practical applications: because the POST parameters of the POST method are not saved, and the GET method is converted into a POST method when needed, therefore, When the user accesses the protected page for the first time, the method used is POST. After the user completes the identity authentication, the protected page to be accessed for the first time will be automatically accessed again with the GET method. In this way, the user may not get the desired result. result. But in this case, it will not cause substantial damage: first, because the user’s initial access is usually protected by the GET method, not the POST method; second, even if the initial access is usually protected by the GET method, The web application system will prompt the user to resubmit the data, and subsequent POST requests will be submitted normally.

If the web service component is Windows IIS 7.0 and later versions, in addition to the implementation of IIS6 mentioned above, the single sign-on HTTP plug-in can also be implemented based on the Native-Code HTTP Module extension function or Managed-Code HTTP Module of IIS , and the security token processing page can be implemented based on ISAPI Extension or ASP.NET.

If the single sign-on HTTP plug-in is implemented based on the Native-Code HTTP Module, it is necessary to implement a derived class of CHttpModule, and perform single sign-on processing on HTTP requests in the OnBeginRequest method of this class, and perform single sign-on on HTTP responses in the OnSendResponse method Login processing. The single sign-on HTTP plug-in saves the "server-side return protocol data and parameters" data in the IHttpModuleContextContainer object based on the TCP connection of the IHttpConnection object of the Native-Code HTTP Module. The single sign-on HTTP plug-in can directly read the data (including POST parameters) in the request line, request header and body of the corresponding HTTP request during the HTTP response processing stage.

The method of implementing the SSO HTTP plug-in based on the Managed-Code HTTP Module is similar to the method of implementing the SSO HTTP plug-in based on the Native-Code HTTP Module. For how to develop IIS extension modules through Native-Code HTTP Module or Managed-Code HTTP Module, please refer to Microsoft's MSDN (Microsoft Development Network).

If the Web service component of the Web application system is JSP/Servlet Web Container (including Web Container of J2EE Application Server), the single sign-on HTTP plug-in can be based on Servlet Filter (this is available in all Web containers), AuthenticationFilter (such as WebLogic) , Valve (such as Tomcat) of the Web container or other similar HTTP plug-in mechanisms (such as TAI of WebSphere, etc.), how to implement and whether it can be implemented, one depends on what kind of plug-in mechanism the Web container provides, and the other depends on the plug-in Whether the mechanism can meet the above-mentioned single sign-on processing requirements, such as intercepting the HTTP request and response of the HTTP authentication protocol, and modifying the HTTP request and response in a certain way. For example, if the HTTP request and response of the HTTP authentication protocol deployed on a certain Web Container can be intercepted by Servlet Filter, Authentication Filter or Valve, the single sign-on HTTP plug-in can be implemented based on Servlet Filter, Authentication Filter or Valve. For the HTTP plug-in mechanism provided by JSP/Servlet Web Container, the single sign-on HTTP plug-in is usually able to directly read all the data of the HTTP request during the HTTP response processing phase. Corresponding to JSP/Servlet Web Container, the security token processing page can be implemented based on JSP/Servlet. For obtaining the security configuration information, either directly read the configuration file, or obtain it through the interface provided by the web container.

If the Web service component of the Web application system is Apache HTTP Server or IBM HTTP Web Server, then a single sign-on HTTP plug-in can be developed based on Apache Hook and Filter, where the functions in the HTTP request processing phase are implemented based on Apache Hook, and the HTTP response processing phase The function is implemented based on Apache Hook and Filter, among which, Apache Hook processes the header, and Apache Filter processes the response content. The storage of "server-side return protocol data and parameters" uses the data storage location based on the TCP connection provided by Apache. For Apache Filter, the single sign-on HTTP plug-in can directly read all the data of the HTTP request during the HTTP response processing phase. The security token processing page can be developed based on Apache ContentHandler, or based on the page technology (such as Perl, Python) of the corresponding Web application component. To obtain the security configuration information of Apache HTTP Server and IBM HTTP Web Server, either directly read the configuration file, or obtain it through the interface variables provided by Apache, such as the directory configuration information in the request_rec structure and conn_rec in the request_rec structure Server configuration information in the structure.

For other Web service components, such as Domino Web Server, etc., there are similar HTTP plug-in mechanisms. The specific implementation methods of the single sign-on HTTP plug-ins and security token processing pages based on these Web platforms are similar to the specific implementation methods described above. .

In addition, for the specific implementation of the involved single sign-on protocol and security token, the single sign-on protocol and security token can use standard protocols, such as SAML, WS-FPRP and the corresponding SAML assertion, WS-Security Token As a security token to prove the identity of the user; or, use a self-defined single sign-on protocol and a self-defined security token, as long as it is consistent with the interaction and processing process described in the present invention. If the single sign-on protocol and security token are based on XML (eXtensible Markup Language), such as SAML, WS-FPRP, then various mature dynamic libraries and class libraries (such as Windows Communication Foundation class library) can be used to process XML data , API (such as Java API for XML Processing, JAXP), etc. For implementations involving data encryption and digital signatures, various mature dynamic libraries (such as OpenSSL), class libraries (such as Java Cryptography Extension), and APIs (such as WindowsCryptoAPI, etc.) can be used.

The content not described in detail in this specification belongs to the prior art known to those skilled in the art.

Claims (10)

1. A plug-in type single sign-on integration method for HTTP identity authentication protocol, the single sign-on system of the method comprises Web service component, Web application component, single sign-on HTTP plug-in, security token processing page, browser, The identity service system, the master account database, and the master-slave account binding database are characterized in that: Web service component: provide HTTP request reception, response transmission function, and other related support functions for Web application components, including: receiving service requests in HTTP format submitted by user browsers, and submitting them to Web application components for processing after corresponding preprocessing , after that, transmit the processing result returned by the Web application component to the user's browser in the form of an HTTP response; perform identity authentication and access control on the user based on the corresponding security configuration; maintain the user's HTTP session; Web application component: Functional software that provides specific application services to users, receives application service requests submitted by users through browsers through corresponding Web service components, and returns the processing results to user browsers through Web service components after completing corresponding processing; The Web application components and the corresponding Web service components constitute a Web application system; there is at least one of the Web application systems; The component uses the standard HTTP authentication protocol to authenticate the user; the user needs to use the corresponding account in the corresponding Web application system to complete the identity authentication before accessing the protected page or resource of the Web application system; the standard HTTP Identity authentication protocols include but not limited to HTTP Basic, Digest, NTLM, Negotiate web-oriented identity authentication protocols; Single sign-on HTTP plug-in: Based on the extension mechanism provided by the Web service component, it is inserted into the HTTP request and response processing channel of the Web service component of the Web application system using the HTTP identity authentication protocol to realize the single sign-on function; The plug-in mechanism adopted by the point-to-sign-on HTTP plug-in can intercept the request and response data of the HTTP identity authentication protocol; In order to intercept all HTTP requests and responses submitted to the directory or path protected by security and HTTP requests and responses submitted to the directory or path where the security token processing page is located; the single sign-on HTTP plug-in has corresponding configuration information, It is used to set the information related to single sign-on. Optionally, the configuration information includes the following content: 1) Which web page directories or paths in the web application system where the single sign-on HTTP plug-in is located are protected; Which or which HTTP identity authentication protocol is adopted by the security protected directory or path, and the relevant identity authentication protocol parameters; Allow the client browser to actively submit an HTTP request including the Authorization header before receiving the HTTP response with the response status code "401" and the WWW-Authenticate header, requesting the server to authenticate the client user and access resources authorize; Security token processing page: a Web page deployed on the Web service component of the Web application system using the HTTP identity authentication protocol to specifically process the security token issued by the identity service system to prove the identity of the user; the security token processing page is deployed on The non-secure protection path or directory of the Web service group, that is, the user who submits the HTTP request to the processing page through the browser does not need to complete identity authentication; Browser: the client that the user interacts with the Web application system, transmits the HTTP request to the Web service component through the HTTP protocol, receives the HTTP response returned by the Web service component, and displays the content of the response; Identity service system: a system that provides online identity authentication services for users, conducts online identity authentication for users based on user identity credentials, and transmits a security token that proves user identity to the Web application system through a corresponding single sign-on protocol and with the help of a browser; The format of the security token issued by the identity service system depends on the single sign-on protocol used, which can be a SAML assertion, or a WS-Federation security token, or a custom security token; the identity service system passes a digital signature Guarantee the originality and integrity of the issued security token; Master account database: store the master account information of the user logging into the identity service system, including the account name and password of the master account, or the relevant information of the data certificate corresponding to the master account; the master account refers to the identity authentication of the user in the identity service system The account used at the time; the main account database can be an independent account database, or an account database of an application system; Master-slave account binding database: save the corresponding or binding relationship between the user's master account and the user's slave account in the Web application system, as well as the password of the slave account; the slave account refers to the user's corresponding account in a specific Web application system ; The user's master account and its slave account in a certain Web application system can be the same or different. 2. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 1, characterized in that: the single sign-on HTTP plug-in saves the identity authentication related information of each user, which is called user login information ; The user login information includes: 1) Identity authentication protocol: the HTTP identity authentication protocol currently used by Web service components to authenticate users; 2) The server returns protocol data and parameters: when the Web service component uses the HTTP authentication protocol to authenticate the client user, it returns the protocol data and parameters to the client browser through the WWW-Authentucate response header, including the HTTP identity Authentication protocol indication; 3) The last protected URL to be accessed: before the Web application system completes identity authentication, the user uses the URL of the last protected Web page that the browser expects to visit; 4) The last POST parameter: before the Web application system completes identity authentication, if the HTTP request method used by the user to access the securely protected Web page last time using a browser is POST, then the value of the last POST parameter is this The POST parameter corresponding to the HTTP request, otherwise its value is empty; 5) User identity information: information to identify and authenticate users, including the user's primary account name, secondary account name, and secondary account password; The various user login information is stored in the form of character strings, and for non-character data, it is stored in Base64 encoded data format; the user identity information is encrypted and time-sensitive to prevent leaks and replay attacks; the The identity authentication protocol, the last protected URL to be accessed, the latest POST parameters, and user identity information are stored in the cookie, and the action path of the cookie needs to include both the secure protected path and the security token set by the Web service component The non-safety-protected path where the processing page is located, that is, the cookie can be viewed regardless of the web page in the secure-protected path or the non-secure-protected security token processing page, or the relevant user login information is simultaneously Stored in two different cookies, one of which acts on the path protected by security, and the other is the path where the non-secured security token processing page is located; The single sign-on HTTP plug-in according to the different data storage mechanisms provided by the Web service component to the HTTP plug-in, according to the following priority order, store the protocol data and parameters returned by the server according to the following methods: Scenario 1: If the Web service component provides the HTTP plug-in with a data storage location based on the TCP connection, the single sign-on HTTP plug-in saves the protocol data and parameters returned by the server in the data storage location based on the TCP connection; or, Situation 2: If the Web service group provides the HTTP plug-in with a data storage location based on the HTTP session, then the single sign-on HTTP plug-in saves the protocol data and parameters returned by the server in the data storage location based on the HTTP session; or, Case 3: If the single sign-on HTTP plug-in has a custom-developed data storage location based on TCP connection or HTTP session, then the single-sign-on HTTP plug-in saves the protocol data and parameters returned by the server in the custom-developed TCP connection or HTTP session-based The data storage location of the session; otherwise, Scenario 4: The single sign-on HTTP plug-in saves all user login information in the client browser through cookies; The data storage location based on the TCP connection refers to that the data storage location provided by the Web service component to the HTTP plug-in is associated with the TCP connection for HTTP data transmission. If the TCP connection is different, the data storage location provided is different; the HTTP session-based Data storage location means that as long as it is the same HTTP session, even if the TCP connection is different, the data storage location is still the same, that is, the data storage location has nothing to do with the TCP connection, but only with a specific HTTP user session; For the protocol data and parameters returned by the server, the following content must be set in the configuration information of the single sign-on HTTP plug-in: for each HTTP identity authentication protocol used by the Web application system, after the user identity authentication is successful, the server The terminal returns the corresponding setting method of the protocol data and the value of the parameter. The options of the setting method are: keep unchanged, set to empty, or set to a space. 3. The plug-in single sign-on integration method for the HTTP identity authentication protocol according to claim 1 or 2, characterized in that: when a user uses a browser to access a Web application that uses the HTTP identity authentication protocol to authenticate the user system, the single sign-on HTTP plug-in intercepts the HTTP request, and then processes the HTTP request as follows: Step 1: According to the relevant configuration information, determine whether the current HTTP request URL corresponds to a page protected by security or a page not protected by security. If it is protected by security, go to step 2; otherwise, let the HTTP request pass and complete This HTTP request processing; Step 2: Check the protocol data and parameters returned by the server, if it is not set or its value is empty, then go to step 3; otherwise, go to step 6; Step 3: Check the user identity information, if it exists and is valid, then go to step 4; otherwise, let the HTTP request pass, and complete the HTTP request processing; Step 4: Obtain the HTTP identity authentication protocol currently used by the Web application system from the identity authentication protocol information stored in the cookie, and then determine whether the adopted HTTP identity authentication protocol allows the client to actively issue authentication and authorization according to the relevant configuration information request, if it is not allowed, let the HTTP request pass, and complete the HTTP request processing; otherwise, go to step 5; Step 5: Obtain the data and parameters required by the HTTP authentication protocol from the relevant configuration information, generate the Authorization request header containing the authentication data submitted by the client for the first time according to the HTTP authentication protocol, and add the generated header to the In the intercepted HTTP request, then, let the modified HTTP request pass through to complete the HTTP request processing; Step 6: If the value of the protocol data and parameters returned by the server end is a space, then let the HTTP request pass, and complete the HTTP request processing; otherwise, go to step 7; Step 7: Generate the Authorization request header of the identity authentication protocol at the current protocol stage according to the HTTP authentication protocol and other data in the protocol data and parameters returned by the server, and add the generated header to the intercepted HTTP request , and then, let the modified HTTP request pass through to complete the HTTP request processing; The relevant configuration information described in the steps 1, 4, and 5 refers to the configuration information related to security access control, identity authentication, and single sign-on of the Web service component and/or the single-sign-on HTTP plug-in; The identity authentication process of the HTTP identity authentication protocol requires the client and the server to interact in multiple steps or stages through HTTP requests and responses, and the current protocol stage of the HTTP identity authentication protocol described in step 7 is Refers to the step or stage at which the client submits the identity authentication request information according to the requirements of the identity authentication protocol; After the single sign-on HTTP plug-in completes the relevant processing of steps 2-7 in the HTTP request processing stage, before allowing the HTTP request to pass, the following processing operations need to be performed: if the URL of the current HTTP request is the same as the URL to be accessed last time If the URL saved in the protected URL is the same and the method of the current HTTP request is GET and the value of the last POST parameter is not empty, then the method of the current HTTP request is changed to POST, and the data in the last POST parameter Added to the current HTTP request as a POST parameter; If based on the HTTP plug-in mechanism provided by the Web service component, the single-sign-on HTTP plug-in cannot obtain the request line, header or body of the HTTP request corresponding to the current HTTP response during the HTTP response processing phase, then the single-sign-on HTTP plug-in After the steps 1-7 of the HTTP request processing stage complete all relevant processing including converting the request of the GET mode into a request of the POST mode, before allowing the HTTP request to pass, according to the following priority order, all the current HTTP requests are processed according to the following different situations The above relevant data is passed to the single sign-on HTTP plugin in the HTTP response processing stage: Scenario A: If the Web service component provides a data storage location based on a TCP connection, save the relevant data of the current HTTP request to the data storage location based on a TCP connection, and obtain it by the single sign-on HTTP plug-in during the HTTP response processing stage; or, Scenario B: If the Web service component provides a data storage location based on an HTTP session, save the relevant data of the current HTTP request to the data storage location based on an HTTP session, and obtain it in the HTTP response processing phase of the single sign-on HTTP plug-in; or, Scenario C: If the header of the HTTP response can be directly set in the HTTP request processing stage, then the relevant data of the current HTTP request will be passed to the single sign-on HTTP plug-in in the HTTP response processing stage through the custom HTTP response header to obtain it. Click the login HTTP plug-in to delete the custom header after obtaining relevant data through the custom header during the HTTP response processing phase; or, Scenario D: If the single sign-on HTTP plug-in has a custom-developed TCP connection or session-based data storage location, then save the relevant data of the current HTTP request to the custom-developed TCP connection-based or session-based data storage location, and the single sign-on The HTTP plugin is acquired during the HTTP response processing phase; otherwise, Scenario E: The relevant data of the current HTTP request is transmitted to the single sign-on HTTP plug-in in the HTTP response processing stage through the thread mechanism; The single sign-on HTTP plug-in only needs to pass the POST parameters of the protected Web page to the single sign-on HTTP plug-in in the HTTP response processing stage. 4. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 3, characterized in that: in the steps 5 and 7 of the HTTP request processing process, the single sign-on HTTP plug-in is based on The HTTP identity authentication protocol is different, and the corresponding Authorization request header of the HTTP identity authentication protocol in the corresponding protocol stage is generated as follows: Situation I: If the identity authentication protocol is HTTP Basic, then decrypt the user identity information data from the cookie, obtain the user's secondary account name and password in the Web application system, and then form the Authorization header according to the requirements of the HTTP Basic protocol ;or, Situation II: If the identity authentication protocol is HTTP Digest, then decrypt the user identity information data from the cookie, obtain the user's secondary account name and password in the Web application system, and then return the protocol data and parameters according to the server. The content, and the requirements of the HTTPDigest protocol, form the Authorization header; or, Situation III: If the identity authentication protocol is HTTP NTLM, and the server-side return protocol data and parameters are not set or its value is empty or its value is the initial prompt for identity authentication, then generate NTLM Type1 data, and then press HTTP NTLM Protocol requirements, form the data in the Authorization header; otherwise, first decrypt the user identity information data from the Cookie, obtain the user's secondary account name and password in the Web application system, and then use the secondary account name, password and save in the Described server end returns the NTLM Type2 data in the agreement data and parameter, produces NTLM Type3 data, then forms Authorization header by HTTP NTLM protocol requirement; Or, Situation IV: If the identity authentication protocol is HTTP Negotiate, first decrypt the user identity information data from the cookie, and obtain the user's secondary account name and password in the Web application system, that is, the user's account name and password in the Kerberos system , and then use the slave account name and password to call the corresponding Kerberos interface, connect to the identity authentication server of the Kerberos KDC, obtain the user's TGT, and then use the TGT to call the GSS-API or equivalent interface to obtain the user's access to the Spnego of the Web application system. Token, then, use the obtained Spnego Token to form the Authorization header according to the requirements of the HTTP Negotiate protocol; or, Scenario V: If it is another valid HTTP authentication protocol, it will be processed according to the relevant protocol; Otherwise, direct the user's browser to an error page. 5. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 1 or 2, characterized in that: after the single sign-on HTTP plug-in intercepts the HTTP response, the HTTP response is processed as follows: Step 1: Check the response status and header of the HTTP response, if the response status is "401" and contains the WWW-Authenticate response header, then go to step 2; otherwise, go to step 7; Step 2: Check the user identity information, if it exists and is valid, then go to step 3; otherwise, go to step 6; Step 3: Check the value of the WWW-Authenticate header of the current HTTP response, if it is an initial prompt for identity authentication and the corresponding HTTP request includes an Authorization header and the value of the Authorization header is the WWW-Authenticate header The identity credential data corresponding to the HTTP identity authentication protocol indicated in or the data after the identity credential data password operation, then go to step 4; otherwise, go to step 5; Step 4: the user identity information is set to be empty, the value of the protocol data and parameters returned by the server is set to the value of the WWW-Authenticate header of the HTTP response, and the HTTP request URL corresponding to the current HTTP response is obtained, and the It is saved as the value of the last protected URL to be accessed; if the method of the HTTP request corresponding to the current HTTP response is POST, then the POST parameter corresponding to the request is saved in the last POST parameter, otherwise it will be The value of the last POST parameter is set to be empty; then, modify the response status code of the HTTP response to 302, remove the WWW-Authenticate response header, and remove the HTTP response body and the length indication of the response body that may be included. Add the Location header to , and set its value to the URL of the user agent login error page of the identity service system. The URL is appended with the system identifier of the web application system where the single sign-on HTTP plug-in is located through the Query String. Finally, let the modified HTTP The response is passed, and the processing of this HTTP response is completed; Step 5: Set the value of the protocol data and parameters returned by the server as the value of the WWW-Authenticate header of the HTTP response, obtain the HTTP request URL corresponding to the current HTTP response, and use it as the last subject to be accessed The value of the protected URL is saved; if the method of the HTTP request corresponding to the current HTTP response is POST, then the POST parameter corresponding to the request is saved in the last POST parameter, otherwise the value of the last POST parameter is set to Empty; Then, change the response status code of the HTTP response to 302, remove the WWW-Authenticate response header, remove the HTTP response body that may be included and the length indication of the response body, add the Location header to the response, and set its value to It is the HTTP request URL corresponding to the current HTTP response, and then, let the modified HTTP response pass to complete the processing of this HTTP response; Step 6: Save the HTTP identity authentication protocol indicated in the WWW-Authenticate header to the identity authentication protocol of the user login information, and set the value of the protocol data and parameters returned by the server to the WWW of the HTTP response -The value of the Authenticate header, set the user identity information to be empty, obtain the HTTP request URL corresponding to the current HTTP response, and store it as the value of the protected URL to be accessed last time; if the current HTTP response corresponds to If the method of the HTTP request is POST, save the POST parameter corresponding to the request into the last POST parameter, otherwise set the value of the last POST parameter to empty; then, modify the response status code of the HTTP response If it is 302, remove the WWW-Authenticate response header in the HTTP response, remove the HTTP response body that may be included and the length indication of the response body, and add the Location header to the response header, whose value is the user login page of the identity service system URL, the URL is appended with the system identifier of the web application system where the single sign-on HTTP plug-in is located through the Query String, and finally, the modified HTTP response is passed to complete the processing of this HTTP response; Step 7: Obtain the HTTP request URL corresponding to the current HTTP response, and determine whether the HTTP request URL corresponds to a securely protected Web page according to the relevant configuration information. If not, let the HTTP response pass to complete the processing of this HTTP response; otherwise , go to step 8; Step 8: If the HTTP response contains a WWW-Authenticate response header, remove the WWW-Authenticate response header; if the URL of the HTTP request corresponding to the current HTTP response is the same as the last protected URL to be accessed , then set the last protected URL to be accessed and the last POST parameter value to null; Step 9: According to the configuration information of the single sign-on HTTP plug-in for the currently used HTTP identity authentication protocol, the setting method of the server-side return protocol data and parameter values after the user identity authentication is successful, Set the server end to return the value of the protocol data and parameters, and then allow the modified HTTP response to pass through to complete the processing of this HTTP response; The value of the WWW-Authenticate header described in the third step is an initial prompt for identity authentication, which means that the value of the header is the value returned by the Web server for the first time when the user accesses the protected page for the first time before the user completes the identity authentication. The data in the WWW-Authenticate response header that requires authentication; The identity credential data described in the 3rd step refers to electronic data that can prove the identity of the user, including account name, password, and a security token containing identity confirmation information; the data after the cryptographic operation of the identity credential data, It refers to the data obtained after the identity certificate is passed through a certain password operation; If the HTTP response intercepted by the single sign-on HTTP plug-in contains multiple WWW-Authenticate headers, the WWW-Authenticate header used in step 3 and the values used in steps 4, 5, and 6 The WWW-Authenticate header in the returned protocol data and parameters saved to the server and the WWW-Authenticate header used for saving the identity authentication protocol in the 6th step are a correspondence selected according to predetermined rules. In the WWW-Authenticate header of a certain HTTP authentication protocol, and the WWW-Authenticate header deleted in the 4th, 5th, 6th, and 8th steps includes all WWW-Authenticate headers; In terms of data structure, the modified HTTP response described in steps 4, 5, 6, and 9 can be the HTTP response obtained after directly modifying the original HTTP response data structure, or it can be obtained in a new HTTP response. The newly generated HTTP response on the response data structure; The relevant configuration information in the seventh step refers to the configuration information related to security access control, identity authentication and single sign-on of the Web service component and/or the single-sign-on HTTP plug-in. 6. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 5, characterized in that: the sixth step of the HTTP response processing process is by modifying or setting the status code of the HTTP response After redirecting the browser to the user login page of the identity service system for 302 and setting the Location header of the HTTP response, the identity service system processes the HTTP request as follows: Step 1: Determine whether the Web application system that the user wants to access is a system that the identity service system trusts and provides services through the Web application system identifier carried in the Query String of the HTTP request URL. If not, return an error message; otherwise, go to the step two; Step 2: Determine whether the user has completed identity authentication in the identity service system before, and if so, go to the next step; otherwise, guide the user to the login page, and authenticate the user based on the user's main account. After successful authentication, go to Step three; Step 3: According to the user's master account and the Web application system to be accessed by the user, the user's slave account name and password in the Web application system to be accessed are obtained in the master-slave account binding database; Step 4: Generate a security token for the user that includes the primary account name, secondary account name, and encrypted secondary account password, and digitally sign the relevant information, and then submit the user identity information containing the security token in the form Return to the user's browser by means of automatic POST submission of the Form form, and submit the user identification information including the security token to the security token processing page of the Web application system that the user needs to access. 7. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 1, 2 or 6, characterized in that: the security token processing page is issued by the identity service system and browsed by the user After the server automatically submits the user identification information including the security token through the Form form, it will be processed as follows: Step I: Verify whether the security token is valid through digital signature, if it is valid, go to Step II; otherwise, return an error message; Step II: separate the user's primary account name and secondary account name and password from the security token, decrypt the secondary account password, and then create a Set-Cookie header in the HTTP response to set the Cookie that stores the user identity information, The value of the cookie contains the encrypted user's main account name, secondary account name, and password; Step III: Set the status code of the HTTP response to 302, create a Location header in the HTTP response, and set the value of the header to obtain the last protected URL to be accessed from the Cookie, and then return HTTP response. 8. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 5, characterized in that: the fourth step in the HTTP response processing phase is modified or set by the status code of the HTTP response After redirecting the browser to the URL of the user agent login error page of the identity service system for 302 and setting the Location header of the HTTP response, the identity service system processes the HTTP request as follows: Step 1: Determine whether the Web application system that the user wants to access is a system that the identity service system trusts and provides services through the Web application system identifier carried in the HTTP request URL. If not, return an error message; otherwise, go to the second step ; Step 2: Prompt the user to input and submit the account name and password in the web application system to be accessed; Step 3: After the user submits the account name and password, determine whether the user has logged into the identity service system to complete identity authentication, if so, then go to step 5; otherwise, go to step 4; Step 4: Return to the user login page of the identity service system, and authenticate the user based on the user's main account. After the authentication is successful, go to the fifth step; Step 5: Based on the user's account name and password in the Web application system obtained in the second and third steps, update the user's account name and password in the corresponding Web application system in the master-slave account binding database; Step 6: Generate a security token for the user that includes the primary account name, secondary account name, and encrypted secondary account password, and digitally sign the relevant information, and then submit the user identity certification information containing the security token in Form The form is returned to the user's browser, and the user's identification information including the security token is submitted to the security token processing page of the Web application system that the user needs to visit through the automatic POST submission of the Form form. 9. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 7, characterized in that: if the entire Web path or directory of the Web application system is a path or path protected by security, and cannot If a non-secured path or directory is set in or outside the secured path or directory, the security token processing page is not an actual web page, but only a virtual web page path; correspondingly , the single sign-on HTTP plug-in intercepts the HTTP request submitted to the security token processing page in the HTTP request processing stage, completes the processing operation described in the first step, and then intercepts the HTTP response in the response processing stage of the HTTP request , complete the processing operations described in the second and third steps. 10. The plug-in single sign-on integration method for HTTP identity authentication protocol according to claim 1, characterized in that: if the user accesses the Web application system through a Web proxy, and the Web proxy passes the HTTP The proxy mode of the identity authentication protocol authenticates the user, and the Web proxy provides an HTTP plug-in mechanism in its HTTP request and response processing channel, and the HTTP plug-in based on this plug-in mechanism can intercept the request and response data of the HTTP identity authentication protocol, Then the method described is also applicable with the following corresponding changes: The Web service component refers to the Web agent; the Web application component refers to the entire Web system behind the Web agent; the Web agent and the entire Web system thereafter constitute the Web application system; the single sign-on HTTP plug-in deployment On the Web proxy, and configured to intercept all HTTP requests and responses on the deployed Web proxy; the HTTP response status code "401" becomes "407"; the HTTP response header WWW- Authenticate becomes the Proxy-Authenticate header; the HTTP request header Authorization becomes the Proxy-Authorization header.

Images