从现有浏览器会话中认证富客户端

摘要

用户从基于浏览器的客户端向基于Web或基于云的应用进行认证。基于浏览器的客户端具有相关联的富客户端。在会话从基于浏览器的客户端被发起（并且凭证被获得）之后，用户可以发现富客户端可用并使其获得该凭证（或新的凭证）以用于自动地（使用富客户端）向该应用认证该用户，即不需要额外的用户输入。应用界面向用户提供了显示，通过该显示，用户可以配置富客户端认证操作，诸如规定如果富客户端被检测为正在运行则其是否应当自动地被认证，由富客户端对应用的访问是否以及在什么程度上要被限制，由富客户端对应用的访问是否以及何时要被取消，等等。

说明书

技术领域

本公开一般地涉及应用安全，尤其涉及一种使得能够从现有web 浏览器会话中传递或获取用于“富客户端”的凭证的方法。

背景技术

在现有技术中，用所谓的“富”客户端来集成基于Web或基于 云的应用是公知的，其中“富”客户端是（客户端-服务器应用的）支 持其自身界面（而不是仅从web应用本身导出web界面）的客户端。 “富”客户端通常不是基于浏览器的，并且其有时被称为“厚”（相 较于基于浏览器的或者“瘦”）客户端。说明性的富客户端为Lotus 其提供电子邮件、日历、联系人管理和即时通讯。富客户端 可以被用来代表用户访问和自动地执行动作。

许多该类型的非基于浏览器的（富）客户端应用也具有基于浏览 器的（瘦客户端）应用的对应部分或特征。瘦客户端可以是简单的web 浏览器和登录页面。当终端用户想要从单个工作站同时使用这些多个 客户端时，他或她必须向认证服务器分别地认证。应对该需求的普遍 方法是使用口令，其在多个界面中被输入，例如，每个客户端一个界 面。该方法不是用户友好的，因为用户需要多次输入他或她的口令。 而且，在用户以本地方式（在每个客户端中）存储口令的情况下，考 虑到多个副本被存储，其增加了损害的风险。进一步地，当用户修改 口令时，同样地，其必须在多个地方被改变。当然，当用户被迫多次 输入口令时，更有可能的是用户将选择较弱的口令。如果基于Web 或基于云的应用使用不支持基于口令的认证（基于口令的认证对于瘦 客户端方式是典型的）的单点登录协议（诸如SAML或OpenID）， 则出现了另一个问题。在这种情况下，用户被迫针对每个厚客户端和 瘦客户端使用不同类型的认证凭证和技术，这导致了进一步的低效率 和安全风险。

希望能够提供一种技术，通过该技术用户只需要在与基于Web 或基于云的应用的会话期间认证一次，但是其中该认证可以被传播到 相关联的可以由该用户发现的富客户端或以其他方式对这样的富客户 端可用。

发明内容

根据本公开，用户从瘦（基于浏览器的）客户端向基于Web或 基于云的应用认证。所述客户端具有相关联的富客户端。在会话从所 述基于浏览器的客户端被发起（以及凭证被获得）之后，用户可以发 现所述富客户端可用并且使其获得所述凭证（或新的凭证）以用于（使 用富客户端）自动地向所述应用来认证所述用户，即不需要额外的用 户输入。应用界面为用户提供了显示，通过该显示，用户可以配置富 客户端认证操作，诸如规定如果富客户端被检测为正在运行则其是否 应当自动地被认证，由富客户端对应用的访问是否以及在什么程度上 要被限制，由富客户端对应用的访问是否以及何时要被取消，等等。

在一个实施例中，为了便于所描述的操作，在浏览器与富客户端 之间建立了控制信道，富客户端被修改为包括HTTP服务器。通过向 到HTTP服务器的本地主机连接上的端口发送HTTP请求，浏览器可 以确定富客户端是否正在执行，并接着传递基于浏览器的凭证。

在另选的实施例中，控制信道使用标准操作系统机制来实现。特 别地，富客户端在操作系统中注册内容类型，并将自身建立为用于该 类型的处理程序（handler）。当需要发起富客户端认证时，浏览器向 所述应用发出HTTP请求，以请求新的凭证。HTTP响应包括具有与 所注册的内容类型相匹配的mime类型的凭证。新的凭证接着通过操 作系统被传递给富客户端，富客户端接着使用其来向所述应用认证。

