一种Session ID全透明传递的ISAPI访问控制系统

摘要

本发明涉及一种具有Session全透明传递的ISAPI访问控制系统，它能在Web系统不参与、不修改以及不使用Cookie的情况下，实现用户Session维护及Session ID的传递，为部属在IIS服务器上的Web应用提供用户身份鉴别和访问控制功能。它包括四个组成部分：ISAPI访问控制过滤器，Session维护引擎，授权决策引擎，身份与权限管理系统。本发明成功解决了在ISAPI访问控制过滤器重写响应消息中的URL链接加入Session ID信息时所涉及的关键技术问题，如在过滤器回调函数间传递相关信息，正确地修改响应消息数据块中的长度指示等。

说明书

技术领域

本发明属于网络信息安全技术领域，是一种基于ISAPI过滤器的访问控制系统，它以一种对Web应用系统透明的方式，为部署在IIS服务器上的Web应用提供访问控制功能，尤其是在不依赖于Web系统(Web容器或Web应用)和不使用cookie的情况下实现Session ID的透明传递。

背景技术

对于部署在互联网上的许多Web应用服务系统，用户身份鉴别(Authentication)和访问控制(Access Control)是必不可少的安全功能。身份鉴别，即知道对方是谁，确认对方是其声称的人(或实体)；而访问进行控制，即根据用户的权限和访问控制策略在线决定是否允许用户访问某项资源并进行有关操作，这些资源可以是主机、系统目录、文件，或某项服务功能，如交易、支付等。访问控制又称为访问授权(Authorization)，包括权限管理(Privilege Management)、授权决策(Authorization Decision)和授权实施(Authorization Enforcement)三部分。身份鉴别和访问控制是密切相关的。

对于现有的已部署的许多Web应用系统，可能存在这样的情形：在系统开发之初未考虑访问控制功能，或者已实施的访问控制功能不完善，目前需要加入或完善其访问控制功能。加入或完善所需的访问控制功能当然可以通过修改应用系统来实现，但这种做法存在如下问题：

(1)修改工作量可能很大，动一发而牵全身，可能会涉及到修改整个系统；

(2)修改、开发成本高；

(3)原系统开发文档、开发商已无法找到，而系统又很复杂；

(4)对于基于不同Web技术开发的应用系统，如ASP、ASP.NET，、JSP/Servlet、CGI、PHP等，需要采用的不同实现方法；

(5)有可能需要长时间地中止服务，这在许多情况是不允许的。

而基于ISAPI过滤器的访问控制技术，能在不修改Web应用系统的情况下，加入其所需的访问控制功能，因而具有很高的实际应用价值。

ISAPI(Internet Server Application Programming Interface)是微软公司IIS(Internet Information Server)Web服务器上的一个API标准，基于ISAPI的DLL被Web服务器程序加载到自己的进程空间，并和Web服务器程序共用一个地址空间。基于ISAPI的DLL又分为扩展(extension)和过滤器(filter)两类。

ISAPI过滤器(又称为插件plug-in)位于客户端浏览器与Web服务器的网络连接之间，可在HTTP请求/响应处理的不同阶段对请求/响应进行拦截和处理。对HTTP请求/响应处理的不同阶段，ISAPI用不同的事件标识，通过注册相应的事件通知，如SF_NOTIFY_PREPROC_HEADERS(通知预处理题头)，SF_NOTIFY_SEND_RAW_DATA(通知发送原数据)等，Web服务器在不同阶段调用ISAPI过滤器的事件处理回调函数，对HTTP请求或响应进行处理，如读取HTTP请求中的数据，处理题头(Header)，鉴别用户，进行URL修改，返回数据，记录日志等。

ISAPI过滤器有两个入口回调函数，分别是注册函数GetFilterVersion()和过滤器处理函数HttpFilterProc()，其接口定义如下，

BOOL WINAPI GetFilterVersion(PHTTP_FILTER_VERSION pVer)；

DWORD WINAPI HttpFilterProc(PHTTP_FILTER_CONTEXT pfc，DWORDNotificationType，LPVOID pvNotification)；

PHTTP_FILTER_VERSION和PHTTP_FILTER_CONTEXT由ISAPI定义。

这两个入口函数，前者由Web服务器初始化时调用，它返回过滤器支持的ISAPI的版本号，并对每个要处理的事件通知进行注册；后者负责对一系列触发的事件通知进行处理。一般地，对于每个触发事件通知，HttpFilterProc()会再调用对应的回调函数进行处理，如对SF_NOTIFY_PREPROC_HEADERS事件通知调用回调函数OnPreprocHeaders()进行处理，对SF_NOTIFY_SEND_RAW_DATA事件通知调用OnSendRawData()回调函数进行处理，对SF_NOTIFY_END_OF_NET_SESSION事件通知调用回调函数OnEndOfNetSession()进行处理等。

利用ISAPI过滤器的功能特点，可开发一个ISAPI访问控制过滤器，进行用户身份鉴别与访问控制，并在此基础上扩展其它功能模块(如权限管理系统等)，构成一个完整的基于ISAPI过滤器的访问控制系统。

基于ISAPI过滤器的访问控制系统要实现其功能，需在线维护用户的状态信息，如用户的身份ID、组ID、访问时间等信息，并能在线标识、跟踪用户及将用户与其状态信息关联起来。在Web技术中，用户的在线状态信息称为Session，每个用户的状态信息通常保存在一个Session对象中；同时，每个在线用户被分配一个临时Session ID(Session标识)，用于标识、区分不同用户，及将用户同其Session对象关联起来。这里，为每个在线用户产生和管理Session对象和Session ID的过程，称为Session维护。

