用于基于策略的自动同意的方法和装置制造方法

用于基于策略的自动同意的方法和装置制造方法
【专利摘要】本发明涉及一种用于基于策略的自动同意的方法和装置。描述一种用于智能自动同意的技术，可以使用所述技术，基于资源所有者的先前授权决策和/或其它客户机分类，自动授权客户机访问所述所有者的受保护信息(例如，简档)。使用这种方法授予同意，在请求访问的每个客户机的授权步骤期间，不需要所述资源所有者干预。可以对客户机进行分类，并且基于个体客户机所属的类别和/或访问请求的范围，为个体客户机提供授权。可以使用以用户为中心的身份协议以及委托授权协议实现所述技术。所述技术提供基于策略的同意授予。
【专利说明】用于基于策略的自动同意的方法和装置

【技术领域】
[0001] 本公开一般地涉及联网环境中的身份管理。

【背景技术】
[0002] 以用户为中心的身份协议（例如OpenID)和委托授权协议（例如0Auth2. 0)需要 用户针对希望访问用户简档信息的客户机（例如，网站）授权同意。通常经由在身份提供方 或其它授权服务器处向用户提示的网络表单获得这种授权。表单包含标识客户机、数据类 型、一个或多个操作或者其它上下文信息的信息，最终用户可以使用该信息做出同意决策。 通过填写表单或者以其它方式提供同意，用户然后可以允许客户机对用户简档信息进行后 续（和自动）访问。但是，在当前实施方式中，用户必须授权每个客户机，因为没有已知技 术用于针对例如与其它客户机具有某种共性的特定客户机提供自动同意。因此，当访问具 有类似性质的站点时，尤其是在同意决策未持续长期存储的情况下，授权要求给用户带来 很多麻烦。
[0003] 用户管理的访问（UMA)是一种草案协议，其定义资源所有者可如何控制由任意请 求方操作的客户机对受保护资源的访问，其中资源位于任意数量的资源服务器上，并且其 中集中授权服务器基于资源所有者策略来管理访问。该解决方案将授权决策委托给另一个 系统，该另一个系统又必须验证每个客户机请求。但是，UMA协议并未定义任何机制以供资 源所有者创建策略决策或者由访问管理者进行策略决策。


【发明内容】

[0004] 根据本公开，描述一种用于智能自动同意的技术，可以使用所述技术，基于资源所 有者的先前授权决策和/或其它客户机分类，自动授权客户机访问所述所有者的受保护信 息（例如，简档）。使用这种方法授予同意，在请求访问的每个客户机的授权步骤期间，不再 需要所述资源所有者干预。可以对客户机进行分类，并且基于个体客户机所属的类别和/ 或访问请求的范围，为个体客户机提供授权。可以使用以用户为中心的身份协议以及委托 授权协议实现所述技术。所述技术提供基于策略的同意授予。
[0005] 根据一个实施例，描述一种管理对访问受保护资源授予同意的方法。所述受保护 资源与资源所有者关联。所述方法首先接收访问受保护资源的请求，所述请求具有范围并 与客户机关联。在接收时，执行分析（通常分析请求URI)以便标识所述客户机的特征。基 于所述客户机的所述特征和所述请求的所述范围，应用策略以便判定所述客户机是否应接 收访问所述受保护资源的自动同意。如果基于所述策略，所述客户机应接收自动同意，则向 所述客户机返回给定信息。在一个实施例中，所述给定信息是OAuth令牌，所述客户机然后 可以使用所述OAuth令牌获得对所述受保护资源的访问而无需来自所述资源所有者的显 式同意。
[0006] 可以具有多种方法确定所述客户机特征。优选地，可以参考一个或多个信息服务。 所述信息服务例如包括URL分类器、域标签服务、URL信誉引擎、隐私策略服务等。如果不 能满足所述策略，则向所述资源所有者发出提示以便获得对访问的显式同意。在接收到所 述同意时，可以更新所述策略并针对未来请求应用所述策略。
[0007] 上面概述了本发明的某些更相关特性。这些特性应被解释为仅是示例性的。可以 通过以不同方式应用公开的发明或者通过修改将要描述的本发明，获得许多其它有利的结 果。

【专利附图】

【附图说明】
[0008] 为了更全面地理解本发明及其优点，现在参考以下结合附图的描述，这些附图 是：
[0009] 图1示出其中可以实现示例性实施例的示例性方面的分布式数据处理环境的示 例性框图；
[0010] 图2是其中可以实现示例性实施例的示例性方面的数据处理系统的示例性框图；
[0011] 图3示出根据本公开的用于基于策略的自动同意决策的代表性系统；
[0012] 图4示出涉及第一客户机网站的代表性第一用例；
[0013] 图5示出涉及第二客户机网站的代表性第二用例；
[0014] 图6示出一个代表性实施例的过程流；以及
[0015] 图7示出其中可以实现本公开的策略引擎的策略管理系统。