上述认证方法可以在装置中执行。该装置包括处理器和计算机存 储器，该存储器存储计算机程序指令，当该指令被执行时，执行该方 法。

在另一个另选的实施例中，该认证方法由在数据处理系统中使用 的计算机可读介质中的计算机程序产品来执行。该计算机程序产品包 括计算机程序指令，当该指令由数据处理系统执行时，执行该方法。

前面已经概述了本发明的一些较相关的特征。这些特征应当被理 解为仅是说明性的。许多其他有益结果可以通过以不同方式应用所公 开的发明或通过按照将要描述的修改本发明来实现。

附图说明

为了更完整地理解本发明及其优点，现在参考以下结合附图的描 述，在附图中：

图1描绘了在其中可以实现示例性实施例的示例性方面的分布式 数据处理环境的示例性框图；

图2是在其中可以实现示例性实施例的示例性方面的数据处理系 统的示例性框图；

图3例示了在其中可以实现本公开的技术的客户端应用及其相关 联的基于Web或基于云的服务器应用；

图4是描述本公开的基本操作场景的处理流程图；

图5是根据本公开的来自用户通过其配置访问策略的应用界面的 显示页面；以及

图6是来自用户通过其发起富客户端认证操作或取消先前认证的 访问的应用界面的显示页面。

具体实施方式

现在参照附图，特别是参照图1-2，提供了在其中本公开的示例 性实施例可以被实现的数据处理环境的示例图。应当理解，图1-2仅 是示例性的，并且并非旨在断言或暗示关于在其中本公开主题的各方 面或实施例可以被实施的环境的任何限制。可以对所描绘的环境做出 许多修改而不偏离本发明的精神和范围。

现在参照附图，图1描述了在其中示例性实施例的各方面可以被 实现的示例性分布式数据处理系统的图形表示。分布式数据处理系统 100可以包括在其中示例性实施例的各方面可以被实现的计算机网 络。分布式数据处理系统100包含至少一个网络102，其是用于在分 布式数据处理系统100中连接在一起的各种设备和计算机之间提供通 信链路的介质。网络102可以包括连接，诸如有线、无线通信链路， 或光缆。

在所描绘的例子中，服务器104和服务器106以及存储单元108 连接到网络102。另外，客户端110、112和114也连接到网络102。 这些客户端110、112和114可以是例如个人计算机、网络计算机等。 在所描绘的例子中，服务器104向客户端110、112和114提供数据， 诸如引导文件、操作系统镜像、以及应用。在所描绘的例子中，客户 端110、112和114是服务器104的客户端。分布式数据处理系统100 可以包括额外的服务器、客户端以及其他未示出的设备。

在所描绘的例子中，分布式数据处理系统100是因特网，其中网 络102表示世界范围的使用传输控制协议/因特网协议（TCP/IP）的协 议组来相互通信的网络和网关的集合。在互联网的核心处是由成千上 万的路由数据和消息的商业、政府、教育及其他计算机系统组成的主 节点或主机计算机之间的高速数据通信线路的骨干。当然，分布式数 据处理系统100也可以被实现为包括许多不同类型的网络，诸如例如 内联网、局域网（LAN）、广域网（WAN）等。如上所述，图1旨在 作为例子，并非旨在作为对本公开主题的不同实施例的体系结构限制， 因此，图1所示的特定元素不应当被认为是对关于在其中本发明的示 例性实施例可以被实现的环境进行限制。

现在参照图2，其示出了在其中示例性实施例的各方面可以被实 现的示例性数据处理系统的框图。数据处理系统200是诸如图1的客 户端110的计算机的例子，实现本公开的示例性实施例的过程的计算 机可用代码或指令可以位于其中。

现在参照图2，其示出了在其中示例性实施例可以被实现的数据 处理系统的框图。数据处理系统200是诸如图1的服务器104或客户 端110的计算机的例子，实现示例性实施例的过程的计算机可用程序 代码或指令可以位于其中。在该说明性例子中，数据处理系统200包 括通信结构202，其提供处理器单元204、存储器206、持久存储装置 208、通信单元210、输入/输出（I/O）单元212以及显示器214之间 的通信。