基于ISAPI过滤器的访问控制系统要能工作，仅有Session维护是不够的，还需通过一定方式将用户的Session ID传送到其客户端浏览器，并使得用户浏览器在每次提交HTTP服务请求时，请求中包含有该用户的Session ID，以便ISAPI访问控制过滤器能够识别、区分不同用户，并将用户同其Session对象关联起来。这个将Session ID传送到客户端，并由浏览器每次提交请求时包含Session ID的过程，称为Session ID传递。

基于ISAPI过滤器的访问控制系统要实现Session维护和Session ID传递，有两种途径可供选择，一是依赖于Web系统(应用系统或Web容器)来维护Session和传递Session ID，然后由ISAPI访问控制过滤器去设法跟踪、识别；二是由访问控制系统自己来维护Session和传递SessionID。对于前一种途径，在实际应用中，需要基于ISAPI过滤器的访问控制系统与应用系统的耦合、配合，这在有些情况下是不方便的，甚至是不可行的，即这种途径不能完全做到Web系统与访问控制系统间的相互透明。对于后一种途径，关键在如何实现Session ID传递。

Web技术中目前常用的Session ID传递机制有cookie和URL重写两种。Cookie机制简单，Web系统(应用系统或Web容器)只需在初次响应用户HTTP请求时通过set-cookie题头(header)将用户Session ID设置为cookie即可。Cookie机制的缺点是，当客户端浏览器禁用cookie时无法工作，即对客户端不完全透明。URL重写是由Web系统对HTTP响应内容中指向本地的URL链接进行重写，在URL中增加或扩充Querystring，使之包含？...SessionID＝XXXXX...形式的信息，这里XXXXX是用户的Session ID值(当原URL已有Query string时就扩充)。

基于ISAPI过滤器的访问控制系统的Session ID传递既可以采用cookie，也可以采用URL重写，采用cookie机制存在如前所述对客户端不完全透明、被禁用的问题；采用URL重写，即由ISAPI访问控制过滤器拦截响应消息对响应内容中的指向本地的URL链接进行重写，存在一些技术难点。但是，采用URL重写来传递Session ID具有独特的优点，这就是对Web应用系统和客户端完全透明，既不依赖于Web应用系统，也不用担心客户端浏览器禁用Cookie。

发明内容

本发明的目的是提供一种具有Session ID全透明传递机制的ISAPI访问控制系统，它以ISAPI过滤器技术为基础，能以一种对Web应用系统和客户端浏览器完全透明的方式，为部署在IIS服务器上的Web应用提供访问控制功能。本发明解决了由ISAPI访问控制过滤器进行URL重写传递Session ID存在的关键技术问题。

本发明的ISAPI访问控制系统包括如下四个组成部分：

ISAPI访问控制过滤器(简称过滤器)：它是一个由IIS服务器加载的ISAPI过滤器DLL，位于用户客户端(浏览器)与Web应用系统之间，负责用户身份鉴别和访问控制授权实施(访问控制执行)。当用户通过浏览器访问部署在IIS服务器上的Web应用系统时，过滤器拦截用户请求，通过对请求信息进行分析和处理，实现对用户的身份鉴别和访问控制。当Web服务器返回响应结果时，过滤器再次拦截响应信息，并通过重写响应信息中指向本地的URL链接加入用户Session ID，实现用户SessionID的透明传递。

Session维护引擎：负责为每一个在线访问Web服务的用户创建一个保存状态的Session对象，产生相应的Session ID，从身份与权限管理系统获取用户身份信息填充Session对象，将用户其他状态信息保存到Session对象，提供Session信息、身份信息的查询，删除超时不用的Session对象等；

授权决策引擎：根据用户的身份和权限信息及资源访问控制策略，对用户访问资源的请求进行授权决策；

身份与权限管理系统：保存和维护用户的身份信息，设定资源的访问控制策略，并提供用户身份信息及访问控制策略信息的查询服务。

在以上部分中，ISAPI访问控制过滤器是本发明的核心，而SessionID传递方法是本发明的关键技术。

本发明的访问控制系统的工作流程如下：

A1.用户访问IIS服务器上部署的Web应用系统；

A2.ISAPI访问控制过滤器响应SF_NOTIFY_PREPROC_HEADERS事件通知，拦截HTTP请求的头部，根据请求URL中是否包含有效的Session ID、身份鉴别信息以及当前URL指向，对用户类别进行判断；

A3.对未鉴别用户，即初次登录Web应用系统的用户，ISAPI访问控制过滤器转入用户登录处理；

A4.对等待鉴别用户，即未鉴别但正通过登录页面提交身份鉴别信息的用户，ISAPI访问控制过滤器转入用户身份鉴别处理；

A5.对已鉴别用户，ISAPI访问控制过滤器请求授权决策引擎进行授权决策，请求中有用户Session ID、要访问的资源URL及访问方法；

A6.对于ISAPI访问控制过滤器提交的授权决策请求，授权决策引擎从Session维护引擎查询是否有与Session ID对应的Session对象，若无，则返回“拒绝”，并指明拒绝原因是“未鉴别用户”；若有，则授权决策引擎进一步根据从Session维护引擎获得的用户身份信息以及从身份与权限管理系统获得的访问控制策略决定是否允许用户访问有关资源并进行有关操作，然后将结果“允许”或“拒绝”返回给过ISAPI访问控制过滤器，若授权决策结果是拒绝，则还指明拒绝原因，如等“待鉴别用户”，“无相应权限”，或“资源不存”在等。

