CN102638454A

CN102638454A - 一种面向http身份鉴别协议的插件式单点登录集成方法

Info

Publication number: CN102638454A
Application number: CN201210067271XA
Authority: CN
Inventors: 龙毅宏; 谢坤轩; 郭浩平; 王亚龙; 吴志奇; 唐志红; 刘旭
Original assignee: BEIJING ITRUSCHINA Co Ltd; Wuhan University of Technology WUT
Current assignee: BEIJING ITRUSCHINA Co Ltd; Wuhan University of Technology WUT
Priority date: 2012-03-14
Filing date: 2012-03-14
Publication date: 2012-08-15
Anticipated expiration: 2032-03-14
Also published as: CN102638454B

Abstract

本发明涉及一种面向HTTP身份鉴别协议的插件式单点登录集成方法，该方法的单点登录***包括Web服务组件、Web应用组件、单点登录HTTP插件、安全令牌处理页面、浏览器、身份服务***、主帐户数据库、主从帐户绑定数据库，其中单点登录HTTP插件是关键，它基于Web服务组件提供的扩展机制***到采用HTTP身份鉴别协议的Web服务组件的HTTP请求、响应处理通道中；当用户在身份服务***登录后，该插件使用用户在Web应用***上的帐户名、口令自动完成与Web服务组件的HTTP身份鉴别协议交互，使得用户无需输入Web应用***中的帐户名、口令即能登录Web应用***，从而达到单点登录的目的。采用本发明的方法实现单点登录无需改变***原有的安全配置及功能。

Description

一种面向HTTP身份鉴别协议的插件式单点登录集成方法

技术领域

本发明属于信息安全的身份鉴别与访问控制技术领域，特别地，是一种面向HTTP身份鉴别协议的插件式单点登录集成方法。

背景技术

随着企业电子商务和办公信息化的发展，越来越多的企业、组织机构建立了大量的具有特别用途的信息***，统称应用***，如客户关系管理***、ERP(Enterprise Resource Planning)***、财务***、办公自动化***、电子邮件***等。这些众多的应用***在给人们的生产、管理、办公带来方便，提高生产和工作效率的同时，也给人们带来一些困扰，这就是，每个用户必须记住他(或者她)在不同应用***的帐户名、口令(也称为用户名、口令)；这些在不同应用***的帐户名、口令可能是相同的，也可能是不同的；需要记住、使用众多的不同的帐户名、口令的问题有：1)帐户名、口令管理的困难，如帐户名、口令太多容易混淆、遗忘；2)每次登录不同***时都需要输入帐户名、口令，给用户带来了不便。针对这一问题，由此产生了所谓的单点登录(Single SignOn，SSO)需求和技术，即用户只需要使用一个身份凭证(如一个帐户名、口令，或一张数字证书等)，在某个在线***完成在线身份鉴别(也即login登录)后就能访问所有其他能够访问的***，而无需再次输入帐户名、口令或使用数字证书进行身份鉴别(即再进行登录操作)。

目前的各类应用***大多采用客户机/服务器(Client/Server)的模式，而其中，有的采用基于浏览器(Browser)、Web服务器的标准和通用技术，即采用Browser/Server模式(简称B/S模式)，有的采用非标准或非通用的客户端/服务器技术(简称C/S模式)。B/S模式的***，客户端浏览器与Web服务器之间通过标准的HyperText Transfer Protocol(HTTP)进行数据交互与传送：浏览器将HTTP格式的服务请求(HTTP请求)传送到Web服务器，Web服务器针对请求进行相应处理，之后Web服务器将处理结果以HTTP格式的响应(HTTP响应)返回到浏览器，最后浏览器根据返回的结果数据展现返回的结果内容。HTTP请求由一个请求行(Request Line)、多个可选的头部(Header)和一个可选的主体(Body)组成，其中从请求行和“Host”头部，可以构造出HTTP请求URL(UniformResource Locator)；HTTP响应由一个状态行(Status Line)、多个可选的头部(Header)和一个可选的主体(Body)组成。由于B/S模式采用浏览器这种通用客户端以及标准技术架构，易于使用和互操作，是目前信息***技术发展的主流和趋势，也是本发明针对的应用***所采用的技术。采用了B/S模式或架构的应用***称为Web应用***。

针对B/S模式的Web应用***的单点登录技术目前常见的有：1)基于Cookie的；2)基于安全网关的；3)基于Windows Kerberos的；4)基于单点登录协议的(标准或自定义协议)：5)其他方案。

Cookie是Web服务器通过HTTP响应在客户端浏览器中(或客户端主机中)保存的信息，可以包含任何内容，但通常包含用户会话(Session)状态信息。Cookie有作用域，其作用域由域名(Doma in Name)和路径(Path)构成；若HTTP请求的主机域名部分和路径部分在Cookie的作用域内，则浏览器提交的HTTP请求中将包含服务器端设置的Cookie。基于Cookie的单点登录，要求不同信息***的域名的“基部”相同，比如，若两个信息***的域名是oa.example.com.cn，crm.example.com.cn，这样它们的“基部”都是example.com.cn，因此，可以实现基于Cookie的单点登录，IBM的LTPA(Lightweight Third Party Authentication)单点登录技术就是基于Cookie的。

基于安全网关的单点登录，就是采用一个实现安全控制功能的Web反向代理(Reverse Proxy)作为用户访问部署在其后面的不同信息***、应用***的关卡(即网关)，只有在安全网关完成身份鉴别(即进行成功登录)的用户才能通过安全网关访问部署在其后面的***，比如IBM的WebSEAL就这样的一个安全网关。这种单点登录技术的最大缺点是，当并发用户访问量很大时，安全网关是性能瓶颈，而且它是潜在的单点失效点(Single Point of Failure)。

基于Windows Kerberos的Web单点登录技术，通过Windows ActiveDirectory，AD)的Kerberos身份鉴别(Authentication)结合HTTPNegotiate协议实现。这种技术方案的局限性在于：1)它需要部署WindowsAD或其他Kerberos***；2)要求所有用户在AD域上有帐户且用户主机要登录AD域；3)要求所有的Web信息***、应用***采用HTTP Negotiate协议进行用户身份鉴别，而且所有Web信息***、应用***采用AD域的用户帐户对用户访问进行管理和控制；4)只适合于通过内网访问的信息***、应用***。由于这些特别要求，这就限制了基于Windows Kerberos的单点登录解决方案的应用，因为，无论从开发技术角度还是从应用环境的角度，目前的大量Web信息***、应用***都不符合这些条件(或者说，不是所有的Web信息***、应用***都符合这些条件)。

针对Web单点登录的协议目前主要有Security Assertion MarkupLanguage(SAML)和WS-Federation Passive Requestor Profile(简称WS-FPRP)。无论是SAML还是WS-FPRP，在其技术架构中都有一个称为Identity Provider(简称IdP)的***提供在线身份鉴别服务(称为身份服务***)，用户只需(使用浏览器)在IdP完成一次登录(即在线身份鉴别)，就能访问该IdP信任域中的其他Web信息***而无需再进行登录(身份鉴别)操作。但是，这种单点登录技术方案要获得成功应用，有两个关键问题需要解决：一是如何解决用户在不同***中的帐户之间的对应、转化，二是如何使得已有的各类信息***、应用***与单点登录协议集成。所述第一个问题的更具体描述如下：涉及单点登录的各种信息***、应用***通常都有各自的用户帐户管理组件和帐户数据库，且这些信息***、应用***是基自身的用户帐户来对用户进行访问控制的，这样，用户在IdP进行登录、身份鉴别时所使用的用户帐户与其在某个要访问的信息***、应用***中的帐户可能是不相同的(当然也可能相同)，因此，当用户在IdP完成身份鉴别后、访问某个应用***时，需要进行相应的帐户对应、转化，用户才能以其在该应用***中的帐户(身份)登录、访问该应用***。

对于前面所述的第一个问题的常用解决方案是：用户使用一个主帐户在IdP登录，这个主帐户可以是用户已有的某个应用***帐户，或者是某个已有的全局帐户(如Windows Active Directory中的帐户)，或者是某个专门新创建的全局帐户；用户的主帐户事先通过一定的方式同用户在不同信息***、应用***的帐户(称为从帐户)关联起来，这个过程称为身份(帐户)关联(Identity Federation或Account Federation)或身份(帐户)绑定(Identity Binding或Account Binding)；当用户使用其主帐户在IdP完成登录(身份鉴别)后、访问某个特定应用***时，其主帐户通过一定的方式被对应、转化成该用户在该应用***的从帐户，然后用户基于该从帐户访问应用***，这个主、从帐户对应、转化的过程称为身份(帐户)映射(Identity Mapping或Account Mapping)。

所述第二问题实际上涉及到单点登录的集成技术，它是目前单点登录应用中最复杂、最难解决的问题，对这个问题的解决通常有这么几种方案：(1)应用***的运行平台本身支持相关的单点登录协议(如OracleWebLogic Server的最新版本支持SAML协议)，因此，如果应用***依赖于运行平台来进行登录操作(用户身份鉴别)，那么，通过配置运行平台的用户身份鉴别方式，就能通过协议互联实现单点登录；(2)通过修改应用***的用户登录部分的功能实现，这可能包括修改身份鉴别的相关配置，修改相应的用户登录模块等；(3)通过运行平台提供的身份鉴别扩展机制，如JAAS(Java Authentication and Authorization Service)。