处理器单元204用于执行可以被加载到存储器206中的软件指 令。处理器单元204可以是一组一个或多个处理器或者可以是多处理 器核，这取决于特定实现。进一步地，处理器单元204可以使用一个 或多个异构处理器系统来实现，其中主处理器与副处理器在单个芯片 上存在。作为另一个说明性例子，处理器单元204可以是对称多处理 器（SMP）系统，其包含多个相同类型的处理器。

存储器206和持久存储装置208是存储设备的例子。存储设备是 能够临时和/或持久地存储信息的任何硬件。在这些例子中，存储器206 可以是例如随机存取存储器或任何其他合适的易失性或非易失性存储 设备。持久存储装置208可以取决于特定实现而采用各种形式。例如， 持久存储装置208可以包含一个或多个组件或设备。例如，持久存储 208可以是硬盘驱动器、闪存、可重写光盘、可重写磁带或上述技术 的组合。持久存储装置208所使用的介质也可以是可移动的。例如， 可移动硬盘驱动器可以用于持久存储装置208。

在这些例子中，通信单元210提供与其他数据处理系统或设备的 通信。在这些例子中，通信单元210是网络接口卡。通信单元210可 以通过使用物理和/或无线通信链路来提供通信。

输入/输出单元212允许与可以连接到数据处理系统200的其他 设备的数据输入和输出。例如，输入/输出单元212可以为通过键盘和 鼠标的用户输入提供连接。进一步地，输入/输出单元212可以将输出 发送到打印机。显示器214提供向用户显示信息的机制。

用于操作系统和应用或程序的指令位于持久存储装置208上。这 些指令可以被加载到存储器206中以供处理器单元204执行。不同实 施例的处理可以由处理器单元204使用计算机实现的指令来执行，该 指令可以位于存储器中，诸如存储器206中。这些指令被称为程序代 码、计算机可用程序代码或计算机可读程序代码，其可以由处理器单 元204中的处理器读取和执行。不同实施例中的程序代码可以具体实 现在不同的物理或有形计算机可读介质上，诸如存储器206或持久存 储装置208上。

程序代码216以功能形式位于选择性可移动的计算机可读介质 218上，而且可以被加载到或转移到数据处理系统200上以供处理器 单元204执行。在这些例子中，程序代码216和计算机可读介质218 形成计算机程序产品220。在一个例子中，计算机可读介质218可以 是有形形式，诸如例如插入或放入驱动器中的光盘或磁盘，或者作为 持久存储装置208的一部分的用于传递到存储设备上的其他设备（诸 如作为持久存储装置208的一部分的硬盘驱动器）。按有形形式，计 算机可读介质218也可以采用持久存储装置的形式，诸如连接到数据 处理系统200的闪存、硬盘驱动器或拇指驱动器。计算机可读介质218 的有形形式也被称为计算机可记录的存储介质。在一些情况下，计算 机可记录介质218可以不是可移动的。

另选地，程序代码216可以通过到通信单元210的通信链路和/ 或通过到输入/输出单元212的连接而从计算机可读介质218传递到数 据处理系统200。在说明性例子中，该通信链路和/或连接可以是物理 的或无线的。计算机可读介质还可以采用非有形介质的形式，诸如包 含程序代码的通信链路或无线传输。例示的用于数据处理系统200的 不同组件并不意味着提供对在其中不同实施例可以被实现的方式的体 系结构限制。不同的说明性实施例可以被实现在这样的数据处理系统 中，其包括附加于或代替例示的用于数据处理系统200的那些组件的 组件。图2所示的其他组件可以不同于所示的说明性例子。作为一个 例子，数据处理系统200中的存储设备是可以存储数据的任何硬件装 置。存储器206、持久存储装置208和计算机可读介质218是有形形 式的存储设备的例子。

在另一个例子中，总线系统可以用于实现通信结构202，并且可 以由一个或多个总线组成，诸如系统总线或输入/输出总线。当然，总 线系统可以使用在附接于总线系统的不同组件或设备之间提供数据传 递的任何合适类型的体系结构来实现。另外，通信单元可以包括用于 发送和接收数据的一个或多个设备，诸如调制解调器或网络适配器。 进一步地，存储器可以是例如存储器206或缓存，诸如在可以存在于 通信结构202中的接口和存储器控制器集线器中找到的。