A7.ISAPI访问控制过滤器接收到授权决策结果后，依结果对用户HTTP请求进行进一步处理。若授权结果是允许，则ISAPI访问控制过滤器直接修改HTTP请求中的URL，去掉其中包含的Session ID信息，然后退出；否则，ISAPI访问控制过滤器根据拒绝的原因作进一步处理：若拒绝原因是“未鉴别用户”，则转入A3；若拒绝原因是“等待鉴别用户”，则将用户引导到登录页面；若拒绝的原因是用户没有权限等，则将用户引导到相应出错页面，然后退出。

A8.IIS服务器将ISAPI访问控制过滤器处理后的HTTP请求提交给Web应用系统，Web应用系统完成用户请求处理后返回响应结果。

A9.当HTTP响应结果返回时，ISAPI访问控制过滤器响应SF_NOTIFY_SEND_RAW_DATA事件通知，拦截响应结果，通过对响应内容中指向本地的URL链接进行重写，加入用户Session ID信息。

A10.应用服务系统完成响应结果发送后，ISAPI访问控制过滤器响应SF_NOTIFY_END_OF_NET_SESSION事件通知，不做任何处理，立即退出。

在上述A2步骤中，ISAPI访问控制过滤器检查HTTP请求中的SessionID信息，并据此判断用户类别的过程如下：

A21.检查HTTP请求中是否包含Session ID，

A22.若HTTP请求中不包含Session ID，则用户类别为未鉴别用户；

A23.若包含，则进一步判断该HTTP请求的URL是否指向登录页面(login页面)，

A24.若是，则判断用户是等待鉴别用户；

A25.若不是，则(初步)判断用户是已鉴别用户。

上述A3步骤中用户登录处理的过程如下：

A31.ISAPI访问控制过滤器请求Session维护引擎为用户创建一个Session对象，请求中有用户当前访问的URL(若该URL本身就是登录页面URL，则URL为空)；

A32.Session维护引擎接收到创建Session对象请求后，创建Session对象并产生对应的Session ID，将请求中的URL保存到Session对象中作为URL历史(若URL为空则保存缺省页面)，然后返回Session ID；

A33.ISAPI访问控制过滤器接到Session ID后，将用户引导到登录页面，然后退出。

上述A4步骤中ISAPI访问控制过滤器进行身份鉴别处理的工作过程如下：

A41.检查HTTP请求中是否包含身份鉴别信息，

A42.若请求中不包含身份鉴别信息，则将用户引导登录页面，然后退出；

A43.若请求中包含身份鉴别信息，即用户ID/口令信息，则从身份与权限管理系统获得有关信息验证用户ID和口令是否正确(若是基于动态口令的身份鉴别，则到验证服务器去验证)，

A44.若验证不通过，则将用户引导到相应出错页面，然后退出；

A45.若验证通过，则请求Session维护引擎为用户更新Session对象，请求中有Session ID、用户ID；

A46.Session维护引擎接收到更新Session对象请求后，从身份与权限管理系统获取用户的相关信息(如用户组、角色及其他用户属性)，将用户ID、用户组ID、用户角色等信息填充到Session对象，然后通知ISAPI访问控制过滤器更新的结果，“成功”或“失败”，失败给出原因，如无法获取用户信息等；

A47.ISAPI访问控制过滤器从Session维护引擎获得更新结果.

A48.若更新Session对象成功，则ISAPI访问控制过滤器进一步从Session维护引擎获得保存的用户URL历史(从Session对象取得)，并将用户HTTP请求中的当前URL改写为历史URL，然后转入A5；

A49.若更新Session对象失败，则ISAPI访问控制过滤器将用户引导到相应出错页面，然后退出。

在步骤A6中，如果授权决策引擎不能从Session维护引擎查询到与授权决策请求中Session ID对应的Session对象，则说明请求中的Session ID，或者由于超时对应的Session对象已删除，或者Session ID是伪造的根本无对应Session对象，因此，需重新鉴别用户身份。进一步，即使查询到对应的Session对象，但Session对象是空的，没有填充有关信息，则说明用户虽非初次登录，但身份鉴别还未完成。

在以上过滤器处理HTTP请求的过程中可能需要将用户引导到身份鉴别或出错页面，但是，当用户完成身份鉴别或点击出错页面提示后，过滤器应该将用户重新引导到其最初访问的页面。为此，本发明中ISAPI访问控制过滤器在HTTP请求处理阶段，当需要将用户引导到身份鉴别或出错页面时，ISAPI访问控制过滤器先请求Session维护引擎保存用户当前的URL，之后在适当的时候(如完成用户身份鉴别后)，再从Session维护引擎获取保存的URL历史，重新将用户引导最初访问的页面。

从前面介绍看到，Session对象维护与Session ID的产生由Session维护引擎独立进程负责，而将Session ID传递到客户端由ISAPI访问控制过滤器拦截HTTP响应，对响应内容中所有指向本地的URL链接进行重写，将Session ID信息加入到响应内容中的URL链接。用这种方式进行Session ID的传递，避免了cookie机制和由Web系统重写URL机制存在的问题(被禁用、依赖性)，且对客户端浏览器和应用是完全透明、独立的。

但是，ISAPI访问控制过滤器重写URL需要解决如下两个关键技术问题：

(C1)过滤器拦截HTTP响应结果，对响应中的URL重写，需要知道该用户的Session ID，而过滤器回调函数只有在处理HTTP请求时才知道该用户的Session ID(对非初次登录用户，过滤器从拦截的HTTP请求的URL中获得Session ID，对初次登录用户，过滤器从Session维护引擎获得为该用户新产生的Session ID)，而过滤器回调函数在HTTP请求处理时被调用和在HTTP响应时被调用是两个独立的调用，两次调用间无法直接传递Session ID。