【具体实施方式】
[0016] 现在参考附图，具体地说参考图1-2,提供其中可以实现本公开的示例性实施例的 数据处理环境的示例性图。应理解，图1-2仅是示例性的，并且并非旨在断言或暗示有关其 中可以实现公开的主题的各个方面或实施例的环境的任何限制。在不偏离本发明的精神和 范围的情况下可以对所示环境做出许多修改。
[0017] 现在参考附图，图1示出其中可以实现示例性实施例的各个方面的示例性分布式 数据处理系统的图形表示。分布式数据处理系统100可以包括其中可以实现示例性实施例 的各个方面的计算机网络。分布式数据处理系统100包含至少一个网络102,其是用于在分 布式数据处理系统100中连接在一起的各种设备和计算机之间提供通信链路的介质。网络 102可以包括连接，例如有线、无线通信链路或光缆。
[0018] 在所示实例中，服务器104和服务器106以及存储单元108连接到网络102。此 夕卜，客户机110、112和114也连接到网络102。这些客户机110、112和114例如可以是个人 计算机、网络计算机等。在所示实例中，服务器104为客户机110U12和114提供数据，例 如引导文件、操作系统映像和应用。在所示实例中，客户机110、112和114是服务器104的 客户机。分布式数据处理系统100可以包括其它服务器、客户机和其它未示出的设备。
[0019] 在所示实例中，分布式数据处理系统100是因特网，同时网络102代表全球范围内 使用传输控制协议/网际协议（TCP/IP)协议集来相互通信的网络和网关的集合。在因特 网的核心是主节点或主机之间的高速数据通信线路的主干，它包括数以千计的商业、政府、 教育以及其它路由数据和消息的计算机系统。当然，分布式数据处理系统100也可以实现 为包括许多不同类型的网络，例如内联网、局域网（LAN)、广域网（WAN)等。如上所述，图1 旨在作为一个实例，并非旨在作为对公开的主题的不同实施例的体系架构限制，因此，图1 中所示的特定元素不应被视为有关其中可以实现本发明的示例性实施例的环境的限制。
[0020] 现在参考图2,示出其中可以实现示例性实施例的各个方面的示例性数据处理系 统的框图。数据处理系统200是诸如图1中的客户机110之类的计算机的一个实例，实现 本公开的示例性实施例的过程的计算机可用代码或指令可以位于其中。
[0021] 现在参考图2,示出其中可以实现示例性实施例的数据处理系统的框图。数据处 理系统200是诸如图1中的服务器104或客户机110之类的计算机的一个实例，实现示例 性实施例的过程的计算机可用程序代码或指令可以位于其中。在该示例性实例中，数据处 理系统200包括通信光纤通道网络202,其在处理器单元204、存储器206、永久性存储装置 208、通信单元210、输入/输出（I/O)单元212和显示器214之间提供通信。
[0022] 处理器单元204用于执行可以被加载到存储器206的软件的指令。处理器单元 204可以是包含一个或多个处理器的集合或者可以是多处理器核心，具体取决于特定的实 现。此外，处理器单元204可以使用一个或多个异构处理器系统来实现，其中在单个芯片上 同时存在主处理器与辅助处理器。作为另一个示例性实例，处理器单元204可以是包含同 一类型的多个处理器的对称多处理器系统。
[0023] 存储器206和永久性存储装置208是存储设备的实例。存储设备是任何能够临时 和/或永久存储信息的硬件。在这些实例中，存储器206例如可以是随机存取存储器或任 何其它合适的易失性或非易失性存储设备。永久性存储装置208可以采取各种形式，具体 取决于特定的实现。例如，永久性存储装置208可以包含一个或多个组件或设备。例如，永 久性存储装置208可以是硬盘驱动器、闪存、可重写光盘、可重写磁带或上述某种组合。永 久性存储装置208使用的介质也可以是移动的。例如，可移动硬盘驱动器可以用于永久性 存储装置208。
[0024] 在这些实例中，通信单元210提供与其它数据处理系统或设备的通信。在这些实 例中，通信单元210是网络接口卡。通信单元210可以通过使用物理和无线通信链路两者 之一或全部来提供通信。
[0025] 输入/输出单元212允许使用其它可以连接到数据处理系统200的设备来输入和 输出数据。例如，输入/输出单元212可以通过键盘、鼠标提供连接以实现用户输入。此外， 输入/输出单元212可以将输出发送到打印机。显示器214提供用于向用户显示信息的机 构。
[0026] 用于操作系统和应用或程序的指令位于永久性存储装置208中。这些指令可以被 加载到存储器206以便由处理器单元204执行。处理器单元204可以使用计算机实现的指 令（可以位于存储器（例如存储器206)中）执行不同实施例的过程。这些指令称为程序 代码、计算机可用程序代码或计算机可读程序代码，它们可以由处理器单元204中的处理 器读取和执行。在不同的实施例中，程序代码可以包含在不同的物理或有形计算机可读介 质（例如存储器206或永久性存储装置208)中。
[0027] 程序代码216以功能形式位于选择性地可移动的计算机可读介质218中，并且可 以被加载或传输到数据处理系统200以便由处理器单元204执行。在这些实例中，程序代码 216和计算机可读介质218形成计算机程序产品220。在一个实例中，计算机可读介质218 可以采取有形形式，例如光盘或磁盘，光盘或磁盘被插入或放置到属于永久性存储装置208 的一部分的驱动器或其它设备中，以便传输到属于永久性存储装置208的一部分的存储设 备（例如硬盘驱动器）。在有形形式中，计算机可读介质218还可以采取永久性存储装置的 形式，例如连接到数据处理系统200的硬盘驱动器、拇指驱动器或闪存。有形形式的计算机 可读介质218也称为计算机可记录存储介质。在某些情况下，计算机可记录介质218可能 不可移动。
[0028] 备选地，可以通过到通信单元210的通信链路和/或通过到输入/输出单元212的 连接，将程序代码216从计算机可读介质218传输到数据处理系统200。在示例性实例中， 通信链路和/或连接可以是物理或无线的。计算机可读介质还可以采取非有形介质的形 式，例如包含程序代码的通信链路或无线传输。针对数据处理系统200示出的不同组件并 非旨在提供有关可以实现不同实施例的方式的体系结构限制。可以在如下数据处理系统中 实现不同的示例性实施例：该系统包括除了针对数据处理系统200示出的那些组件之外的 组件或替代那些组件的组件。图2中所示的其它组件可以不同于所示的示例性实例。作为 一个实例，数据处理系统200中的存储设备是任何可以存储数据的硬件装置。存储器206、 永久性存储装置208和计算机可读介质218是有形形式的存储设备的实例。
[0029] 在另一个实例中，总线系统可以用于实现通信光纤通道网络202,并且可以包括一 条或多条总线（例如系统总线或输入/输出总线）。当然，总线系统可以使用任何合适类型 的体系结构来实现，该体系结构在连接到总线系统的不同组件或设备之间提供数据传输。 此外，通信单元可以包括一个或多个用于发送和接收数据的设备，例如调制解调器或网络 适配器。此外，存储器例如可以是存储器206,或者例如在接口中发现的高速缓存以及可以 存在于通信光纤通道网络202中的存储控制器集线器。
[0030] 可以以一种或多种程序设计语言的任意组合来编写用于执行本发明的操作 的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言一诸如JavaTM、 Smalltalk、Objectvie-C、C++等，还包括常规的过程式程序设计语目一诸如"C"语目或类 似的程序设计语言。程序代码可以以解释语言（例如Python)编写。程序代码可以完全 地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在 用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及 远程计算机的情形中，远程计算机可以通过任意种类的网络一包括局域网（LAN)或广域网 (WAN)-连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来 通过因特网连接）。此处的技术还可以在非传统的IP网络中实现。
[0031] 所属【技术领域】的普通技术人员应理解，图1-2中的硬件可以有所变化，具体取决 于实现。除了图1-2中所示的硬件之外或替代这些硬件，可以使用其它内部硬件或外围设 备，例如闪存、等效的非易失性存储器或光盘驱动器等。此外，在不偏离公开的主题的精神 和范围的情况下，可以将示例性实施例的过程应用于不同于先前提及的SMP系统的多处理 器数据处理系统。
[0032] 如将看到的，在此描述的技术可以结合诸如图1中所示的标准客户机-服务器范 例操作，其中客户机机器与在包含一个或多个机器的集合上执行的因特网可访问的基于网 络的门户通信。最终用户操作能够访问门户并且与门户交互的因特网可连接的设备（例 如，台式计算机、笔记本计算机、支持因特网的移动设备等）。通常，每个客户机或服务器机 器是包括硬件和软件的数据处理系统（例如图2中所示），并且这些实体通过网络（例如 因特网、内联网、外联网、专用网络）或任何其它通信介质或链路彼此通信。数据处理系统 通常包括一个或多个处理器、操作系统、一个或多个应用以及一个或多个实用工具。数据处 理系统上的应用提供对Web服务的本机支持，包括但不限于对HTTP、SOAP、XML、WSDL、UDDI 和WSFL等的支持。有关SOAP、WSDL、UDDI和WSFL的信息可以从万维网联盟（W3C)获得， 该联盟负责开发和维护这些标准；有关HTTP和XML的进一步信息可以从因特网工程任务组 (IETF)获得。假设熟悉这些标准。
[0033] 通过额外背景，认证是验证用户提供或者代表用户提供的一组凭证的过程。通过 检验用户知道的某些事物、用户具有的某些事物或者用户属于的某些事物（即，有关用户 的某些物理特征）而实现认证。用户知道的某些事物可以包括共享秘密（例如用户的密 码），或者通过验证只有特定用户知道的某些事物（例如用户的加密密钥）。用户具有的某 些事物可以包括智能卡或硬件令牌。有关用户的某些物理特征可包括生物特征输入，例如 指纹或视网膜图。应注意，用户通常但不一定是自然人；用户可以是机器、计算设备，或者使 用计算资源的其它类型的数据处理系统。还应注意，用户通常但不一定具有单个唯一标识 符；在某些情况下，多个唯一标识符可以与单个用户关联。
[0034] 认证凭证是用于各种认证协议的一组质询/响应信息。例如，用户名和密码组合 是最熟悉形式的认证凭证。其它形式的认证凭证可以包括各种形式的质询/响应信息、公 钥基础架构（PKI)证书、智能卡、生物特征识别等。认证凭证不同于认证断言：认证凭证由 用户使用认证服务器或服务提供，作为认证协议序列的一部分，而认证断言是有关成功提 供和验证用户的认证凭证的声明，随后必要时在实体之间转移。
[0035] 单点登录（SS0)是一种访问控制机制，其能够使用户认证一次（例如，通过提供用 户名和密码）并且跨多个系统获得对软件资源的访问。通常，SS0系统能够使用户访问企 业或组织中的资源。联合单点登录（F-SS0)跨多个企业扩展单点登录的概念，因此在不同 组织和企业之间建立合作伙伴关系。F-SS0系统通常包括诸如SAML之类的协议，这些协议 允许一个企业（例如，身份提供方）将用户的身份和其它属性提供给另一个企业（例如，月艮 务提供方）。F-SS0系统有助于使用合适的协议（通常为HTTP)，以可信方式将用户的凭证 从身份提供方传输到服务提供方。在典型的F-SS0实现中，身份提供方和服务提供方具有 如下F-SS0系统：其包括逻辑以便认证用户，建立用户的凭证，并且生成包括用户信息的加 密安全令牌（例如，cookie)。此外，服务提供方还可以包括一个或多个目标应用。目标应 用可以位于同一 Web环境中，或者是同一服务提供方中的不同Web环境的一部分。
[0036] 在传统的客户机-服务器认证模型中，客户机使用其凭证访问服务器托管的资 源。随着分布式Web服务和云计算使用的增加，第三方应用通常需要访问这些服务器托管 的资源。OAuth是一种开放协议（因特网请求注释（RFC)5849)，其能够使用户在不同网站 之间共享其私有数据及其凭证，而仅在保存数据的原始网站上公开数据。具体地说，OAuth 协议允许用户与其它站点共享存储在一个网站上的私有资源，而不向保存用户数据的网站 之外的网站公开用户的凭证（例如，用户名和密码）。采用OAuth作为其认证协议之一的网 站可增强用户的隐私性和安全性。为了实现这种功能，OAuth向传统的客户机-服务器认 证模型引入第三角色：即，资源所有者。在OAuth模型中，客户机（不是资源所有者，而是代 表其操作）请求访问由资源所有者控制但由服务器托管的资源。此外，OAuth允许服务器 不仅检验资源所有者授权，而且还检验发出请求的客户机的身份。
[0037] 作为额外背景，可以是上述协议的目标的应用可以位于相同或不同的Web环境 中，并且具有不同的认证机制和不同的要求。没有限制，目标应用可以位于企业中，或者可 以位于基于云的操作环境中。云计算是一种服务交付模式，用于对共享的可配置计算资源 池进行方便、按需的网络访问。可配置计算资源是能够以最小的管理成本或与服务提供者 进行最少的交互即可快速部署和释放的资源，例如可以是网络、网络带宽、服务器、处理、内 存、存储、应用、虚拟机和服务。云计算环境是面向服务的，特点集中在无状态性、低耦合性、 模块性和语意的互操作性。云计算的核心是包含互连节点网络的基础架构。上面的图2中 示出代表性云计算节点。云计算基础架构通常包括一组功能抽象层，包括硬件/软件层、虚 拟层、管理层和工作负载层。虚拟层提供一个抽象层，该层可以提供下列虚拟实体的例子： 虚拟服务器、虚拟存储、虚拟网络（包括虚拟私有网络）、虚拟应用和操作系统，以及虚拟客 户机。管理层提供用于在云计算环境中执行任务的计算资源和其它资源的动态获取。工作 负载层提供云计算环境可能实现的功能。通常，代表性云计算环境具有一组高级功能组件， 这些组件包括前端身份管理器、业务支持服务（BSS)功能组件、操作支持服务（OSS)功能组 件和计算云组件。身份管理器负责与请求客户机对接以便提供身份管理，并且该组件可以 使用一个或多个已知系统实现，这些系统例如包括可以从位于纽约阿蒙克的IBM?公司 获得的 Tivoli'1^ Federated Identity Manager(TFIM)。在适当的情况下，TFIM 可以用于 为其它云组件提供F-SS0。业务支持服务组件提供某些管理功能，例如计费支持。操作支 持服务组件用于提供其它云组件（例如虚拟机（VM)实例）的供应和管理。云组件表示通 常是多个虚拟机实例的主要计算资源，这些虚拟机实例用于执行可以通过云访问的目标应 用。使用一个或多个数据库存储目录、日志和其它工作数据。所有这些组件（包括前端身 份管理器）均位于云"中"，但并非必须如此。
[0038] 某于策略的自动同意
[0039] 使用以上所述作为背景，现在描述本公开的基于策略的自动同意技术。如所描述 的，在这种方法中，可以基于一个或多个准则（例如资源所有者进行的先前授权决策）和/ 或一个或多个与客户机关联的分类，自动为客户机（请求访问所有者的受保护资源）授予 同意以进行此类访问。如将看到的，这种方法针对未来客户机访问请求实现自动同意（或 "自动同意"）而不需要资源所有者干预。
[0040] 如图3中所示，在基本OAuth范例（具有代表性）中，资源所有者300是操作者 (通常为人），其希望控制客户机302对在资源服务器306处提供并受到保护的特定受保护 资源304的访问。资源服务器306是如下实体：其通过使所有者的受保护资源仅可用于经 过适当认证和授权的客户机而保护这些资源。客户机是操作者（通常为网站），其希望访 问资源服务器306处的受保护资源。授权服务器308 (例如，身份提供方）是颁发访问令牌 (在OAuth中）的实体。访问令牌是数据对象，客户机通过它向资源服务器306认证并且断 言其访问特定资源的授权。其它类似的协议使用其它类型的数据对象以实现该目的。访问 令牌通常在授权范围和持续时间方面受到限制。资源服务器306和授权服务器308可以是 同一或不同的服务器，并且它们可以位于一起或者彼此远离。在已知技术中，资源所有者可 以针对客户机访问所有者的受保护资源而授权同意。如将描述的，在此描述的技术的目标 是使授权同意的过程自动化（如果可能），以便每当特定客户机希望获得资源时，不需要一 定与资源所有者联系。
[0041] 根据本公开并且为了此目的，在系统中包括其它计算元件。如图3中所示，系统还 包括"策略引擎"310。策略引擎310是计算实体（或计算实体集合），资源所有者可用以定 义一个或多个策略，当客户机请求受保护资源时，应该应用这些策略。通常，策略引擎（在 此有时称为"引擎"）在授权服务器处实现，例如作为存储在计算机存储器中并由一个或多 个硬件元件执行的计算机软件程序或过程。资源所有者可以主动（即，预先）定义策略，然 后将策略应用于一个或多个客户机。但是，在典型的用例中并且如将描述的，动态定义策 略，具体地说，在资源所有者首次为特定客户机授予特定同意时。在这种动态方法中，当首 次与资源所有者联系以便授权为第一客户机（请求访问受保护资源）授予同意时，为所有 者提供机会以便指示后续在判定是否可以自动授权其它客户机时是否应使用此特定决策。 如果资源所有者然后指示他或她的决策在未来使用当前同意授予，则基于从资源所有者处 接收的一个或多个输入，并且可选地基于其它客户机分类信息服务或源，自动生成诸如此 类的策略。这些信息服务例如包括根据不同内容类型对URL进行分类的内容分类服务（例 如，IBM X-Force URL分类数据库）、将一个或多个"标签"与特定类或类型的网站（例如， "sports"标签）关联的域标记服务、可被查询以便保证URI真实性的信誉服务、可被查询以 便判定客户机请求是否满足某些隐私或其它安全准则的隐私策略服务、可被查询以便确定 第一客户机和第二客户机之间的任何关系的性质的客户机关系服务等，以及它们的组合。 一旦定义了策略，一个或多个未来客户机（也试图访问受保护资源）然后获得（至少一个 先前同意的）利益，即，通过基于策略在引擎中的应用，潜在获得访问资源所有者的受保护 资源的自动授权。
[0042] 如将描述的，优选地，在创建之后，特定策略（在此有时称为"授权策略"）可以基 于资源所有者的交互式同意习惯或其它因素而动态改变。
[0043] 现在通过实例的方式描述此处的技术。典型的用例如下。具体地说，假设资源所 有者已为第一客户机（例如网站espn.com(体育站点））授权（S卩，提供同意），以便从授权 服务器（例如，第三方社交网络帐户，例如Facebook?)访问一个或多个受保护资源（例 如，所有者的电子邮件地址、姓名、地址等）。在授予授权时（优选地为交互式）并且根据本 公开，为资源所有者提供机会以便例如批准访问"具有类似分类的站点"(例如"所有体育站 点")，或者访问espn. com客户机被确定为属于其一部分的任何其它客户机分类或类别。优 选地，并且如下面更详细描述的，策略引擎和/或授权服务器负责执行客户机分类。随后， 第二客户机（例如站点fifa.com)试图从所有者的社交网络帐户访问资源所有者的受保护 资源（例如，他或她的电子邮件地址）。当客户机将所有者的Web浏览器重定向到授权同意 页面时，授权服务器例如针对客户机"类型"执行分析。基于此分析，自动提供同意，例如因 为第二客户机fifa. com(与espn. com-样）也是体育站点，并且资源所有者先前授权第一 客户机访问所有者的（另外）受保护资源。如可以在该简单实例情景中看到的，客户机被 分类为体育站点，并且解决方案允许资源所有者为例如属于体育站点的客户机提供自动同 意，而不必手动授权所有这些类似的客户机。在该实例中，资源所有者仅需为第一客户机显 式授权，而后续客户机接收自动授权，例如如果它们属于相同的类别并且发出与先前同意 的主题具有相同（或可能更小）范围的请求。
[0044] 使用这种方法，资源所有者对客户机访问受保护资源进行有效和细粒度的控制。 因此，例如这种方法允许资源所有者选择仅允许高度可信并且信誉良好的站点（例如银行 网站客户机）访问受保护资源信息（可能具有高价值）。如上所述，客户机获得访问资源所 有者的受保护资源的自动授权的方式优选地基于授权服务器处的引擎，资源所有者可以在 授权服务器中帮助定义策略。如上所述，基于用户的交互式同意习惯，递增地获知此授权策 略。
[0045] 如图4中所示，存在资源所有者400、试图访问资源服务器406处的受保护资源 404的客户机402、实现诸如OAuth之类的协议的授权服务器408以及策略引擎410。OAuth 的使用仅是描述性的，因为此处的技术与其它类似的协议（例如OpenID) -起工作。在该 实例中，假设授权/资源服务器是社交网络站点。在步骤（1)，客户机402 (例如，espn. com) 想要访问资源所有者的受保护资源（例如，姓名和电子邮件地址）。在步骤（2)，将资源所 有者重定向到社交网络站点并且要求资源所有者授权客户机。在步骤（3)，查询策略引擎 以便判定先前是否提供同意。在该实例中，假设不存在这种同意。在步骤（3)，策略引擎还 例如通过执行重定向URL分析、通过查询上述一个或多个信息源等，执行客户机分类。完成 分类之后，授权服务器判定访问受保护资源的授权是否需要所有者的同意。在该情景中，并 且因为没有为该客户机提供先前同意，在步骤（4)，针对同意而提示客户机。此外，此时资 源所有者可以提供在判定是否可以自动授权其它客户机时可以使用当前同意的指示。在步 骤（5)，授权服务器接收此同意（以及可以使用该同意判定是否可以随后授权其它客户机 的指示）。作为响应，授权服务器向客户机返回令牌（当使用OAuth时）。通常在HTTP重 定向中提供该令牌，然后HTTP重定向将客户机返回到资源服务器并且使能访问所示的受 保护资源。
[0046] 现在参考图5,假设第二客户机502 (例如，fifa. com)需要访问受保护资源。在步 骤（1)，客户机将资源所有者（用户）重定向到社交网络站点。在步骤（2)，社交网络站点 针对客户机的重定向URL执行分析，并且使用已描述的策略引擎检查策略。基于此分析，确 定针对第二客户机的自动授权是适当的，例如因为第二客户机被标识为与第一客户机属于 相同类别，并且请求范围不大于先前授予的同意范围。然后，在步骤（3)，授权服务器向客户 机返回令牌。通常并且如上所述，在HTTP重定向中将令牌返回到客户机。在步骤（4)，将第 二客户机返回到资源服务器，提供令牌，并且然后获得对受保护资源的访问以便完成所述 过程。
[0047] 如图3和图4中的实例情景所示，当实现本公开的策略引擎方法时，不需要咨询资 源所有者以便获得对第二客户机的后续访问请求的显式同意。这提供智能"自动同意"决 策，该决策与现有技术相比提供显著的优势，在现有技术中，每次需要同意时都必然咨询资 源所有者。
[0048] 图6示出本公开的策略引擎的操作的过程流。该过程流总体上对应于图5中的步 骤（2)。例程通常在步骤600开始，此时将导航到客户机站点的资源所有者重定向到授权服 务器以便评估同意问题（即，是否允许客户机站点访问与资源所有者关联的某一受保护资 源）。在步骤602,认证资源所有者。然后在步骤604,执行测试以便判定是否已发出先前 自动同意。如果已发出先前同意，则例程跳转到步骤606以便判定被请求的同意的范围是 否属于其它范围（与先前同意相比）。如果在步骤606的测试结果是肯定的，则在步骤608 例程继续。如果在步骤606的测试结果是否定的，则允许访问而无需更多操作。当在步骤 604的测试为否定判定时，还到达步骤608。在步骤608,通常通过分析重定向URL，执行客 户机分类。然后在步骤610,例程继续判定给出在步骤608确定的类别和请求范围，先前是 否已授予对该类别/范围的同意。如果未授予，则在步骤612,例程继续以提示资源所有者 同意。但是，如果服务器先前已发出对该类别/范围的自动同意，则例程跳转到步骤614以 便处理一个或多个其它策略，例如隐私、信誉等。因此，在步骤616,执行测试以便判定类别 /范围是否在策略内。如果在步骤616的测试结果是否定的，则例程返回到步骤612以便 提示资源所有者同意。如果在步骤616的测试结果指示类别/范围在策略内，则例程将资 源所有者重定向回客户机并且同意，意味着客户机具有访问受保护资源的授权。这是步骤 618,并且该步骤完成所述过程。
[0049] 当需要提示资源所有者同意时，在步骤620,执行测试以便判定资源所有者是否已 发出同意。如果已发出，则在步骤622,例程继续以将客户机添加到"自动同意"列表。根据 需要，此时例程还更新一个或多个类别和/或一个或多个策略以便反映资源所有者新发出 的同意。此更新可以是必需的，因为现在针对什么可以是新客户机类型而授权同意。然后， 例程则继续步骤618,如先前所述。
[0050] 如本领域技术人员应理解的，最佳资源所有者同意决策体验通过路径600、602、 604、608、610、614、616 和 618。
[0051] "受保护资源"的性质和类型可以改变，并且并非作为本公开的限制。通常，资源所 有者的受保护资源包括诸如姓名、地址、电子邮件别名、帐号、人口统计数据之类的数据。
[0052] 策略引擎可以实现为授权服务器的一部分或者实现为其附件。
[0053] 此处的技术并不限于特定类型的客户机（例如网站）。可以以其它方式实现客 户机，例如以设备方式实现，如适当供应的移动电话、平板计算机、电视、智能车辆或其它设 备。
[0054] 如上所述，优选地，策略引擎利用一个或多个客户机分类源或服务以便判定是否 可以继续自动同意。如上所述，在一个实施例中，可以基于重定向URI分类实现客户机分 类。例如可以使用URL分类数据库、通过域标记等对URI进行分类。IBM X-Force提供可被 查询的URL分类数据库。开放DNS域标记可以用于标记站点。在上述实例中，站点espn. com和fifa. com可以被标记为"sports"。在图4中的步骤（3)，适用的策略然后可以声明 所有具有标签"sports"的站点都可以从社交网络站点访问受保护资源（例如，电子邮件地 址和姓名）。因为fifa. com也被标记为"sports"站点，接着执行图5中的步骤（2)(验证 策略），并且允许fifa. com自动访问所有者的电子邮件地址和姓名。但是，如果未被标记为 "sports"的第三站点然后尝试访问这些资源，则必须首先提示所有者授权该站点。
[0055] 还如上所述，另一个信息源或服务可以是信誉服务。可以查询此类服务以便判定 重定向URI是否信誉良好并且满足其它准则（用于特定范围）。众所周知，可以查询信誉 服务引擎以便保证URI的真实性。采取上述实例情景，授权服务器可以将重定向URI视为 URI，并且然后使用该URI验证客户机是否真实。具体地说，使用信誉服务引擎检查重定向 URI，该引擎可以是第三方提供的服务。在上面图3的实例中，假设espn. com具有没有任何 恶意企图的关联URI。在步骤（3)，策略可以声明所有具有没有任何恶意企图的重定向URI 的网站都可以从社交网络站点访问所有者的受保护资源（多个）。然后，如果fifa. com具 有没有恶意企图的重定向URI，则允许该站点访问这些资源，如前所述。
[0056] 另一个信息源可以是隐私策略信息服务。在一种备选方案中，隐私策略可以与授 权服务器本身关联。隐私策略服务的已知技术实现是那些基于P3P、ICRA等的实现。如在 域标记和信誉的实例中，可以实现如下策略：其声明所有共享相同隐私策略的网站都可以 访问所有者的私有数据。在一种实例情景中，可以使用诸如Google'?:网络安全浏览API之 类的服务，判定特定站点（重定向URI)是否足够可信以便允许它访问私有数据。
[0057] 作为另一个信息源，可以获得并检查客户机关系数据，以便确定请求客户机与其 它已被授予访问受保护资源（多个）的客户机的关系。如果策略包括关系数据，则可以检 查该关系数据以便判定然后是否应授予自动同意。
[0058] 特定策略可以实现上述信息源中的一个或多个。
[0059] 概括地说，策略引擎维护如下信息，该信息关联客户机、客户机的分类、先前同意 的范围、任何关系数据以及然后可以用于定义一个或多个策略的其它数据。以所描述的方 式生成、维护、更新和应用策略，以便判定然后是否可以为请求访问受保护资源的新客户机 提供自动同意。
[0060] 尽管在OAuth用例的上下文中通过实例描述了主题技术，但这并非限制。可以以 其它用例实现主题技术，例如在服务提供商处断言用户身份的F-SS0协议。这些F-SS0协 议例如包括OpenID、SAML(Post/构件）或OAuth保护的资源请求。
[0061] 图7示出其中可以实现本公开的异常工作流的策略管理系统。可以跨在例如图1 中所示的计算环境中操作的一个或多个机器实现系统700。通常，所述系统包括策略管理点 (PAP)702、策略决策点（PDP)704和策略实施点（PEP)706。通常，策略管理点702用于定义 同意策略，同意策略可以被指定为一组XACML策略表达式。该策略使用从用户库708提供 的主题属性，以及从策略信息点（PIP) 710接收的运行时和环境数据。策略决策点（PDP) 704 接收类似的信息并且响应从策略实施点（PEP) 706接收的XACML策略查询，以便针对主题 以及针对主题启动的特定操作实施策略。PEP706实现所需的同意工作流。在该方法的一 种商业实现中，PAP702 由 BM Tivoli? Security Policy Manager(TSPM)策略服务或控制 台实现，PDP704在tspm运行时安全服务中实现，并且pep实现为丨BM WebSphere? Application Server 的 TSPM 插件。
[0062] 公开的技术提供多个优点。通过使用这种技术，在每个客户机的授权步骤中，资源 所有者不需要干预。系统是"智能的"，因为它对客户机进行分类，并且基于客户机所属的类 别为客户机提供授权。为了促进该过程，将资源所有者的授权决策提供给引擎，该引擎判定 资源所有者是否需要其它授权。该方法促进供应可靠、可用并且可扩展的受管同意功能/ 服务。
[0063] 上述功能可以实现为独立的方法，例如，由处理器执行的基于软件的功能，或者可 以提供为受管服务（包括为经由S0AP/XML接口的Web服务）。在此描述的特定硬件和软件 实现细节仅为了示例性目的，并非旨在限制所述主题的范围。
[0064] 更一般地说，公开的本发明的上下文中的计算设备均是包括硬件和软件的数据处 理系统（例如图2中所示），并且这些实体通过网络（例如因特网、内联网、外联网、专用 网络）或任何其它通信介质或链路彼此通信。数据处理系统上的应用提供对Web以及其 它已知服务和协议的本机支持，包括但不限于对HTTP、FTP、SMTP、SOAP、XML、WSDL、SAML、 WS-Trust、UDDI和WSFL等的支持。有关SOAP、WSDL、UDDI和WSFL的信息可以从万维网联 盟（W3C)获得，该联盟负责开发和维护这些标准；有关HTTP、FTP、SMTP和XML的进一步信 息可以从因特网工程任务组（IETF)获得。假设熟悉这些已知标准和协议。
[0065] 在此描述的方案可以在基于云的基础架构之外的各种服务器侧体系架构中实现 或者结合这些体系架构实现。这些体系架构包括但不限于简单η层体系架构、Web门户、联 合系统等。
[0066] 如上面的实例所示，一个或多个F-SS0功能可以在云中托管或者在云的外部。 [0067] 更一般地说，在此描述的主题可以采取完全硬件实施例、完全软件实施例或者包 含硬件和软件元素的实施例的形式。在一个优选实施例中，异常检测功能以软件实现，所述 软件包括但不限于固件、驻留软件、微代码等。检测设备检索的数据可以被配置为数据结构 (例如，阵列、链接列表等），并且存储在数据存储库（例如计算机存储器）中。此外，如上所 述，在此描述的增强的F-SS0功能可以采取计算机程序产品的形式，该计算机程序产品可 以从提供程序代码的计算机可用或计算机可读介质访问以便被计算机或任何指令执行系 统使用或者与其结合使用。出于本描述的目的，计算机可用或计算机可读介质可以是任何 能够包含或存储程序的装置，该程序可以被指令执行系统、装置或者设备使用或者与其结 合使用。所述介质可以是电、磁、光、电磁、红外线、或半导体系统（或装置或设备）。计算机 可读介质的实例包括半导体或固态存储器、磁带、可移动计算机盘、随机存取存储器（RAM)、 只读存储器（ROM)、硬磁盘和光盘。光盘的当前实例包括压缩盘-只读存储器（CD-ROM)、压 缩盘 -读/写（⑶-R/W)和DVD。计算机可读介质是有形物品。
[0068] 计算机程序产品可以是具有程序指令（或程序代码）以便实现一个或多个所述功 能的产品。这些指令或代码可以在通过网络从远程数据处理系统下载之后，存储在数据处 理系统中的计算机可读存储介质中。或者，这些指令或代码可以存储在服务器数据处理系 统中的计算机可读存储介质中，并且适合于通过网络下载到远程数据处理以便在远程系统 中的计算机可读存储介质中使用。
[0069] 在一个代表性实施例中，代理和F-SS0组件在专用计算机中实现，优选地在一个 或多个处理器执行的软件中实现。关联的配置（安全级别、状态、计时器）存储在关联的数 据存储库中。还在与一个或多个处理器关联的一个或多个数据存储库或存储器中维护软 件，并且所述软件可以实现为一个或多个计算机程序。
[0070] 如上所述，策略引擎功能可以实现为现有访问管理器或策略管理解决方案的附件 或扩展。
[0071] 尽管上面描述了本发明的某些实施例执行的操作的特定顺序，但应理解，这种顺 序是示例性的，因为备选实施例可以以不同顺序执行操作，组合某些操作，重叠某些操作 等。说明书中对给定实施例的引用指示所描述的实施例可以包括特定特性、结构或特征，但 每个实施例可能不一定包括该特定特性、结构或特征。
[0072] 最后，尽管单独描述了系统的给定组件，但本领域技术人员应理解，可以在给定指 令、程序序列、代码部分等中组合或共享某些功能。
[0073] 如在此使用的，"客户机侧"应用应被广泛解释为指应用、与该应用关联的页面，或 者向应用发出的客户机侧请求所调用的某种其它资源或功能。"浏览器"如在此使用的，并 非旨在指任何特定浏览器（例如，Internet Explorer、Safari、FireFox等），而是应被广 泛解释为指任何可以访问和显示因特网可访问资源的客户机侧呈现引擎。"富"客户机通常 指基于非HTTP的客户机侧应用，例如SSH或CFIS客户机。此外，尽管通常使用HTTP进行 客户机-服务器交互，但这并非限制。可以设置客户机服务器交互的格式以便遵守简单对 象访问协议（SOAP)并且通过HTTP(通过公共因特网）、FTP传送，或者可以使用任何其它可 靠的传输机制（例如IBM MQSeries?技术和C0RBA，以便通过企业内联网传输）。通过提 供到另一个应用的钩子，通过促进使用机制作为插件，通过链接到机制等，可以将在此描述 的任何应用或功能实现本机代码。
[0074] 描述了我们的发明之后，现在要求保护的内容如下所示。
【权利要求】
1. 一种管理对访问受保护资源授予同意的方法，所述受保护资源与资源所有者关联， 所述方法包括： 在接收到访问受保护资源的请求时，所述请求具有范围并与客户机关联，执行分析以 标识所述客户机的特征，使用具有硬件元件的计算实体执行所述分析； 基于所述客户机的所述特征和所述请求的所述范围，应用策略以判定所述客户机是否 应接收访问所述受保护资源的自动同意；以及 如果基于所述策略，所述客户机应接收自动同意，则返回给定信息，所述客户机可以使 用所述给定信息来获得对所述受保护资源的访问而无需来自所述资源所有者的显式同意。
2. 根据权利要求1的方法，其中所述分析基于与所述请求关联的统一资源标识符URI。
3. 根据权利要求1的方法，其中所述客户机的所述特征是以下之一：客户机类别、域标 签、所述请求源自信誉良好的源的指示，以及所述客户机具有给定隐私策略的指示。
4. 根据权利要求1的方法，其中如果所述客户机不应接收访问所述受保护资源的所述 自动同意，则向所述资源所有者发出提示以便获得显式同意。
5. 根据权利要求4的方法，还包括： 获得对所述提示的响应； 在接收到对所述提示的响应时，更新所述策略以包括与所述客户机关联的类别。
6. 根据权利要求5的方法，还包括更新同意列表以包括所述客户机。
7. 根据权利要求1的方法，其中所述给定信息是OAuth令牌。
8. -种装置，包括： 处理器； 计算机存储器，其保存计算机程序指令，当由所述处理器执行时，所述计算机程序指令 执行一种管理对访问受保护资源授予同意的方法，所述受保护资源与资源所有者关联，所 述方法包括： 在接收到访问受保护资源的请求时，所述请求具有范围并与客户机关联，执行分析以 标识所述客户机的特征； 基于所述客户机的所述特征和所述请求的所述范围，应用策略以判定所述客户机是否 应接收访问所述受保护资源的自动同意；以及 如果基于所述策略，所述客户机应接收自动同意，则返回给定信息，所述客户机可以使 用所述给定信息来获得对所述受保护资源的访问而无需来自所述资源所有者的显式同意。
9. 根据权利要求8的装置，其中所述分析基于与所述请求关联的统一资源标识符URI。
10. 根据权利要求8的装置，其中所述客户机的所述特征是以下之一：客户机类别、域 标签、所述请求源自信誉良好的源的指示，以及所述客户机具有给定隐私策略的指示。
11. 根据权利要求8的装置，其中所述方法还包括：如果所述客户机不应接收访问所述 受保护资源的所述自动同意，则向所述资源所有者发出提示以便获得显式同意。
12. 根据权利要求11的装置，其中所述方法还包括： 获得对所述提示的响应； 在接收到对所述提示的响应时，更新所述策略以包括与所述客户机关联的类别。
13. 根据权利要求12的装置，其中所述方法还包括更新同意列表以包括所述客户机。
14. 根据权利要求8的装置，其中所述给定信息是OAuth令牌。
【文档编号】H04L29/06GK104144158SQ201410185123
【公开日】2014年11月12日 申请日期:2014年5月5日 优先权日:2013年5月8日
【发明者】S·G·加宁, S·B·魏登, C·S·普拉纳姆 申请人:国际商业机器公司