用于执行本发明的操作的计算机程序代码可以用一种或多种编 程语言的任何组合来编写，包括面向对象的编程语言（诸如Java^TM、 Smalltalk、c++等），以及传统的过程编程语言（诸如“C”编程语言 或类似的编程语言）。程序代码可以完全地在用户的计算机上执行、 部分地在用户的计算机上执行、作为独立软件包执行、部分地在用户 的计算机上且部分地在远程计算机上执行、或者完全地在远程计算机 或服务器上执行。在后一种场景中，远程计算机可以通过任何类型的 网络连接到用户的计算机，该网络包括局域网（LAN）或广域网 （WAN），或者可以连接到外部计算机（例如经由使用因特网服务提 供商的因特网）。

本领域的普通技术人员将理解，图1-2中的硬件可以取决于实现 而变化。其他的内部硬件或外围设备，诸如闪存、等效的非易失性存 储器、或光盘驱动器等，可以附加于或代替图1-2所描绘的硬件而使 用。同样，除了应用于前述SMP系统，说明性实施例的处理可以应 用于多处理器数据处理系统，而不脱离本公开主题的精神和范围。

可以看出，这里描述的技术可以结合在诸如图1所例示的标准客 户端-服务器范例中操作，在该范例中客户端机器与在一组一个或多个 机器上执行的互联网可访问的、基于Web的门户（portal）通信。终 端用户操作能够访问该门户并与其交互的因特网可连接的设备（例如 台式计算机、笔记本计算机、具有因特网功能的移动设备等）。通常， 每个客户端或服务器机器是诸如图2中例示的数据处理系统，其包括 硬件和软件，并且这些实体通过网络相互通信，所述网络诸如因特网、 内联网、外联网、专用网络或任何其他通信介质或链路。数据处理系 统通常包括一个或多个处理器、操作系统、一个或多个应用以及一个 或多个实用程序。数据处理系统上的应用提供对Web服务的原生支 持，包括但不限于对HTTP、SOAP、XML、WSDL、UDDI和WSFL 等的支持。关于SOAP、WSDL、UDDI和WSFL的信息可以从负责 开发和维护这些标准的万维网联盟（W3C）获得；关于HTTP和XML 的进一步信息可以从因特网工程任务组（IETF）获得。假定对这些标 准是熟悉的。

众所周知以及作为附加的背景，认证是验证由用户提供的或代表 用户的一组凭证的过程。认证是通过核实用户知道的事情、用户具有 的事物或用户所为何物（即关于用户的某一物理特性）来完成的。用 户知道的事情可以包括共享的秘密，诸如用户的口令，或者通过核实 仅特定用户知道的事情，诸如用户的加密密钥。用户具有的事物可以 包括智能卡或硬件令牌。关于用户的某一物理特性可以包括生物计量 输入，诸如指纹或视网膜地图。应当注意，用户通常是但未必一定是 自然人；用户可以是机器、计算设备或者使用计算资源的其他类型的 数据处理系统。还应当注意，用户通常但不是必须拥有单个唯一的标 识符；在某些场景下，多个唯一的标识符可以与单个用户相关联。

认证凭证是在各种认证协议中使用的一组质询/响应信息。例如， 用户名和口令组合是认证凭证的最常见形式。其他形式的认证凭证可 以包括各种形式的质询/响应信息、公钥基础设施（PKI）证书、智能 卡、生物计量等等。通常，认证由用户呈现，作为与认证服务器或服 务的认证协议序列的一部分。

如现在参照图3将要描述的，作为本公开的主题的技术通常在其 中基于Web或基于云的应用包括客户端侧和服务器侧组件的场景中 实现。客户端侧组件包括web浏览器或与其相关联的代码（例如浏览 器插件、小应用程序（applet）等）300、非基于浏览器的客户端302， 其中的每个都在诸如上面参照图2所描述的客户端机器304中执行。 例如，客户端机器304包括处理器306、计算机存储器308以及操作 系统310。基于浏览器的客户端在这里可以被称为“瘦”客户端，并 且非基于浏览器的客户端可以被称为“厚”或“富”客户端。每个这 种客户端组件被适配为通过诸如图1所示的网络314与包括服务器应 用312的服务器侧组件互操作。服务器应用304可以是基于Web的或 基于云的，并且其也在诸如图2所示的一个或多个机器上执行。