(C2)过滤器拦截HTTP响应结果，对响应消息内容中的URL重写，需要正确的修改响应消息主体(message body)中的数据传输长度指示(transfer-length)，而这在技术实现上存在很大的难点。

本发明对以上关键技术问题(C1)的解决方法是，利用IIS服务器传递给ISAPI过滤器回调函数的一个HTTP_FILTER_CONTEXT结构参量中包含的一个指针pFilterContext，在一个HTTP请求/响应处理过程中被调用的回调函数间传递信息(包括但不限于Session ID信息)。这里，pFilterContext是一个空类型指针，通过类型转换可指向任何数据结构。在本发明中pFilterContext指向一个包含如下信息的数据结构变量：

(1)Session ID字段；

(2)已接收响应消息块计数字段；

(3)响应消息为chunked传输编码标志字段；

(4)响应消息主体的数据长度字段；

(5)累计已接收的响应消息主体数据长度字段。

据此，回调函数间传递Session ID的具体处理方法如下，

C11.当ISAPI访问控制过滤器拦截HTTP请求，完成有关处理后，退出前，过滤器回调函数将用户Session ID存放在该结构变量的“SessionID”字段中，并设置其它字段，然后将pFilterContext指针指向该结构变量。(其他字段用途及设置见后面说明)

C12.当ISAPI访问控制过滤器拦截HTTP响应消息时，过滤器回调函数从传给它的该结构变量的“Session ID”字段中取出Session ID值。

关于以上关键技术问题(C2)，需做重点说明。Web系统(Web容器或应用)有两种响应消息主体(message body)的产生、传输编码方式，一种是一次性产生并编码全部的响应消息主体，在这种情况下响应消息头部中有一个Content-Length题头(header)字段，其对应的16进制数值是响应消息主体的数据传输长度指示；另一种是是分块地产生并编码响应消息主体，这里每个块称为一个chunk，这种方式称为分块的传输编码(chunked transfer-coding)方式，这时在响应消息的头部有一个Transfer-Encoding：chunked题头(header)字段，指明该响应消息主体是chunked传输编码方式，而每个消息块(chunk)都有一个独立的长度指示，指明本响应消息数据块的传输长度。无论哪种传输编码方式，浏览器都需要依赖有关的数据传输长度指示来正确地接收数据。

ISAPI访问控制过滤器对响应消息中的URL链接进行重写，改变了消息主体(body)或消息主体块(chunk)的字节个数，因此，须正确地修改相应的传输长度指示。对chunked传输编码方式，过滤器做到这点相对比较容易，因为，ISAPI过滤器回调函数响应SF_NOTIFY_SEND_RAW_DATA事件通知，分次拦截每个响应消息块(chunk)，由于每个块有自己独立的长度指示，因此，若改变了某个块(chunk)只需修改相应块的长度指示即可(实际上这个过程也很麻烦)。但是，对于非chunked的传输编码方式，这个问题要复杂得多，因为这时即使响应消息主体是由Web系统一次产生并编码的，但IIS服务器仍会分块地(block)传输整个响应消息，这样ISAPI访问控制过滤器回调函数仍然是分次地拦截每个响应消息数据块(block)，而且除了第一个块包含Content-Length长度指示外，后面的块没有自己的长度指示，因此，修改了后面数据块的内容，必须相应地修改第一个块中的Content-Length长度指示，但这是不可能的，因为这时第一个块已传输了。对此的一种解决方案是，对非chunked传输编码方式下的响应消息，ISAPI过滤器将所有响应消息数据块(block)累积起来，当完成所有消息主体内容的修改后，重新修改整个消息的Content-Length长度指示，然后将整个响应消息返回给IIS服务器传输(在这之前，回调函数留下数据，返回空数据)。这样做的缺点在于，一方面实现起来非常复杂，特别考虑到在一个多线程环境下进行有关工作，另一方面这样做非常消耗内存和计算资源，降低了响应速度，影响系统性能。

本发明对以上关键技术问题(C2)解决方法步骤是，

C21.对于chunked传输编码方式的响应消息，ISAPI访问控制过滤器回调函数分次拦截到每个响应消息主体块(chunk)，若URL重写改变了某个块(chunk)，则回调函数直接修改该块(chunk)的长度指示。

C22.对于非chunked传输编码方式的响应消息，ISAPI访问控制过滤器回调函数将每次拦截的响应消息数据块(block)转变为chunked传输编码方式下的响应消息块，具体方法步骤如下：

C221.若接收的响应消息数据块是本响应消息的第一个数据块(这是一个仅包含头部的响应消息数据块)，则将其Content-Length字段删除，然后加上Transfer-Encoding：chunked题头字段；

C222.对于接收到的每个后续数据块(block)，过滤器回调函数完成URL重写后，在其前面加上一个长度指示，使之成为chunked传输编码方式下的一个消息块(chunk)；

C223.对于接收的最后一个响应消息数据块，除了完成步骤C222外，还要在数据块后面加上一个chunk结束标识(即字符0后跟一个空行)。

采用以上方法进行URL重写、修改数据传输长度，不但实现容易，而且资源占用少，处理速度快，性能好。

采用本发明中的方法进行URL重写，对传输数据长度指示进行修改，还需要解决几个问题：

(D1)拦截响应消息的ISAPI过滤器回调函数如何识别出哪个响应消息数据块是包含响应头部的第一个数据块(chunk或block)，哪些是不包含响应头部的后续数据块。

