专利名称：一种Session ID全透明传递的ISAPI访问控制系统的制作方法
技术领域：
本发明属于网络信息安全技术领域，是一种基于ISAPI过滤器的访 问控制系统，它以一种对Web应用系统透明的方式，为部署在IIS服务 器上的Web应用提供访问控制功能，尤其是在不依赖于Web系统(Web容 器或Web应用)和不使用cookie的情况下实现Session ID的透明传递。
背景技术：
对于部署在互联网上的许多Web应用服务系统，用户身份鉴别 (Authentication)和访问控制(Access Control)是必不可少的安全 功能。身卩分鉴别，即知道对方是谁，确认对方是其声称的人(或实体)； 而访问进行控制，即根据用户的权限和访问控制策略在线决定是否允许 用户访问某项资源并进行有关操作，这些资源可以是主机、系统目录、 文件，或某项服务功能，如交易、支付等。访问控制又称为访问授权 (Authorization),包括权限管理(Privi lege 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-N0TIFY-PREPR0C—HEADERS (通知 预处理题头)，SF—NOTIFY_SEND_RAlDATA (通知发送原数据)等，Web 服务器在不同阶段调用ISAPI过滤器的事件处理回调函数，对HTTP请求 或响应进行处理，如读耳又HTTP请求中的数据，处理题头(Header),鉴别 用户，进行URL修改，返回数据，记录日志等。ISAPI过滤器有两个入口回调函数，分别是注册函数 GetFiUerVersion()和过滤器处理函数HUpFilterProc(),其接口定义 ^口下，BOOL WINAPI GetFilterVersion(PHTTP一FILTER—VERSION pVer); DWORD WINAPI HttpFilterProc(PHTTP—FILTER—CONTEXT pfc， DWORD NotificationType， IJ VOID pvNotification );PHTTP-FILTER—VERSION和PHTTP-FILTER-CONTEXT由ISAPI定义。这两个入口函数，前者由Web服务器初始化时调用，它返回过滤器 支持的ISAPI的版本号，并对每个要处理的事件通知进行注册；后者负 责对一系列触发的事件通知进行处理。 一般地，对于每个触发事件通知， HttpFilterProc()会再调用对应的回调函数进行处理，如对 SF—N0TIFY—PREPR0C-HEADERS事件通知调用回调函数OnPreprocHeaders () 进行处理，对SF—N0TIFY—SEND—RAW—DATA事件通知调用OnSendRawData () 回调函数进行处理，对SF-NOTIFY—END—OF—NET—SESSION事件通知调用回 调函数OnEndOfNetSession0进行处理等。利用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和传递 Session ID。对于前一种途径，在实际应用中，需要基于ISAPI过滤器 的访问控制系统与应用系统的耦合、配合，这在有些情况下是不方便的， 甚至是不可行的，即这种途径不能完全做到Web系统与访问控制系统间 的相互透明。对于后一种途径，关键在如何实现Session ID传递。Web技术中目前常用的Sess ion ID传递机制有cookie和URL重写两 种。Cookie机制简单，Web系统(应用系统或Web容器)只需在初次响 应用户HTTP请求时通过set-cookie题头(header)将用户Session ID 设置为cookie即可。Cookie机制的缺点是，当客户端浏览器禁用cookie 时无法工作，即对客户端不完全透明。URL重写是由Web系统对HTTP响 应内容中指向本地的URL《连接进行重写，在URL中增加或扩充Query string,使之包含？. ..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 访问控制系统，它以I SAP I过滤器技术为基础，能以 一种对Web应用系 统和客户端浏览器完全透明的方式，为部署在IIS服务器上的Web应用 提供访问控制功能。本发明解决了由ISAPI访问控制过滤器进行URL重 写传递Session ID存在的关4建技术问题。本发明的ISAPI访问控制系统包括如下四个组成部分 ISAPI访问控制过滤器(简称过滤器)它是一个由IIS服务器加载 的ISAPI过滤器DLL,位于用户客户端(浏览器)与Web应用系统之间， 负责用户身份鉴别和访问控制授权实施(访问控制执行)。当用户通过浏 览器访问部署在IIS服务器上的Web应用系统时，过滤器拦截用户请求， 通过对请求信息进行分析和处理，实现对用户的身Y分鉴别和访问控制。 当Web服务器返回响应结果时，过滤器再次拦截响应信息，并通过重写 响应信息中指向本地的URL链接加入用户Session ID，实现用户Session ID的透明传递。Session维护引擎负责为每一个在线访问Web服务的用户创建一个 保存状态的Session对象，产生相应的Session ID, /人身份与权限管理 系统获取用户身份信息填充Session对象，将用户其他状态信息保存到 Session对象，提供Session信息、身份信息的查询，删除超时不用的 Session对象等；授权决策引擎根据用户的身份和权P艮信息及资源访问控制策略， 对用户访问资源的请求进行授权决策；身份与权限管理系统保存和维护用户的身份信息，设定资源的访 问控制策略，并提供用户身份信息及访问控制策略信息的查询服务。在以上部分中，ISAPI访问控制过滤器是本发明的核心，而SessionID传递方法是本发明的关键技术。本发明的访问控制系统的工作流程如下Al.用户访问IIS服务器上部署的Web应用系统；A2. ISAPI访问控制过滤器响应SF-N0TIFY_PREPR0C—HEADERS事件通 知，拦截HTTP请求的头部，根据请求URL中是否包含有效的Session ID、 身份鉴别信息以及当前URL指向，对用户类別进行判断；A3.对未鉴别用户，即初次登录Web应用系统的用户，ISAPI访问控 制过滤器转入用户登录处理；A4.对等待鉴别用户，即未鉴别但正通过登录页面提交身份鉴别信 息的用户，ISAPI访问控制过滤器转入用户身^f分鉴别处理；A5.对已鉴別用户，ISAPI访问控制过滤器请求授权决策引擎进行授 权决策，请求中有用户Session ID、要访问的资源URL及访问方法；A6.对于ISAPI访问控制过滤器提交的授权决策请求，授权决策引 擎从Session维护引擎查询是否有与Session ID对应的Session对象， 若无，则返回"拒绝"，并指明拒绝原因是"未鉴别用户"；若有，则授 权决策引擎进一步根据从Session维护引擎获得的用户身份信息以及从 身份与权限管理系统获得的访问控制策略决定是否允许用户访问有关资 源并进行有关操作，然后将结果"允许，，或"拒绝"返回给过ISAPI访 问控制过滤器，若4受斥又决策结果是拒绝，则还指明拒绝原因，如等"待 鉴别用户"，"无相应权限"，或"资源不存"在等。A7. ISAPI访问控制过滤器接收到授权决策结果后，依结果对用户 HTTP请求进行进一步处理。若授权结果是允许，则ISAPI访问控制过滤 器直接修改HTTP请求中的URL,去掉其中包含的Session ID信息，然后 退出；否则，ISAPI访问控制过滤器根据拒绝的原因作进一步处理若拒 绝原因是"未鉴别用户"，则转入A3;若拒绝原因是"等待鉴别用户"，则将用户引导到登录页面；若拒绝的原因是用户没有权限等，则将用户 引导到相应出4昔页面，然后退出。A8. IIS服务器将ISAPI访问控制过滤器处理后的HTTP请求提交给 Web应用系统，Web应用系统完成用户请求处理后返回响应结果。A9.当HTTP响应结果返回时，ISAPI访问控制过滤器响应 SF—NOTIFY_SEND_RAW_DATA事件通知，拦截响应结果，通过对响应内容中 指向本地的URL《连4妻进行重写，加入用户Session ID信息。A10.应用服务系统完成响应结果发送后，ISAPI访问控制过滤器响 应SF_N0TIFY_END—0F-NET—SESSION事件通知，不喉文任何处理，立即退出。在上述A2步骤中，ISAPI访问控制过滤器检查HTTP请求中的Ses s ion ID信息，并据此判断用户类别的过程如下A21.检查HTTP请求中是否包含Session ID,A22.若HTTP请求中不包含Session ID,则用户类别为未鉴别用户；A23.若包含，则进一步判断该HTTP请求的URL是否指向登录页面 (login页面)，A24.若是，则判断用户是等待鉴別用户；A25.若不是，则(初步)判断用户是已鉴别用户。上述A3步骤中用户登录处理的过程如下A31. ISAPI访问控制过滤器请求Ses s i on维护引擎为用户创建一个 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访问控制过滤器将用户引 导到相应出4晉页面，然后退出。在步骤A6中，如果授权决策引擎不能从Session维护引擎查询到与 授权决策请求中Sess ion ID对应的Sess ion对象，则说明请求中的Session ID,或者由于超时对应的Session对象已删除，或者Session ID 是伪造的根本无对应Session对象，因此，需重新鉴别用户身份。进一 步，即使查询到对应的Session对象，但Session对象是空的，没有填 充有关信息，则说明用户虽非初次登录，但身份鉴别还未完成。在以上过滤器处理HTTP请求的过程中可能需要将用户《}导到身份鉴 别或出错页面，但是，当用户完成身份鉴別或点击出错页面提示后，过 滤器应该将用户重新引导到其最初访问的页面。为此，本发明中ISAPI 访问控制过滤器在HTTP请求处理阶段，当需要将用户引导到身份鉴别或 出错页面时，ISAPI访问控制过滤器先请求Ses s ion维护引擎保存用户当 前的URL，之后在适当的时候(如完成用户身份鉴别后)，再从Session 维护引擎获取保存的URL历史，重新将用户引导最初访问的页面。乂人前面介绍看到，Session对象维护与Session ID的产生由Session 维护引擎独立进程负责，而将Session ID传递到客户端由ISAPI访问控 制过滤器拦截HTTP响应，对响应内容中所有指向本地的URL链接进行重 写，将Session ID信息加入到响应内容中的URL链接。用这种方式进行 Session ID的传递，避免了 cookie机制和由Web系统重写URL机制存在 的问题(被禁用、依赖性)，且对客户端浏览器和应用是完全透明、独立 的。但是，ISAPI访问控制过滤器重写URL需要解决如下两个关键技术问题(CI)过滤器拦截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),而这在技术实现上存在很大的难点。本发明对以上关键技术问题(CI)的解决方法是，利用IIS服务器传 递给ISAPI过滤器回调函数的一个HTTP_FILTER_CONTEXT结构参量中包 含的一个指4十pFilterContext,在一个HTTP i青求/响应处理过程中被调 用的回调函数间传递信息(包括但不限于Session ID信息)。这里， pFilterContext是一个空类型指针，通过类型转换可指向任何数据结构。 在本发明中pFilterContext指向一个包含如下信息的数据结构变量 (1 ) Session ID字段； (2)已接收响应消息块计数字段； (3 )响应消息为chunked传输编码标志字,殳； (4 )响应消息主体的数据长度字段； (5 )累计已接收的响应消息主体数据长度字H 据jt匕，回调函iU'iH专递Session ID的具体处理方法如下， Cll.当ISAPI访问控制过滤器拦截HTTP请求，完成有关处理后，退 出前，过滤器回调函数将用户Session ID存放在该结构变量的"Session ID"字段中，并设置其它字段，然后将pFilterContext指针指向该结构 变量。(其他字段用途及设置见后面说明)C12.当ISAPI访问控制过滤器拦截HTTP响应消息时，过滤器回调函 凄t乂人传^会它的该结构变量的"Session ID"字)殳中取出Session ID值。 关于以上关4建技术问题(C2)，需做重点说明。Web系统(Web容器或 应用)有两种响应消息主体( message body)的产生、传输编码方式,一种是一次性产生并编码全部的响应消息主体，在这种情况下响应消息头部中有一个Content-Length题头(header)字段，其对应的16进制 数值是响应消息主体的数据传输长度指示；另一种是是分块地产生并编 码响应消息主体，这里每个块称为一个chunk,这种方式称为分块的传输 编码(chunked transfer-coding )方式，这时在响应消息的头部有一个 Transfer-Encoding: chunked题头(header)字H指明该响应消息主 体是chunked传输编码方式，而每个消息块(chunk)都有一个独立的长 度指示，指明本响应消息数据块的传输长度。无i仑哪种传输编码方式， 浏览器都需要依赖有关的数据传输长度指示来正确地接收数据。ISAPI访问控制过滤器对响应消息中的URL链接进行重写，改变了消 息主体(body)或消息主体块(chunk)的字节个数，因此，须正确地修 改相应的传输长度指示。对chunked传输编码方式，过滤器做到这点相 对比较容易，因为，ISAPI过滤器回调函数响应SF_N0TIFY_SEND—RAW-DATA 事件通知，分次拦截每个响应消息块(chunk),由于每个块有自己独立 的长度指示，因此，若改变了某个块(chunk)只需修改相应块的长度指 示即可(实际上这个过程也4艮麻烦)。但是，对于非chunked的传输编码 方式，这个问题要复杂得多，因为这时即使响应消息主体是由Web系统 一次产生并编码的，但IIS服务器仍会分块地(block)传输整个响应消 息，这样ISAPI访问控制过滤器回调函数仍然是分次地拦截每个响应消 息数据块(block ),而且除了第一个块包含Content-Length长度指示外， 后面的块没有自己的长度指示，因此，修改了后面数据块的内容，必须 相应地修改第一个块中的Content-Length长度指示，但这是不可能的， 因为这时第一个块已传输了。对此的一种解决方案是，对非chunked传 输编码方式下的响应消息，ISAPI过滤器将所有响应消息数据块(block ) 累积起来，当完成所有消息主体内容的修改后，重新修改整个消息的Content-Length长度指示，然后将整个响应消息返回给IIS服务器传输 (在这之前，回调函数留下数据，返回空数据)。这样做的缺点在于，一 方面实现起来非常复杂，特别考虑到在一个多线程环境下进行有关工作， 另一方面这样做非常消耗内存和计算资源，降低了响应速度，影响系统 性能。本发明对以上关4建技术问题(C2)解决方法步骤是，C21.对于chunked传输编码方式的响应消息，ISAPI访问控制过滤器 回调函数分次拦截到每个响应消息主体块(chunk),若URL重写改变了 某个块(chunk )，则回调函数直接修改该块(chunk )的长度指示。C22.对于非chunked传输编码方式的响应消息，ISAPI访问控制过滤 器回调函数将每次拦截的响应消息数据块(block)转变为chunked传输 编码方式下的响应消息块，具体方法步骤如下C221.若接收的响应消息数据块是本响应消息的第一个数据块(这是一个仅包含头部的响应消息数据块)，则将其Content-Length字段删除，然后加上Transfer-Encoding: chunked题头字4殳；C222.对于接收到的每个后续数据块(block),过滤器回调函数完成URL重写后，在其前面加上一个长度指示，4吏之成为chunked传输编码方式下的一个消息块(chunk);C223.对于接收的最后一个响应消息数据块，除了完成步骤C222夕卜，还要在数据块后面加上一个chunk结束标识(即字符0后跟一个空行)。采用以上方法进行URL重写、修改数据传输长度，不但实现容易，而 且资源占用少，处理速度快，性能好。采用本发明中的方法进行URL重写，对传输数据长度指示进行修改， 还需要解决几个问题(Dl )拦截响应消息的ISAPI过滤器回调函数如何识别出哪个响应消
息数据块是包含响应头部的第一个数据块(chunk或block),哪些是不
包含响应头部的后续lt据块。
(D2)对于后续的、不包含响应头部的数据块，拦截响应的ISAPI过 滤器回调函数如何知道该数据块对应的传输编码方式是chunked,还是非 chunked的。
(D3 )对于非chunked传输编码方式，ISAPI过滤器回调函数如何判 断接收的响应消息数据块是最后一个数据块。
本发明对这三个问题的解决方法是通过利用前面提到的、在回调函数 间传递信息的数据结构变量来实现(即前面介绍的pFilterContext所指 的结构变量)。在该结构中有一个"已接收响应消息块计数"字段，记录 到目前为止本次响应已"l妄收的响应数据块的个数； 一个布尔型字段"响 应消息为chunked传输编码标志"，用来标识本次响应是chunked传输编 码方式(TRUE),还是非chunked (FALSE); —个"响应消息主体的数据 长度"字段，用于在非chunked传输编码方式下，存放响应消息主体的 传输数据长度，即存放Content-Length题头对应的长度指示； 一个"累 计已接收的响应消息主体数据长度"字段，用于在非chunked传输编码 方式下，累计记录本次响应到目前为止已接收的响应消息主体数据的总 长度。
通过以上传递信息的数据结构，本发明对问题(D1)的解决方法如下， Dll.过滤器回调函数在拦截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) 方法简单，实施方便，与应用无缝集成，易于维护更新，升级 快速方4更。
图1为本发明的整体系统结构图。 图2为本发明的身份与权限管理系统图。
具体实施例方式
下面结合附图和实施例对本发明作进一步的详细描述。 本发明所涉及的系统的整体结构如图l所示，其中构成本发明访问控制系统的组成部分是ISAPI访问控制过滤器Sll， Session维护引擎 S12、授权决策引擎S13,及身份与权限管理系统S14。由于ISAPI访问 控制过滤器是本发明的核心部分，因此，对其实施作重点说明。在以下 描述中，为了简略，在不引起误解的请求下，用省略号…表函数的传递参数。
1) ISAPI访问控制过滤器
ISAPI访问控制过滤器是一基于ISAPI的过滤器动态连接库(DLL)， 它的一种实施方式是采用VC++语言编写，扩展MFC的一个ISAPI实现类 ChttpFilter，并重载ChttpFilter的如下虚函数实现
(1) GetFilterVersion(PHTTP-FILTER—VERSION pVer),注册回调函数；
(2) OnPreprocHeaders (CHttpFi1terContext* pCtxt， PHTTP—FILTER一PREPROC—HEADERS pHeaderlnfo)，
对SF_N0TIFY-PREPR0C-HEADERS(通知预处理题头)事件响应的回调函数；
(3) 0nSendRawData (CHttpFilterContext* pCtxt，， PHTTP—FILTER—RAW—DATA pRawData)，
对SF_N0TIFY_SEND_RAW_DATA (通知发送原数据)事件响应的回调函数；
(4) OnEndOfNetSession (CHUpFilterContext* pCUt)，对 SF_N0TIFY_END_0F_NET_SESSI0N (通知结束本事务会话)事件响应的回 调函数。
这几个回调函数实际上不被IIS服务器直接调用，而是被一个最终生 成的ISAPI过滤器处理回调函数GetFilterVersion(...)和 HttpFiUerProc(…)调用(参见背景介绍)，处理相应的触发事件，其中， PHTTP_FILTER_VERSI0N是指向HTTP_FILTER-VERSI0N结构的指针， PHTTP—FILTER_PREPROC_HEADERS是指向HTTP—FILTER—PREPROC—HEADERS 结构的指针，PHTTP-FILTER-RAW-DATA是指向PHTTP—FILTER—RAW—DATA结构的指4十，
ChttpFilterContext是传递过滤器Context的结构指4十，
SF_NOTIFY_PREPROC-HEADERS，
SF-N0TIFY_SEND—RAIDATA，
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 pHeaderlnfo) 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，以及关键技术问题(CI)(步 骤Cll)、 (Dl)(步骤Dll)。具体实施描述如下OnPreprocHeader (…)从IIS服务器传给它的指针pHeaderlnfo所指的 结构中获得HTTP请求头部信息，然后通过解析HTTP请求头部中的URL 对用户类别进行判断。若URL中不包含？.…SessionlD-XXXXX…模式的 Query string,则-〖人定用户是未鉴别用户，其中字串SessionID (可用其 他字串符号)表示用户Session ID信息，字串XXXXX表示Session ID 的值；若包含，进一步判断该URL是否指向一登录页面，若是，则认定 用户是一等待鉴别用户，否则认定用户是已鉴别用户(假冒和失效的 Session ID在4更斥又决策时确定)。(这一实施过程对应工作流程中的A2和 A21-A25 )接下来，对于未鉴别用户，OnPreprocHeaders (…)请求Session维 护引擎为用户创建Session对象，请求中包含用户当前的URL (若当前 URL是登录页面，则URL为空)；Session维护引擎完成Session对象创 建后返回结果，结果中有用户Session对象对应的Session ID值。 OnPreprocHeaders (...)收到Session ID后，通过调用 pHeaderlnfo-〉SetHeader (...)函数直接修改HTTP请求头部的URL，使之指向登录页面(login页面)，然后退出。(这一实施过程对应工作流程中 的A3、 A31及A33)对于等4寺鉴别用户，OnPreprocHeaders (…)进一步判断请求中是否 有身份筌别信息，具体方法是判断HTTP请求的URL中是否包 含？...1]361"10=丫丫丫丫丫& &33\￥(^(1=22222...模式的Query string,字串 YYYYY和ZZZZZ分别是UserID (用户ID)和Password ( 口令)的值。需 说明的是，Name/Value对中的Name的具体名字不重要，可才艮据具体情况 任意选定。如请求中包含身j分鉴别信息，OnPreprocHeaders (...)对用户进行身份 鉴别。对于基于用户名/口令的身份鉴别方式，OnPreprocHeaders (...)到 身份与权限管理系统获取用户相关信息完成口令验证；对于基于动态口 令的身份鉴别方式，0nPr印rocHeaders (…)到动态口令验证服务验证用 户的有效性。对于身份鉴别失败的用户，0nPr印rocHeaders (…)通过调用 pHeaderlnfo-〉SetHeader (…)直接修改HTTP请求中的URL,将用户引导 到出错页面，然后返回。对于鉴别通过的用户，OnPreprocHeaders请求 Session维护引擎用户更新Session对象，请求中有用户标识(UserID ); Session维护引擎从身份与权限系统获得用户身份信息，更新Session对 象，返回更新结果，"成功"或"失败"。若更新失败，OnPreprocHeaders (...) 通过pHeaderlnfo-〉SetHeader (…)直接修改HTTP请求中的URL，将用户 引导到出错页面，然后退出；若更新成功，OnPreprocHeaders (...)请求 Session维护引擎返回用户URL历史，请求中有用户SessionID，获得了 Session维护引擎返回的用户初次登录URL后，OnPr印rocHeaders (...) 通过pHeaderlnfo-〉SetHeader(…)直接修改HTTP请求中的URL使之指向 返回的URL。(以上实施过程对应工作流程中的A4、 A41-A45及A47-A49 ) 接下来，对于已完成身份鉴别的用户(无论是提交请求前已完成鉴 别的用户还是刚完成鉴别的用户),OnPr印rocHeaders(…)请求授权决策 引擎对用户的访问进行授权决策，请求中包含用户Session ID、要访问 的URL及访问方法(如GET、 POST)。授权决策引擎将授权决策结果返回 给OnPreprocHeaders (...)。OnPreprocHeaders (...)接收到返回的授权决策结果后，作进一步的 处理。若结果是拒绝，且原因是未鉴别用户，则转入到前面的未鉴别用 户登录处理；若结果是拒绝，且拒绝原因是等待鉴别用户，则通过调用 pHeaderlnfo-〉SetHeader(…)直接修改HTTP请求中的URL,使之指向登 录页面，然后退出；若结果是拒绝，且拒绝原因是无权限，则通过调用 pHeaderlnfo->SetHeader (...)直接修改HTTP请求中的URL，使之指向相 应出错页面，然后退出。若授权决策结果是允许，则通过调用 pHeaderlnfo-〉SetHeader(…)直接修改HTTP i會求中的URL，去掉其中包 含的Session ID信息，然后返回。(这一实施过程对应工作流程中的A5、 A7)无论何种情况，在OnPreprocHeaders (…)进行完有关处理，退出前， 都要向拦截响应消息的回调函数OnSendRawData(…)传送与Session ID 传递有关的控制信息。具体步骤如下OnPreprocHeaders (…)首先从传递给它的结构pCtxt中取出指针 pCtxt->m_pFC->pFilterContext ( pFi IterContext的类型是void*,其 ^Hl是NULL);然后用pCtxt->m—pFC_>pFiIterContext = (void*)pCtxt->AllocMem (s izeof (SessionContext), 0), 为 pFilterContext分酉己一内存空间，其中结构SessionContext为 struct SessionContextchar SessionID[MAX- SESSION—ID—LEN]; 〃Session ID字|殳int RespBlockCnt; 〃已接收响应消息块计it字段bool RespChunkedFlag;〃响应消息为chunked传l命编码标志字賴long RespContentLength; 〃响应消息主体的凝:据长度字段long RespAccMsgLen; 〃累计已接收的响应消息主体数据长度字段接下来，OnPr印rocHeaders(…)将用户的Session ID值XXXXX,赋给 pFilterContext所指SessionContext结构变量之中的SessionID字段， 将RespBlockCnt字辛殳置为零，之后OnPr印rocHeaders (...)退出。(以上 实施过程对应于关键技术问题(Cl)的Cll、 ( Dl )的Dll)需指出的是pCtxt->m_pFC-〉pFilterContext对应于IIS服务器传给 过滤器回调函数HUpFilterProc(...)的一个HTTP-FILTER—CONTEXT结构 变量中的指针pFilterContext。 C. 0nSe威awData (CHttpFilterContext* pCtxt， PHTTP—FILTER—RAW—DATA pRawData)0nSendRawData (...)在IIS服务器发送HTTP响应lt据时被触发调 用，它的功能是进行URL重写，在指向本地的URL链接中保存当前用户 的Session ID,即实现发明内容中工作流程A9所涉及的关键技术(Cl) (步骤C12)、 (C2),关键技术问题(Dl)(步骤D12)、 (D2)、 ( D3 ),其 具体实施如下。0nSendRawData (…)首先从IIS服务器传递给它的结构 pCtxt->m_pFC->pFilterContext中取出pFiUerContext指针，若 pFilterContext为空，则直接返回；若不为空，则从pFi 1 terContext指 针所指SessionContext结构中的SessionID字段取出用户SessionID值XXXXX。在试验用pFilterContext所指结构前，先4夸pFi 1 terContext强制 转换为指向SessionContext结构。(这对应于关键技术问题(Cl )的C12 ) OnSendRawData (…)从IIS服务传给它的pRawData指针所指的结构中 可获得HTTP响应消息数据块，按发明内容中D12所述方法，通过 pCtxt->m_pFC->pFUterContext所指SessionContext结构中的 RespBlockCnt字段，判断接收到的数据块是否为第一个消息响应数据块。 (这对应于关键技术问题(Dl )的D12 )若拦截的数据块是第 一个消息响应数据块，则进行如下处理 (1 ) >接D21所述方法，判断响应消息是否为chunked传输编码方式， 并依此i殳定传给它的pCtxt—>m—pFC-〉pFilterContext所指结构中的 RespChunkedFlag字段,若是chunked,则设为TRUE,反之，设为FALSE, 然后退出；(2 )若响应消息是非chunked传输编码模式，则进一步按D21所述方 法，从响应数据块中的Content-Length字段中取出响应消息主体的长度 指示值，(21)若长度指示值为零，则OnSendRawData(...)退出； (22 )若长度指示值非零,则0nSendRawData(…)按D31所述将回 调函数间传递信息的结构中的RespContentLength字)殳设为该长度 值，然后将RespAccMsgLen字段设置为零，接下来将响应数据块中的 Content-Length题头字段删除，加上Transfer-Encoding: chunked 题头字段，然后退出。(对应C22的C221) 若拦截的数据块不是第 一个消息响应数据块，则进行如下处理 (1) 4要D22所述方法，通过pCtxt->m—pFC->pFilterContext所指结构中的RespChunkedFlag字段判断响应消息的传输编码才莫式是chunked或非chunked的；(2) 若是chunked ( RespChunkedFlag为TRUE )，则对响应内容中所 有指向本地的有效URL链接进行重写，加入？... SessionlD-XXXXX…模式 的Query string,其中字串SessionID (可用其他字串符号)表示用户 Session ID信息，字串XXXXX表示Session ID的值，然后退出；(对应 C21对chunked响应凄t据块的处理)(3) 若是非chunked ( RespChimkedFlag为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. OnEndOfNetSessiorUCHttpFilterContext* pCtxt)0nEnd0fNetSession (CHttpFi 1 terContext* pCtxt)在IIS月良务器完成 一个HTTP请求/响应的处理时被触发调用，它什么不做即返回。它的作 用是让I IS服务器释放由Al locMem (...)分配的内存。 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访问控制过滤器初始化时创建初始化，如由GetFi 1terVers ion (PHTTP—FILTER—VERSION pVer)创建初始化，或者第一次使用时创建初始化。另 一种方式是将Session维护引擎作为一个运行在IIS服务器上的独 立进程实现，ISAPI访问控制过滤器通过进程间通信(Inter-process comfflunicat ions, IPC)与Sess ion维护独立进程进4亍信息交互。相对于 前一种方式，这种方式的性能略差，但开发、调试和维护要容易。比如， 用Java 4支术来开发一个Session维护独立进程非常简单。总之，只要实现所需的功能，Session维护引擎有多种的实施方式， 且不存在技术障碍。3) 授权决策引擎授权决策引擎主要实现工作流程A6中与之有关的功能，即根据ISAPI 的授权决策请求对用户的资源访问做出决策。与Session维护引擎类似， 只要实现本发明所述功能，它有多种的实施方式和方法。与Session维 护引擎类似，它既可以作为一个模块实现，与ISAPI访问控制过滤器一 同加载并被ISAPI过滤器直接调用，也可以作为一个运行在IIS服务器 上的独立进程实现。授权决策引擎的实现是直接的，不存在技术障碍。4) 身份与权限管理系统 身份与权限管理系统实现步骤A43、 A46中与之有关的功能。只要实现本发明所述功能，它有多种的实施方式，下面描述其中一种实施方式。 身份与权限管理系统包括三部分(如图2所示)身份与权限服务器 Tll，身份与权限数据库T12和身份与权限份管理器T13。身份与权限数 据库可釆用任一支持LDAP (Lightweight Directory Access Protocol) 的数据库系统，它存放用户身份信息(如用户ID、用户组、角色)、访问 控制策略等，具体存放信息的内容和形式与访问控制方法(如ACL、 RBAC等)有关；身份与权限服务器是一个基于Java的服务进程，对外提供了 身份与权限信息创建、更新、删除、查询等的服务接口，服务接口的方 式包括RMI、 Web Services;身份与权限份管理器提供身份与权限管理的 人机交互界面，可采用JSP/Servlet及其他Web技术实现。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现 有技术。
权利要求
1、一种Session ID全透明传递的ISAPI访问控制系统，它包括四个组成部分ISAPI访问控制过滤器负责进行访问控制的授权实施，当用户通过浏览器访问部署在IIS服务器上的Web应用系统时，该访问控制过滤器拦截HTTP请求和响应，进行用户身份鉴别、访问控制授权实施以及用户Session ID(Session标识)的传递；Session维护引擎负责为每一个Web服务访问用户创建一个Session对象并产生相应Session ID，从身份与权限管理系统获取用户身份信息填充Session对象，将用户其他状态信息保存到Session对象，以及提供Session信息、身份信息的查询，删除超时不用的Session对象等；授权决策引擎根据用户的身份和权限信息及资源访问控制策略，对用户访问资源的请求进行授权决策；身份与权限管理系统保存、维护用户的身份信息、资源的访问控制策略，并提供用户身份信息及资源访问控制策略的查询服务。
2、 根据权利要求1所述的一种Session ID全透明传递的ISAPI访 问控制系统，其特征在于按如下步骤实施访问控制功能第一步骤用户访问IIS服务器上部署的Web应用系统； 第二步骤ISAPI访问控制过滤器响应SF-N0TIFY—PREPR0C—HEADERS事件通知，拦截HTTP i青求头部，根据请求URL中是否包含有效的SessionID、身份鉴别信息以及当前URL指向，对用户类别进行判断，然后根据不同用户类别分别转入第三、第四或第五步骤；第三步骤对未鉴别用户，即初次登录Web应用系统的用户，ISAPI访问控制过滤器首先请Ses s ion维护引擎创建用户Ses s ion对象并返回Session ID j矣下来将用户HTTP请求重定向到登录页面，之后向拦截HTTP 响应消息数据的ISAPI过滤器回调函数传送与Session ID传递有关的控 制信息，然后退出；第四步骤对等待鉴别用户，即未鉴别但正通过登录页面提交身份 鉴别信息的用户，ISAPI访问控制过滤器转入用户身份鉴别处理，对于鉴 别未通过的用户，则将其HTTP请求重定向到登录页面，之后向拦截HTTP 响应消息数据的ISAPI过滤器回调函数传送与Session ID传递有关的控 制信息，然后退出；对于鉴别通过的用户，继续后续步骤；第五步骤对已鉴别用户，ISAPI访问控制过滤器请求授权决策引擎 进行授权决策，请求中有用户Session ID、要访问的资源URL及访问方 法；第六步骤对于ISAPI访问控制过滤器提交的授权决策请求，授权 决策引擎从Session维护引擎查询该用户是否是有效的已鉴别用户并获 取所需的用户信息，然后根据用户身份、用户权限以及相应的访问控制 策略，决定是否允许用户访问有关的资源，之后将授权决策结果返回给 ISAPI访问控制过滤器；第七步骤ISAPI访问控制过滤器依授权决策引擎的授权决策结果对 用户HTTP请求进行访问控制授权实施，之后向拦截HTTP响应消息数据 的ISAPI过滤器回调函凄t传送与Session ID传递有关的控制信息，然后 退出；第八步骤IIS服务器将ISAPI访问控制过滤器处理后的HTTP请求提 交给Web应用系统，Web应用系统完成用户请求处理后返回响应结果；第九步骤ISAPI访问控制过滤器响应每个SF—NOTIFY_SEND_RAW_DATA 事件通知，依次拦截每个HTTP响应消息数据块，若拦截的是第一个响应 消息数据块，即仅包含响应消息头部的数据块，则ISAPI访问控制过滤器设定与Session ID传递有关的控制信息；若拦截的是后续响应消息数 据块，即响应消息主体数据块，ISAPI访问控制过滤器对块中所有指向本 地的URL链接进行重写，加入用户Session ID信息，然后退出；第十步骤应用服务系统完成响应结果发送后，ISAPI访问控制过滤 器响应SF-NOTIFY—END—OF—NET—SESSION事件通知，不做任何处理，立即 退出。
3、 才艮据权利要求2所述的一种Session ID全透明传递的ISAPI访 问控制系统，其特征是所述第三步骤转移到用户登录处理后，按如下 步骤进行处理第一步ISAPI访问控制过滤器请求Sess ion维护引擎为用户创建一 个Session对象，请求中有用户当前访问的URL，若该URL本身就是登录 URL，则URL为空；第二步Session维护引擎收到请求后,为该用户创建Session对象 并产生对应的Session ID，将请求中的URL保存到Session对象中作为 URL历史，然后返回Session ID到ISAPI访问控制过滤器；第三步ISAPI访问控制过滤器接收到返回的用户Session ID后， 直接修改HTTP请求头部中的URL,使之指向登录页面，之后向拦截HTTP 响应消息数据的过滤器回调函数传送与Session ID传递有关的控制信 息，然后退出。
4、 才艮据权利要求2所述的一种Session ID全透明传递的ISAPI访 问控制系统，其特征是所述第三、四、七、九步骤中，处理HTTP请求 /响应的ISAPI过滤器回调函数之间利用一个IIS服务器传递给回调函数 的HTTP—FILTER_CONTEXT结构参数中的pFi 1 terContext指针，传递一个 包含如下信息字段的共用数据结构变量(1) Session ID字段;(2 )已接收响应消息块计数器字段；(3) 响应消息为chunked传输编码标志字,殳；(4) 响应消息主体的数据长度字段；(5 )累计已接收的响应消息主体数据长度字,殳。 且响应SF—N0TIFY-PREPR0C-HEADERS事件的ISAPI过滤器回调函数， 在每次完成响应处理后，退出前，将"Session ID"字段的值设置为当 前用户的Session ID值，将"已接收响应消息块计数器"字段的值设置 为0。
5、 根据权利要求2所述的一种Session ID全透明传递的ISAPI访问 控制系统，其特征是所述第九步骤每次拦截响应数据块时，先按如下 方法判断接收的数据块是否为仅包含HTTP响应头部的第 一个响应消息数 据块每拦截一个HTTP响应数据块，将回调函数间传递信息的数据结构变 量中的"已接收响应消息块计数器"字段加l，若加l后结果为l,则当 前拦截的HTTP响应数据块是仅包含HTTP响应头部的第一个响应数据块， 否则为后续响应消息数据块。
6、 才艮据权利要求2所述的一种Session ID全透明传递的ISAPI访问 控制系统，其特征是所述第九步骤响应每个SF—N0TIFY_SEND_RAW—DATA 事件通知，当拦截的响应消息数据块是第 一个仅包含响应消息头部的数 据块时，则按如下步骤设定与Session ID传递有关的控制信息步骤1:查看该响应消息数据块是否包含Transfer-Encoding: chunked 题头字段，如包含则转入步骤2，否则转入步骤3步骤2:将回调函数间传递信息的数据结构中的"响应消息为chunked 传输编码标志，，字段设为TRUE,结束设置；步骤3:进行如下信息设定(1)将回调函^t间传递信息的数据结构中的"响应消息为chunked 传输编码标志"字l殳-i殳为FALSE;(2 )从该响应消息凝:据块中的Content-Length字段中取出响应消息 主体的长度指示值，并将回调函数间传递信息的结构中的"响应消息主 体的数据长度"字段设为该长度值；(3) 将其中的"累计已接收的响应消息主体数据长度"字段设置为零；(4) 将该响应消息头部数据块中的Content-Length题头字^:删除， 然后加上Transfer-Encoding: chunked题头字^殳，然后结束设置。
7、 根据权利要求2所述的一种Session ID全透明传递的ISAPI访问 控制系统，其特征是所述第九步骤响应SF—NOTIFY—SEND—RAW—DATA事 件通知时，按如下步骤对每个拦截的响应消息主体数据块中的URL链接 进行重写第一步ISAPI访问控制过滤器回调函数从IIS服务器传递给它的 HTTP—FILTER—CONTEXT结构参凄t中的pFi IterContext指针所指结构变量 中的"Session ID"字,殳取得用户的Session ID值;第二步ISAPI访问控制过滤器回调函数对HTTP响应数据块中所有指 向本地的URL链接进行重写，使之加入？... SessionID-XXXXX...模式的 Query string,其中XXXXX为按第一步取得的用户Session ID值;第三步若发生了URL重写，则修改响应消息数据块的长度指示。
8、 根据权利要求7所述的一种Session ID全透明传递的ISAPI访问 控制系统，其特征是对响应消息主体数据块中的URL链接进行重写后， 按如下步骤修改响应消息数据块的长度指示步骤l:;险查回调函数间传递信息的数据结构中的"响应消息为 chunked传输编码标志，，字段，如果其值为TRUE,则转入步骤2，否则，转入步骤3;步骤2:直接修改该chunked传输编码方式的响应消息主体数据块中 的chunk长度指示，结束修改；步骤3:在该响应消息主体数据块前面加上一个chunk长度指示，使 之变为chunked的传输编码方式下的一个响应消息数据块，然后进一步 判断该数据块是否是最后一个响应响应消息主体数据块，若是，则在数 据块后面还要再加上一个chunk结束标识。
9、根据权利要求8所述的一种Session ID全透明传递的ISAPI访问 控制系统，其特征是所述步骤3之方法修改非chunked传输编码方式 的响应消息块的长度指示时，按如下方法确定接收到响应消息数据块是 否为最后一个响应消息主体数据块将回调函数间传递信息的数据结构中的"累计已接收的响应消息主体 数据长度，，字段与当前响应数据块的长度累加并更新其值，若累加、更 新后该"累计已接收的响应消息主体数据长度"字段值与数据结构中保 存的"响应消息主体的数据长度"字段的值相等，则确定当前的响应数 据块为最后一个数据块。
全文摘要
本发明涉及一种具有Session全透明传递的ISAPI访问控制系统，它能在Web系统不参与、不修改以及不使用Cookie的情况下，实现用户Session维护及Session ID的传递，为部属在IIS服务器上的Web应用提供用户身份鉴别和访问控制功能。它包括四个组成部分ISAPI访问控制过滤器，Session维护引擎，授权决策引擎，身份与权限管理系统。本发明成功解决了在ISAPI访问控制过滤器重写响应消息中的URL链接加入Session ID信息时所涉及的关键技术问题，如在过滤器回调函数间传递相关信息，正确地修改响应消息数据块中的长度指示等。
文档编号H04L29/06GK101247395SQ20081004705
公开日2008年8月20日 申请日期2008年3月13日 优先权日2008年3月13日
发明者唐志红, 张海松, 汪克炎, 龙毅宏 申请人:武汉理工大学;北京天威诚信电子商务服务有限公司