基于浏览器的客户端300已建立了和与其相关联的服务器应用 312的认证机制。同样地，非基于浏览器的或“富”客户端302已建 立了与服务器应用312的认证机制。这些认证机制可以是相同或不同 的。如上所述，“富”客户端不是基于浏览器的。说明性的富客户端 应用是Lotus其提供电子邮件、日历、联系人管理以及即时 通讯，尽管富客户端可以被实现在任何客户端-服务器应用中。在该例 子中，服务器应用304是数据服务器。当然，这些例子无意 限制所公开的主题，其可以用任何的基于Web或基于云的应用来实 现。

根据本公开，控制信道316在一方面的基于浏览器的客户端300 与另一方面的非基于浏览器的客户端302之间被建立。控制信道被用 来在这些组件之间传递信息，如将要描述的。在一个实施例中，控制 信道316使用本地主机连接318来实现，基于浏览器的客户端300和 与富客户端相关联的HTTP服务器实例320通过本地主机连接318通 信。在该实施例中，客户端300与客户端302之间的通信通常通过 HTTPS发生，尽管这不是必需的。在另选的实施例中，如将要描述的， 控制信道是使用操作系统310本身实现的，例如通过使富客户端注册 为用于特定mime类型的处理程序。控制信道可以以其他方式实现， 例如作为共享存储器段、进程间通信（IPC），通过网络呼叫、通过 文件等。如果控制信道是可以由其他客户端进程发现的，其应当使用 已知技术被保护。

现在参照图4的流程图描述本公开的典型操作场景。在步骤400， 终端用户已经打开了浏览器300的实例，并且已经向服务器应用312 认证，这通常是通过在浏览器中呈现的SSL安全登录页面处输入用户 标识符（UID）以及口令。其结果是，浏览器获得并存储相关联的凭 证305，其是由服务器应用提供的。如在步骤402所指示的，该操作 建立用户会话或“基于web的用户会话”。结果，用户然后可以采取 基于Web或基于云的应用所允许的一个或多个动作。根据本公开，在 用户会话从浏览器（即在现有web会话期间）被发起之后，富客户端 302被发现并向服务器应用312认证，其优选为自动地且不需要终端 用户输入额外的认证相关信息。换句话说，富客户端认证是透明地— —实际上是“在幕后”——但是以由服务器应用预期的方式被执行。 然而，终端用户不需要从富客户端执行与认证操作相关联的常规任务。 他或她认证一次（使用基于浏览器的方法），而该认证使能或便利了 基于富客户端的认证。

优选地，该富客户端自动的登录（自动登录）操作以如下方式完 成。假定该用户（或另一个用户）已经配置了某些发现和认证操作， 优选使用在下面描述的应用界面。在步骤404，执行检查以确定用户 是否想要使用该富客户端向服务器应用认证。如果用户想要向服务器 应用认证，则执行发现步骤406。发现步骤406识别是否有任何的富 客户端（一个或多个）正在客户端机器中执行（可能会有很多）。发 现步骤可以主动地执行，例如通过使浏览器在本地主机连接上发出一 个或多个请求并接收返回的“状态”响应，或者其可以被动地进行， 例如通过使这种状态信息按需对浏览器可用以及可显示。另选地，当 富客户端被启动时，其执行状态恰好以某种方式暴露给用户，例如在 听觉上、视觉上等等。发现过程的性质将取决于实现方式。可以使用 的其他发现技术包括使富客户端在HTTP服务器实例上打开端口，以 及使浏览器在一组可用的端口上迭代直到其定位到该打开的端口，其 表明富客户端正在执行。在IPC被用作控制信道的情况下，操作系统 发布机制可以用于提供富客户端正在执行的通知。这些例子并非旨在 限制。