(D2)对于后续的、不包含响应头部的数据块，拦截响应的ISAPI过滤器回调函数如何知道该数据块对应的传输编码方式是chunked，还是非chunked的。

(D3)对于非chunked传输编码方式，ISAPI过滤器回调函数如何判断接收的响应消息数据块是最后一个数据块。

本发明对这三个问题的解决方法是通过利用前面提到的、在回调函数间传递信息的数据结构变量来实现(即前面介绍的pFilterContext所指的结构变量)。在该结构中有一个“已接收响应消息块计数”字段，记录到目前为止本次响应已接收的响应数据块的个数；一个布尔型字段“响应消息为chunked传输编码标志”，用来标识本次响应是chunked传输编码方式(TRUE)，还是非chunked(FALSE)；一个“响应消息主体的数据长度”字段，用于在非chunked传输编码方式下，存放响应消息主体的传输数据长度，即存放Content-Length题头对应的长度指示；一个“累计已接收的响应消息主体数据长度”字段，用于在非chunked传输编码方式下，累计记录本次响应到目前为止已接收的响应消息主体数据的总长度。

通过以上传递信息的数据结构，本发明对问题(D1)的解决方法如下，

D11.过滤器回调函数在拦截HTTP请求、完成有关处理退出前，将回调函数间传递信息的结构中的“已接收响应消息块计数”字段置为零。

D12.执行步骤A9的过滤器回调函数拦截HTTP响应消息时，每拦截一个HTTP响应数据块，先将回调函数间传递信息的数据结构变量中的“已接收响应消息块计数”字段加1，若加1后结果为1，则当前拦截的HTTP响应消息数据块是包含HTTP响应头部的第一个数据块，否则为后续数据块。

本发明对于问题(D2)的解决方法是，

D21.执行步骤A9的ISAPI过滤器回调函数，若按D12所述方法判断出本次拦截的响应数据块是第一个数据块，则过滤器回调函数接下来查看接收的第一个响应数据块是否包含Transfer-Encoding：chunked题头字段，若包含则将回调函数间传递信息的数据结构中的“响应消息为chunked传输编码标志”字段设为TRUE，反之设为FALSE。

D22.执行步骤A9的ISAPI过滤器回调函数，若按D12所述方法判断出本数据块不是第一个响应数据块，则过滤器回调函数通过回调函数间传递信息的数据结构中的“响应消息为chunked传输编码标志”字段可以知道当前响应消息的传输编码方式是chunked(若该标志字段为TRUE)，还是非chunked(若该标志字段为FALSE)。

本发明对于问题(D3)的解决方法是，

D31.当执行A9的ISAPI过滤器拦截第一个响应消息数据块(即包含响应头部数据块)，并按D21确定响应消息是非chunked传输编码方式后，除了设置“响应消息为chunked传输编码标志”字段为FALSE，还进一步地从响应消息数据块中的Content-Length题头字段中取出响应消息主体的长度指示值，并将回调函数间传递信息的结构中的“响应消息主体的数据长度”字段设为该长度指示值，然后将“累计已接收的响应消息主体数据长度”字段设置为零。

D32.当执行A9的ISAPI过滤器拦截后续的响应消息数据块时(即响应消息主体数据块)，若检查到回调函数间传递信息的结构变量中的“响应消息为chunked传输编码标志”字段为FALSE，即响应消息为非chunked传输编码方式，则将该数据结构变量中的“累计已接收的响应消息主体数据长度”字段值与接收的当前响应消息数据块的长度(URL重写前的)累加、更新，若累加、更新后该字段值与结构变量中的“响应消息主体的数据长度”字段值相等，则当前的响应数据块为最后一个数据块。

以上是本发明的内容。本发明的访问控制系统有效地解决了在Web系统(应用系统或Web容器)不参与及不使用cookie的情况下，进行用户Session ID传递的关键技术问题，如在拦截HTTP请求和拦截HTTP响应的过滤器回调函数间传递用户Session ID，在对响应消息数据块完成URL链接重写加入Session ID后，正确修改响应消息数据块的传输数据长度指示等。本发明中的Session ID传递机制的优点在于它对应用系统、客户端是完全透明。

除了对Web应用系统、客户端完全透明，本发明的访问控制系统还有如下优点或特点：

(1)对服务中止非常短暂，只需重启Web服务器，而这可以在夜间用户很少时进行，因此，对服务的影响微乎其微；

(2)适用于采用不同Web开发技术的应用系统，如ASP、ASP.NET，、JSP/Servlet、CGI、PHP等；

(3)方法简单，实施方便，与应用无缝集成，易于维护更新，升级快速方便。

附图说明

图1为本发明的整体系统结构图。

图2为本发明的身份与权限管理系统图。

具体实施方式

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

本发明所涉及的系统的整体结构如图1所示，其中构成本发明访问控制系统的组成部分是：ISAPI访问控制过滤器S11，Session维护引擎S12、授权决策引擎S13，及身份与权限管理系统S14。由于ISAPI访问控制过滤器是本发明的核心部分，因此，对其实施作重点说明。在以下描述中，为了简略，在不引起误解的请求下，用省略号...表函数的传递参数。

1)ISAPI访问控制过滤器

ISAPI访问控制过滤器是一基于ISAPI的过滤器动态连接库(DLL)，它的一种实施方式是采用VC++语言编写，扩展MFC的一个ISAPI实现类ChttpFilter，并重载ChttpFilter的如下虚函数实现：

(1)GetFilterVersion(PHTTP_FILTER_VERSION pVer)，注册回调函数；

