从现有浏览器会话中认证富客户端的制作方法

文档序号:7990972阅读:170来源:国知局
从现有浏览器会话中认证富客户端的制作方法
【专利摘要】用户从基于浏览器的客户端向基于Web或基于云的应用进行认证。基于浏览器的客户端具有相关联的富客户端。在会话从基于浏览器的客户端被发起(并且凭证被获得)之后,用户可以发现富客户端可用并使其获得该凭证(或新的凭证)以用于自动地(使用富客户端)向该应用认证该用户,即不需要额外的用户输入。应用界面向用户提供了显示,通过该显示,用户可以配置富客户端认证操作,诸如规定如果富客户端被检测为正在运行则其是否应当自动地被认证,由富客户端对应用的访问是否以及在什么程度上要被限制,由富客户端对应用的访问是否以及何时要被取消,等等。
【专利说明】从现有浏览器会话中认证富客户端
【技术领域】
[0001]本公开一般地涉及应用安全,尤其涉及一种使得能够从现有web浏览器会话中传递或获取用于“富客户端”的凭证的方法。
【背景技术】
[0002]在现有技术中,用所谓的“富”客户端来集成基于Web或基于云的应用是公知的,其中“富”客户端是(客户端-服务器应用的)支持其自身界面(而不是仅从web应用本身导出web界面)的客户端。“富”客户端通常不是基于浏览器的,并且其有时被称为“厚”(相较于基于浏览器的或者“瘦”)客户端。说明性的富客户端为Lotus Notes?,其提供电子邮件、日历、联系人管理和即时通讯。富客户端可以被用来代表用户访问和自动地执行动作。
[0003]许多该类型的非基于浏览器的(富)客户端应用也具有基于浏览器的(瘦客户端)应用的对应部分或特征。瘦客户端可以是简单的web浏览器和登录页面。当终端用户想要从单个工作站同时使用这些多个客户端时,他或她必须向认证服务器分别地认证。应对该需求的普遍方法是使用口令,其在多个界面中被输入,例如,每个客户端一个界面。该方法不是用户友好的,因为用户需要多次输入他或她的口令。而且,在用户以本地方式(在每个客户端中)存储口令的情况下,考虑到多个副本被存储,其增加了损害的风险。进一步地,当用户修改口令时,同样地,其必须在多个地方被改变。当然,当用户被迫多次输入口令时,更有可能的是用户将选择较弱的口令。如果基于Web或基于云的应用使用不支持基于口令的认证(基于口令的认证对于瘦客户端方式是典型的)的单点登录协议(诸如SAML或OpenID),则出现了另一个问题。在这种情况下,用户被迫针对每个厚客户端和瘦客户端使用不同类型的认证凭证和技术,这导致了进一步的低效率和安全风险。
[0004]希望能够提供一种技术,通过该技术用户只需要在与基于Web或基于云的应用的会话期间认证一次,但是其中该认证可以被传播到相关联的可以由该用户发现的富客户端或以其他方式对这样的富客户端可用。

【发明内容】

[0005]根据本公开,用户从瘦(基于浏览器的)客户端向基于Web或基于云的应用认证。所述客户端具有相关联的富客户端。在会话从所述基于浏览器的客户端被发起(以及凭证被获得)之后,用户可以发现所述富客户端可用并且使其获得所述凭证(或新的凭证)以用于(使用富客户端)自动地向所述应用来认证所述用户,即不需要额外的用户输入。应用界面为用户提供了显示,通过该显示,用户可以配置富客户端认证操作,诸如规定如果富客户端被检测为正在运行则其是否应当自动地被认证,由富客户端对应用的访问是否以及在什么程度上要被限制,由富客户端对应用的访问是否以及何时要被取消,等等。
[0006]在一个实施例中,为了便于所描述的操作,在浏览器与富客户端之间建立了控制信道,富客户端被修改为包括HTTP服务器。通过向到HTTP服务器的本地主机连接上的端口发送HTTP请求,浏览器可以确定富客户端是否正在执行,并接着传递基于浏览器的凭证。[0007]在另选的实施例中,控制信道使用标准操作系统机制来实现。特别地,富客户端在操作系统中注册内容类型,并将自身建立为用于该类型的处理程序(handler)。当需要发起富客户端认证时,浏览器向所述应用发出HTTP请求,以请求新的凭证。HTTP响应包括具有与所注册的内容类型相匹配的mime类型的凭证。新的凭证接着通过操作系统被传递给富客户端,富客户端接着使用其来向所述应用认证。
[0008]上述认证方法可以在装置中执行。该装置包括处理器和计算机存储器,该存储器存储计算机程序指令,当该指令被执行时,执行该方法。
[0009]在另一个另选的实施例中,该认证方法由在数据处理系统中使用的计算机可读介质中的计算机程序产品来执行。该计算机程序产品包括计算机程序指令,当该指令由数据处理系统执行时,执行该方法。
[0010]前面已经概述了本发明的一些较相关的特征。这些特征应当被理解为仅是说明性的。许多其他有益结果可以通过以不同方式应用所公开的发明或通过按照将要描述的修改本发明来实现。
【专利附图】