前面所述的第一种集成解决方案不是在任何情况下都能适用的，因为目前大多数的Web运行平台(Web服务组件、服务器)并不支持相应的单点登录协议。对于第二种解决方案，在很多情况下也不适用，因为，企业、组织机构可能由于各种原因，不愿意或者不能够采用第二种集成解决方案，比如，由于担心修改***后会对***的稳定运行带来影响，或者，***的源代码已不存在(如原***开发商不愿意配合提供相关的代码，或已倒闭等)。前面所述的第三种方案也不是所有情况都合适，一是因为这种方案通常只适用于应用***依赖于Web运行平台(Web服务组件、Web服务器)进行身份鉴别的情形(如由Servlet Container对用户进行身份鉴别)，不适用于应用***自身进行用户身份鉴别的情形；二是采用这种机制实现单点登录，通常需要改变平台以前的身份鉴别方式，而有时企业、组织机构由于各种原因不愿意做这种改变(如因为担心这种改变会影响***的运行或者不安全)；三是不是所有Web运行平台都提供了身份鉴别的扩展机制，或者说理论上提供了这种扩展机制，但实际上由于技术上的限制，扩展的身份鉴别机制难以达到与之前的身份鉴别机制同样的功效，比如对于微软IIS(Internet Information Services)Web服务器，其技术文档指出可通过ISAPI(Internet ServiceApplication Programming Interface)扩展IIS的身份鉴别功能，但实际上这种扩展是受限的，比如只能在IIS配置为匿名身份鉴别(AnonymousAuthentication)方式下才能扩展定制的身份鉴别机制，而且由于微软没有公开IIS的内部技术，很难基于ISAPI扩展机制开发出与IIS自身的身份鉴别机制同等功效的单点登录身份鉴别机制。对于其他Web运行平台也都可能会遇到类似的问题。

在单点登录的实际应用集成中，Web应用***依赖于Web平台采用标准HTTP身份鉴别协议(如HTTP Basic。Digest，NTLM，Negotiate)进行用户身份鉴别，且Web应用***的身份鉴别方式不能改变是一种经常遇到的情形，针对这情形，本发明提出另一种思路来解决已有Web应用***与单点登录技术的集成问题：在不改变***原有的身份鉴别机制、配置及功能的前提下，通过HTTP插件(Plug-in)技术来实现单点登录。也就是说，在这种单点登录集成方案下，Web运行平台的身份鉴别机制仍然按其原有的方式运行和发挥作用。这里所述的HTTP插件，是指基于Web运行平台提供的扩展机制***到Web运行平台的HTTP请求、响应处理通道中的一个软件组件，该组件能对通过它的HTTP请求、响应的相关内容进行修改。很多的Web运行平台都提供了这种HTTP插件机制，如微软的IIS服务器的ISAPI，IIS7.0以后的Native-Code API和Managed-CodeAPI，Tomcat Valve、WebLogic的Authentication Filter，WebSphere的Servlet Filter等。

发明内容

本发明的目的是：针对Web应用***基于标准HTTP身份鉴别协议对用户进行身份鉴别且这种身份鉴别安全配置不能修改、改变的情形，提出一种面向HTTP身份鉴别协议的插件式单点登录集成方法，以克服现有单点登录集成技术的不足。

为了实现上述目的，本发明所采用的技术方案是：

一种面向HTTP身份鉴别协议的插件式单点登录集成方法，所述方法的单点登录***包括Web服务组件、Web应用组件、单点登录HTTP插件、安全令牌处理页面、浏览器、身份服务***、主帐户数据库、主从帐户绑定数据库，其中：

Web服务组件：为Web应用组件提供HTTP请求接收、响应传送功能，及其他相关的支撑功能，包括：接收用户浏览器提交的HTTP格式的服务请求，进行相应预处理后提交给Web应用组件进行处理，之后，将Web应用组件返回的处理结果，以HTTP响应的格式传送到用户浏览器；基于相应的安全配置，对用户进行身份鉴别、访问控制；维护用户的HTTP会话(Session)等；

Web应用组件：向用户提供特定应用服务的功能软件，如OA、CRM、WebMail等，其主要功能是：通过相应的Web服务组件，接收用户通过浏览器提交的应用服务请求，完成相应处理后将处理结果通过Web服务组件返回到用户浏览器；所述Web应用组件和对应的所述Web服务组件构成了Web应用***；

单点登录HTTP插件：基于Web服务组件提供的扩展机制，***到采用HTTP身份鉴别协议的Web应用***的Web服务组件的HTTP请求、响应处理通道中实现单点登录功能的软件组件；

安全令牌处理页面：在采用HTTP身份鉴别协议的Web应用***的Web服务组件上部署的专门处理身份服务***签发的证明用户身份的安全令牌的Web页面；所述安全令牌处理页面部署在Web服务组的非安全保护路径(目录)，即通过浏览器提交HTTP请求到该处理页面的用户无需完成身份鉴别；

浏览器：用户与Web应用***交互的客户端，其主要功能是：通过HTTP协议向Web服务组件传送HTTP请求，接收Web服务组件返回的HTTP响应并展现响应的内容；

身份服务***：提供用户在线身份鉴别服务的***，其功能包括：基于用户身份凭证对用户进行在线身份鉴别，通过相应的单点登录协议并借助浏览器向Web应用***传送证明用户身份的安全令牌；

主帐户数据库：存放用户登录身份服务***的主帐户信息，包括主帐户的帐户名、口令，或主帐户对应的数据证书的相关信息；

主从帐户绑定数据库：保存用户主帐户与用户在Web应用***的从帐户的对应(绑定)关系，以及从帐户的口令。

所述Web服务组件可以是HTTP Web服务器(如IIS)、Web容器(WebContainer，如Tomcat)、J2EE应用服务器(Application Server，如WebLogic、WebSphere)；所述Web应用***通过一定的方式对用户进行身份鉴别，其中部分Web应用***通过Web服务组件采用标准HTTP身份鉴别协议(如HTTP Basic、HTTP Negotiate)对用户进行身份鉴别；用户访问某个Web应用***的受保护的页面或资源，需要使用其在该Web应用***中的相应帐户完成身份鉴别后才能进行；所述Web应用***可以有多个。

所述单点登录HTTP插件采用的插件机制能够拦截HTTP身份鉴别协议的请求、响应数据(即携带Authorization头部的HTTP请求和携带WWW-Authentication头部的HTTP响应)；所述单点登录HTTP插件在其所部署的Web服务组件上被配置为拦截所有的HTTP请求、响应，或者被配置为拦截所有提交到受安全保护的目录或路径的HTTP请求及其响应和提交到安全令牌处理页面所在目录或路径的HTTP请求及其响应。

所述单点登录HTTP插件有相应的配置信息，用于设置与单点登录有关的信息，如身份服务***的用户登录地址(URL)、对安全令牌签名的数字证书等；可选地，配置信息中包含如下内容：1)单点登录HTTP插件所在的Web应用***中哪些Web页面目录或路径是受安全保护的；2)受安全保护的目录或路径所采用的HTTP身份鉴别协议是哪个或哪些(即可以设置多个)，及相关的身份鉴别协议参数(如domain、realm等)；3)所使用的HTTP身份鉴别的具体实施是否允许客户端主动发出鉴别和授权请求。所述配置信息3)是针对这样的情形：有的HTTP身份鉴别协议(如HTTP Negotiate)允许客户端浏览器在初次访问受保护的资源时候，在Web服务器端返回要求身份鉴别的响应提示前，也即在客户端浏览器接收到响应状态码是“401”(提示Unauthorized或Authentication required)且包含WWW-Authenticate头部的HTTP响应之前，由客户端浏览器主动发起身份鉴别过程，即主动提交包含Authorization头部的HTTP请求，请求服务器端对客户端用户进行身份鉴别和对资源访问进行授权；但是，某个Web组件的具体协议实施也许并不支持这种客户端主动发起身份鉴别的方式，该配置信息即用于对此进行指示。所述内容1)、2)通常可通过一定的方式，如API、配置文件读取，从Web服务组件获得，但在无法获得请求下，可通过单点登录HTTP插件的配置信息设置并获得。

所述身份服务***签发的所述安全令牌的格式依赖于使用的单点登录协议，可以是SAML断言(Assertion)，或者WS-Federation安全令牌(Security Token)，或者自定义的安全令牌；所述身份服务***通过数字签名保证所签发的安全令牌的安全性(原发性、完整性)。

用户在所述身份服务***进行在线身份鉴别时所用的身份凭证，可以是普通帐户名、口令，也可以是数字证书，或者其他能够标识、验证用户身份的其他电子身份数据。用户在所述身份服务***进行身份鉴别时使用的帐户称为主帐户。所述主帐户数据库是用于保存用户主帐户及相关信息的数据库，所述主帐户数据库可以是独立的帐户数据库，也可以选择某个应用***的用户帐户数据库作为主帐户数据库。所述从帐户即指用户在某个特定Web应用***的帐户；用户的主帐户与其在某个Web应用***中的从帐户可以是同一个，也可以不同。

所述单点登录HTTP插件保存有每个用户的登录(身份鉴别)相关信息，称为用户登录信息。所述用户登录信息包括：

1)身份鉴别协议，即Web服务组件当前使用的、用于对用户进行身份鉴别的HTTP身份鉴别协议；

2)服务器端返回协议数据与参数，即Web服务组件使用HTTP身份鉴别协议对客户端用户进行身份鉴别时，通过WWW-Authentucate响应头部返回到客户端浏览器的协议相关数据和参数，如HTTP身份鉴别协议指示及Realm、Challenge(挑战码)、密钥协商参数等，其中HTTP身份鉴别协议指示在“身份鉴别协议”中也同时保存；

3)最近一次要访问的受保护的URL，即用户在Web应用***完成身份鉴别前，使用浏览器最近一次期望访问的受安全保护的Web页面的URL；

4)最近一次POST参数，用户在Web应用***完成身份鉴别前，若使用浏览器最近一次访问受安全保护的Web页面时使用的HTTP请求方法(Method)是POST，则“最近一次POST参数”的值是该HTTP请求对应的POST参数(即POST方式提交的Form表单数据)，否则其值是空(NULL)；

5)用户身份信息，标识和鉴别用户的信息，包括用户的主帐户名、从帐户名及从帐户口令；