在发现之后，例程继续到步骤408，在该步骤中富客户端获得用 于向服务器应用执行实际认证的凭证。在一个实施例中，该凭证正是 在基于浏览器的向应用服务器认证期间获得的凭证305。在该实施例 中，浏览器简单地经由控制信道将该凭证传递到富客户端。在另选的 实施例中，富客户端已经向本地操作系统注册为用于mime内容类型 （例如x-application/rich-auth）的处理程序。在步骤408，浏览器发 出HTTP请求到服务器应用以请求新凭证；来自服务器应用的HTTP 响应包括新凭证和标识相关联的mime类型的报头。由于富客户端被 注册为用于该mime类型的处理程序，所以HTTP响应（新凭证）通 过操作系统内核被传播给富客户端，富客户端然后使用其来认证，再 一次地不需要显式的用户输入。在该另选的实施例中，控制信道使用 标准OS机制，因此是与平台无关的。在步骤410，富客户端完成向 服务器应用的认证，过程终止。

图4中所示的一个或多个步骤可以按不同的顺序进行。一个或多 个步骤可以被组合，或可以实行替换。

富客户端向服务器应用312认证的特定方式不是本公开的方面。 用于该目的的已知技术包括但不限于基于SAML的认证（其中服务器 发出SAML断言，该断言接着被转发给富客户端，富客户端用该断言 认证或用其交换另一个凭证）、基于OAuth的认证（其中服务器发出 由富客户端使用以认证的OAuth令牌）、基于一次性令牌的认证（其 中服务器生成保存在服务器侧并与用户相关联的随机现时标志 （nonce）），等等。

在基于浏览器的客户端300与富客户端直接通过控制信道通信的 第一实施例中，服务器应用与本地HTTP服务器（与富客户端相关联 执行）可以在不同域中操作。本地HTTP服务器可以附加于富客户端， 或与其成一体。因此，已知的跨域通信方法（例如脚本包含）应当被 使用以促进该交互。在另一个变型中，不是使用本地HTTP服务器， 而是使用浏览器插件或签名的小应用程序来与应用服务器交互以获得 凭证及实现富客户端认证。

图5例示了代表性的应用界面322（图3），通过其用户（或其 他个人或者实体）可以配置操作。该界面可以作为一个或多个网页被 导出到浏览器，尽管这并不是限制。代表性的页面500展现了一组配 置元件，诸如输入字段、HTML填写式表格、单选按钮等。因此，例 如，通过选择单选按钮502，用户可以请求在发起web会话后所有运 行的富客户端被发现。通过选择单选按钮504，用户可以选择使所有 运行的富客户端根据请求而更新。用户可以选择单选按钮来规定当富 客户端被检测为运行时自动被认证。使用从列表506可获得的选项， 用户可以规定对富客户端如何与服务器应用交互的约束或限制。因此， 例如，该列表可以展现一个或多个选项，例如，访问是“只读”的， 访问对于可以指定的有限时间是可用的，只有某些功能或应用编程接 口（API）是可用的，等等。这些仅仅是代表性配置选项，并且本领 域的普通技术人员将会明白可以根据需要实现其他配置选项。该配置 界面也可以提供一种控件，一旦选择了该控件，使用户能够直接从浏 览器启动富客户端，如果该客户端未在运行的话。使用该界面，用户 配置定义了富客户端应当如何向服务器应用认证的“策略”。一组默 认策略可以展现给用户以便于这种选择。虽然已经描述了界面的实施 例，但是可以使用一个或多个另选的方法，例如使用命令行界面、以 编程方式定义策略，等等。

图6例示了界面的发现页面600。该页面在前面描述的发现步骤 之后被显示。在该例子中，发现操作已经识别了两个富客户端（客户 端1和客户端2）在客户端机器中执行，并且这些客户端在这里由图 标602和604表示。图标602包括对已经针对与之相关联的客户端1 发出了凭证的指示或视觉提示。通过选择该图标，终端用户可以被提 供使客户端1的认证无效的机会（例如经由单独的对话框）；另选地， 对图标602的选择本身终止富客户端的认证。在任一情况下，从富客 户端对服务器应用的访问被有效地取消（通过使凭证无效）。通过选 择图标604，终端用户可以发起获得凭证的过程，如上面所描述的， 因此客户端2可以访问和使用服务器应用。

