网络应用访问转让专利

申请号 : CN201080012291.6

文献号 : CN102356620A

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : R·曼那尼S·霍维

申请人 : 英国电讯有限公司

摘要 :

一种为用户提供对服务器上运行的网络应用的访问(作为网络门户会话的一部分)的计算机网络和相应方法。所述网络包括经由中间网络服务器相连接的第一通信量管理器和第二通信量管理器。所述第一通信量管理器包括接口装置,所述接口装置用于从所述用户接收访问所述网络应用的请求(进行作为门户会话的一部分),并且用于将所述请求传送给所述中间网络服务器;用于转送至所述第二通信量管理器。所述第二通信量管理器包括接口装置,所述接口装置用于经由所述中间网络服务器从所述第一通信量管理器接收所述请求,并且用于将接收到的所述请求传送给所述网络应用。

权利要求 :

1.一种对访问网络应用的用户进行验证的方法,其中,对访问网络应用的用户进行验证是网络门户会话的一部分,所述方法包括以下步骤:从网络浏览器接收访问所述网络应用的请求;其中所述请求包括网络门户会话Cookie;

在第一通信量管理器处,检测所述请求中提供的所述网络门户会话Cookie;

当已经检测到网络门户会话Cookie时,检查所述请求中是否有所述第一通信量管理器生成的、表示授权所述用户访问所述应用的Cookie;以及当在所述请求中找到所述第一通信量管理器生成的所述Cookie时,将所述请求经由中间网络服务器转送到第二通信量管理器;其中所述第二通信量管理器将所述请求转送到所述应用。

2.根据权利要求1所述的方法,其中,当在所述请求中没有找到所述第一通信量管理器生成的、表示授权所述用户访问所述应用的Cookie时,所述第一通信量管理器将所述请求转送到所述中间网络服务器,以对访问所述应用的用户进行验证和授权;

其中,在接收到来自所述中间网络服务器的、表示对所述用户的验证和授权成功的响应时,所述第一通信量管理器生成表示授权所述用户访问所述应用的Cookie,并且在对所述请求的响应中将所述Cookie发送给所述网络浏览器;

其中所述响应要求所述网络浏览器重新提交合并有在所述响应中发送的所述Cookie的所述请求。

3.根据权利要求1或2所述的方法,其中,所述第二通信量管理器将所述请求连同经由所述中间网络服务器从数据库提供的识别所述应用的信息一起,转送到所述应用。

4.根据权利要求1至3中任意一项所述的方法,其中,对所述第一通信量管理器生成的所述Cookie进行加密。

5.根据权利要求1至4中任意一项所述的方法,其中,所述应用利用包括所述应用生成的一个或者更多个Cookie的响应,对所述第二通信量管理器转发的所述请求进行响应。

6.根据权利要求5所述的方法,其中,由所述应用生成的所述一个或者更多个Cookie被名称分隔,其中每个名称分隔对应于所述第一通信量管理器上运行的不同虚拟服务器。

7.根据权利要求1至6中任意一项所述的方法,其中,当从所述第一网络通信量管理器接收到所述请求时,所述中间网络服务器验证所述门户会话并且保持所述门户会话继续有效。

8.一种存储有处理器可执行指令的计算机可读介质,当在通用计算机上运行所述处理器可执行指令时,使得执行权利要求1至7中任何一项所述的方法。

9.一种计算机网络,该计算机网络用于为用户提供对服务器上运行的网络应用的访问,其中,为用户提供对服务器上运行的网络应用的访问是网络门户会话的一部分,其中,所述网络包括:经由中间网络服务器连接的第一通信量管理器和第二通信量管理器;其中所述第一通信量管理器包括如下接口装置,该接口装置用于从所述用户接收访问所述网络应用的请求,并且用于将所述请求传送到所述中间网络服务器,以转送到所述第二通信量管理器,其中,从所述用户接收访问所述网络应用的请求是所述门户会话的一部分;其中所述第二通信量管理器包括如下接口装置,该接口装置用于经由所述中间网络服务器从所述第一通信量管理器接收所述请求,并且用于将所接收到的请求传送到所述网络应用。

10.根据权利要求9所述的计算机网络,该计算机网络包括授权管理器,所述授权管理器用于从所述中间网络服务器接收所述请求,并且将响应返回到所述中间网络服务器,以转送至所述第一通信量管理器;其中所述响应包括所述用户访问所述网络应用的授权状态的指示符。

11.根据权利要求10所述的计算机网络,其中,所述响应包括所请求的网络应用所需的附加参数。

12.根据权利要求10或11所述的计算机网络,其中所述响应包括与所述网络应用相关的地址信息和与运行所述应用的服务器相关的地址信息之间的映射。

13.根据权利要求9至12中任意一项所述的计算机网络,其中,所述第一通信量管理器被配置用于检查所述请求,以确定所述请求是否是在当前网络门户会话期间从所述用户第一次接收到的针对所述网络应用的第一请求(第一请求);其中,所述第一通信量管理器被配置用于,当确定所述请求是第一次接收到的第一请求时,将所述请求传送到所述中间网络服务器,以对所述请求进行验证并且授权所述用户访问所述网络应用,并且被配置用于从所述中间网络服务器接收表示所述请求的和所述用户的状态的响应;并且其中所述第一通信量管理器被配置用于当在所述响应中表示所述请求有效且在所述响应中表示所述用户被授权时,生成表示有效且被授权的状态的一个或者更多个Cookie,以将所述一个或者更多个Cookie添加到所述响应中,并且将所述响应转送到所述用户,其中所转送的响应包括要求所述用户重新提交具有所述第一通信量管理器生成的所述一个或者更多个Cookie的所述第一请求的指示符;其中通过检查所述请求中是否存在由所述第一通信量管理器所生成的所述一个或者更多个Cookie,来确定所述请求是否是第一次接收到的所述第一请求。