以上所述各种用户登录信息以字符串的形式保存(对于非字符数据，以Base64编码的格式保存)；所述“用户身份信息”被加密且具有时效性，以防止泄露和重播攻击；所述“身份鉴别协议”、“最近一次要访问的受保护的URL”、“最近一次POST参数”和“用户身份信息”保存在Cookie中，且该Cookie的作用路径需要同时包含Web服务组件设置的受安全保护的路径和安全令牌处理页面所在非受安全保护的路径，即无论在受安全保护的路径中的Web页面还是非受安全保护的安全令牌处理页面都能查看得到该Cookie，或者，将有关的用户登录信息同时保存在两个不同的Cookie中，其中一个的作用路径是受安全保护的路径，另一是非受安全保护的安全令牌处理页面所在路径。

单点登录HTTP插件根据Web服务组件提供给HTTP插件的数据存储机制的不同，依如下优先顺序，分别按如下方法对用户登录信息中的相关信息进行存储：

1)若Web服务组件向HTTP插件提供了基于TCP连接(Connection)的数据存储位置，则单点登录HTTP插件将“服务器端返回协议数据与参数”保存在基于TCP连接的数据存储位置，将其他信息通过Cookie保存在客户端浏览器中；或者，

2)若Web服务组向HTTP插件提供了基于HTTP会话(Session)的数据存储位置，则单点登录HTTP插件将“服务器端返回协议数据与参数”保存在基于HTTP会话的数据存储位置，将其他信息通过Cookie保存在客户端浏览器中；或者，

3)若单点登录HTTP插件有定制开发的基于TCP连接或HTTP会话的数据存储位置，则单点登录HTTP插件将“服务器端返回协议数据与参数”保存在定制开发的基于TCP连接或HTTP会话的数据存储位置，将其他信息通过Cookie保存在客户端浏览器中；

否则，

4)单点登录HTTP插件将所有用户登录信息通过Cookie保存在客户端浏览器中。

所述基于TCP连接的数据存储位置，指Web服务组件向HTTP插件提供的数据存储位置与HTTP数据传输的TCP连接相关联，TCP连接不同，则提供的数据存储位置不同(如IIS向ISAPI Filter提供的基于TCP连接的数据存储位置)；所述基于HTTP会话的数据存储位置指：只要是同一HTTP会话，即便TCP连接不同，数据存储位置仍然相同，即数据存储位置与TCP连接无关，仅与特定的HTTP用户会话有关，这种HTTP会话数据存储机制通常用Cookie中存放的特定标识来区分不同的会话，并将会话数据保存在Web服务器(组件)中，如Java Web容器向Servlet Filter提供的存放数据的Session对象就是这种情况。

针对所述“服务器端返回协议数据与参数”，在单点登录HTTP插件的配置信息中必须设定如下内容：对于Web应用***使用的每一个HTTP身份鉴别协议，在用户身份鉴别成功后，“服务器端返回协议数据与参数”的值的相应设置方式，设置方式的选项是：保持不变，设置为空(NULL)，或设置为一个空格(Space)。

当用户使用浏览器访问某个使用HTTP身份鉴别协议对用户进行身份鉴别的Web应用***时，所述单点登录HTTP插件拦截HTTP请求，然后按如下方式对HTTP请求进行处理：

A1.根据相关配置信息，确定当前HTTP请求URL对应的是受安全保护的页面还是非受安全保护的页面，若是受安全保护的，则转入下一步骤；否则，让该HTTP请求通过，完成本次HTTP请求处理；

A2.检查“服务器端返回协议数据与参数”，若其没有设置或其值为空，则转入下一步骤；否则，转入步骤A6；

A3.检查“用户身份信息”，若其存在且有效，则转入下一步骤；否则，让HTTP请求通过，完成本次HTTP请求处理；

A4.从Cookie中保存的“身份鉴别协议”信息中得到Web应用***当前使用的HTTP身份鉴别协议，然后，根据相关配置信息确定所采用的HTTP身份鉴别协议是否允许客户端主动发出鉴别和授权请求，若不允许，则让HTTP请求通过，完成本次HTTP请求处理；否则，继续；

A5.从相关配置信息中获得HTTP身份鉴别协议所需的数据与参数(如realm参数)，依HTTP身份鉴别协议，生成客户端初次提交的包含身份鉴别数据的Authorization请求头部，并将生成的头部加入到拦截的HTTP请求中，然后，让修改后的HTTP请求通过，完成本次HTTP请求处理；

A6.若“服务器端返回协议数据与参数”的值为一个空格，则让该HTTP请求通过，完成本次HTTP请求处理；否则，继续；

A7.根据“服务器端返回协议数据与参数”中的HTTP身份鉴别协议及其他数据，生成HTTP身份鉴别协议在当前协议阶段的Authorization请求头部，并将生成的头部加入到拦截的HTTP请求中，然后，让修改后的HTTP请求通过，完成本次HTTP请求处理。

所述步骤A1、A4、A5中所述相关配置信息指Web服务组件和/或单点登录HTTP插件的与安全访问控制、身份鉴别、单点登录有关的配置信息；所述单点登录HTTP插件或者通过Web服务组件提供的相应接口查询Web服务组件的相关配置信息，或者直接读取相关配置文件。

所述HTTP身份鉴别协议的身份鉴别过程可能需要客户端与服务器端通过HTTP请求、响应进行多个步骤或阶段的交互，而所述步骤A7中所述的HTTP身份鉴别协议的“当前协议阶段”是指客户端根据身份鉴别协议当前所处的步骤或阶段；HTTP身份鉴别协议的“当前协议阶段”决定了HTTP请求的当前Authorization头部的数据内容是什么；客户端可根据服务器端返回的协议数据与参数，确定当前所处的步骤或阶段。

所述单点登录HTTP插件在HTTP请求处理阶段的所述步骤A5、A7，根据HTTP身份鉴别协议的不同，分别按如下方式，产生HTTP身份鉴别协议在对应协议阶段的相应Authorization请求头部：

情形1.1.若HTTP身份鉴别协议是HTTP Basic，则从Cookie中解密“用户身份信息”数据、获取用户在Web应用***中的从帐户名、口令，然后按HTTP Basic协议的要求，形成Authorization头部；否则，

情形1.2.若HTTP身份鉴别协议是HTTP Digest，则从Cookie中解密“用户身份信息”数据、获取用户在Web应用***中的从帐户名、口令，然后根据“服务器端返回协议数据与参数”中的内容，以及HTTP Digest协议的要求，形成Authorization头部；否则，

情形1.3.若HTTP身份鉴别协议是HTTP NTLM，且“服务器端返回协议数据与参数”为未设置或者其值为空或者其值为进行身份鉴别的初次提示，则产生NTLM Type 1数据，然后按HTTP NTLM协议要求，形成Authorization头部的数据；否则，先从Cookie中解密“用户身份信息”数据、获取用户在Web应用***中的从帐户名、口令，然后，利用该从帐户名、口令以及保存在“服务器端返回协议数据与参数”中的相关数据(即NTLM Type 2数据)，产生NTLM Type 3数据，然后按HTTP NTLM协议要求，形成Authorization头部；否则，

情形1.4.若HTTP身份鉴别协议是HTTP Negotiate，则先从Cookie中解密“用户身份信息”数据、获取用户在Web应用***中的从帐户名、口令(即在Kerberos***中，如Windows AD中，的帐户名、口令)，然后利用该从帐户名、口令调用相应的Kerberos接口，连接Kerberos KDC(Key Distribution Center)的Authentication Server(身份鉴别服务器)，获得用户的TGT(Ticket-Granting Ticket)，然后再使用该TGT调用GSS-API或相当的接口(如Windows SSPI)，获得用户访问Web应用***的Spnego Token，然后，利用获得的Spnego Token，按HTTP Negotiate协议要求，形成Authorization头部；否则，

情形1.5：若是其他有效的HTTP身份鉴别协议，则按相关协议进行处理；否则，将用户浏览器引导到出错页面。

所述单点登录HTTP插件在HTTP请求处理阶段完成所述步骤A2-7的相关处理后，让HTTP请求通过前，需做如下处理操作：若当前HTTP请求的URL与“最近一次要访问的受保护的URL”中保存的URL相同且当前HTTP请求的方法是GET且“最近一次POST参数”的值非空，则将当前HTTP请求的方法改为POST，将“最近一次POST参数”中的数据作为POST参数添加到当前HTTP请求中。

当所述单点登录HTTP插件拦截HTTP响应后，按如下方式对HTTP响应进行处理：

B1.检查HTTP响应的响应状态及头部，如果响应状态码是“401”(提示Unauthorized或Authentication required)且包含WWW-Authenticate响应头部，则转入下一步骤；否则，转入B7；

B2.检查“用户身份信息”，若其存在且有效，则转入一下步；否则，转入B6；

B3.检查当前HTTP响应的WWW-Authenticate头部的值，若是进行身份鉴别的初始提示且响应对应的HTTP请求包含有Authorization头部且该Authorization头部的值是所述WWW-Authenticate头部中指示的HTTP身份鉴别协议对应的身份凭证数据或者经身份凭证数据密码运算后的数据，则转入下一步骤；否则，转入步骤B5；

B4.将“用户身份信息”设置为空，将“服务器端返回协议数据与参数”的值设置为HTTP响应的WWW-Authenticate头部的值，获取当前HTTP响应对应的HTTP请求URL，将其作为“最近一次要访问的受保护的URL”的值保存；若当前HTTP响应对应的HTTP请求的方法是POST，则将该请求对应的POST参数(即Form表单数据)保存到“最近一次POST参数”中，否则将“最近一次POST参数”的值设置为空；然后，将HTTP响应的响应状态码修改为“302”，将WWW-Authenticate响应头部去掉，将可能包含的HTTP响应主体(Body)及响应主体长度指示去掉，在响应中加入Location头部，将其值设置为身份服务***的用户代登录出错页面URL，该URL通过Query String附加了单点登录HTTP插件所在的Web应用***的***标识，最后，让修改后的HTTP响应通过，完成本次HTTP响应的处理；