因此，根据该技术，用户可以使富客户端能够自动地并且基于由 用户定义的策略向服务器应用认证。该策略可以规定凭证可以仅针对 特定时间段而发布，或者其仅用于访问应用的一部分，等等。访问是 可取消的，这同样是基于用户的所配置的策略。

所公开的主题具有许多优点。一个关键的优点是在与基于Web 或基于云的应用的会话期间（并且在一个地方），用户只需要进行一 次认证。使用所描述的技术，该认证然后有效地用于使相关联的富客 户端能够访问该应用。另一个优点是富客户端的这种访问可以根据用 户配置的策略而定制，并且用户可以根据需要取消富客户端的这种访 问。使用所述发现特征，用户可以查看本地运行的富客户端并通过请 求服务器应用（或其他实体）发出凭证（或令牌等）来对其认证，该 凭证接着被富客户端用来向应用认证该用户。该技术提供了几种用于 将现有基于浏览器的凭证传播到富客户端或者使富客户端能够获得新 凭证的本地机制。

该技术可以用于任何的富客户端，而不管该客户端如何向服务器 应用进行认证。

在一个所描述的实施例中，该技术使得（基于浏览器的）客户端 应用凭证能够自动且直接地传播到与浏览器应用相关联的对应的非浏 览器进程。如果想要在现有的基于web的用户会话中开始该客户端的 话，该方案避免了用户必须登录到富客户端。

如这里所使用的，“凭证”应当被广义地理解为便于对服务器应 用进行访问的任何凭证、令牌、数据集或数据。如上面所指出的，客 户端（无论是基于浏览器的还是富的）具有与其相关联的服务器应用 建立的认证机制，并且所公开的技术遵循所涉及的语义和通信协议。

本公开的自动登录方案提供了基于浏览器的客户端与相关联的 富客户端之间的独特的交互，二者都优选与基于Web或基于云的服务 器应用相关联。该方案假设基于浏览器的客户端与服务器应用之间的 现有用户会话已就位，换句话说，当终端用户登录到服务器应用时， 凭证已经先前生成了。

虽然不作限制，但是在代表性的实施例中，服务器应用执行应用 服务器（诸如服务器），其包括对一个或多个基于 服务器的代码功能的支持，通常以兼容J2EE的小服务程序（servlet） 的形式。

上面描述的功能可以被实现为独立的方法，例如由处理器执行的 基于软件的功能，或者其可以作为管理服务（包括作为经由 SOAP/XML界面的web服务）而可用。这里所描述的特定硬件和软 件实现方式细节仅仅是用于说明的目的而并不旨在限制所描述的主题 的范围。

更一般地，在所公开的主题的上下文中，计算设备均为包括硬件 和软件的数据处理系统（诸如图2所示），这些实体通过网络相互通 信，诸如因特网、内联网、外联网、专用网络或任何其他通信介质或 链路。在数据处理系统上的应用提供对Web以及其他已知服务和协议 的原生支持，包括但不限于对HTTP、FTP、SMTP、SOAP、XML、 WSDL、UDDI和WSFL等的支持。关于SOAP、WSDL、UDDI和 WSFL的信息可以从万维网联盟（W3C）获得，其负责开发和维护这 些标准；关于HTTP、FTP、SMTP和XML的进一步信息可以从因 特网工程任务组（IETF）获得。假定对这些已知的标准和协议是熟悉 的。

这里描述的富客户端自动登录方案可以在各种服务器侧的体系 结构中实现或者与所述体系结构相结合来实现，所述体系结构包括简 单的n层体系结构、web门户、联合系统等。应用服务器组件可以位 于与一个或多个后端应用的域不同的域中，因此，这里的技术可以在 松散耦合的服务器（包括基于“云”的）环境中实践。应用服务器本 身可以被托管在所述云中。