(2)OnPreprocHeaders(CHttpFilterContext*pCtxt，PHTTP_FILTER_PREPROC_HEADERS pHeaderInfo)，对SF_NOTIFY_PREPROC_HEADERS(通知预处理题头)事件响应的回调函数；

(3)OnSendRawData(CHttpFilterContext*pCtxt，，PHTTP_FILTER_RAW_DATA pRawData)，对SF_NOTIFY_SEND_RAW_DATA(通知发送原数据)事件响应的回调函数；

(4)OnEndOfNetSession(CHttpFilterContext*pCtxt)，对SF_NOTIFY_END_OF_NET_SESSION(通知结束本事务会话)事件响应的回调函数。

这几个回调函数实际上不被IIS服务器直接调用，而是被一个最终生成的ISAPI过滤器处理回调函数GetFilterVersion(...)和HttpFilterProc(...)调用(参见背景介绍)，处理相应的触发事件，其中，PHTTP_FILTER_VERSION是指向HTTP_FILTER_VERSION结构的指针，PHTTP_FILTER_PREPROC_HEADERS是指向HTTP_FILTER_PREPROC_HEADERS结构的指针，

PHTTP_FILTER_RAW_DATA是指向PHTTP_FILTER_RAW_DATA结构的指针，

ChttpFilterContext是传递过滤器Context的结构指针，

SF_NOTIFY_PREPROC_HEADERS，

SF_NOTIFY_SEND_RAW_DATA，

SF_NOTIFY_END_OF_NET_SESSION为常量。

以上结构、结构指针和常量由MFC的ISAPI相关类定义。

包含以上回调函数的ISAPI访问控制过滤器DLL，通过IIS服务器的配置程序配置到IIS服务器中，IIS服务器启动时加载该DLL。在本发明中，过滤器对HTTP请求的拦截、处理，只需拦截HTTP请求、处理的头部，因此，只注册了预处理请求头部事件通知。

下面就ISAPI访问控制过滤器的以上几个回调函数(即ChttpFilter类中对应的虚函数)的具体实施进行描述。

A.GetFilterVersion(PHTTP_FILTER_VERSION pVer)

GetFilterVersion(...)的实现较简单，IIS服务器启动时加载DLL，然后执行GetFilterVersion(...)回调函数，通过它实现如下功能(可参见ISAPI规范)：

(1)返回版本号；

(2)注册SF_NOTIFY_PREPROC_HEADERS，SF_NOTIFY_SEND_RAW_DATA，SF_NOTIFY_END_OF_NET_SESSION事件通知。

B.OnPreprocHeaders(CHttpFilterContext*pCtxt，PHTTP_FILTER_PREPROC_HEADERS pHeaderInfo)OnPreprocHeaders(...)在IIS服务器预处理HTTP请求头部时被触发调用，它实现如下功能：

(1)用户类别判断；

(2)发起用户Session创建；

(3)保存、获取用户URL历史；

(4)用户身份鉴别；

(5)发起用户Session更新；

(6)发起授权决策请求；

(7)授权实施；

(8)HTTP请求URL重定向；

(9)向处理响应结果的回调函数传递用户Session ID等信息。

OnPreprocHeader(...)实现了发明内容中的工作流程步骤A2-A5及A7，A21-A25，A31和A33，A41-A45及A47-A49，以及关键技术问题(C1)(步骤C11)、(D1)(步骤D11)。具体实施描述如下：

OnPreprocHeader(...)从IIS服务器传给它的指针pHeaderInfo所指的结构中获得HTTP请求头部信息，然后通过解析HTTP请求头部中的URL对用户类别进行判断。若URL中不包含？...SessionID＝XXXXX...模式的Query string，则认定用户是未鉴别用户，其中字串SessionID(可用其他字串符号)表示用户Session ID信息，字串XXXXX表示Session ID的值；若包含，进一步判断该URL是否指向一登录页面，若是，则认定用户是一等待鉴别用户，否则认定用户是已鉴别用户(假冒和失效的Session ID在授权决策时确定)。(这一实施过程对应工作流程中的A2和A21-A25)

接下来，对于未鉴别用户，OnPreprocHeaders(...)请求Session维护引擎为用户创建Session对象，请求中包含用户当前的URL(若当前URL是登录页面，则URL为空)；Session维护引擎完成Session对象创建后返回结果，结果中有用户Session对象对应的Session ID值。OnPreprocHeaders(...)收到Session ID后，通过调用pHeaderInfo->SetHeader(...)函数直接修改HTTP请求头部的URL，使之指向登录页面(login页面)，然后退出。(这一实施过程对应工作流程中的A3、A31及A33)

对于等待鉴别用户，OnPreprocHeaders(...)进一步判断请求中是否有身份鉴别信息，具体方法是判断HTTP请求的URL中是否包含？...User ID＝YYYYY&Password＝ZZZZZ...模式的Query string，字串YYYYY和ZZZZZ分别是UserID(用户ID)和Password(口令)的值。需说明的是，Name/Value对中的Name的具体名字不重要，可根据具体情况任意选定。

如请求中包含身份鉴别信息，OnPreprocHeaders(...)对用户进行身份鉴别。对于基于用户名/口令的身份鉴别方式，OnPreprocHeaders(...)到身份与权限管理系统获取用户相关信息完成口令验证；对于基于动态口令的身份鉴别方式，OnPreprocHeaders(...)到动态口令验证服务验证用户的有效性。