B5.将“服务器端返回协议数据与参数”的值设置为HTTP响应的WWW-Authenticate头部的值，获取当前HTTP响应对应的HTTP请求URL并将其作为“最近一次要访问的受保护的URL”的值保存；若当前HTTP响应对应的HTTP请求的方法是POST，则将该请求对应的POST参数保存到“最近一次POST参数”中，否则将“最近一次POST参数”的值设置为空；然后，将HTTP响应的响应状态码修改为“302”，将WWW-Authenticate响应头部去掉，将可能包含的HTTP响应主体(Body)及响应主体长度指示去掉，在响应头部中加入Location头部，将其值设置为当前HTTP响应对应的HTTP请求URL，然后，让修改后的HTTP响应通过，完成本次HTTP响应的处理；

B6.将WWW-Authenticate头部中指示的HTTP身份鉴别协议保存到所述用户登录信息的所述“身份鉴别协议”中，将“用户身份信息”设置为空，将“服务器端返回协议数据与参数”的值设置为HTTP响应的WWW-Authenticate头部的值，获取当前HTTP响应对应的HTTP请求URL，将其作为“最近一次要访问的受保护的URL”的值保存；若当前HTTP响应对应的HTTP请求的方法是POST，则将该请求对应的POST参数保存到“最近一次POST参数”中，否则将“最近一次POST参数”的值设置为空；然后，将HTTP响应的响应状态码修改为“302”，将WWW-Authenticate响应头部去掉，将可能包含的HTTP响应主体(Body)及响应主体长度指示去掉，在响应中加入Location头部，其值为身份服务***的用户登录页面URL，且该URL通过Query String附加了单点登录HTTP插件所在的Web应用***的***标识，最后，让修改后的HTTP响应通过，完成本次HTTP响应的处理；

B7.获取当前HTTP响应对应的HTTP请求URL，根据相关配置信息确定该HTTP请求URL是否对应受安全保护的Web页面，若不是，则让HTTP响应通过，完成本次HTTP响应的处理；否则，转入下一步骤；

B8.若HTTP响应中包含有WWW-Authenticate响应头部，则将WWW-Authenticate响应头部去掉；若当前HTTP响应对应的HTTP请求的URL与“最近一次要访问的受保护的URL”相同，则将“最近一次要访问的受保护的URL”和“最近一次POST参数”的值设置为空；

B9.根据单点登录HTTP插件的配置信息中针对当前所使用的HTTP身份鉴别协议所设定的、在用户身份鉴别成功后的“服务器端返回协议数据与参数”的值的设置方式，设置“服务器端返回协议数据与参数”的值，然后让修改后的HTTP响应通过，完成本次HTTP响应的处理。

所述步骤B3中所述的WWW-Authenticate头部的值是进行身份鉴别的初始提示是指该头部的值是用户完成身份鉴别前，初次访问受保护的页面时，Web服务器端初次返回的要求进行身份鉴别的WWW-Authenticate响应头部的数据。

所述步骤B3中所述的身份凭证数据，是指能证明用户身份的电子数据，如帐户名、口令(如HTTP Basic)，或者是包含身份确认信息的安全令牌(如HTTP Negotiate的Spnego Token)；所述经身份凭证数据密码运算后的数据，是指经身份凭证，如用户/口令，通过一定的密码运算(如HASH运算)后得到数据(如HTTP NTLM的经帐户名、口令散列运算的Type3数据)。

若单点登录HTTP插件拦截的HTTP响应包含多个WWW-Authenticate头部，则所述步骤B3中所用的WWW-Authenticate头部和所述步骤B4、B5、B6中所用的、其值被保存到“服务器端返回协议数据与参数”中的WWW-Authenticate头部以及所述步骤B6中保存“身份鉴别协议”所使用的WWW-Authenticate头部，是一个根据预定的规则选择的对应于某个HTTP身份鉴别协议的WWW-Authenticate头部(比如，按从Negotiate、NTLM、Digest到Basic协议优先顺序选择的WWW-Authenticate头部)，而在所述步骤B4、5、6、8中删除的WWW-Authenticate头部包括所有的WWW-Authenticate头部。

所述步骤B4、B5、B6、B9中所述的修改后的HTTP响应从数据结构上来说既可以是在原HTTP响应数据结构上直接修改后得到的HTTP响应，也可以是在一个新的HTTP响应数据结构上新生成的HTTP响应。

所述步骤B7中所述相关配置信息指Web服务组件和/或单点登录HTTP插件的与安全访问控制、身份鉴别、单点登录有关的配置信息。

在以上所述步骤中，将HTTP响应的状态码修改或设置为“302”并在响应中加入Location头部，即进行所谓HTTP重定向，将浏览器引导到Location所指的页面或Web站点。

单点登录HTTP插件在HTTP响应处理阶段根据不同情形分别按如下方式获得当前HTTP响应对应的HTTP请求的请求行、头部和主体中的相关数据(如请求URL、Cookie、Authorization头部、POST参数等)：

情形2.1：若HTTP插件能直接访问HTTP请求中的相关数据头部，则直接从请求中获得相关数据；否则，

情形2.2：若Web服务组件提供了基于TCP连接的数据存储位置，则单点登录HTTP插件在HTTP请求处理阶段完成所有相关处理包括将GET方式的请求转换为POST方式的请求后，让HTTP请求通过前，将当前HTTP请求的相关数据保存到基于TCP连接的数据存储位置，由单点登录HTTP插件在HTTP响应处理阶段获取；否则，

情形2.3：若Web服务组件提供了基于HTTP会话的数据存储位置，则单点登录HTTP插件在HTTP请求处理阶段完成所有相关处理包括将GET方式的请求转换为POST方式的请求后，让HTTP请求通过前，将当前HTTP请求的相关数据保存到基于HTTP会话的数据存储位置，由单点登录HTTP插件在HTTP响应处理阶段获取；否则，

情形2.4：若在HTTP请求处理阶段能直接设置HTTP响应的头部，则单点登录HTTP插件在HTTP请求处理阶段完成所有相关处理包括将GET方式的请求转换为POST方式的请求后，让HTTP请求通过前，将当前HTTP请求的相关数据，通过自定义的HTTP响应头部传递到HTTP响应处理阶段的单点登录HTTP插件获取，单点登录HTTP插件在HTTP响应处理阶段通过自定义头部获取相关数据后，删除该自定义头部；否则，

情形2.5：若单点登录HTTP插件有定制开发的基于TCP连接或会话的数据存储位置，则单点登录HTTP插件在HTTP请求处理阶段完成所有相关处理包括将GET方式的请求转换为POST方式的请求后，让HTTP请求通过前，将当前HTTP请求的相关数据保存到定制开发的基于TCP连接或会话的数据存储位置，由单点登录HTTP插件在HTTP响应处理阶段获取；否则，

情形2.6：单点登录HTTP插件在HTTP请求处理阶段完成所有相关处理包括将GET方式的请求转换为POST方式的请求后，让HTTP请求通过前，通过线程(Thread)机制将当前HTTP请求的相关数据传送到HTTP响应处理阶段的单点登录HTTP插件。

在所述情形2.2-2.6，单点登录HTTP插件在HTTP请求处理阶段完成所有相关处理包括将GET方式的请求转换为POST方式的请求后，让HTTP请求通过前，只需要将受安全保护的Web页面的POST参数(若有)传递到HTTP响应处理阶段的单点登录HTTP插件。

当用户浏览器被单点登录HTTP插件在HTTP响应处理阶段的所述步骤B6通过将HTTP响应的状态码修改或设置为“302”并设置HTTP响应的Location头部重定向到身份服务***的用户登录页面后，身份服务***按如下方式进行HTTP请求处理：

C1.通过HTTP请求URL的Query String中携带的Web应用***标识确定用户要访问的Web应用***是否是身份服务***信任、提供服务的***，若不是，则返回出错信息；否则，转入下一步骤；

C2.确定用户之前是否已在身份服务***完成身份鉴别，若是，则转入下一步骤；否则，将用户引导到登录页面，并基于用户主帐户对用户进行身份鉴别，鉴别成功后转入下一步骤；

C3.根据用户的主帐户及用户要访问的Web应用***，在主从帐户绑定数据库中获得用户在要访问的Web应用***中的从帐户名和口令；

C4.为用户生成一个包含其主帐户名、从帐户名及加密后的从帐户口令的安全令牌，并对相关信息进行数字签名，然后将包含安全令牌的用户身份证明信息以Form表单的方式返回到用户浏览器，并通过Form表单的自动POST提交(Submit)方式将包含安全令牌的用户身份证明信息提交到用户需要访问的Web应用***的安全令牌处理页面。

安全令牌处理页面接收到身份服务***签发并由用户浏览器通过Form表单自动POST方式提交的包含安全令牌的用户身份证明信息后，按如下方式进行处理：

D1.通过数字签名验证安全令牌是否有效，若有效，转入下一步骤；否则，返回出错提示；

D2.从安全令牌中分离出用户的主帐户名和从帐户名、口令，解密从帐户口令，然后，在HTTP响应中创建Set-Cookie头部，设置存放“用户身份信息”的Cookie，Cookie的值包含加密后的主帐户名和从帐户名、口令；

D3.将HTTP响应的状态码设置为“302”，在HTTP响应中创建一个Location头部，该头部的值设置为从Cookie中获得“最近一次要访问的受保护的URL”，然后返回HTTP响应。

当用户浏览器被单点登录HTTP插件在HTTP响应处理阶段的所述步骤B4通过将HTTP响应的状态码修改或设置为“302”并设置HTTP响应的Location头部重定向到身份服务***的用户代登录出错页面URL后，身份服务***按如下方式进行HTTP请求处理；

E1.通过HTTP请求URL中携带的Web应用***标识确定用户要访问的Web应用***是否是身份服务***信任、提供服务的***，若不是，则返回出错信息；否则，转入下一步骤；

E2.提示用户输入、提交其要访问的Web应用***中的帐户名、口令；

E3.用户提交帐户名、口令后，确定用户之前是否已登录身份服务***完成身份鉴别，若是，则转入步骤E5；否则，转入下一步骤；