【附图说明】
[0011]为了更完整地理解本发明及其优点,现在参考以下结合附图的描述,在附图中:
[0012]图1描绘了在其中可以实现示例性实施例的示例性方面的分布式数据处理环境的示例性框图;
[0013]图2是在其中可以实现示例性实施例的示例性方面的数据处理系统的示例性框图;
[0014]图3例示了在其中可以实现本公开的技术的客户端应用及其相关联的基于Web或基于云的服务器应用;
[0015]图4是描述本公开的基本操作场景的处理流程图;
[0016]图5是根据本公开的来自用户通过其配置访问策略的应用界面的显示页面;以及
[0017]图6是来自用户通过其发起富客户端认证操作或取消先前认证的访问的应用界面的显示页面。
【具体实施方式】
[0018]现在参照附图,特别是参照图1-2,提供了在其中本公开的示例性实施例可以被实现的数据处理环境的示例图。应当理解,图1-2仅是示例性的,并且并非旨在断言或暗示关于在其中本公开主题的各方面或实施例可以被实施的环境的任何限制。可以对所描绘的环境做出许多修改而不偏离本发明的精神和范围。
[0019]现在参照附图,图1描述了在其中示例性实施例的各方面可以被实现的示例性分布式数据处理系统的图形表示。分布式数据处理系统100可以包括在其中示例性实施例的各方面可以被实现的计算机网络。分布式数据处理系统100包含至少一个网络102,其是用于在分布式数据处理系统100中连接在一起的各种设备和计算机之间提供通信链路的介质。网络102可以包括连接,诸如有线、无线通信链路,或光缆。
[0020]在所描绘的例子中,服务器104和服务器106以及存储单元108连接到网络102。另外,客户端110、112和114也连接到网络102。这些客户端110、112和114可以是例如个人计算机、网络计算机等。在所描绘的例子中,服务器104向客户端110、112和114提供数据,诸如引导文件、操作系统镜像、以及应用。在所描绘的例子中,客户端110、112和114是服务器104的客户端。分布式数据处理系统100可以包括额外的服务器、客户端以及其他未不出的设备。
[0021]在所描绘的例子中,分布式数据处理系统100是因特网,其中网络102表示世界范围的使用传输控制协议/因特网协议(TCP/IP)的协议组来相互通信的网络和网关的集合。在互联网的核心处是由成千上万的路由数据和消息的商业、政府、教育及其他计算机系统组成的主节点或主机计算机之间的高速数据通信线路的骨干。当然,分布式数据处理系统100也可以被实现为包括许多不同类型的网络,诸如例如内联网、局域网(LAN)、广域网(WAN)等。如上所述,图1旨在作为例子,并非旨在作为对本公开主题的不同实施例的体系结构限制,因此,图1所示的特定元素不应当被认为是对关于在其中本发明的示例性实施例可以被实现的环境进行限制。
[0022]现在参照图2,其示出了在其中示例性实施例的各方面可以被实现的示例性数据处理系统的框图。数据处理系统200是诸如图1的客户端110的计算机的例子,实现本公开的示例性实施例的过程的计算机可用代码或指令可以位于其中。
[0023]现在参照图2,其示出了在其中示例性实施例可以被实现的数据处理系统的框图。数据处理系统200是诸如图1的服务器104或客户端110的计算机的例子,实现示例性实施例的过程的计算机可用程序代码或指令可以位于其中。在该说明性例子中,数据处理系统200包括通信结构202,其提供处理器单元204、存储器206、持久存储装置208、通信单元210、输入/输出(I/O)单元212以及显示器214之间的通信。
[0024]处理器单元204用于执行可以被加载到存储器206中的软件指令。处理器单元204可以是一组一个或多个处理器或者可以是多处理器核,这取决于特定实现。进一步地,处理器单元204可以使用一个或多个异构处理器系统来实现,其中主处理器与副处理器在单个芯片上存在。作为另一个说明性例子,处理器单元204可以是对称多处理器(SMP)系统,其包含多个相同类型的处理器。
[0025]存储器206和持久存储装置208是存储设备的例子。存储设备是能够临时和/或持久地存储信息的任何硬件。在这些例子中,存储器206可以是例如随机存取存储器或任何其他合适的易失性或非易失性存储设备。持久存储装置208可以取决于特定实现而采用各种形式。例如,持久存储装置208可以包含一个或多个组件或设备。例如,持久存储208可以是硬盘驱动器、闪存、可重写光盘、可重写磁带或上述技术的组合。持久存储装置208所使用的介质也可以是可移动的。例如,可移动硬盘驱动器可以用于持久存储装置208。
[0026]在这些例子中,通信单元210提供与其他数据处理系统或设备的通信。在这些例子中,通信单元210是网络接口卡。通信单元210可以通过使用物理和/或无线通信链路来提供通信。
[0027]输入/输出单元212允许与可以连接到数据处理系统200的其他设备的数据输入和输出。例如,输入/输出单元212可以为通过键盘和鼠标的用户输入提供连接。进一步地,输入/输出单元212可以将输出发送到打印机。显示器214提供向用户显示信息的机制。
[0028]用于操作系统和应用或程序的指令位于持久存储装置208上。这些指令可以被加载到存储器206中以供处理器单元204执行。不同实施例的处理可以由处理器单元204使用计算机实现的指令来执行,该指令可以位于存储器中,诸如存储器206中。这些指令被称为程序代码、计算机可用程序代码或计算机可读程序代码,其可以由处理器单元204中的处理器读取和执行。不同实施例中的程序代码可以具体实现在不同的物理或有形计算机可读介质上,诸如存储器206或持久存储装置208上。
[0029]程序代码216以功能形式位于选择性可移动的计算机可读介质218上,而且可以被加载到或转移到数据处理系统200上以供处理器单元204执行。在这些例子中,程序代码216和计算机可读介质218形成计算机程序产品220。在一个例子中,计算机可读介质218可以是有形形式,诸如例如插入或放入驱动器中的光盘或磁盘,或者作为持久存储装置208的一部分的用于传递到存储设备上的其他设备(诸如作为持久存储装置208的一部分的硬盘驱动器)。按有形形式,计算机可读介质218也可以采用持久存储装置的形式,诸如连接到数据处理系统200的闪存、硬盘驱动器或拇指驱动器。计算机可读介质218的有形形式也被称为计算机可记录的存储介质。在一些情况下,计算机可记录介质218可以不是可移动的。
[0030]另选地,程序代码216可以通过到通信单元210的通信链路和/或通过到输入/输出单元212的连接而从计算机可读介质218传递到数据处理系统200。在说明性例子中,该通信链路和/或连接可以是物理的或无线的。计算机可读介质还可以采用非有形介质的形式,诸如包含程序代码的通信链路或无线传输。例示的用于数据处理系统200的不同组件并不意味着提供对在其中不同实施例可以被实现的方式的体系结构限制。不同的说明性实施例可以被实现在这样的数据处理系统中,其包括附加于或代替例示的用于数据处理系统200的那些组件的组件。图2所示的其他组件可以不同于所示的说明性例子。作为一个例子,数据处理系统200中的存储设备是可以存储数据的任何硬件装置。存储器206、持久存储装置208和计算机可读介质218是有形形式的存储设备的例子。
[0031]在另一个例子中,总线系统可以用于实现通信结构202,并且可以由一个或多个总线组成,诸如系统总线或输入/输出总线。当然,总线系统可以使用在附接于总线系统的不同组件或设备之间提供数据传递的任何合适类型的体系结构来实现。另外,通信单元可以包括用于发送和接收数据的一个或多个设备,诸如调制解调器或网络适配器。进一步地,存储器可以是例如存储器206或缓存,诸如在可以存在于通信结构202中的接口和存储器控制器集线器中找到的。
[0032]用于执行本发明的操作的计算机程序代码可以用一种或多种编程语言的任何组合来编写,包括面向对象的编程语言(诸如Java?、Smalltalk、c++等),以及传统的过程编程语言(诸如“C”编程语言或类似的编程语言)。程序代码可以完全地在用户的计算机上执行、部分地在用户的计算机上执行、作为独立软件包执行、部分地在用户的计算机上且部分地在远程计算机上执行、或者完全地在远程计算机或服务器上执行。在后一种场景中,远程计算机可以通过任何类型的网络连接到用户的计算机,该网络包括局域网(LAN)或广域网(WAN),或者可以连接到外部计算机(例如经由使用因特网服务提供商的因特网)。
[0033]本领域的普通技术人员将理解,图1-2中的硬件可以取决于实现而变化。其他的内部硬件或外围设备,诸如闪存、等效的非易失性存储器、或光盘驱动器等,可以附加于或代替图1-2所描绘的硬件而使用。同样,除了应用于前述SMP系统,说明性实施例的处理可以应用于多处理器数据处理系统,而不脱离本公开主题的精神和范围。
[0034]可以看出,这里描述的技术可以结合在诸如图1所例示的标准客户端-服务器范例中操作,在该范例中客户端机器与在一组一个或多个机器上执行的互联网可访问的、基于Web的门户(portal)通信。终端用户操作能够访问该门户并与其交互的因特网可连接的设备(例如台式计算机、笔记本计算机、具有因特网功能的移动设备等)。通常,每个客户端或服务器机器是诸如图2中例示的数据处理系统,其包括硬件和软件,并且这些实体通过网络相互通信,所述网络诸如因特网、内联网、外联网、专用网络或任何其他通信介质或链路。数据处理系统通常包括一个或多个处理器、操作系统、一个或多个应用以及一个或多个实用程序。数据处理系统上的应用提供对Web服务的原生支持,包括但不限于对HTTP、SOAP、XML、WSDL、UDDI和WSFL等的支持。关于SOAP、WSDL、UDDI和WSFL的信息可以从负责开发和维护这些标准的万维网联盟(W3C)获得;关于HTTP和XML的进一步信息可以从因特网工程任务组(IETF)获得。假定对这些标准是熟悉的。
[0035]众所周知以及作为附加的背景,认证是验证由用户提供的或代表用户的一组凭证的过程。认证是通过核实用户知道的事情、用户具有的事物或用户所为何物(即关于用户的某一物理特性)来完成的。用户知道的事情可以包括共享的秘密,诸如用户的口令,或者通过核实仅特定用户知道的事情,诸如用户的加密密钥。用户具有的事物可以包括智能卡或硬件令牌。关于用户的某一物理特性可以包括生物计量输入,诸如指纹或视网膜地图。应当注意,用户通常是但未必一定是自然人;用户可以是机器、计算设备或者使用计算资源的其他类型的数据处理系统。还应当注意,用户通常但不是必须拥有单个唯一的标识符;在某些场景下,多个唯一的标识符可以与单个用户相关联。
[0036]认证凭证是在各种认证协议中使用的一组质询/响应信息。例如,用户名和口令组合是认证凭证的最常见形式。其他形式的认证凭证可以包括各种形式的质询/响应信息、公钥基础设施(PKI)证书、智能卡、生物计量等等。通常,认证由用户呈现,作为与认证服务器或服务的认证协议序列的一部分。
[0037]如现在参照图3将要描述的,作为本公开的主题的技术通常在其中基于Web或基于云的应用包括客户端侧和服务器侧组件的场景中实现。客户端侧组件包括web浏览器或与其相关联的代码(例如浏览器插件、小应用程序(applet)等)300、非基于浏览器的客户端302,其中的每个都在诸如上面参照图2所描述的客户端机器304中执行。例如,客户端机器304包括处理器306、计算机存储器308以及操作系统310。基于浏览器的客户端在这里可以被称为“瘦”客户端,并且非基于浏览器的客户端可以被称为“厚”或“富”客户端。每个这种客户端组件被适配为通过诸如图1所示的网络314与包括服务器应用312的服务器侧组件互操作。服务器应用304可以是基于Web的或基于云的,并且其也在诸如图2所示的一个或多个机器上执行。
[0038]基于浏览器的客户端300已建立了和与其相关联的服务器应用312的认证机制。同样地,非基于浏览器的或“富”客户端302已建立了与服务器应用312的认证机制。这些认证机制可以是相同或不同的。如上所述,“富”客户端不是基于浏览器的。说明性的富客户端应用是Lotus Notes?,其提供电子邮件、日历、联系人管理以及即时通讯,尽管富客户端可以被实现在任何客户端-服务器应用中。在该例子中,服务器应用304是Domino?.数据服务器。当然,这些例子无意限制所公开的主题,其可以用任何的基于Web或基于云的应用来实现。
[0039]根据本公开,控制信道316在一方面的基于浏览器的客户端300与另一方面的非基于浏览器的客户端302之间被建立。控制信道被用来在这些组件之间传递信息,如将要描述的。在一个实施例中,控制信道316使用本地主机连接318来实现,基于浏览器的客户端300和与富客户端相关联的HTTP服务器实例320通过本地主机连接318通信。在该实施例中,客户端300与客户端302之间的通信通常通过HTTPS发生,尽管这不是必需的。在另选的实施例中,如将要描述的,控制信道是使用操作系统310本身实现的,例如通过使富客户端注册为用于特定mime类型的处理程序。控制信道可以以其他方式实现,例如作为共享存储器段、进程间通信(IPC),通过网络呼叫、通过文件等。如果控制信道是可以由其他客户端进程发现的,其应当使用已知技术被保护。
[0040]现在参照图4的流程图描述本公开的典型操作场景。在步骤400,终端用户已经打开了浏览器300的实例,并且已经向服务器应用312认证,这通常是通过在浏览器中呈现的SSL安全登录页面处输入用户标识符(UID)以及口令。其结果是,浏览器获得并存储相关联的凭证305,其是由服务器应用提供的。如在步骤402所指示的,该操作建立用户会话或“基于web的用户会话”。结果,用户然后可以采取基于Web或基于云的应用所允许的一个或多个动作。根据本公开,在用户会话从浏览器(即在现有web会话期间)被发起之后,富客户端302被发现并向服务器应用312认证,其优选为自动地且不需要终端用户输入额外的认证相关信息。换句话说,富客户端认证是透明地——实际上是“在幕后”——但是以由服务器应用预期的方式被执行。然而,终端用户不需要从富客户端执行与认证操作相关联的常规任务。他或她认证一次(使用基于浏览器的方法),而该认证使能或便利了基于富客户端的认证。
[0041]优选地,该富客户端自动的登录(自动登录)操作以如下方式完成。假定该用户(或另一个用户)已经配置了某些发现和认证操作,优选使用在下面描述的应用界面。在步骤404,执行检查以确定用户是否想要使用该富客户端向服务器应用认证。如果用户想要向服务器应用认证,则执行发现步骤406。发现步骤406识别是否有任何的富客户端(一个或多个)正在客户端机器中执行(可能会有很多)。发现步骤可以主动地执行,例如通过使浏览器在本地主机连接上发出一个或多个请求并接收返回的“状态”响应,或者其可以被动地进行,例如通过使这种状态信息按需对浏览器可用以及可显示。另选地,当富客户端被启动时,其执行状态恰好以某种方式暴露给用户,例如在听觉上、视觉上等等。发现过程的性质将取决于实现方式。可以使用的其他发现技术包括使富客户端在HTTP服务器实例上打开端口,以及使浏览器在一组可用的端口上迭代直到其定位到该打开的端口,其表明富客户端正在执行。在IPC被用作控制信道的情况下,操作系统发布机制可以用于提供富客户端正在执行的通知。这些例子并非旨在限制。
[0042]在发现之后,例程继续到步骤408,在该步骤中富客户端获得用于向服务器应用执行实际认证的凭证。在一个实施例中,该凭证正是在基于浏览器的向应用服务器认证期间获得的凭证305。在该实施例中,浏览器简单地经由控制信道将该凭证传递到富客户端。在另选的实施例中,富客户端已经向本地操作系统注册为用于mime内容类型(例如x-application/rich-auth)的处理程序。在步骤408,浏览器发出HTTP请求到服务器应用以请求新凭证;来自服务器应用的HTTP响应包括新凭证和标识相关联的mime类型的报头。由于富客户端被注册为用于该mime类型的处理程序,所以HTTP响应(新凭证)通过操作系统内核被传播给富客户端,富客户端然后使用其来认证,再一次地不需要显式的用户输入。在该另选的实施例中,控制信道使用标准OS机制,因此是与平台无关的。在步骤410,富客户端完成向服务器应用的认证,过程终止。
[0043]图4中所示的一个或多个步骤可以按不同的顺序进行。一个或多个步骤可以被组合,或可以实行替换。
[0044]富客户端向服务器应用312认证的特定方式不是本公开的方面。用于该目的的已知技术包括但不限于基于SAML的认证(其中服务器发出SAML断言,该断言接着被转发给富客户端,富客户端用该断言认证或用其交换另一个凭证)、基于OAuth的认证(其中服务器发出由富客户端使用以认证的OAuth令牌)、基于一次性令牌的认证(其中服务器生成保存在服务器侧并与用户相关联的随机现时标志(nonce)),等等。
[0045]在基于浏览器的客户端300与富客户端直接通过控制信道通信的第一实施例中,服务器应用与本地HTTP服务器(与富客户端相关联执行)可以在不同域中操作。本地HTTP服务器可以附加于富客户端,或与其成一体。因此,已知的跨域通信方法(例如脚本包含)应当被使用以促进该交互。在另一个变型中,不是使用本地HTTP服务器,而是使用浏览器插件或签名的小应用程序来与应用服务器交互以获得凭证及实现富客户端认证。
[0046]图5例示了代表性的应用界面322 (图3),通过其用户(或其他个人或者实体)可以配置操作。该界面可以作为一个或多个网页被导出到浏览器,尽管这并不是限制。代表性的页面500展现了一组配置元件,诸如输入字段、HTML填写式表格、单选按钮等。因此,例如,通过选择单选按钮502,用户可以请求在发起web会话后所有运行的富客户端被发现。通过选择单选按钮504,用户可以选择使所有运行的富客户端根据请求而更新。用户可以选择单选按钮来规定当富客户端被检测为运行时自动被认证。使用从列表506可获得的选项,用户可以规定对富客户端如何与服务器应用交互的约束或限制。因此,例如,该列表可以展现一个或多个选项,例如,访问是“只读”的,访问对于可以指定的有限时间是可用的,只有某些功能或应用编程接口(API)是可用的,等等。这些仅仅是代表性配置选项,并且本领域的普通技术人员将会明白可以根据需要实现其他配置选项。该配置界面也可以提供一种控件,一旦选择了该控件,使用户能够直接从浏览器启动富客户端,如果该客户端未在运行的话。使用该界面,用户配置定义了富客户端应当如何向服务器应用认证的“策略”。一组默认策略可以展现给用户以便于这种选择。虽然已经描述了界面的实施例,但是可以使用一个或多个另选的方法,例如使用命令行界面、以编程方式定义策略,等等。
[0047]图6例示了界面的发现页面600。该页面在前面描述的发现步骤之后被显示。在该例子中,发现操作已经识别了两个富客户端(客户端I和客户端2)在客户端机器中执行,并且这些客户端在这里由图标602和604表示。图标602包括对已经针对与之相关联的客户端I发出了凭证的指示或视觉提示。通过选择该图标,终端用户可以被提供使客户端I的认证无效的机会(例如经由单独的对话框);另选地,对图标602的选择本身终止富客户端的认证。在任一情况下,从富客户端对服务器应用的访问被有效地取消(通过使凭证无效)。通过选择图标604,终端用户可以发起获得凭证的过程,如上面所描述的,因此客户端2可以访问和使用服务器应用。[0048]因此,根据该技术,用户可以使富客户端能够自动地并且基于由用户定义的策略向服务器应用认证。该策略可以规定凭证可以仅针对特定时间段而发布,或者其仅用于访问应用的一部分,等等。访问是可取消的,这同样是基于用户的所配置的策略。
[0049]所公开的主题具有许多优点。一个关键的优点是在与基于Web或基于云的应用的会话期间(并且在一个地方),用户只需要进行一次认证。使用所描述的技术,该认证然后有效地用于使相关联的富客户端能够访问该应用。另一个优点是富客户端的这种访问可以根据用户配置的策略而定制,并且用户可以根据需要取消富客户端的这种访问。使用所述发现特征,用户可以查看本地运行的富客户端并通过请求服务器应用(或其他实体)发出凭证(或令牌等)来对其认证,该凭证接着被富客户端用来向应用认证该用户。该技术提供了几种用于将现有基于浏览器的凭证传播到富客户端或者使富客户端能够获得新凭证的本地机制。
[0050]该技术可以用于任何的富客户端,而不管该客户端如何向服务器应用进行认证。
[0051]在一个所描述的实施例中,该技术使得(基于浏览器的)客户端应用凭证能够自动且直接地传播到与浏览器应用相关联的对应的非浏览器进程。如果想要在现有的基于web的用户会话中开始该客户端的话,该方案避免了用户必须登录到富客户端。
[0052]如这里所使用的,“凭证”应当被广义地理解为便于对服务器应用进行访问的任何凭证、令牌、数据集或数据。如上面所指出的,客户端(无论是基于浏览器的还是富的)具有与其相关联的服务器应用建立的认证机制,并且所公开的技术遵循所涉及的语义和通信协议。
[0053]本公开的自动登录方案提供了基于浏览器的客户端与相关联的富客户端之间的独特的交互,二者都优选与基于Web或基于云的服务器应用相关联。该方案假设基于浏览器的客户端与服务器应用之间的现有用户会话已就位,换句话说,当终端用户登录到服务器应用时,凭证已经先前生成了。
[0054]虽然不作限制,但是在代表性的实施例中,服务器应用执行应用服务器(诸如1BM_? WebSphere'?服务器),其包括对一个或多个基于服务器的代码功能的支持,通常以兼容J2EE的小服务程序(servlet)的形式。
[0055]上面描述的功能可以被实现为独立的方法,例如由处理器执行的基于软件的功能,或者其可以作为管理服务(包括作为经由S0AP/XML界面的web服务)而可用。这里所描述的特定硬件和软件实现方式细节仅仅是用于说明的目的而并不旨在限制所描述的主题的范围。
[0056]更一般地,在所公开的主题的上下文中,计算设备均为包括硬件和软件的数据处理系统(诸如图2所示),这些实体通过网络相互通信,诸如因特网、内联网、外联网、专用网络或任何其他通信介质或链路。在数据处理系统上的应用提供对Web以及其他已知服务和协议的原生支持,包括但不限于对HTTP、FTP、SMTP、SOAP、XML、WSDL、UDDI和WSFL等的支持。关于SOAP、WSDL、UDDI和WSFL的信息可以从万维网联盟(W3C)获得,其负责开发和维护这些标准;关于HTTP、FTP、SMTP和XML的进一步信息可以从因特网工程任务组(IETF)获得。假定对这些已知的标准和协议是熟悉的。
[0057]这里描述的富客户端自动登录方案可以在各种服务器侧的体系结构中实现或者与所述体系结构相结合来实现,所述体系结构包括简单的η层体系结构、web门户、联合系统等。应用服务器组件可以位于与一个或多个后端应用的域不同的域中,因此,这里的技术可以在松散耦合的服务器(包括基于“云”的)环境中实践。应用服务器本身可以被托管在所述云中。
[0058]更一般地,这里所描述的主题可以采用以下形式:完全的硬件实施例、完全的软件实施例或包含硬件和软件元件的实施例。在优选实施例中,功能在软件中实现,该软件包括但不限于固件、驻留软件、微代码等。此外,如上面所指出的,自动登录功能可以采取计算机程序产品的形式,该计算机程序产品可以从计算机可用或计算机可读介质访问,并提供了供计算机或任何指令执行系统使用或与其结合使用的程序代码。用于该描述的目的,计算机可用或计算机可读介质可以是可以包含或存储供指令执行系统、装置或设备使用或与其结合使用的任何装置。该介质可以是电、磁、光、电磁、红外、或半导体系统(或装置或设备)。计算机可读介质的例子包括半导体或固态存储器、磁带、可移动计算机盘、随机存取存储器(RAM)、只读存储器(ROM)、硬磁盘和光盘。光盘的当前例子包括光盘一只读存储器(CD-ROM)、光盘一读/写(CD-R/W)和DVD。计算机可读介质是有形物品。
[0059]计算机程序产品可以是具有实现所描述的功能中的一个或多个的程序指令(或程序代码)的产品。在通过网络从远程数据处理系统被下载之后,这些指令或代码可以被存储在数据处理系统中的计算机可读存储介质中。或者,这些指令或代码可以被存储在服务器数据处理系统中的计算机可读存储介质中,并被适配为通过网络被下载到远程数据处理系统以供在远程系统中的计算机可读存储介质中使用。
[0060]在代表性的实施例中,所描述的客户端和服务器组件被实现在专用计算机中,优选被实现在由一个或多个处理器执行的软件中。该软件被保持在与一个或多个处理器相关联的一个或多个数据存储库或存储器中,并且该软件可以被实现为一个或多个计算机程序。共同地,该专用硬件和软件包括提供富客户端自动登录功能的组件。
[0061]所描述的功能可以被实现为现有应用服务器功能或操作的附加或扩展。
[0062]虽然以上描述了由本发明的某些实施例执行的操作的特定顺序,但应当理解,这种顺序是示例性的,因为另选实施例可以按不同的顺序执行操作,组合某些操作,重叠某些操作等等。在说明书中对给定实施例的参考指示了所描述的实施例可以包括特定特征、结构或特性,但每个实施例可能并不必定包括该特定特征、结构或特性。
[0063]最后,虽然已经分别描述了系统的给定组件,但本领域的普通技术人员会清楚一些功能可以以给定的指令、程序序列、代码部分等等共享或组合。
[0064]这里所用的“浏览器”并非旨在指代任何特定的浏览器(例如Internet Explorer,Safar1、FireFox等),而是应当被广义地解释为指任何客户端侧的可以访问并显示因特网可访问的资源的呈现引擎。进一步地,尽管通常客户端-服务器的交互使用HTTP发生,如上面所指出的,但这也不是限制。客户端服务器交互可以被格式化为符合简单对象访问协议(SOAP),并且通过HTTP (通过公共因特网)、FTP或任何其他可靠的传输机制(诸如
IBM? MQSeries?技术和corba,用于通过企业内联网传输)的传输可以被使用。此
夕卜,术语“网站”或“服务供应商”应当被广义地解释为覆盖网站(一组链接的网页)、在给定的网站或服务器处的域、与服务器或服务器组相关联的信任域等。“服务供应商域”可以包括网站或网站的一部分。通过提供到另一个应用中的钩子,通过促进将机制作为插件使用,通过链接到机制等,这里所描述的任何应用或功能可以被实现为本机代码。
[0065]如所指出的,上面描述的富客户端自动登录功能可以被用于任何系统、设备、门户、站点等中,其中非基于浏览器的客户端应用凭证需要被传递至相关联的浏览器进程。更一般地,所描述的技术被设计用于任何操作环境,其中希望给定的信息(包括但不局限于凭证数据)从客户端应用到相关联的浏览器进程以自动方式持续。
[0066]虽然上面描述的实施例提供了从现有的浏览器会话中认证富客户端,但是基本技术也可以实现于这样的场景,其中向web应用认证富客户端,并且想要将现有的凭证传送到瘦客户端。在该场景中,假设富客户端具有确保由瘦客户端(对该应用的)访问是被允许的方法,则控制信道在富客户端与可用的基于浏览器的客户端之间被启用。富客户端所获得的凭证接着被传递到基于浏览器的客户端,以使得用户能够被认证。
[0067]服务器应用使得能够对服务、服务器、应用程序、进程、页面(例如维基、网页等)、文件、链接对象、目录等等进行访问。
[0068]在已经描述了我们的发明之后,我们现在要求保护权利要求。
【权利要求】
1.一种对服务器应用的经认证的用户访问的方法,包括: 在基于浏览器的客户端中接收发起与所述服务器应用的web会话的用户输入; 在所述基于浏览器的客户端处接收凭证; 在所述web会话中,识别能够与所述服务器应用交互的富客户端; 在所述web会话中,向所述富客户端提供凭证,该凭证是以下之一:在所述基于浏览器的客户端处接收的所述凭证,和从所述服务器应用接收的新凭证;以及 在所述web会话中,使用向所述富客户端提供的所述凭证来使用所述富客户端向所述服务器应用认证用户。
2.如权利要求1所述的方法,其中识别富客户端的步骤包括发起发现操作以确定一个或多个本地执行的富客户端的操作状态。
3.如权利要求2所述的方法,进一步包括: 向所述用户提供指示所述一个或多个本地执行的富客户端的显示;以及 从所述用户接收选择,该选择识别要向其提供所述凭证的富客户端。
4.如权利要求1所述的方法,进一步包括在所述基于浏览器的客户端与所述富客户端之间建立控制信道。
5.如权利要求4所述的方法,进一步包括使用所述控制信道向所述富客户端提供所述凭证。
6.如权利要求1所述的方法,其中向所述富客户端提供的所述凭证与策略相关联,该策略定义了至少一个针对所述服务器应用的访问限制。
7.如权利要求6所述的方法,其中所述策略是用户配置的策略。
8.如权利要求1所述的方法,进一步包括使向所述富客户端提供的所述凭证无效。
9.一种向服务器应用提供经认证的用户访问的装置,包括: 处理器; 存储计算机程序指令的计算机存储器,当该计算机程序指令由所述处理器执行时,执行包括以下步骤的方法: 在基于浏览器的客户端中接收发起与所述服务器应用的web会话的用户输入; 在所述基于浏览器的客户端处接收凭证; 在所述web会话中,识别能够与所述服务器应用交互的富客户端; 在所述web会话中,向所述富客户端提供凭证,该凭证是以下之一:在所述基于浏览器的客户端处接收的所述凭证,和从所述服务器应用接收的新凭证;以及 在所述web会话中,使用向所述富客户端提供的所述凭证来使用所述富客户端向所述服务器应用认证用户。
10.如权利要求9所述的装置,其中识别富客户端的步骤包括发起发现操作以确定一个或多个本地执行的富客户端的操作状态。
11.如权利要求10所述的装置,其中所述方法进一步包括: 向所述用户提供指示所述一个或多个本地执行的富客户端的显示;以及 从所述用户接收选择,该选择识别要向其提供所述凭证的富客户端。
12.如权利要求9所述的装置,其中所述方法进一步包括在所述基于浏览器的客户端与所述富客户端之间建立控制信道。
13.如权利要求12所述的装置,其中所述方法进一步包括使用所述控制信道向所述富客户端提供所述凭证。
14.如权利要求9所述的装置,其中向所述富客户端提供的所述凭证与策略相关联,该策略定义了至少一个针对所述服务器应用的访问限制。
15.如权利要求14所述的装置,其中所述策略是用户配置的策略。
16.如权利要求9所述的装置,其中所述方法进一步包括使向所述富客户端提供的所述凭证无效。
17.一种计算机可读介质中的计算机程序产品,其用于在数据处理系统中使用以提供对服务器应用的经认证的用户访问,该计算机程序产品存储计算机程序指令,当该计算机程序指令由所述数据处理系统执行时,执行包括以下步骤的方法: 在基于浏览器的客户端中接收发起与所述服务器应用的web会话的用户输入; 在所述基于浏览器的客户端处接收凭证; 在所述web会话中,识别能够与所述服务器应用交互的富客户端; 在所述web会话中,向所述富客户端提供凭证,该凭证是以下之一:在所述基于浏览器的客户端处接收的所述凭证,和从所述服务器应用接收的新凭证;以及 在所述web会话中,使用向所述富客户端提供的所述凭证来使用所述富客户端向所述服务器应用认证用户。
18.如权利要求17所述的计算机程序产品,其中识别富客户端的步骤包括发起发现操作以确定一个或多个本地执行的富客户端的操作状态。`
19.如权利要求18所述的计算机程序产品,其中所述方法进一步包括: 向所述用户提供指示所述一个或多个本地执行的富客户端的显示;以及 从所述用户接收选择,该选择识别要向其提供凭证的富客户端。
20.如权利要求17所述的计算机程序产品,其中所述方法进一步包括在所述基于浏览器的客户端与所述富客户端之间建立控制信道。
21.如权利要求20所述的计算机程序产品,其中所述方法进一步包括使用所述控制信道向所述富客户端提供所述凭证。
22.如权利要求17所述的计算机程序产品,其中向所述富客户端提供的所述凭证与策略相关联,该策略定义了至少一个针对所述服务器应用的访问限制。
23.如权利要求22所述的计算机程序产品,其中所述策略是用户配置的策略。
24.如权利要求17所述的计算机程序产品,其中所述方法进一步包括使向所述富客户端提供的所述凭证无效。
25.—种便利第二客户端从由第一客户端发起的用户会话中对服务器应用的访问的方法,其中第一和第二客户端位于相同位置,该方法包括: 在第一与第二客户端之间建立控制信道; 在所述用户会话正在进行时,发现第二客户端可用于与所述服务器应用交互; 向第二客户端提供凭证;以及 使用所述凭证来使用第二客户端向所述服务器应用认证用户。
26.如权利要求25所述的方法,其中第一客户端是基于浏览器的客户端,第二客户端是非基于浏览器的客户端。
27.如权利要求25所述的方法,其中向第二客户端提供的所述凭证是当所述用户会话被发起时由第一客户端获得的凭证。
28.如权利要求25所述的方法,其中向第二客户端提供的所述凭证是通过注册第二客户端以从所述应用服务器接 收响应而获得的,该响应包括所述凭证。
【文档编号】H04L9/32GK103650414SQ201280033855
【公开日】2014年3月19日 申请日期:2012年7月9日 优先权日:2011年7月8日
【发明者】O·皮埃祖尔, M·A·麦克格洛因, M·E·祖尔科 申请人:国际商业机器公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1