更一般地，这里所描述的主题可以采用以下形式：完全的硬件实 施例、完全的软件实施例或包含硬件和软件元件的实施例。在优选实 施例中，功能在软件中实现，该软件包括但不限于固件、驻留软件、 微代码等。此外，如上面所指出的，自动登录功能可以采取计算机程 序产品的形式，该计算机程序产品可以从计算机可用或计算机可读介 质访问，并提供了供计算机或任何指令执行系统使用或与其结合使用 的程序代码。用于该描述的目的，计算机可用或计算机可读介质可以 是可以包含或存储供指令执行系统、装置或设备使用或与其结合使用 的任何装置。该介质可以是电、磁、光、电磁、红外、或半导体系统 （或装置或设备）。计算机可读介质的例子包括半导体或固态存储器、 磁带、可移动计算机盘、随机存取存储器（RAM）、只读存储器（ROM）、 硬磁盘和光盘。光盘的当前例子包括光盘—只读存储器（CD-ROM）、 光盘—读/写（CD-R/W）和DVD。计算机可读介质是有形物品。

计算机程序产品可以是具有实现所描述的功能中的一个或多个 的程序指令（或程序代码）的产品。在通过网络从远程数据处理系统 被下载之后，这些指令或代码可以被存储在数据处理系统中的计算机 可读存储介质中。或者，这些指令或代码可以被存储在服务器数据处 理系统中的计算机可读存储介质中，并被适配为通过网络被下载到远 程数据处理系统以供在远程系统中的计算机可读存储介质中使用。

在代表性的实施例中，所描述的客户端和服务器组件被实现在专 用计算机中，优选被实现在由一个或多个处理器执行的软件中。该软 件被保持在与一个或多个处理器相关联的一个或多个数据存储库或存 储器中，并且该软件可以被实现为一个或多个计算机程序。共同地， 该专用硬件和软件包括提供富客户端自动登录功能的组件。

所描述的功能可以被实现为现有应用服务器功能或操作的附加 或扩展。

虽然以上描述了由本发明的某些实施例执行的操作的特定顺序， 但应当理解，这种顺序是示例性的，因为另选实施例可以按不同的顺 序执行操作，组合某些操作，重叠某些操作等等。在说明书中对给定 实施例的参考指示了所描述的实施例可以包括特定特征、结构或特性， 但每个实施例可能并不必定包括该特定特征、结构或特性。

最后，虽然已经分别描述了系统的给定组件，但本领域的普通技 术人员会清楚一些功能可以以给定的指令、程序序列、代码部分等等 共享或组合。

这里所用的“浏览器”并非旨在指代任何特定的浏览器（例如 Internet Explorer、Safari、FireFox等），而是应当被广义地解释为 指任何客户端侧的可以访问并显示因特网可访问的资源的呈现引擎。 进一步地，尽管通常客户端-服务器的交互使用HTTP发生，如上面所 指出的，但这也不是限制。客户端服务器交互可以被格式化为符合简 单对象访问协议（SOAP），并且通过HTTP（通过公共因特网）、 FTP或任何其他可靠的传输机制（诸如技术和 CORBA，用于通过企业内联网传输）的传输可以被使用。此外，术 语“网站”或“服务供应商”应当被广义地解释为覆盖网站（一组链 接的网页）、在给定的网站或服务器处的域、与服务器或服务器组相 关联的信任域等。“服务供应商域”可以包括网站或网站的一部分。 通过提供到另一个应用中的钩子，通过促进将机制作为插件使用，通 过链接到机制等，这里所描述的任何应用或功能可以被实现为本机代 码。

如所指出的，上面描述的富客户端自动登录功能可以被用于任何 系统、设备、门户、站点等中，其中非基于浏览器的客户端应用凭证 需要被传递至相关联的浏览器进程。更一般地，所描述的技术被设计 用于任何操作环境，其中希望给定的信息（包括但不局限于凭证数据） 从客户端应用到相关联的浏览器进程以自动方式持续。

虽然上面描述的实施例提供了从现有的浏览器会话中认证富客 户端，但是基本技术也可以实现于这样的场景，其中向web应用认证 富客户端，并且想要将现有的凭证传送到瘦客户端。在该场景中，假 设富客户端具有确保由瘦客户端（对该应用的）访问是被允许的方法， 则控制信道在富客户端与可用的基于浏览器的客户端之间被启用。富 客户端所获得的凭证接着被传递到基于浏览器的客户端，以使得用户 能够被认证。

服务器应用使得能够对服务、服务器、应用程序、进程、页面（例 如维基、网页等）、文件、链接对象、目录等等进行访问。

在已经描述了我们的发明之后，我们现在要求保护权利要求。