E4.返回身份服务***的用户登录页面，并基于用户主帐户对用户进行身份鉴别，鉴别成功后转入下一步；

E5.基于步骤E2、E3获得的用户在Web应用***中的帐户名、口令，在主从帐户绑定数据库中，更新用户在对应的Web应用***中从帐户名、口令；

E6.为用户生成一个包含其主帐户名、从帐户名及加密后的从帐户口令的安全令牌，并对相关信息进行数字签名，然后将包含安全令牌的用户身份证明信息以Form表单的方式返回到用户浏览器，并通过Form表单的自动POST提交(Submit)方式将包含安全令牌的用户身份证明信息提交到用户需要访问的Web应用***的安全令牌处理页面。

若所述Web应用***的整个Web路径(目录)都是安全保护的路径，且无法在受安全保护的路径(目录)之中或之外设置一个非受安全保护的路径(目录)，则安全令牌处理页面不是一个实际存在的Web页面，而仅仅是一个虚拟的Web页面路径；相应地，所述单点登录HTTP插件在HTTP请求处理阶段拦截提交到安全令牌处理页面的HTTP请求，完成步骤D1所述的处理操作，然后在该HTTP请求的响应处理阶段，拦截HTTP响应，完成步骤D2、D3所述的处理操作。

若用户对所述Web应用***的访问是通过Web代理(Proxy)进行的，且由Web代理通过HTTP身份鉴别协议的代理模式对用户进行身份鉴别，且Web代理在其HTTP请求、响应处理通道中提供了HTTP插件机制，且基于该插件机制的HTTP插件能够拦截HTTP身份鉴别协议的请求、响应数据，则在做如下相应改变的情况下本发明所述的方法同样适用：

所述Web服务组件指Web代理；所述Web应用组件指Web代理之后的整个Web***(本身也包含一个或多个Web服务组件和Web应用软件)；所述Web代理和其后的整个Web***构成了所述Web应用***；所述单点登录HTTP插件部署在所述Web代理上，且在其所部署的Web代理上被配置为拦截所有的HTTP请求、响应；所述的HTTP响应状态码“401”变为“407”(提示Proxy Authentication Required)，所述HTTP响应头部WWW-Authenticate变为Proxy-Authenticate头部，所述HTTP请求头部Authorization变为Proxy-Authorization头部。

本发明的单点登录集成方法，针对的只是整个单点登录***中采用HTTP身份鉴别协议且该HTTP身份鉴别协议的使用不能替换或更改的Web应用***；对于其他的Web应用***，可采用其他的单点登录集成方法。

本发明的创新之处在于：通过单点登录HTTP插件，使得使用HTTP身份鉴别协议(如Basic，Digest，NTLM，Negotiate)对用户进行身份鉴别的Web应用***，能够在不改变身份鉴别配置且不修改应用程序的情况下实现单点登录。它解决了单点登录在实际应用集成中常见的一个技术难题。

本发明的一个特点是：用户即便在外网仍然能够访问采用Kerberos协议(即HTTP Negotiate协议且使用Kerberos进行身份鉴别)的Web应用***。

附图说明

图1为本采用本发明的单点登录***整体结构框图。

具体实施方式

下面结合附图对本发明作进一步的详细描述。

本发明是一种面向HTTP身份鉴别协议的插件式单点登录集成方法，采用本方法的单点登录***的整体结构如图1所示，包括Web服务组件、Web应用组件、单点登录HTTP插件、安全令牌处理页面、浏览器、身份服务***、主帐户数据库、主从帐户绑定数据库，其中Web服务组件、Web应用组件构成了Web应用***，而各组成部分的功能在前面的发明内容中已做了详细描述，在此不再重复。在整个单点登录***的***组件中，单点登录HTTP插件、安全令牌处理页面、身份服务***、主帐户数据库、主从帐户绑定数据库属于本发明要实现的内容，而在要实现的内容中，单点登录HTTP插件又是最关键、最主要的部分。

对于身份服务***的实现，可以采用已有的各种成熟的信息***开发技术，如J2EE技术，ASP.NET技术等；对于主帐户数据库，可以采用LDAP、关系数据库，或已有的Windows Active Directory或某个应用***帐户数据库；对于主从帐户绑定数据库，可以使用关系数据库。主从帐户绑定数据库只要保存这样一些信息：1)用户的主帐户名；2)主帐户对应的用户在每个授权访问的应用***中从帐户名及口令。

单点登录HTTP插件和安全令牌处理页面的实现，取决于其要部署的Web服务组件(但不必与Web应用组件的开发技术一样)。下面针对一些常用的Web服务组件，相应的具体实施方案描述如下。

如果Web服务组件是Windows IIS5，则单点登录HTTP插件可以基于ISAPI Filter实现，具体方案如下。

单点登录HTTP插件使用ISAPI Filter提供的基于TCP连接的数据存储位置，即ISAPI传递给ISAPI入点函数(Entry-Point Function)HttpFilterProc(...)的HTTP_FILTER_CONTEXT结构类型的输入参数pfc中的pFilterContext字段，保存“服务器端返回协议数据与参数”。单点登录HTTP插件(经入点函数GetFilterVersion(...)注册)在HTTP请求处理阶段对SF_NOTIFY_READ_RAW_DATA、SF_NOTIFY_PREPROC_HEADERS通知事件做出响应，完成相应的处理，其中：解密用户身份信息、增加Authorization请求头部的操作在响应SF_NOTIFY_PREPROC_HEADERS通知事件时进行；将GET方式的HTTP请求转换成POST方式的请求(在需要时)，并将“最近一次POST参数”中的数据作为POST参数加入到在HTTP请求主体中的操作在响应SF_NOTIFY_READ_RAW_DATA通知事件时进行；如果当前HTTP请求是POST方式(包括经GET、POST转化后的HTTP请求)，单点登录HTTP插件在响应SF_NOTIFY_READ_RAW_DATA通知事件时，将当前请求的POST参数保存在所述pFilterContext字段中，由单点登录HTTP插件在响应处理阶段获取。单点登录HTTP插件在HTTP处理阶段可通过ISAPI Filter提供的回调函数(callback function)获取HTTP请求行、请求头部的各种信息，如请求URL、Cookie等。

单点登录HTTP插件(经通知事件注册)在HTTP响应处理阶段对SF_NOTIFY_SEND_RESPONSE、SF_NOTIFY_SEND_RAW_DATA、SF_NOTIFY_END_OF_NET_SESSION通知事件做出响应，并完成相应的处理，其中：在响应SF_NOTIFY_SEND_RESPONSE、SF_NOTIFY_SEND_RAW_DATA通知事件时，完成修改HTTP响应(包括修改状态行、头部和删除响应主体)、保存用户登录信息等操作处理；在响应SF_NOTIFY_END_OF_NET_SESSION通知事件时，释放相应的***资源。实际上，单点登录HTTP插件在HTTP响应处理阶段对HTTP响应的修改，既可在SF_NOTIFY_SEND_RESPONSE和SF_NOTIFY_SEND_RAW_DATA两个通知事件点分别配合完成部分操作，也可以在SF_NOTIFY_SEND_RAW_DATA通知事件点完成全部操作，也就是说，可以不对SF_NOTIFY_SEND_RESPONSE通知事件作出响应。在HTTP响应处理阶段的单点登录HTTP插件可通过ISAPI Filter提供的回调函数获取HTTP请求行、请求头部的各种信息，如请求URL、Cookie等，以及修改响应，生成新的响应；单点登录HTTP插件在HTTP响应处理阶段，从所述pFilterContext字段中获取单点登录HTTP插件在HTTP请求处理阶段保存的POST方式的POST参数(也即采用情形2.2的方案)。

而安全令牌处理页面可以基于ISAPI Extension实现。基于ISAPIExtension的安全令牌处理页面可通过调用ISAPI Extension的回调函数处理请求、生成响应。安全令牌处理页面或者位于不受安全保护的目录(路径)，或者位于受安全保护的目录(路径)中的一个不受安全保护的子目录(子路径)。单点登录HTTP插件和安全令牌处理页面基于IIS的Administration API获取IIS的相关安全配置信息，如受保护的目录(路径)、使用的身份鉴别协议等。

如果Web服务组件是Windows IIS6，则或者将IIS6配置成IIS5工作模式，然后使用前面所述的IIS5的单点登录HTTP插件；或者，按如下方式实现单点登录HTTP插件：

单点登录HTTP插件使用与IIS5中同样的方法，保存“服务器端返回协议数据与参数”。单点登录HTTP插件在HTTP请求处理阶段只对SF_NOTIFY_PREPROC_HEADERS通知事件做出响应，除了不进行将GET方法转化成POST方法，以及将POST方法的POST参数保存在pFilterContext字段中的操作外，其他操作处理的实现与IIS5中的实现相同。单点登录HTTP插件在HTTP相应处理阶段的实现，除了不保存POST方法的POST参数外，其他操作处理的实现与IIS5中的相同。安全令牌处理页面的实现与IIS5中的相同。

当IIS6中的单点登录HTTP插件采用非IIS5实现方式时，在实际应用中，会存一点问题：由于不保存POST方法的POST参数，以及在需要时，将GET方法转化成POST方法，因此，当用户初次访问受保护页面时使用的方法是POST，则在用户完成身份鉴别后，将会以GET方法自动再次访问初次要访问的受保护的页面，这样，用户就可能得不到希望获得的结果。但这种情况，并不会造成实质性的损害：一是因为用户初次访问受保护通常采用的方法GET方法，而不是POST方法；二是因为即便初次访问受保护通常采用的方法是GET方法，Web应用***会提示用户重新提交数据，这以后的POST请求会正常提交、

如果Web服务组件是Windows IIS 7.0及之后的版本，则除了可用前面所述的IIS6的实施方案外，单点登录HTTP插件还可以基于IIS的Native-Code HTTP Module扩展功能或Managed-Code HTTP Module实现，而安全令牌处理页面可以基于ISAPI Extens ion或ASP.NET实现。