对于身份鉴别失败的用户，OnPreprocHeaders(...)通过调用pHeaderInfo->SetHeader(...)直接修改HTTP请求中的URL，将用户引导到出错页面，然后返回。对于鉴别通过的用户，OnPreprocHeaders请求Session维护引擎用户更新Session对象，请求中有用户标识(UserID)；Session维护引擎从身份与权限系统获得用户身份信息，更新Session对象，返回更新结果，“成功”或“失败”。若更新失败，OnPreprocHeaders(...)通过pHeaderInfo->SetHeader(...)直接修改HTTP请求中的URL，将用户引导到出错页面，然后退出；若更新成功，OnPreprocHeaders(...)请求Session维护引擎返回用户URL历史，请求中有用户Session ID，获得了Session维护引擎返回的用户初次登录URL后，OnPreprocHeaders(...)通过pHeaderInfo->SetHeader(...)直接修改HTTP请求中的URL使之指向返回的URL。

(以上实施过程对应工作流程中的A4、A41-A45及A47-A49)

接下来，对于已完成身份鉴别的用户(无论是提交请求前已完成鉴别的用户还是刚完成鉴别的用户)，OnPreprocHeaders(...)请求授权决策引擎对用户的访问进行授权决策，请求中包含用户Session ID、要访问的URL及访问方法(如GET、POST)。授权决策引擎将授权决策结果返回给OnPreprocHeaders(...)。

OnPreprocHeaders(...)接收到返回的授权决策结果后，作进一步的处理。若结果是拒绝，且原因是未鉴别用户，则转入到前面的未鉴别用户登录处理；若结果是拒绝，且拒绝原因是等待鉴别用户，则通过调用pHeaderInfo->SetHeader(...)直接修改HTTP请求中的URL，使之指向登录页面，然后退出；若结果是拒绝，且拒绝原因是无权限，则通过调用pHeaderInfo->SetHeader(...)直接修改HTTP请求中的URL，使之指向相应出错页面，然后退出。若授权决策结果是允许，则通过调用pHeaderInfo->SetHeader(...)直接修改HTTP请求中的URL，去掉其中包含的Session ID信息，然后返回。(这一实施过程对应工作流程中的A5、A7)

无论何种情况，在OnPreprocHeaders(...)进行完有关处理，退出前，都要向拦截响应消息的回调函数OnSendRawData(...)传送与Session ID传递有关的控制信息。具体步骤如下：

OnPreprocHeaders(...)首先从传递给它的结构pCtxt中取出指针pCtxt->m_pFC->pFilterContext(pFilterContext的类型是void*，其初值是NULL)；然后用pCtxt->m_pFC->pFilterContext＝(void*)pCtxt->AllocMem(sizeof(SessionContext)，0)，为pFilterContext分配一内存空间，其中结构SessionContext为：Struct SessionContext

{

 char SessionID[MAX_SESSION_ID_LEN]；//Session ID字段

 int RespBlockCnt；//已接收响应消息块计数字段

 bool RespChunkedFlag；//响应消息为chunked传输编码标志字段

 long RespContentLength；//响应消息主体的数据长度字段

 long RespAccMsgLen；//累计已接收的响应消息主体数据长度字段

}；

接下来，OnPreprocHeaders(...)将用户的Session ID值XXXXX，赋给pFilterContext所指SessionContext结构变量之中的SessionID字段，将RespBlockCnt字段置为零，之后OnPreprocHeaders(...)退出。(以上实施过程对应于关键技术问题(C1)的C11、(D1)的D11)

需指出的是pCtxt->m_pFC->pFilterContext对应于IIS服务器传给过滤器回调函数HttpFilterProc(...)的一个HTTP_FI LTER_CONTEXT结构变量中的指针pFilterContext。

C.OnSendRawData(CHttpFilterContext*pCtxt，

PHTTP_FILTER_RAW_DATA pRawData)

OnSendRawData(...)在IIS服务器发送HTTP响应数据时被触发调用，它的功能是进行URL重写，在指向本地的URL链接中保存当前用户的Session ID，即实现发明内容中工作流程A9所涉及的关键技术(C1)(步骤C12)、(C2)，关键技术问题(D1)(步骤D12)、(D2)、(D3)，其具体实施如下。

OnSendRawData(...)首先从IIS服务器传递给它的结构pCtxt->m_pFC->pFilterContext中取出pFilterContext指针，若pFilterContext为空，则直接返回；若不为空，则从pFilterContext指针所指SessionContext结构中的SessionID字段取出用户SessionID值XXXXX。在使用pFilterContext所指结构前，先将pFilterContext强制转换为指向SessionContext结构。(这对应于关键技术问题(C1)的C12)

OnSendRawData(...)从IIS服务传给它的pRawData指针所指的结构中可获得HTTP响应消息数据块，按发明内容中D12所述方法，通过pCtxt->m_pFC->pFilterContext所指SessionContext结构中的RespBlockCnt字段，判断接收到的数据块是否为第一个消息响应数据块。(这对应于关键技术问题(D1)的D12)

若拦截的数据块是第一个消息响应数据块，则进行如下处理：

(1)按D21所述方法，判断响应消息是否为chunked传输编码方式，并依此设定传给它的pCtxt->m_pFC->pFilterContext所指结构中的RespChunkedFlag字段，若是chunked，则设为TRUE，反之，设为FALSE，然后退出；

(2)若响应消息是非chunked传输编码模式，则进一步按D21所述方法，从响应数据块中的Content-Length字段中取出响应消息主体的长度指示值，

(21)若长度指示值为零，则OnSendRawData(...)退出；

(22)若长度指示值非零，则OnSendRawData(...)按D31所述将回调函数间传递信息的结构中的RespContentLength字段设为该长度值，然后将RespAccMsgLen字段设置为零，接下来将响应数据块中的Content-Length题头字段删除，加上Transfer-Encoding：chunked题头字段，然后退出。(对应C22的C221)