14.一种用于为用户提供对服务器上运行的网络应用的访问的反向代理,其中为用户提供对服务器上运行的网络应用的访问是网络门户会话的一部分,其中所述反向代理包括经由中间网络服务器连接的第一通信量管理器和第二通信量管理器。

说明书 :

网络应用访问

[0001] 本发明总体上涉及网络应用及对网络应用的访问的领域。
[0002] 本发明致力于解决双网站运行中涉及的问题,例如何处可获得对网络应用(可能由第二方提供或者也可能不是由第二方提供)的访问,以通过服务供应商网络门户(可能由第三方提供或者可能不是由第三方提供)来将服务交付给用户,例如所述网络门户在何处能够进行单一登录(SSO,single sign-on)。
[0003] 图1示出常规通信网络,所述常规通信网络经由浏览器12和因特网14,为用户10提供对后端服务器(BES,back-end server)28上的应用(例如App1、App2、App3)的访问。浏览器12经由因特网14连接到网络交换机16,所述网络交换机16例如是提供诸如负载均衡和地址转换的标准功能的思科ACE(Cisco ACE)。网络交换机16与网络服务器40通信,所述网络服务器40例如是托管用于网络门户的SiteMinder单一登录网络代理的SunOne服务器。网络服务器40连接到策略服务器42和托管网络门户的应用服务器50。
[0004] 为了能够使用常规单一登录来访问后端服务器(BES)28上运行的应用,用户10首先必须通过经由网络服务器40登录到网络门户50来进行认证。为了允许访问BES28上运行的应用(比如App1),成功登录后,门户网络服务器40在浏览器12上显示经认证的已登录用户可访问的应用列表。只有授权用户访问的那些应用会由应用服务器50上的网络门户经由网络服务器40在浏览器12上显示给用户。因特网14中包括有未示出的域名服务器(DNS,domain name server)。利用图1的单一登录系统,BES 28上运行的所有应用(例如App1、App2、App3)共享单个域名服务器(DNS)的记录(例如:sso.)。当经由服务器40登录网络门户的用户选择浏览器12中显示的网页上所显示的代表BES 28上运行的应用之一的提示信息时,浏览器12打开新窗口并且生成请求,所述请求包括在DNS中与门户网络服务器40的公共IP地址相关联的URL。当接收到所述请求时,门户网络服务器40上的单一登录网络代理对用户10进行认证,认证成功后,门户网络服务器40将所述请求转送给单一登录代理服务器18。单一登录代理服务器18参考门户数据库32,负责对来自用户10的访问BES28上的应用的请求进行授权,并且负责将用户请求代理到BES 28。
[0005] 根据(在请求URL中所包括的)上下文路径来确定BES 28上作为所述请求的对象的具体应用。请求用户10由网络服务器40上的单一登录网络代理加入所述请求中的HTTP报头“SM_USER”来标识。用户授权所需的任何其他信息或者在所述请求中提供,或者从门户数据库32获得,由此验证用户访问所请求的应用的授权。
[0006] 如果网络服务器40上的单一登录网络代理进行了认证,并且单一登录代理服务器18授权用户访问所请求的应用,则单一登录代理服务器18利用Apache Httpclient库,按照常规方式将所述用户请求代理到EBS 28。为了通过单一登录来访问应用,代理服务器18负责将HTTP报头中的、用于认证和授权请求用户10所需的任何信息发送到BES 28。代理网络服务器40上的单一登录网络代理处理BES 28对用户请求的响应,以去除标识BES
28上的应用的任何参数,诸如IP地址、DNS记录以及端口号,从而使得来自浏览器12的任何访问BES 28上的资源的进一步请求都被寻址至网络服务器40上的单一登录网络代理,而不是直接到BES 28。在单一登录代理服务器18上经过适当处理后,来自BES 28的响应经由网络服务器40沿返回路径返回浏览器12。
[0007] 图1的常规访问系统具有若干缺点。性能因低效的授权和与后端系统的通信而受到限制。对请求进行授权的逻辑相当复杂,因为根据所述请求中的上下文来识别应用很复杂,当所述请求经过单一登录代理服务器18时,需要大量定制编码来处理该请求和响应。
[0008] 多个同时请求需要在单一登录代理服务器18上创建附加线程。因此用户数量受到单一登录代理服务器18所能够处理的同时发生的线程数量的限制。线程的数量具有实践极限,因为允许大量线程会给SSO代理应用服务器18的性能带来负面影响。常规访问系统不支持诸如负载均衡、故障支持以及连接监测这样的希望获得的特性。
[0009] 本发明旨在对作为网络门户会话的一部分的、用于提供对网络应用的访问的已知方法和计算机网络进行改进。根据第一方面,通过一种计算机网络来实现本发明的目的,所述计算机网络包括:经由中间网络服务器连接的第一通信量管理器和第二通信量管理器。所述第一通信量管理器包括接口装置,所述接口装置用于从用户接收对网络应用的访问的请求(作为门户会话的一部分的),并且用于将所述请求传送给所述中间网络服务器;用于转送给所述第二通信量管理器。所述第二通信量管理器包括接口装置,所述接口装置用于经由所述中间网络服务器从所述第一通信量管理器接收请求,并且用于将接收到的所述请求传送给所述网络应用。
[0010] 所述计算机网络有利地实现了高效门户会话验证,以及部件(例如两个通信量管理器和中间网络服务器)之间的工作量分配。
[0011] 根据第二方面,通过对用户进行验证(作为网络门户会话的一部分)的方法来实现本发明的目的。所述方法包括如下步骤:从网页浏览器接收访问所述网络应用的请求;其中所述请求包括网络门户会话Cookie。所述方法还包括:在第一通信量管理器处检测所述请求中提供的所述网络门户会话Cookie;当检测到网络门户会话Cookie时,检查所述请求中是否有由所述第一通信量管理器生成的表示授权用户访问应用的Cookie。如果在所述请求中找到由所述第一通信量管理器生成的所述Cookie,则经由中间网络服务器将所述请求转送给第二通信量管理器;所述第二通信量管理器将所述请求转送给所述应用。
[0012] 根据另一方面,在对第一请求进行检测时,所述第一通信量管理器将所述请求转送给所述中间网络服务器以进行认证和授权,从而确保所述会话有效。为了避免在后续请求时重复验证所述会话,所述第一通信量管理器将特定Cookie插入对所述第一请求的响应中。在同一用户于同一门户会话中发布的对同一应用的后续请求中,重复这些特定Cookie。后续请求中存在这些特定Cookie使得第一通信量管理器可省略进一步验证步骤。
[0013] 根据又一方面,第二通信量管理器将所述请求,连同经由中间网络服务器从数据库提供的、用于识别所述应用的信息一起转送到所述应用。
[0014] 根据又一方面,第一通信量管理器无须进行任何处理来确保会话继续有效;因为此功能由中间网络服务器实施。从第一网络通信量管理器接收到所述请求时,在转送该请求前,中间网络服务器对所述门户会话进行验证并且保持所述门户会话继续有效。
[0015] 根据又一方面,所述应用生成的一个或更多个Cookie被名称分隔(name-space),其中每个名称分隔与第一通信量管理器上运行的不同虚拟服务器相对应。名称分隔便于避免所述后端服务器设置的Cookie名称与网络门户或者通信量管理器设置的Cookie名称之间的冲突。
[0016] 为了辅助理解本发明,下面参照附图仅以示例的方式描述几个实施方式,在附图中:
[0017] 图1示出常规基于网络的IT系统的示意图;
[0018] 图2示出根据本发明的实施方式的基于网络的IT系统的示意图;
[0019] 图3a、3b和图4示出根据本发明的实施方式的带有例示了信息流的注解的图2的示意图;
[0020] 图5和图6示出根据本发明的实施方式的示意性信号流;
[0021] 图7示出用于实现本发明的服务器的示意图;
[0022] 图8示出用户浏览器上显示的登录页面的屏幕快照。
[0023] 下面参照图2至图8来描述本发明的具体实施方式。
[0024] 图2示出根据本发明的第一实施方式的基于网络的IT系统(计算机网络)。采用相同的参考标记来指代图1和图2中相同的特征。
[0025] 图2示出了用户10经由浏览器12和因特网14访问后端服务器(BES)28上的应用。浏览器12经由因特网14连接到网络交换机16,例如思科ACE(Cisco ACE),其提供诸如负载均衡和地址转换的标准功能。网络交换机16与第一通信量管理器20和网络服务器40通信,所述第一通信量管理器20例如是F5 BIG-IP或者Zeus ZXTM网络通信量管理器,而所述网络服务器40例如是托管网络门户的SiteMinder单一登录网络代理的SunOne服务器。
[0026] 防火墙25将所谓“红侧”元件与所谓“绿侧”元件分开,所谓“红侧”元件未经验证并存在潜在安全风险,而所谓“绿侧”元件位于受控环境内,诸如机构组织的专用内部网络,并且被认为是安全的且不存在安全风险。如图2所示,根据优选实施方式,第一通信量管理器20与其他所谓“红侧”元件10、12、14、16、40以及42共同占据防火墙25的所谓“红侧”,而元件22、24、26、30、32以及50位于防火墙25的安全的所谓“绿侧”。BES 28可以实现为单个服务器或者多个服务器,并且不受地理位置的限制,可位于防火墙25的红侧或者绿侧。
[0027] 第一通信量管理器20与“绿侧”的中间网络服务器22通信:所述中间网络服务器22是位于防火墙25的绿侧的、托管单一登录网络代理的服务器,其在第一通信量管理器20与第二通信量管理器26之间。中间网络服务器22和代理网络服务器40(proxy web server)二者与策略服务器42通信。根据本实施方式,中间网络服务器22还与“绿侧”的第二网络交换机24通信,该第二网络交换机24例如是提供包括负载均衡的常规功能的思科ACE。网络交换机24与“绿侧”的第二通信量管理器26通信,第二通信量管理器26例如是F5BIG-IP或者Zeus ZXTM网络通信量管理器。稍后会针对服务器群,介绍更多第二网络交换机24的信息。第二通信量管理器26被委托代理BES 28上的应用(App1、App2、App3)。
[0028] 策略服务器42保存有由门户网络服务器40和中间网络服务器22运行的安全策略的详细资料。认证管理器30和数据库32例如基于用户请求的URL、针对所述URL的应用设置以及数据库32中与所请求的应用有关的用户配置文件设置,来为用户认证提供支持。
[0029] 下面参照图2、图3a、图3b以及图5来描述图2中关于来自用户的访问BES 28上运行的应用的第一请求进行处理的网络运行。图3a和3b包括箭头(310-340),用于例示下文描述的关于图2的系统的各种信息流。
[0030] 在运行中,用户10尝试经由浏览器12和因特网14访问BES 28上运行的应用之一(例如应用App1)。首先,用户10需要登录其拥有账号的网络门户,以便建立会话并且获得对应网络门户会话Cookie和用户名Cookie。用户的门户登录请求由网络交换机16送往运行单一登录网络代理的门户网络服务器40,该单一登录网络代理担当应用服务器50上托管的网络门户的前端。
[0031] 第一请求
[0032] 用户按照如下步骤发起第一登录请求。用户在其浏览器12上选择网络服务器40的地址(即,URL)。因特网14中包括的域名服务器(未示出)按照常规方式来确定此请求的目的地。根据从浏览器12选择的URL,经由因特网14和网络交换机16将所述请求路由到门户网络服务器40(参见图3a中的310)。门户网络服务器40经由反向路径(312)提供登录页面(例如如图8中所示)以通过浏览器12显示给客户。所述登录页面被设置为向用户提示凭证(credential)(例如用户名和密码),从而支持用户登录到网络门户的请求。用户10在网页上输入所请求的信息,并且通过选择网页上显示的提示(例如“登录”),将输入的数据沿着与原始请求相同的路径(310)返回门户网络服务器40。在门户网络服务器40上运行的单一登录网络代理将用户身份信息和用户凭证转送到策略服务器42以进行验证。如果策略服务器42利用所提供的信息发现可正确识别所述用户,则由此通知门户网络服务器40,并且门户网络服务器40提示应用服务器50沿着与原始登录页面相同的路径(312)提供另一网页(“门户网站主页”),以呈现给用户。
[0033] 根据优选实施方式,应用服务器50提供的且呈现在浏览器12上的所述另一网页为用户提供了用户名Cookie、网络门户会话Cookie以及对网络应用(例如在BES 28上运行的App1、App2、App3)的选择,其中用户可通过选择所述网页上的适当服务交付提示来访问所述网络应用。根据优先实施方式,所述另一网页为用户提供网络门户50所生成的用户账户标识符参数(例如“gbcAccountld”)。通过选择适当服务交付提示,用户使浏览器12生成用于请求服务交付BES 28上的应用的第一请求。此请求经由因特网14和网络交换机16被路由(314)到第一通信量管理器20。当用户已登录到所述网络门户时,第一服务交付请求(例如形式为“GET”)将在URL的HTTP报头部分中包含作为网络门户登录的一部分生成的用户名Cookie和网络门户会话Cookie。有效请求还在查询字符串中包含由网络门户50所生成的用户账户标识符参数,作为URL的一部分。
[0034] 参考图5中的顺序图。第一服务交付请求5.1在因特网14上,通常利用安全套接层(SSL,secure socket layer),经由安全链路从浏览器12路由到第一通信量管理器20。
[0035] 第一通信量管理器20也保存有呈现(316)给用户的数字证书,以向用户提供用户与有效目的地通信的再保证。第一通信量管理器20提供初步验证检查,也就是说,检查所述第一服务交付请求中是否有网络门户会话Cookie和用户名Cookie。在此阶段并不验证这些Cookie的实际内容。然而,如果第一通信量管理器20没有在所述请求中找到适当Cookie,则会为用户提示新登录页面,并且所述服务交付处理暂不进行,直至提供预期Cookie。
[0036] 随后第一通信量管理器20检查所述请求中是否有用户名Cookie的散列后的变体(hashed variant)(详情稍后描述)。如下所述,如果没有找到散列后的用户名Cookie(hashed username cookie),则第一通信量管理器20在所述请求中设置表示在所述第一通信量管理器20中将创建散列后的用户名Cookie的标记。所述标记的形式为:
[0037] connection.data.set(“createUsernameHash”,“ture”);
[0038] 第一通信量管理器20还检查当前请求是否是针对网络应用的后续(即不是第一个)服务交付请求。第一通信量管理器20检查在所述请求中是否存在所请求的应用的应用SSO数据Cookie(详情稍后描述)。如果所述请求是用户登录所述网络门户后由用户所做出的针对所述网络应用的第一服务交付请求,则不会存在应用SSO数据Cookie。
[0039] 如果应用SSO数据Cookie不存在,但是在所述请求URL查询字符串中找到了所述用户名Cookie、网络门户会话Cookie以及用户账户标识符参数,则通信量管理器20将当前请求看作针对特定网络应用的有效的第一服务交付请求。如果发现所述请求是有效的第一请求,则第一通信量管理器20将字符串“/authm”插入服务交付请求URL中。随后第一通信量管理器20将所述第一服务交付请求(包括所述用户名Cookie、网络门户会话Cookie以及用户账户标识符参数)转送(318)到中间网络服务器22,用于进一步验证和授权,并且用于检索所请求的网络应用所需的参数(例如合并有用于BES 28的用户凭证、用户详细信息等的报头),参见图5中的5.2。
[0040] 中间网络服务器22还连接到策略服务器42和授权管理器30。因此中间网络服务器22的单一登录网络代理能够识别出对于受保护资源的无效用户请求。中间网络服务器22通过向策略服务器42(如上所述,即与门户网络服务器40使用的相同的策略服务器)查询(320)从第一通信量管理器20接收到的请求中所包括的网络门户会话Cookie,来对所述Cookie进行验证。策略服务器42核实所述网络门户会话Cookie是否有效以及会话是否尚未超时。策略服务器42也酌情更新会话,防止所述会话过早超时。
[0041] 中间网络服务器22从策略服务器42接收所述会话Cookie的验证结果,如果结果为肯定的,则通过将所述服务交付请求转送(322)到授权管理器30(参见图5中的5.3),来对第一通信量管理器20在所述请求中包括“/authm”内容(表示有效的第一请求)作出反应。中间网络服务器22上的单一登录网络代理在发往授权管理器30的所述请求报头中设置参数(例如“SM_USER”)。
[0042] 转发给授权管理器30的所述请求包括所述URL查询字符串中的用户账户标识符参数。用户名Cookie、网络门户会话Cookie以及“SM_USER”参数值包含在标准HTTP报头中。提供给授权管理器30的、与第一请求相关的URL的形式如下:
[0043] http://[:port]/authM/?gbcAccountld=[&gbcLoginname=]
[0044] 提供给授权管理器30的与第一请求相关的URL的示例如下:
[0045] http://subdom.sso.internet.domain.com:7001/authM/abc/home ?gbcAccountld=250031
[0046] 授权管理器30检查是否授权用户访问所请求的应用。在此情况下,授权管理器30查询(324)存储有所述应用和所请求的域名(例如subdom.sso.internet.domain.com)的映射的门户数据库32。
[0047] 更详细的说,授权管理器30从所述服务交付请求中包含的所述用户名Cookie中提取用户的登录名,并且将其与“SM_USER”参数进行对比。使用所述请求中的查询字符串中的用户账户标识符参数来识别用户账户(例如用户的公司),并且(为了识别所请求的应用)使用所述请求的URL来识别所述应用的域名。授权管理器30随后通过根据门户数据库32检查请求此应用的用户是否具有访问所请求的应用的授权,来验证(324)该用户。
[0048] 如果结果为肯定的,则授权管理器30从域服务器32收集(326)所请求的应用的名称、DNS/IP地址、端口等,以及所请求的网络应用所需的附加参数,包括有关报头和指令。授权管理30随后利用“200”响应代码对第一通信量管理器20进行响应(328)。根据一个实施方式,授权管理器30生成字符串响应,因为第一通信量管理器20更易于解析字符串响应。下面是授权管理器30能够发送的响应的一些可能的替代(都是利用HTTP响应代码
200来进行发送)。
[0049] 1、如果在GS数据库中未找到所请求的应用的详细信息,则授权管理器30将在响应主体中利用下列参数对通信量管理器20进行响应:
[0050] Redirect:NO;
[0051] ResponseStatus:404(Not Found(未发现));
[0052] ResponseMessage:Requested Application is not available(请求的应用不可用).
[0053] 2、如果用户未获得查看应用的授权,则授权管理器30将在响应主体中利用下列参数对通信量管理器20进行响应:
[0054] Redirect:NO;
[0055] ResponseStatus:403(Forbidden(禁止));
[0056] ResponseMessage:User is not provisioned for the application(未向用户提供该应用).
[0057] 3、如果用户被识别为所述网络应用的已授权用户,则授权管理器30将在响应主体中利用下列参数对通信量管理器20进行响应:
[0058] Redirect:YES;
[0059] ResponseStatus:302(Found(发现));
[0060] ResponseMessage:User is provisioned for the application(向用户提供该应用);
[0061]
(depends on what is required by SSO application(根据SSO应用需要什么决定));
[0062] ApplicationName:
[0063] HostDetails:.
[0064] 授权管理器30经由中间网络服务器22将所述响应发送(328)给第一通信量管理器20,参见图5中的5.4和5.5。授权管理器30将所请求的网络应用所需的并且从门户数据库32中检索的附加参数包含在所述响应中。第一通信量管理器20将这些附加参数合并到新Cookie中,即应用SSO数据Cookie中,并且发送该新Cookie,作为对浏览器12的响应,参见图5中的5.6。
[0065] 更详细地说,所述应用SSO数据Cookie包括所请求的应用的DNS/IP地址、端口、被第二通信量管理器26视为针对BES上的所请求的应用(例如App1)的池名(pool name)(如后面描述)的应用的名称等,以及所述应用所需的任何其他信息(诸如合并有所述用户的详细信息、BES 28上运行的应用的详细信息、应用凭证、用户凭证、认证方案等)。利用下列各项对所述应用SSO数据Cookie的内容进行加密:从浏览器12请求访问所述应用时所使用的域名、来自所述用户名Cookie的用户名的值以及第一通信量管理器20和第二通信量管理器26上保存的密钥。加密后,在对浏览器12的响应(330)中设置Cookie前,先对所生成的Cookie进行十六进制编码。
[0066] 因为这是用户自登录所述网络门户以后所做出的对所述网络应用的第一请求的响应,所以第一通信量管理器20在从授权管理器30接收的响应(328)中检测到它较早设置的表示将创建散列后的用户名Cookie的标记。第一通信量管理器20通过生成用户名Cookie的散列(例如:SSO_USERNAME_HASH)并将其并入所述响应(330)中,并且通过从所述响应中去除用户账户标识符,来对所述标记的存在进行响应。更详细地说,用户名Cookie的散列包括:较早在连接中设置的用户名的加密的、经散列的且经十六进制编码的值。
[0067] 发送给浏览器12的所述响应携带有响应代码“302”,响应代码“302”表示浏览器应当重新提交所述请求。接收到“302”响应促使浏览器12自动重新提交所述请求(332),而无需用户10的任何操作。重新提交的请求除了包括网络门户会话Cookie和用户名Cookie(来自原始请求)之外,还包括由第一通信量管理器20专为所请求的网络应用而生成的、新散列后的用户名Cookie和应用SSO数据Cookie。因为第一通信量管理器20从针对所述原始请求的响应中去除了所述用户账户标识符,所以重新提交的请求中没有用户账户标识符串。
[0068] 当接收到重新提交的请求时,第一通信量管理器20识别是否存在所述应用SSO数据Cookie。第一通信量管理器20再次将所述请求(334)转送到中间网络服务器22,但因为这次在所述请求URL中缺少所述用户账户标识符,所以未将“/authm”加入请求URL中。在请求URL中缺少/authm导致中间网络服务器22经由第二网络交换机24将所述请求(336)转送到第二通信量管理器26,而不是转到策略服务器42和授权管理器30。根据另一实施方式,作为额外的预防措施,可以仅偶尔或者在每次接收到后续请求时,仍将所述请求转至策略服务器42。
[0069] 第二通信量管理器26检查与所接收的请求相关联的Cookie(这些Cookie是:网络门户会话Cookie、用户名Cookie、散列后的用户名Cookie以及应用SSO数据Cookie),并且如果有效,则将所述请求(338)连同所请求的网络应用所需的报头(这些报头是授权管理器30从域名数据库32中提供的报头,并由第一通信量管理器20存储在应用SSO数据Cookie中)一起,转送给BES 28上运行的所请求的网络应用。
[0070] 更详细地说,第二通信量管理器26利用第一通信量管理器加密所述应用SSO数据Cookie时所用的相同要素(用于访问所述应用的域名、用户名和密钥)来解密所述Cookie。第二通信量管理器使用此Cookie中可获得的应用名称,来选择适当的池名称,并且将所述请求转送给所请求的应用。例如,如果所述应用名称是“ServiceEvents”,则通信量管理器利用名称“PL:GSP:ServiceEvents:Green”来选择池。通信量管理器利用命令:pool.use()来转送所述请求。
[0071] 对第一请求的响应
[0072] 一旦用户已经成功登录到在BES 28上运行的网络应用之一(例如应用App1),则第二通信量管理器26将从所述应用接收的响应,通过第一通信量管理器20经由反向路径发送(340)到浏览器12。所述响应可包含所请求的应用设置的任何附加Cookie。利用来自因特网14中的DNS(未示出)的唯一字符串来对这些附加Cookie进行名称分隔(name spacing)。如果用户在相同网络门户会话期间再次选择相同应用(App1),则这些通过第二通信量管理器26提供的经名称分隔的应用Cookie被包括在来自所述用户的后续请求中。
[0073] 后续请求
[0074] 下面参照图2、4和6来描述图2中对来自用户的访问BES 28上相同应用的后续请求进行处理的网络操作。图4包括箭头(412-424),以例示与图2有关的、下面描述的各种信息流。根据图6中的顺序图,在因特网14上,经由安全链路将用于请求BES 28上运行的应用的后续请求6.1从浏览器12路由到第一通信量管理器20。
[0075] 当用户10在相同网络门户会话期间提交用于请求访问BES 28上运行的相同应用的第二或者后续请求(412)时,如上文所述,浏览器12将所述请求发送到第一通信量管理器20。随同该请求一起,此刻浏览器12还将第二通信量管理器26提供的任何名称分隔的应用Cookie与以下各项一起发送:网络门户50提供的用户名Cookie和网络门户会话Cookie,还有如上所述,在针对网络应用的请求的第一响应期间,由第一通信量管理器20创建的应用SSO数据Cookie和散列后的用户名Cookie。
[0076] 第一通信量管理器20对接收到的请求执行一系列检查。对每个请求执行是否存在所述网络门户会话Cookie、用户名Cookie、散列后的用户名Cookie以及应用SSO数据Cookie的初步检查。如果发现存在所有这些Cookie,则第一通信量管理器20随后通过利用所述用户名Cookie的值、用于访问应用的DNS域名以及密钥的组合作为解密密钥,对所述应用SSO数据Cookie进行解密(此处理是上述加密处理的逆处理)来检查其有效性。如果成功地对所述应用SSO数据Cookie进行解密,并且如果不存在所述用户账户标识符且在所述请求的报头中未设置有表示将要创建散列后的用户名Cookie的标记,则所述第一通信量管理器20将当前请求视为针对网络应用28的有效后续请求,并且将所述请求转送至中间网络服务器22(414)(参见图6中的6.2)。
[0077] 中间网络服务器22参照策略服务器42来检查原始门户会话是否依然继续有效。策略服务器42酌情更新活动会话以避免其过早终止。
[0078] 如上所述,与网络门户策略服务器42相连接的中间网络服务器22上安装有单一登录代理。中间网络服务器22因此能够在接收到形成所述会话的一部分的请求时,更新在策略服务器42上记录的用户网络门户会话。这样,能够确保所述会话不会过早超时。由于所述请求是后续请求,所以其不具有要向授权管理器30进行查询的指示符(即在URL中缺少“/authm”),如果中间网络服务器22确定所述会话仍然继续有效,则根据网络服务器配置规则,将所述请求(416)转发给第二通信量管理器26(参见图6的6.3)。在这种情况下,省略了上文描述的针对第一请求的认证和授权步骤,在这些步骤中中间网络服务器22查阅策略服务器42和授权管理器30。在后续请求中可以安全地省略这些步骤,因为加密后的应用SSO数据Cookie起到足以识别用户对所选择的应用的权利的作用。
[0079] 在接收到所述请求时,第二通信量管理器26解析所述应用SSO数据Cookie,并且利用所述Cookie中的信息,通过使用上文所述的适当池,使用应用名称,将所述请求代理到BES 28上运行的正确应用。第二通信量管理器26对适当报头进行编辑,从请求中去除除了所述网络门户会话Cookie之外与应用无关的任何其他Cookie;从所述应用Cookie的名称中去除名称分隔(即进入请求的域名中的部分),并且利用应用SSO数据Cookie中的应用名称所标识的池(应用名称中的),将所述请求(418)转送给在BES 28上运行的想要的网络应用(参见图6,6.4)。
[0080] 后续请求的URL结构的示例如下:
[0081]
[0082] 对后续请求的响应
[0083] BES 28上运行的所选网络应用(App1、App2、…Appn)对所述请求进行处理并且将响应(420)返回到第二通信量管理器26(参见图6的6.5)。所选网络应用的响应沿着所述请求的反向路径(422):从第二通信量管理器26经由中间网络服务器22(6.6)到第一通信量管理器20(6.7)。第一通信量管理器20对来自所选网络应用的所述响应进行解析,以去除所述响应中的用于识别所选网络应用的实际域名和端口详细信息的绝对路径/URL,并且用所述网络门户SSO域名和端口详细信息来替代所述绝对路径/URL。例如,如果对于一个应用来说,实际主机名是:subdomain.intranet.domain.com:8080;
[0084] 并且如果此应用的网络门户SSO域名和端口详细信息(用于从浏览器12经由因特网14访问此应用)如下:
[0085] Subdom.sso.internet.domain.com:7001;
[0086] 则将在来自所述网络应用的所述响应中做出如下替换,
[0087] 即:如果所述响应包含:
[0088]
[0089] 则按照第一通信量管理器20的响应解析规则将其变为:
[0090]
[0091] 第一通信量管理器20还通过对每个这种Cookie进行名称分隔,来修改由BES28上运行的所选网络应用设置的所述Cookie的名称,即:如上文所描述的那样,利用与当前请求有关的所述网络门户SSO域名的所述应用名称部分对每个Cookie加前缀(例如“subdom”)。如下所述,第一通信量管理器20还将所述Cookie的域名变更为网络应用28的所述网络门户SSO域名。
[0092] 网络应用设置的Cookie详细信息为:
[0093] Cookie名称:JSESSIONID
[0094] Cookie值:
[0095] 路径标记值:/
[0096] 域名标记值:subdomain.intranet.domain.com
[0097] 如果收到的请求的域名&端口是
[0098] Subdom.sso.internet.domain.com:7001,
[0099] 则第一通信量管理器20将把上述Cookie修改为如下:
[0100] Cookie名称:subdom_JSESSIONID
[0101] Cookie值:
[0102] 路径标记值:/
[0103] 域名标记值:subdomain.sso.internet.domain.com
[0104] 在解析所述响应后,第一通信量管理器20将修改后的响应发送(424)到浏览器12,所述浏览器12将所述响应视为直接从所述网络应用接收的(参见图6的6.8)。因此,该SSO解决方案对于浏览器12来说是不可见的。
[0105] 优选的是,如上文所述,利用各种Cookie具有将通常无状态的第二通信量管理器26转化为状态机的效果。
[0106] 服务器群
[0107] 利用常规反向代理存在的问题在于:在BES 28上运行的网络应用返回指向与所述原始应用的上下文不同的上下文的链路。当网络浏览器(有关后续请求的)生成新请求时会存在问题。所述问题是常规反向代理解决方案不能确定将所述请求发送给哪个应用。现有解决方案使用上下文来识别所请求的后端应用。如果两个应用具有相同的上下文(即:字符串跟着://[:port]),则常规单一登录解决方案无法识别所请求的后端应用。
[0108] 为了保证BES 28上运行的每个网络应用都能够向适当用户返回该网络应用专属的链路,BES 28上的每个服务器提供有独特DNS记录。BES 28服务器的独特DNS记录和所述BES服务器上运行的实际网络应用的详细信息(包括所述网络应用的真实DNS/IP地址和端口)之间的映射存储在门户数据库32中,由授权管理器30在接收到第一有效请求时进行询问。
[0109] 为了使得BES 28上运行的每个应用都能够保持其针对每个用户的状态,BES 28上运行的每个应用都被分配有唯一域名和端口号(即:标准端口80和443)。为了为BES 28的每个服务器提供独特DNS记录,第一通信量管理器20支持多个虚拟服务器。在第一通信量管理器20上为BES 28上运行的每个应用配置独立虚拟服务器,并且分配给第一通信量管理器20上运行的每个虚拟服务器的唯一域名包括BES 28上运行的应用之一的DNS记录和端口。因此当通过中间网络服务器22转发请求时,授权管理器30能够利用所述请求中包括的唯一域名(即,与期望的应用相对应的域名)来识别作为所述请求的对象的应用。
[0110] 例如:如果收到的请求如下:
[0111] http://subdom.sso.internet.domain.com:7001,
[0112] 则请求的域名“subdom.sso.internet.domain.com”将告知授权管理器30所述请求是要调用BES 28上运行的特定订单管理应用。如上文所述,此映射存储在门户数据库32中。
[0113] 为了确保用户对BES 28上运行的相同网络应用的后续请求,会由第一通信量管理器20中的相同虚拟服务器接收并处理,第一通信量管理器20被编程为:在来自BES 28上运行的网络应用的文本响应中,将任何发现的应用实际域名用在网络门户50上分配给该应用的域名和端口号(即网络门户SSO域名和端口详细信息)来替代。
[0114] 根据优选实施方式,第一通信量管理器20和第二通信量管理器26可分别包括两个或者更多个服务器的群。通信量管理器群的服务器优选地按照主动-主动模式运行。第一通信量管理器20和第二通信量管理器26分别经由网络交换机(分别是16和24)连接,所述网络交换机用于在各个群的多个服务器之间分配请求以均衡负载。服务器群增强了通信量管理器的处理能力和吞吐量,并且与上文所述的、可以在单个服务器上或者服务器群上托管的虚拟服务器不同。
[0115] 本发明的计算机网络为每个用户提供了不同会话,所以可使用会话ID来标识用户,并且根据发送到用于存储状态的BES 28信息和上下文来确定所请求的应用。
[0116] 如本领域的普通技术人员所理解的那样,上文描述的第一通信量管理器20、第二通信量管理器26以及中间网络服务器22可分别实施为一个或者多个市场上有售的服务器或者类似通用处理装置(如图7所示)。图7示出根据本发明的另一实施方式,适于实现本发明的网络控制器的服务器的典型结构。在实践中,通常需要若干这种服务器。服务器包括用于执行软件程序并且管理和控制处理装置的操作的中央处理单元(CPU)70。CPU70经由总线71连接到多个设备,这些设备包括存储设备72,例如用于存储系统和应用软件的硬盘驱动器和包括ROM 74和RAM 75的内存。所述服务器还包括与外部网络组件(例如图2的基于网络的IT系统(计算机网络)中的其他组件))的接口的通信接口77。所述服务器还可包括经由输入/输出端口76连接到总线71的输入/输出设备,诸如鼠标和键盘(未示出),以及显示器78。普通技术人员能够理解,上文描述的架构仅仅是典型服务器架构的一个示例而非对其的限制。还应该理解所描述的服务器具有能够满足其目的的所有必要操作和应用软件。
[0117] 上述实施方式应该被理解为是本发明的例示性示例。本发明的其他实施方式对于普通技术读者来说是能够想到并且显而易见的。应该理解所描述的与任何一个实施方式相关的任何特征都可以单独使用,或者与所描述的其他特征组合使用,并且也可以与另一实施方式或多个实施方式任意组合中的一个或者更多个特征一起组合使用。此外,在不偏离由随附权利要求书所限定的本发明的范围的情况下,还可采用上文未描述的等同例和修改例。
[0118] 虽然为了清晰描述的缘故,上文描述中仅描述了BES 28的每个服务器上运行单个应用的情况,但上文描述的应用访问系统也可以适用于在BES 28的一个或更多个服务器上运行多个应用的情况。类似地是,BES 28不限于单一数据中心或者单一地理位置。上文描述的多个方面是可选择的,并且仅仅是示例,它们可在上述应用访问系统的另选实施方式中按照不同的方式实现。举例来说,出于效率的原因,中间网络服务器22可被设置为不向策略服务器42询问每个后续请求。
[0119] 第一通信量管理器20、第二通信量管理器26以及中间网络服务器22的设置允许分担工作量。第一通信量管理器20用作请求的接收器,独立于门户服务器运转,而第二通信量管理器26负责对所述请求进行代理。根据优先实施方式,第一通信量管理器20用作位于网络绿侧的中间网络服务器22与位于红侧的网络服务器40之间的防火墙。第一通信量管理器20对各个请求进行识别,并且对用户针对应用的第一请求和任何后续请求进行区别。在检测到第一请求时,所述通信量管理器检查会话有效性并且将所述请求转送给用于认证和授权的网络服务器,以确保所述会话有效。为了避免针对后续请求对所述会话进行重复验证,通信量管理器在对所述第一请求的响应中插入专用Cookie。在同一门户会话内,在同一用户发布的访问同一应用的后续请求中重复这些专用Cookie。后续请求中存在这些专用Cookie使得通信量管理器省略进一步的验证步骤。应用识别是利用用于访问应用的DNS来实现的。
[0120] 有利地是,第一通信量管理器20不需要进行任何处理来确保会话继续有效;因为此功能由中间网络服务器22来实现,针对BES 28上运行的应用的所有请求和针对授权管理器30的所有请求都经过所述中间网络服务器22被路由。