若基于Native-Code HTTP Module实现单点登录HTTP插件，则需要实现一个CHttpModule的派生类，并在该类的OnBeginRequest方法中对HTTP请求进行单点登录处理，在OnSendResponse方法中对HTTP响应进行单点登录处理。单点登录HTTP插件将“服务器端返回协议数据与参数”数据保存在Native-Code HTTP Module的IHttpConnection对象的基于TCP连接的IHttpModuleContextContainer对象中。单点登录HTTP插件，在HTTP响应处理阶段能够直接读取对应HTTP请求的请求行、请求头部和主体中的数据(包括POST参数)。

基于Managed-Code HTTP Module实现单点登录HTTP插件的方法与基于Native-Code HTTP Module实现单点登录HTTP插件的方法类似。关于如何通过Native-Code HTTP Module或Managed-Code HTTP Module开发IIS扩展模块，可参见微软的MSDN(Microsoft Development Network)。

如果Web应用***的Web服务组件是JSP/Servlet Web Container(包括J2EE Application Server的Web Container)，则单点登录HTTP插件可基于Servlet Filter(这是所有Web容器都有的)、AuthenticationFilter(如WebLogic)、Web容器的Valve(如Tomcat)或其他类似的HTTP插件机制(如WebSphere的TAI等)，具体怎样实施以及能否实施，一是取决于Web容器提供了怎样的插件机制，二是看这个插件机制是否能够满足所述的单点登录处理需求，如能够拦截HTTP身份鉴别协议的HTTP请求与响应，能够通过一定的方式对HTTP请求与响应进行修改。比如，若在某个Web Container上部署的HTTP身份鉴别协议的HTTP请求、响应能够被Servlet Filter、Authentication Filter或Valve拦截，则能够基于Servlet Filter、Authentication Filter或Valve实现单点登录HTTP插件。对于JSP/Servlet Web Conta iner提供的HTTP插件机制，单点登录HTTP插件在HTTP响应处理阶段通常是能够直接读取HTTP请求的所有数据。对应JSP/Servlet Web Container，安全令牌处理页面可以基于JSP/Servlet实现。对于安全配置信息的获取，或者采用直接读取配置文件的方法，或者，通过Web容器提供的接口获取。

如果Web应用***的Web服务组件是Apache HTTP Server、IBM HTTPWeb Server，则可以基于Apache Hook和Filter开发单点登录HTTP插件，其中，HTTP请求处理阶段的功能基于Apache Hook实现，而HTTP响应处理阶段的功能基于Apache Hook和Filter实现，其中，Apache Hook处理头部，Apache Filter处理响应内容。“服务器端返回协议数据与参数”的存储，使用Apache提供的基于TCP连接的数据存储位置。对于Apache Filter而言，单点登录HTTP插件在HTTP响应处理阶段能够直接读取HTTP请求的所有数据。安全令牌处理页面可以基于Apache ContentHandler开发，或者基于相应Web应用组件的页面技术(如Perl、Python)开发。对Apache HTTP Server、IBM HTTP Web Server安全配置信息的获取，或者采用直接读取配置文件的方法，或者，通过Apache提供的接口变量获取，如request_rec结构中的目录配置信息，及request_rec结构中的conn_rec结构中的服务器配置信息。

对于其他的Web服务组件，如Domino Web Server等，都有类似的HTTP插件机制，基于这些Web平台的单点登录HTTP插件和安全令牌处理页面的具体实施方法与前面所述的具体实施方法类似。

另外，对于所涉及的单点登录协议及安全令牌的具体实施，单点登录协议和安全令牌可以采用标准协议，如SAML、WS-FPRP及其，以及相应的SAML断言、WS-Security Token作为证明用户身份的安全令牌；或者，使用自定义的单点登录协议和自定义的安全令牌，只要与本发明所述的交互和处理过程一致即可。若单点登录协议和安全令牌是基于XML(eXtensible Markup Language)的，如SAML、WS-FPRP，则对XML数据的处理可以使用各种成熟的动态库、类库(如Windows CommunicationFoundation类库)、API(如Java API for XML Processing，JAXP)等。对于涉及数据加密、数字签名的实现，可以使用各种成熟的动态库(如OpenSSL)、类库(如Java Cryptography Extension)、API(如WindowsCryptoAPI等)。

本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims

1.一种面向HTTP身份鉴别协议的插件式单点登录集成方法，所述方法的单点登录***包括Web服务组件、Web应用组件、单点登录HTTP插件、安全令牌处理页面、浏览器、身份服务***、主帐户数据库、主从帐户绑定数据库，其特征在于：

Web服务组件：为Web应用组件提供HTTP请求接收、响应传送功能，及其他相关的支撑功能，包括：接收用户浏览器提交的HTTP格式的服务请求，进行相应预处理后提交给Web应用组件进行处理，之后，将Web应用组件返回的处理结果，以HTTP响应的格式传送到用户浏览器；基于相应的安全配置，对用户进行身份鉴别、访问控制；维护用户的HTTP会话；

Web应用组件：向用户提供特定应用服务的功能软件，通过相应的Web服务组件，接收用户通过浏览器提交的应用服务请求，完成相应处理后将处理结果通过Web服务组件返回到用户浏览器；所述Web应用组件和对应的所述Web服务组件构成了Web应用***；所述Web应用***至少有一个；所述Web应用***通过一定的方式对用户进行身份鉴别，其中部分Web应用***通过Web服务组件采用标准HTTP身份鉴别协议对用户进行身份鉴别；用户访问所述Web应用***的受保护页面或资源，需要使用其在对应Web应用***中的相应帐户完成身份鉴别后才能进行；所述标准HTTP身份鉴别协议包括但不限于HTTP Basic、Digest、NTLM、Negotiate面向Web的身份鉴别协议；

单点登录HTTP插件：基于Web服务组件提供的扩展机制，***到采用HTTP身份鉴别协议的Web应用***的Web服务组件的HTTP请求、响应处理通道中实现单点登录功能的软件组件；所述单点登录HTTP插件采用的插件机制能够拦截HTTP身份鉴别协议的请求、响应数据；所述单点登录HTTP插件在其所部署的Web服务组件上被配置为拦截所有的HTTP请求、响应，或者被配置为拦截所有提交到受安全保护的目录或路径的HTTP请求及其响应和提交到安全令牌处理页面所在目录或路径的HTTP请求及其响应；所述单点登录HTTP插件有相应的配置信息，用于设置与单点登录有关的信息，可选地，配置信息中包含如下内容：1)单点登录HTTP插件所在的Web应用***中哪些Web页面目录或路径是受安全保护的；2)受安全保护的目录或路径所采用的HTTP身份鉴别协议是哪个或哪些，及相关的身份鉴别协议参数；3)所使用的HTTP身份鉴别的具体实施是否允许客户端主动发出鉴别和授权请求，即是否允许客户端浏览器在接收到响应状态码是“401”且包含WWW-Authenticate头部的HTTP响应之前，主动提交包含Authorization头部的HTTP请求，请求服务器端对客户端用户进行身份鉴别和资源访问进行授权；

安全令牌处理页面：在采用HTTP身份鉴别协议的Web应用***的Web服务组件上部署的专门处理身份服务***签发的证明用户身份的安全令牌的Web页面；所述安全令牌处理页面部署在Web服务组的非安全保护路径或目录，即通过浏览器提交HTTP请求到该处理页面的用户无需完成身份鉴别；

浏览器：用户与Web应用***交互的客户端，通过HTTP协议向Web服务组件传送HTTP请求，接收Web服务组件返回的HTTP响应并展现响应的内容；

身份服务***：提供用户在线身份鉴别服务的***，基于用户身份凭证对用户进行在线身份鉴别，通过相应的单点登录协议并借助浏览器向Web应用***传送证明用户身份的安全令牌；所述身份服务***签发的所述安全令牌的格式依赖于使用的单点登录协议，可以是SAML断言，或者WS-Federation安全令牌，或者自定义的安全令牌；所述身份服务***通过数字签名保证所签发的安全令牌的原发性、完整性；

主帐户数据库：存放用户登录身份服务***的主帐户信息，包括主帐户的帐户名、口令，或主帐户对应的数据证书的相关信息；所述主帐户指用户在所述身份服务***进行身份鉴别时使用的帐户；所述主帐户数据库可以是独立的帐户数据库，也可以是某个应用***的帐户数据库；

主从帐户绑定数据库：保存用户主帐户与用户在Web应用***的从帐户的对应或绑定关系，以及从帐户的口令；所述从帐户即指用户在某个特定Web应用***的相应帐户；用户的主帐户与其在某个Web应用***中的从帐户可以是同一个，也可以不同。

2.根据权利要求1所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：所述单点登录HTTP插件保存有每个用户的身份鉴别相关信息，称为用户登录信息；所述用户登录信息包括：

1)身份鉴别协议：Web服务组件当前使用的、用于对用户进行身份鉴别的HTTP身份鉴别协议；

2)服务器端返回协议数据与参数：Web服务组件使用HTTP身份鉴别协议对客户端用户进行身份鉴别时，通过WWW-Authentucate响应头部返回到客户端浏览器的协议数据和参数，其中包括HTTP身份鉴别协议指示；

3)最近一次要访问的受保护的URL：用户在Web应用***完成身份鉴别前，使用浏览器最近一次期望访问的受安全保护的Web页面的URL；

4)最近一次POST参数：用户在Web应用***完成身份鉴别前，若使用浏览器最近一次访问受安全保护的Web页面时使用的HTTP请求方法是POST，则所述最近一次POST参数的值是该HTTP请求对应的POST参数，否则其值是空；

5)用户身份信息：标识和鉴别用户的信息，包括用户的主帐户名、从帐户名及从帐户口令；