若拦截的数据块不是第一个消息响应数据块，则进行如下处理：

(1)按D22所述方法，通过pCtxt->m_pFC->pFilterContext所指结构中的RespChunkedFlag字段判断响应消息的传输编码模式是chunked或非chunked的；

(2)若是chunked(RespChunkedFlag为TRUE)，则对响应内容中所有指向本地的有效URL链接进行重写，加入？...SessionID＝XXXXX...模式的Query string，其中字串SessionID(可用其他字串符号)表示用户Session ID信息，字串XXXXX表示session ID的值，然后退出；(对应C21对chunked响应数据块的处理)

(3)若是非chunked(RespChunkedFlag为FALSE)，则对响应内容中所有指向本地的有效URL链接进行重写，加入？...SessionID＝XXXXX...模式的Query string，然后按C22的C222所述在响应数据块前面加上一个相应的长度指示，使之成为chunked传输编码方式下的一个消息块(chunk)；接下来进行如下处理：

(31)按D32.所述方法判断当前响应数据块是否为最后一个数据块(重写URL前，当前响应数据块的大小可从传递给它的pRawData指针所指结构中获得)，若不是，则退出；

(32)若是，则按C22的C223所述在响应数据块后面加上一个chunk结束标识(即字符0后跟一个空行)。

在重写响应消息数据块中的URL时，并非对所有指向本地的URL重写，而只是重写有效的URL链接(link)，即页面中能够点击鼠标跳转的URL链接。

OnSendRawData(...)对保存在pRawData所指结构中的响应数据进行修改，要进行正确的数据块内存管理，具体做法是，在修改数据块中的响应内容前，先估算消息内容修改后所需的数据缓存区大小，这些修改可能是增加头部题头、在URL中增加Session ID信息、修改或增加每个数据块的长度指示、添加chunk结束数据块等，然后，调用pCtxt->AllocMem(...)分配相应大小的缓存块，将修改的内容存放在新的缓存块内，最后用新产生的响应数据块，替换pRawData所指结构中原来的响应数据块，并相应地修改pRawData所指结构中的有关数据长度指示变量。

以上对响应数据块的修改遵从HTTP1.1规范。

D.OnEndOfNetSession(CHttpFilterContext*pCtxt)

OnEndOfNetSession(CHttpFilterContext*pCtxt)在IIS服务器完成一个HTTP请求/响应的处理时被触发调用，它什么不做即返回。它的作用是让IIS服务器释放由AllocMem(...)分配的内存。

2)Session维护引擎

Session维护引擎实现工作流程A6、A32、A46、A48中与Session维护有关的功能，主要有：

(1)根据ISAPI访问控制过滤器的请求创建用户Session对象，产生Session ID，并返回Session ID；

(2)根据ISAPI访问控制过滤器的请求保存用户URL历史到Session对象，或返回Session对象中保存的用户URL历史；

(3)根据ISAPI访问控制过滤器的请求，更新Session对象，从身份与权限管理系统获取用户信息(如用户组信息、角色信息等)并填充Session对象；

(4)提供用户Session状态信息(Session ID、身份信息、权限信息等)的查询；

(6)删除超时不用的Session对象。

只要实现本发明所述的功能，Session维护引擎有多种的实施方式。一种方式是将Session维护引擎作为一个程序模块实现，与ISAPI访问控制过滤器一同加载并被ISAPI访问控制过滤器直接调用。在这种实施方式中，Session维护引擎模块通过一个存放在内存中的全局Session对象表来维护用户Session信息，该全局表或者在ISAPI访问控制过滤器初始化时创建初始化，如由GetFilterVersion(PHTTP_FILTER_VERSIONpVer)创建初始化，或者第一次使用时创建初始化。

另一种方式是将Session维护引擎作为一个运行在IIS服务器上的独立进程实现，ISAPI访问控制过滤器通过进程间通信(Inter-processcommunications，IPC)与Session维护独立进程进行信息交互。相对于前一种方式，这种方式的性能略差，但开发、调试和维护要容易。比如，用Java技术来开发一个Session维护独立进程非常简单。

总之，只要实现所需的功能，Session维护引擎有多种的实施方式，且不存在技术障碍。

3)授权决策引擎

授权决策引擎主要实现工作流程A6中与之有关的功能，即根据ISAPI的授权决策请求对用户的资源访问做出决策。与Session维护引擎类似，只要实现本发明所述功能，它有多种的实施方式和方法。与Session维护引擎类似，它既可以作为一个模块实现，与ISAPI访问控制过滤器一同加载并被ISAPI过滤器直接调用，也可以作为一个运行在IIS服务器上的独立进程实现。

授权决策引擎的实现是直接的，不存在技术障碍。

4)身份与权限管理系统

身份与权限管理系统实现步骤A43、A46中与之有关的功能。只要实现本发明所述功能，它有多种的实施方式，下面描述其中一种实施方式。

身份与权限管理系统包括三部分(如图2所示)：身份与权限服务器T11，身份与权限数据库T12和身份与权限份管理器T13。身份与权限数据库可采用任一支持LDAP(Lightweight Directory Access Protocol)的数据库系统，它存放用户身份信息(如用户ID、用户组、角色)、访问控制策略等，具体存放信息的内容和形式与访问控制方法(如ACL、RBAC等)有关；身份与权限服务器是一个基于Java的服务进程，对外提供了身份与权限信息创建、更新、删除、查询等的服务接口，服务接口的方式包括RMI、Web Services；身份与权限份管理器提供身份与权限管理的人机交互界面，可采用JSP/Servlet及其他Web技术实现。

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