所述各种用户登录信息以字符串的形式保存，对于非字符数据，则以Base64编码后的数据格式保存；所述用户身份信息被加密且具有时效性，以防止泄露和重播攻击；所述身份鉴别协议、最近一次要访问的受保护的URL、最近一次POST参数以及用户身份信息保存在Cookie中，且该Cookie的作用路径需要同时包含Web服务组件设置的受安全保护的路径和安全令牌处理页面所在的非受安全保护的路径，即无论在受安全保护的路径中的Web页面还是非受安全保护的安全令牌处理页面都能查看得到该Cookie，或者，将有关的用户登录信息同时保存在两个不同的Cookie中，其中一个的作用路径是受安全保护的路径，另一是非受安全保护的安全令牌处理页面所在的路径；

所述单点登录HTTP插件根据所述Web服务组件提供给HTTP插件的数据存储机制的不同，依如下优先顺序，分别按如下方法对所述服务器端返回协议数据与参数进行存储：

情形1：若Web服务组件向HTTP插件提供了基于TCP连接的数据存储位置，则单点登录HTTP插件将所述服务器端返回协议数据与参数保存在基于TCP连接的数据存储位置；或者，

情形2：若Web服务组向HTTP插件提供了基于HTTP会话的数据存储位置，则单点登录HTTP插件将所述服务器端返回协议数据与参数保存在基于HTTP会话的数据存储位置；或者，

情形3：若单点登录HTTP插件有定制开发的基于TCP连接或HTTP会话的数据存储位置，则单点登录HTTP插件将所述服务器端返回协议数据与参数保存在定制开发的基于TCP连接或HTTP会话的数据存储位置；

否则，

情形4：单点登录HTTP插件将所有用户登录信息通过Cookie保存在客户端浏览器中；

所述基于TCP连接的数据存储位置，指Web服务组件向HTTP插件提供的数据存储位置与HTTP数据传输的TCP连接相关联，TCP连接不同，则提供的数据存储位置不同；所述基于HTTP会话的数据存储位置，指只要是同一HTTP会话，即便TCP连接不同，数据存储位置仍然相同，即数据存储位置与TCP连接无关，仅与特定的HTTP用户会话有关；

针对所述服务器端返回协议数据与参数，在单点登录HTTP插件的配置信息中必须设定如下内容：对于Web应用***使用的每一个HTTP身份鉴别协议，在用户身份鉴别成功后，所述服务器端返回协议数据与参数的值的相应设置方式，设置方式的选项是：保持不变，设置为空，或设置为一个空格。

3.根据权利要求1或2所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：当用户使用浏览器访问某个使用HTTP身份鉴别协议对用户进行身份鉴别的Web应用***时，所述单点登录HTTP插件拦截HTTP请求，然后按如下方法对HTTP请求进行处理：

步骤1：根据相关配置信息，确定当前HTTP请求URL对应的是受安全保护的页面还是非受安全保护的页面，若是受安全保护的，则转入步骤2；否则，让该HTTP请求通过，完成本次HTTP请求处理；

步骤2：检查所述服务器端返回协议数据与参数，若其没有设置或其值为空，则转入步骤3；否则，转入步骤6；

步骤3：检查所述用户身份信息，若其存在且有效，则转入步骤4；否则，让HTTP请求通过，完成本次HTTP请求处理；

步骤4：从Cookie中保存的所述身份鉴别协议信息中得到Web应用***当前使用的HTTP身份鉴别协议，然后，根据相关配置信息确定所采用的HTTP身份鉴别协议是否允许客户端主动发出鉴别和授权请求，若不允许，则让HTTP请求通过，完成本次HTTP请求处理；否则，转入步骤5；

步骤5：从相关配置信息中获得HTTP身份鉴别协议所需的数据与参数，依HTTP身份鉴别协议，生成客户端初次提交的包含身份鉴别数据的Authorization请求头部，并将生成的头部加入到拦截的HTTP请求中，然后，让修改后的HTTP请求通过，完成本次HTTP请求处理；

步骤6：若所述服务器端返回协议数据与参数的值为一个空格，则让该HTTP请求通过，完成本次HTTP请求处理；否则，转入步骤7；

步骤7：根据所述服务器端返回协议数据与参数中的HTTP身份鉴别协议及其他数据，生成身份鉴别协议在当前协议阶段的Authorization请求头部，并将生成的头部加入到拦截的HTTP请求中，然后，让修改后的HTTP请求通过，完成本次HTTP请求处理；

所述步骤1、4、5中所述相关配置信息指Web服务组件和/或单点登录HTTP插件的与安全访问控制、身份鉴别、单点登录有关的配置信息；

所述HTTP身份鉴别协议的身份鉴别过程需要客户端与服务器端通过HTTP请求、响应进行多个步骤或阶段的交互，而所述步骤7中所述的HTTP身份鉴别协议的所述当前协议阶段是指客户端根据身份鉴别协议的要求当前提交身份鉴别请求信息所处的步骤或阶段；

所述单点登录HTTP插件在HTTP请求处理阶段完成所述步骤2-7的相关处理后，让HTTP请求通过前，需进行如下处理操作：若当前HTTP请求的URL与所述最近一次要访问的受保护的URL中保存的URL相同且当前HTTP请求的方法是GET且所述最近一次POST参数的值非空，则将当前HTTP请求的方法改为POST，将所述最近一次POST参数中的数据作为POST参数添加到当前HTTP请求中；

如果基于Web服务组件提供的HTTP插件机制，所述单点登录HTTP插件在HTTP响应处理阶段无法获得当前HTTP响应对应的HTTP请求的请求行、头部或主体，则所述单点登录HTTP插件在HTTP请求处理阶段的所述步骤1-7完成所有相关处理包括将GET方式的请求转换为POST方式的请求后，让HTTP请求通过前，依如下优先顺序，根据如下不同情形将当前HTTP请求的所述相关数据传送到HTTP响应处理阶段的单点登录HTTP插件：

情形A：若Web服务组件提供了基于TCP连接的数据存储位置，则将当前HTTP请求的相关数据保存到基于TCP连接的数据存储位置，由单点登录HTTP插件在HTTP响应处理阶段获取；或者，

情形B：若Web服务组件提供了基于HTTP会话的数据存储位置，则将当前HTTP请求的相关数据保存到基于HTTP会话的数据存储位置，由单点登录HTTP插件在HTTP响应处理阶段获取；或者，

情形C：若在HTTP请求处理阶段能直接设置HTTP响应的头部，则将当前HTTP请求的相关数据，通过自定义的HTTP响应头部传递到HTTP响应处理阶段的单点登录HTTP插件获取，单点登录HTTP插件在HTTP响应处理阶段通过自定义头部获取相关数据后，删除该自定义头部；或者，

情形D：若单点登录HTTP插件有定制开发的基于TCP连接或会话的数据存储位置，则将当前HTTP请求的相关数据保存到定制开发的基于TCP连接或会话的数据存储位置，由单点登录HTTP插件在HTTP响应处理阶段获取；

否则，

情形E：通过线程机制将当前HTTP请求的相关数据传送到HTTP响应处理阶段的单点登录HTTP插件；

所述单点登录HTTP插件只需要将受安全保护的Web页面的POST参数传递到HTTP响应处理阶段的单点登录HTTP插件。

4.根据权利要求3所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：所述的HTTP请求处理过程的所述步骤5、7，所述单点登录HTTP插件根据HTTP身份鉴别协议的不同，分别按如下方式，产生HTTP身份鉴别协议在对应协议阶段的相应Authorization请求头部：

情形I：若身份鉴别协议协议是HTTP Basic，则从Cookie中解密所述用户身份信息数据、获取用户在Web应用***中的从帐户名、口令，然后按HTTP Basic协议的要求，形成Authorization头部；或者，

情形II：若身份鉴别协议是HTTP Digest，则从Cookie中解密所述用户身份信息数据、获取用户在Web应用***中的从帐户名、口令，然后根据所述服务器端返回协议数据与参数中的内容，以及HTTPDigest协议的要求，形成Authorization头部；或者，

情形III：若身份鉴别协议是HTTP NTLM，且所述服务器端返回协议数据与参数为未设置或者其值为空或者其值为进行身份鉴别的初次提示，则产生NTLM Type 1数据，然后按HTTP NTLM协议要求，形成Authorization头部的数据；否则，先从Cookie中解密所述用户身份信息数据、获取用户在Web应用***中的从帐户名、口令，然后，利用该从帐户名、口令以及保存在所述服务器端返回协议数据与参数中的NTLM Type 2数据，产生NTLM Type 3数据，然后按HTTP NTLM协议要求，形成Authorization头部；或者，

情形IV：若身份鉴别协议是HTTP Negotiate，则先从Cookie中解密所述用户身份信息数据、获取用户在Web应用***中的从帐户名、口令，也即用户在Kerberos***中的帐户名、口令，然后利用该从帐户名、口令调用相应的Kerberos接口，连接Kerberos KDC的身份鉴别服务器，获得用户的TGT，然后再使用该TGT调用GSS-API或相当的接口，获得用户访问Web应用***的Spnego Token，然后，利用获得的Spnego Token，按HTTP Negotiate协议要求，形成Authorization头部；或者，

情形V：若是其他有效的HTTP身份鉴别协议，则按相关协议进行处理；

否则，将用户浏览器引导到出错页面。

5.根据权利要求1或2所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：所述单点登录HTTP插件拦截HTTP响应后，按如下方式对HTTP响应进行处理：

第1步：检查HTTP响应的响应状态及头部，如果响应状态是“401”且包含WWW-Authenticate响应头部，则转入第2步；否则，转入第7步；

第2步：检查所述用户身份信息，若其存在且有效，则转入第3步；否则，转入第6步；

第3步：检查当前HTTP响应的WWW-Authenticate头部的值，若是进行身份鉴别的初始提示且响应对应的HTTP请求包含有Authorization头部且该Authorization头部的值是所述WWW-Authenticate头部中指示的HTTP身份鉴别协议对应的身份凭证数据或者经身份凭证数据密码运算后的数据，则转入第4步；否则，转入第5步；

第4步：将所述用户身份信息设置为空，将所述服务器端返回协议数据与参数的值设置为HTTP响应的WWW-Authenticate头部的值，获取当前HTTP响应对应的HTTP请求URL，将其作为所述最近一次要访问的受保护的URL的值保存；若当前HTTP响应对应的HTTP请求的方法是POST，则将该请求对应的POST参数保存到所述最近一次POST参数中，否则将所述最近一次POST参数的值设置为空；然后，将HTTP响应的响应状态码修改为302，将WWW-Authenticate响应头部去掉，将可能包含的HTTP响应主体及响应主体长度指示去掉，在响应中加入Location头部，将其值设置为身份服务***的用户代登录出错页面URL，该URL通过Query String附加了单点登录HTTP插件所在的Web应用***的***标识，最后，让修改后的HTTP响应通过，完成本次HTTP响应的处理；

第5步：将所述服务器端返回协议数据与参数的值设置为HTTP响应的WWW-Authenticate头部的值，获取当前HTTP响应对应的HTTP请求URL并将其作为所述最近一次要访问的受保护的URL的值保存；若当前HTTP响应对应的HTTP请求的方法是POST，则将该请求对应的POST参数保存到所述最近一次POST参数中，否则将所述最近一次POST参数的值设置为空；然后，将HTTP响应的响应状态码修改为302，将WWW-Authenticate响应头部去掉，将可能包含的HTTP响应主体及响应主体长度指示去掉，在响应中加入Location头部，将其值设置为当前HTTP响应对应的HTTP请求URL，然后，让修改后的HTTP响应通过，完成本次HTTP响应的处理；

第6步：将WWW-Authenticate头部中指示的HTTP身份鉴别协议保存到所述用户登录信息的所述身份鉴别协议中，将所述服务器端返回协议数据与参数的值设置为HTTP响应的WWW-Authenticate头部的值，将所述用户身份信息设置为空，获取当前HTTP响应对应的HTTP请求URL，将其作为所述最近一次要访问的受保护的URL的值保存；若当前HTTP响应对应的HTTP请求的方法是POST，则将该请求对应的POST参数保存到所述最近一次POST参数中，否则将所述最近一次POST参数的值设置为空；然后，将HTTP响应的响应状态码修改为302，将HTTP响应中的WWW-Authenticate响应头部去掉，将可能包含的HTTP响应主体及响应主体长度指示去掉，在响应头部中加入Location头部，其值为身份服务***的用户登录页面URL，该URL通过Query String附加了单点登录HTTP插件所在的Web应用***的***标识，最后，让修改后的HTTP响应通过，完成本次HTTP响应的处理；

第7步：获取当前HTTP响应对应的HTTP请求URL，根据相关配置信息确定该HTTP请求URL是否对应受安全保护的Web页面，若不是，则让HTTP响应通过，完成本次HTTP响应的处理；否则，转入第8步；

第8步：若HTTP响应中包含有WWW-Authenticate响应头部，则将WWW-Authenticate响应头部去掉；若当前HTTP响应对应的HTTP请求的URL与所述最近一次要访问的受保护的URL相同，则将所述最近一次要访问的受保护的URL和所述最近一次POST参数的值设置为空；

第9步：根据单点登录HTTP插件的配置信息中针对当前所使用的HTTP身份鉴别协议所设定的、在用户身份鉴别成功后的所述服务器端返回协议数据与参数的值的设置方式，设置所述服务器端返回协议数据与参数的值，然后让修改后的HTTP响应通过，完成本次HTTP响应的处理；

所述第3步中所述的WWW-Authenticate头部的值是进行身份鉴别的初始提示是指该头部的值是用户完成身份鉴别前，初次访问受保护的页面时，Web服务器端初次返回的要求进行身份鉴别的WWW-Authenticate响应头部的数据；

所述第3步中所述的身份凭证数据，是指能证明用户身份的电子数据，包括帐户名、口令，以及包含身份确认信息安全令牌；所述经身份凭证数据密码运算后的数据，是指经身份凭证通过一定的密码运算后得到数据；

若单点登录HTTP插件拦截的HTTP响应包含多个WWW-Authenticate头部，则在所述第3步中所用的WWW-Authenticate头部和所述第4、5、6步中所用的、其值被保存到所述服务器端返回协议数据与参数中的WWW-Authenticate头部以及所述第6步中保存所述身份鉴别协议所使用的WWW-Authenticate头部，是一个根据预定的规则选择的对应于某个HTTP身份鉴别协议的WWW-Authenticate头部，而在所述第4、5、6、8步中删除的WWW-Authenticate头部包括所有的WWW-Authenticate头部；

所述第4、5、6、9步中所述的修改后的HTTP响应从数据结构上来说既可以是在原HTTP响应数据结构上直接修改后得到的HTTP响应，也可以是在一个新的HTTP响应数据结构上新生成的HTTP响应；

所述第7步中所述相关配置信息指Web服务组件和/或单点登录HTTP插件的与安全访问控制、身份鉴别、单点登录有关的配置信息。

6.根据权利要求5所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：所述的HTTP响应处理过程的所述第6步通过将HTTP响应的状态码修改或设置为302并设置HTTP响应的Location头部将浏览器重定向到身份服务***的用户登录页面后，身份服务***按如下方式进行HTTP请求处理：

步骤一：通过HTTP请求URL的Query String中携带的Web应用***标识确定用户要访问的Web应用***是否是身份服务***信任、提供服务的***，若不是，则返回出错信息；否则，转入步骤二；

步骤二：确定用户之前是否已在身份服务***完成身份鉴别，若是，则转入下一步骤；否则，将用户引导到登录页面，并基于用户主帐户对用户进行身份鉴别，鉴别成功后转入步骤三；

步骤三：根据用户的主帐户及用户要访问的Web应用***，在主从帐户绑定数据库中获得用户在要访问的Web应用***中的从帐户名和口令；

步骤四：为用户生成一个包含其主帐户名、从帐户名及加密后的从帐户口令的安全令牌，并对相关信息进行数字签名，然后将包含安全令牌的用户身份证明信息以Form表单的方式返回到用户浏览器，并通过Form表单的自动POST提交方式将包含安全令牌的用户身份证明信息提交到用户需要访问的Web应用***的安全令牌处理页面。

7.根据权利要求1或2或6所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：所述安全令牌处理页面接收到所述身份服务***签发并由用户浏览器通过Form表单自动POST方式提交的包含安全令牌的用户身份证明信息后，按如下方式进行处理：

第I步：通过数字签名验证安全令牌是否有效，若有效，转入第II步；否则，返回出错提示；

第II步：从安全令牌中分离出用户的主帐户名和从帐户名、口令，解密从帐户口令，然后，在HTTP响应中创建Set-Cookie头部，设置存放所述用户身份信息的Cookie，Cookie的值包含加密后的用户主帐户名和从帐户名、口令；

第III步：将HTTP响应的状态码设置为302，在HTTP响应中创建一个Location头部，该头部的值设置为从Cookie中获得所述最近一次要访问的受保护的URL，然后返回HTTP响应。

8.根据权利要求5所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：所述的HTTP响应处理阶段的所述第4步通过将HTTP响应的状态码修改或设置为302并设置HTTP响应的Location头部将浏览器重定向到身份服务***的用户代登录出错页面URL后，身份服务***按如下方式进行HTTP请求处理：

第一步：通过HTTP请求URL中携带的Web应用***标识确定用户要访问的Web应用***是否是身份服务***信任、提供服务的***，若不是，则返回出错信息；否则，转入第二步；

第二步：提示用户输入、提交其要访问的Web应用***中的帐户名、口令；

第三步：用户提交帐户名、口令后，确定用户之前是否已登录身份服务***完成身份鉴别，若是，则转入第五步；否则，转入第四步；

第四步：返回身份服务***的用户登录页面，并基于用户主帐户对用户进行身份鉴别，鉴别成功后转入第五步；

第五步：基于第二、三步获得的用户在Web应用***中的帐户名、口令，在主从帐户绑定数据库中，更新用户在对应的Web应用***中从帐户名、口令；

第六步：为用户生成一个包含其主帐户名、从帐户名及加密后的从帐户口令的安全令牌，并对相关信息进行数字签名，然后将包含安全令牌的用户身份证明信息以Form表单的方式返回到用户浏览器，并通过Form表单的自动POST提交方式将包含安全令牌的用户身份证明信息提交到用户需要访问的Web应用***的安全令牌处理页面。

9.根据权利要求7所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：若所述Web应用***的整个Web路径或目录都是安全保护的路径或路径，且无法在受安全保护的路径或目录之中或之外设置一个非受安全保护的路径或目录，则安全令牌处理页不是一个实际存在的Web页面，而仅仅是一个虚拟的Web页面路径；相应地，所述单点登录HTTP插件在HTTP请求处理阶段拦截提交到安全令牌处理页面的HTTP请求，完成所述第I步所述的处理操作，然后在该HTTP请求的响应处理阶段，拦截HTTP响应，完成所述第II、III步所述的处理操作。

10.根据权利要求1、3-5中任一项所述的面向HTTP身份鉴别协议的插件式单点登录集成方法，其特征在于：若用户对所述Web应用***的访问是通过Web代理进行的，且由Web代理通过HTTP身份鉴别协议的代理模式对用户进行身份鉴别，且Web代理在其HTTP请求、响应处理通道中提供了HTTP插件机制，且基于该插件机制的HTTP插件能够拦截HTTP身份鉴别协议的请求、响应数据，则在做如下相应改变的情况下本发明所述的方法同样适用：

所述Web服务组件指Web代理；所述Web应用组件指Web代理之后的整个Web***；所述Web代理和其后的整个Web***构成了所述Web应用***；所述单点登录HTTP插件部署在所述Web代理上，且在其所部署的Web代理上被配置为拦截所有的HTTP请求、响应；所述HTTP响应状态码“401”变为“407”；所述HTTP响应头部WWW-Authenticate变为Proxy-Authenticate头部；所述HTTP请求头部Authorization变为Proxy-Authorization头部。