专利名称：联合环境中启用数字权限管理的策略管理的方法和系统的制作方法
技术领域：
本发明一般涉及在联合环境中对用户会话的管理。
背景技术：
联合环境是本领域内已知的。2004年7月21日提交的美国出版物No. 2006/0021018具有代表性。联盟(federation)是不同实体的集合，所述实体诸如企业、组织、协会等，其进行协作以便向用户提供单次登录、易于使用的体验；联合环境与典型的单次登录环境的不同之处在于，两家企业不需要具有直接的、预先建立的关系，所述关系定义了如何传送以及传送哪些关于用户的信息。在联合环境内，实体提供处理下述情况的服务认证用户、接受由其它实体呈现的认证断言(assertion)(例如认证令牌)、以及提供某种形式的翻译，所述翻译把为用户担保的身份翻译为在本地实体内可以理解的一种身份。联盟减轻了服务提供者的管理负担。服务提供者可以依赖于其与作为整体的联盟的信任关系；服务提供者不需要管理认证信息，诸如用户口令信息，因为其可以依赖于由用户的认证主域或身份提供者所完成的认证。 联合实体可以作为用户的主域，其提供关于联合用户的身份信息和属性信息。提供身份信息、身份或认证断言、或身份服务的联合计算环境内的实体被称为身份提供者。相同联盟内的其它实体或联盟伙伴可以依赖于对用户认证凭证进行首次管理的身份提供者，例如，接受由用户的身份提供者提供的单次登录令牌(token);用户进行认证所在的域可以被称为用户的(认证)主域。身份提供者是一种特定类型的提供身份信息的服务，作为对联合计算环境内的其它实体的服务。针对大多数联合事务，对认证断言的发布方通常将是身份提供者；任意其它实体可以与身份提供者区分开。在联合计算环境内提供服务的任意其它实体可以被分类为服务提供者。 一旦用户已认证为身份提供者，则在给定联合会话或给定联合事务的持续期间，联盟内的其它实体或企业就可以仅被看作是服务提供者。
数字权限管理(DRM)是一种用于保护数字内容的公知技术。DRM通过在分发之前加密内容以及通过将访问仅限于已获得播放所述内容的正确许可的那些终端用户来工作。典型地，在播放器/客户机完成对DRM许可的强制执行。完整的DRM系统典型地包括若干部分加密、商业逻辑、以及许可传送。DRM开始于加密内容。 一旦内容被加密，就需要密钥来解锁(解密)该内容。已加密的内容可以通过公知的传送方法被传送到终端用户。典型地，想要获得内容的终端用户访问电子商务网站，并且与商业逻辑过程进行交易，所述商业逻辑过程通常涉及注册、登录、和/或支付中的一种；一旦完成所述交易，则向终端用户发布播放该内容的许可。被发布的许可典型地包括(i)密钥(用于解密该内容)，(ii)权限(例如，恰好播放一次、在30天内播放等等)的组合，以及(iii)具有所述许可仅在其被发布的终端用户机器上有效的性质。当终端用户试图播放经DRM保护的内容时，播放器首先检查在本地机器上是否存在许可；如果存在，则回放开始于解密该内容。如果未找到许可，则播放器试图典型地从嵌入在内容中的店面URL获得一个许可。
发明内容
—种可在身份提供者处操作的方法实施与一部分内容相关联的数字权限管理 (DRM)方案。服务提供者典型地是内容提供者。身份提供者是参与到"联盟"中的实体，所 述联盟具有一个多个其它实体，例如包括服务提供者(诸如内容提供者)、DRM特权提供 者、以及DRM策略提供者。在一个实施例中，所述方法开始于使身份提供者获得并针对DRM 策略评估与请求访问所述一部分内容的终端用户相关联的DRM特权集合。基于所述评估， 身份提供者生成单次登录(SSO)消息，所述消息包括对DRM特权集合的引用。接着所述消 息被转发给服务提供者实体，其向终端用户提供响应。 所述身份提供者、服务提供者、DRM特权提供者、以及DRM策略提供者的功能便利 于启用DRM策略的联盟。DRM特权提供者和DRM策略提供者的一个或多个功能可以与身份 提供者和/或服务提供者相集成。 前述内容已经概述了本发明的某些更恰当的特征。这些特征应被理解为仅是说明 性的。通过以不同方式应用所公开的发明，或者通过修改将描述的发明，可以得到许多其它 有利结果。
为了更完整地理解本发明及其优点，现在结合附图参考以下描述，在附图中
图IA描述了数据处理系统的典型网络，每个数据处理系统都可以实现此处所述 的主题； 图IB描述了可在其中可实现所公开的主题的数据处理系统中使用的典型计算机 体系结构； 图2描述了示出联合环境的术语的框图； 图3描述了示出在给定域的已存在的数据处理系统与可被用于支持所述主题的 实施例的某些联合体系结构组件的集成的框图； 图4描述了示出其中联合体系结构内的某些组件可被用于建立信任关系以支持 所述主题的实现的方式示例的框图； 图5描述了示出根据能够支持所述主题的示例性的联合体系结构，在使用信任代 理和信任调度程序的联合域之间的示例性信任关系集合的框图；
图6描述了示出支持联合单次登录操作的联合环境的框图；
图7A示出用于实现联合用户生命周期管理功能的现有技术； 图7B示出用于实现联合用户生命周期管理功能、同时实现用于这种功能的基于 策略的机制的另一种已知技术； 图7C示出用于某些数据单元的附加细节，所述数据单元由图7B的策略过滤器和 引擎相关于FULM消息相关联地被处理； 图8是根据此处主题在启用DRM策略的联盟内的参与实体的框图；
图9示出在启用DRM策略的联盟内的第一示例场景；
图10示出在启用DRM策略的联盟内的第二示例场景；
图11示出在启用DRM策略的联盟内的第三示例场景； 图12示出一框图，所述框图示出以下场景，其中第一数据处理系统从身份提供者内的第二数据处理系统检索断言，所述身份提供者使用支持分布式断言检索的分布式数据 处理系统实现；以及 图13示出另一示例性的数字权限管理场景。
具体实施例方式
现在参考附图，图1A描述了数据处理系统的典型网络，每个数据处理系统都可以 实现此处所述的主题。分布式数据处理系统100包含网络101，网络101是可被用于提供在 分布式数据处理系统100内连接在一起的多种设备和计算机之间的通信链路的一种介质。 网络101可以包括诸如线缆或光缆的永久性连接，或者通过电话或无线通信完成的临时 性连接。在所述示例中，服务器102和服务器103连同存储单元104连接于网络101。此 外，客户机105-107也连接于网络101。客户机105-107和服务器102-103可以由多种计算 设备表示，诸如大型机、个人计算机、个人数字助理(PDA)等等。分布式数据处理系统IOO 可以包括未示出的附加的服务器、客户机、路由器、其它设备、以及对等体系结构。
在所述示例中，分布式数据处理系统IOO可以包括具有网络101的因特网，其表 示世界范围内的、使用多种协议彼此进行通信的网关与网络的集合，所述多种协议诸如 LDAP(轻量目录访问协议)、TCP/IP(传输控制协议/因特网协议)、HTTP(超文本传输协 议)等。当然，分布式数据处理系统100还可以包括多种不同类型的网络，例如内联网、局 域网(LAN)、或广域网(WAN)。例如，服务器102直接支持包含无线通信链路的网络IIO和 客户机109。网络支持(network-enabled)的电话111通过无线链路112连接到网络110， 并且PDA 113通过无线链路114连接到网络110。电话111和PDA 113还可以使用适当的 技术(例如Bluetooth 无线技术)通过无线链路115在它们之间直接传送数据，以创建所 谓的个人区域网络或个人特定(ad-hoc)网络。以类似的方式，PDA 113可以经由无线通信 链路116传送数据到PDA 107。 此处的主题可以在多种硬件平台和软件环境上实现。图1A意在作为异构计算环 境的示例，而不是对本发明的体系结构限制。 现在参考图1B，该图描述了数据处理系统(诸如图1A所示的那些数据处理系统) 的典型计算机体系结构。数据处理系统120包含连接到内部系统总线123的一个或多个 中央处理单元(CPU)122，所述内部系统总线123与随机存取存储器(RAM)124、只读存储器 126、和输入/输出适配器128互连，所述输入/输出适配器128支持多种I/O设备，诸如打 印机130、盘单元132或其它未示出的设备，诸如音频输出系统等。系统总线123还连接提 供对通信链路136的访问的通信适配器134。用户接口适配器148连接多种用户设备，诸 如键盘140和鼠标142或其它未示出的设备，诸如触摸屏、记录笔、麦克风等。显示适配器 144将系统总线123与显示器设备146相连接。 本领域普通技术人员将认识到，图1B中的硬件可取决于系统实现方式而变化。例
如，所述系统可以具有一个或多个处理器(诸如基于11^61@卩611钍11111@的处理器和数字信
号处理器(DSP))以及一种或多种类型的易失性和非易失性存储器。除了图1B中描述的硬 件之外或作为这些硬件的替代，可以使用其它外围设备。所描述的示例并不意味着暗示对 本发明的体系结构限制。 除了能够在多种硬件平台上实现本发明外，本发明还可以在多种软件环境中实现。典型的操作系统可以被用来控制每个数据处理系统内的程序执行。例如，一个设备可
以运行1111"@操作系统，而另一设备包含简单的,13\^@运行时环境。代表性的计算机平 台可以包括浏览器，浏览器是公知的用于访问多种格式的超文本文档的软件应用，所述多 种格式的超文本文档诸如图形文件、字处理文件、可扩展标记语言(XML)、超文本标记语言 (HTML)、手持设备标记语言(HDML)、无线标记语言(丽L)和多种其它格式和类型的文件。还 应该注意，图1A所示的分布式数据处理系统被预期为完全能够支持多种对等子网和对等 服务。 在给出对某些当前技术的前述简要描述后，对其余附图的描述涉及其中本发明可
以起作用的联合计算环境。不过，在更详细地讨论本发明之前，要引入某种术语。 如此处所使用的，术语"实体"或"方"通常指代组织、个人、或代表组织、个人进行
操作的系统、或者另一系统。术语"域"意味着网络环境内的附加特性，不过术语"实体"、
"方"和"域"可以互换地使用。例如，术语"域"也可以指代DNS(域名系统)域，或者更一
般地指代包括多种设备和应用的数据处理系统，所述多种设备和应用针对外部实体显现为
逻辑单元。 术语"请求"和"响应"应被理解为包括数据格式化操作，其适用于在特定操作中涉 及的信息的传输，诸如消息、通信协议信息、或其它关联信息。受保护资源是一种资源(应 用、对象、文档、页面、文件、可执行代码、或其它计算资源、通信类型的资源等等)，对其的访 问是被控制或被限制的。 令牌提供了成功操作的直接证据，并由执行该操作的实体产生，例如，在成 功的认证操作之后生成的认证令牌。Kerberos令牌是可用于本发明的认证令牌的 一个示例。关于Kerberos的更多信息可以在Kohl等人的"TheKerberos Network Authentication Service (V5) ，， (Internet EngineeringTask Force (IETF) Request for Comments (RFC) 1510,09/993)中找到。 断言提供某种动作的间接证据。断言可以提供身份、认证、属性、授权决定、或其它 信息和/或操作的间接证据。认证断言提供由一实体进行认证的间接证据，所述实体不是 认证服务，但其得到认证服务的许可。 安全断言标记语言(SAML)断言是可用于本发明的可能断言格式的示例。SAML已 经被结构化信息标准促进组织(OASIS)所发布，所述OASIS是一个非赢利性、全球化的协 会。SAML在"Assertions and Protocolfor the OASIS Security Assertion Markup Lan guage(SAML) " (CommitteeSpecification 01,05/31/2002)中进行了如下描述
安全断言标记语言(SAML)是一种基于XML的、用于交换安全信息的框架。该安全 信息由与主体有关的断言的格式所表达，其中主体是在某个安全域中具有身份的实体(人 或计算机)。主体的典型示例是在特定因特网DNS域中由他或她的电子邮件地址所标识的 个人。断言可以传达与由主体执行的认证动作、主体属性、以及关于主体是否被允许访问某 些资源的授权决定有关的信息。断言被表示为XML构造，并具有嵌套结构，从而单个断言可 以包含与认证、授权和属性有关的若干个不同的内部语句。注意，包含认证语句的断言仅描 述了之前发生的认证的动作。断言由SAML授权机构所发布，SAML授权机构即认证授权机 构、属性授权机构和策略决定点。SAML定义了 一种协议，通过所述协议，客户机可以从SAML 授权机构请求断言，并从其获得响应。包括基于XML的请求和响应消息格式的此协议可以绑定到许多不同的底层通信和传输协议；SAML当前定义了通过HTTP与SOAP的一种绑定。 在创建其响应时，SAML授权机构可以使用多种信息源，诸如外部策略存储库和作为请求中 的输入被接收的断言。由此，尽管客户机通常使用断言，但SAML授权机构也可以同时是断 言的制造者以及使用者。 SAML规范规定了 ，断言是提供由发布者完成的一个或多个语句的信息包。SAML允 许发布者完成三种不同种类的断言语句认证，其中指定主体在特定时间被特定装置进行 认证；授权，其中允许指定主体访问指定资源的请求已经被同意或拒绝；以及属性，其中指 定主体与所提供的属性相关联。如下文进一步讨论的，当需要时，多种断言格式可以被翻译 为其它断言格式。 认证是证实由一个用户或代表一个用户提供的一组凭证的过程。认证的完成是通 过验证用户所知道的东西、用户所具有的东西、或用户就是的东西，即，与用户有关的某种 物理特性。用户所知道的东西可以包括共享秘密，诸如用户口令，或者通过验证仅对特定用 户已知的东西，诸如用户的密钥。用户所具有的东西可以包括智能卡或硬件令牌。与用户 有关的某种物理特性可以包括生物测定输入，诸如指纹或视网膜地形图。应该理解，用户典 型地是、但并非一定是自然人；用户可以是机器、计算设备、或使用计算资源的其它类型的 数据处理系统。还应该理解，用户典型地、但并非一定处理单个唯一的标识符；在某些情景 中，多个唯一的标识符可以与单个用户相关联。 认证凭证是用于多种认证协议的一组质询/响应信息。例如，用户名和口令的组
合是认证凭证的最常见形式。其它形式的认证凭证可以包括多种形式的质询/响应信息、
公钥基础设施(PKI)证书、智能卡、生物测定等等。认证凭证区别于认证断言在于认证凭
证由用户呈现，作为与认证服务器或服务的认证协议序列的一部分；而认证断言是与对用
户的认证凭证的成功呈现与证实有关的语句，其随后当需要时在实体之间传送。 在万维网的上下文中，用户越来越期待以下能力，S卩，从与一个因特网域上的应用
进行交互跳跃到另一域上的另一应用，同时对于每个特定域之间的信息障碍的关注度最
低。用户不想要由于为了单个事务不得不对多个域认证所导致的挫折感。换句话说，用户
期望各个组织应该交互操作，但是用户通常想要各个域尊重他们的隐私。此外，用户可能更
希望限制这些域永久性地存储隐私信息。这些用户期望存在于快速发展的异构环境中，在
所述环境中，许多企业和组织正在发布有竞争力的认证技术。 此处的主题在联合模型中得到支持，所述联合模型允许企业向用户提供单次登录 体验。换句话说，本发明可以在联合异构环境内实现。作为将从联合异构环境中获益的事 务的一个示例，用户能够认证到一个域，并接着让该域向可能在事务中涉及的每个下游域 提供适当的断言。这些下游域需要能够理解并信任认证断言和/或其它类型的断言，即使 在该域和这些其它下游域之间不存在预先建立的断言格式。除了认出断言之外，下游域还 需要能够将断言中包含的身份翻译成表示特定域内的用户的身份，即使不存在预先建立的 身份映射关系。 此处的主题在联合模型中得到支持。 一般而言，一家企业具有其自己的用户注册 表，并维护与其自身的用户集合的关系。每个企业典型地具有其自身的用于认证这些用户 的手段。不过，用于本发明的联合方案允许企业以集体方式进行协作，从而在一家企业中的 用户可以通过企业参与到企业联盟中而促进与企业集合的关系。用户可以被同意对位于任
9一所述企业的资源进行访问，就好像他们具有与每家企业的直接关系一样。用户不需要在
每个感兴趣企业进行注册，并且用户不会总是被要求标识和认证他们自身。因此，在该联合
环境内，认证方案允许在信息技术方面快速发展的异构环境内的单次登录体验。 在本发明的上下文中，联盟是不同实体的集合，所述实体诸如企业、企业内的逻辑
单元、组织、协会等，其进行协作以便向用户提供单次登录、易于使用的体验；联合环境与典
型的单次登录环境的不同之处在于，两家企业不需要具有直接的、预先建立的关系，所述关
系定义了如何传送以及传送哪些关于用户的信息。在联合环境内，实体提供处理下述情况
的服务认证用户、接受由其它实体呈现的认证断言(例如认证令牌)、以及提供某种形式
的翻译，所述翻译把为用户担保的身份翻译为在本地实体内可以理解的一种身份。 联盟减轻了服务提供者的管理负担。服务提供者可以依赖于其与作为整体的联盟
的信任关系；服务提供者不需要管理认证信息，诸如用户口令信息，因为其可以依赖于由用
户的认证主域或身份提供者所完成的认证。 支持本发明的系统还涉及联合身份管理系统，其建立了一种基础，其中松散耦合 的认证、用户登记、用户简档管理和/或授权服务跨安全域进行合作。联合身份管理允许驻 留于完全不同的安全域中的服务安全地交互操作和合作，即使位于这些完全不同的域的底 层安全机制和操作系统平台存在不同之处。 如上所述并且如下文更详细地进一步解释的，联合环境提供了显著的用户利益。 联合环境允许用户在第一实体进行认证，所述第一实体可以作为发布方，用于发布与用户 有关的认证断言以在第二实体处使用。用户接着可以通过呈现由第一实体发布的认证断言 来访问位于不同的第二实体(被称为依赖方)的受保护资源，而不必非要在第二实体处进 行明确认证。从发布方传递到依赖方的信息采用断言的形式，并且此断言可以包含语句形 式的、不同类型的信息。例如，断言可以是与被认证的用户身份有关的语句，或者其可以是 与关联于特定用户的用户属性信息有关的语句。此外，基于依赖方的访问控制规则、身份映 射规则、以及可能由依赖方维护的某些用户属性，此信息可以被依赖方用于提供对依赖方 的资源的访问。 现在参考图2，该框图描述了联合环境的术语，所述联合环境与由用户向第一联
合企业发起的事务有关，所述第一联合企业作为响应调用位于联合环境内的下游实体的动
作。图2示出了 取决于联盟内的实体针对给定联合操作的前景，术语可以不同。更具体地，
图2示出了支持本发明的计算环境支持信任的传递性以及认证断言过程的传递性；一个域
或实体可以基于其对于由另一域或另一实体断言的身份的信任，而发布断言。 用户202通过对于位于企业204的受保护资源的请求发起事务。如果用户202已
经被企业204认证，或者在事务过程期间最终将被企业204认证，则企业204可以针对该联
合会话被称为用户的主域。假定该事务需要由企业206进行的某种类型的操作，并且企业
204将断言传送到企业206，则企业204是与特定操作有关的发布实体，而企业206是针对
该操作的依赖实体。 发布实体发布由依赖域使用的断言；发布实体通常是、但并非一定是用户的主域 或用户的身份提供者。因此，经常会是这样的情形发布方已使用典型的认证操作认证了用 户。不过，以下是可能的发布方之前作为依赖方，从而它从不同的发布方接收了断言。换 句话说，由于用户发起的事务可以通过联合环境内的一系列企业分多级进行，因此一个接收方可以随后作为下游事务的发布方。 一般而言，具有代表用户发布认证断言的能力的任 意实体都可以作为发布方。 依赖实体是从发布实体接收断言的实体。依赖方能够接受、信任以及理解由第三 方，即发布实体，代表用户发布的断言；使用适当的认证授权机构来解释认证断言通常是依 赖实体的责任。依赖方是依赖于代表用户或另一实体呈现的断言的实体。以此方式，取代 于需要依赖实体提示用户提供用户的认证凭证以作为与用户的交互会话的一部分，可以在 依赖实体处向用户给出单次登录的体验。 再次参考图2，假定事务需要进一步的操作从而企业206将断言传送到企业208，
则企业206是作为与随后的或次级的事务操作有关的发布实体的上游实体，而企业208是
作为该操作的依赖实体的下游实体；在此情形中，企业208可以被看成是与初始事务有关
的另一个下游实体，但是随后的交易也可以被描述成仅与两个实体有关。 如图2所示，联合实体可以作为用户的主域，其提供与联合用户有关的身份信息
和属性信息。联合计算环境内提供身份信息、身份或认证断言、或身份服务的实体可以被称
为实体提供者。同一联盟内的其它实体或联盟伙伴可以依赖于身份提供者对于用户的认证
凭证的最初管理，例如，接受由用户的身份提供者提供的单次登录令牌；用户进行认证所在
的域可以被称为用户的(认证)主域。身份提供者可以由用户的雇主、用户的ISP、或某个
其它的商业实体来支持。 身份提供者是一种特定类型的提供身份信息的服务，作为对联合计算环境内的其 它实体的服务。针对大多数联合事务，对认证断言的发布方通常将是身份提供者；任意其它 实体可以与身份提供者区分开。在联合计算环境内提供服务的任意其它实体可以被分类为 服务提供者。 一旦用户已认证到身份提供者，则在给定联合会话或给定联合事务的持续期 间，联盟内的其它实体或企业就可以仅被看作是服务提供者。 在某些情形中，在联合环境内可以存在可作为用户的身份提供者的多个实体。例 如，用户可以在多个联合域处具有账号，每个联合域都能够作为用户的身份提供者；这些域 不必非要具有与其它域有关以及与用户在不同域处的身份有关的信息。 尽管以下是可能的在联合环境内可以存在可作为身份提供者的多个企业，例如 这是因为可以存在具有生成及证实用户的认证凭证等的能力的多个企业，但是联合事务通 常仅涉及单个身份提供者。如果在联盟内存在有且仅有一个实体，用户与该实体已执行了 联合登记或注册操作，则会期望该实体将作为用户的身份提供者，以便支持用户在整个联 合环境中的事务。 在需要多个服务提供者的交互操作的某些联合事务中，下游服务提供者可以接受 来自上游服务提供者的断言；以下状况可以取决于服务提供者之间的信任关系以及服务提 供者之间的事务的类型，在所述状况中，上游服务提供者可以作为与作为依赖方的下游服 务提供者有关的发布实体。不过，在简单的联合事务的范围内，仅有一个作为发布实体的实 体。 本发明可以在给定的计算环境中得到支持，在所述计算环境中，联合基础设施可 以被添加到现有的系统中，同时使得对现有的非联合体系结构的影响最小化。因此，在任意 给定企业或服务提供者处包括认证操作在内的操作不是必然被以下事实所改变，所述事实 为，一个实体也可以参与到联合环境中。换句话说，即使一个实体的计算系统可以被集成到联合环境中，用户也可能能够继续以非联合方式直接与企业执行包括认证操作在内的各种 操作。不过，用户可能能够在执行与给定实体有关的联合操作的同时，具有相同的终端用户 体验，就如同用户已经以非联合方式与给定实体执行了类似操作。因此，应该注意，当给定 企业参与到联盟中时，并非给定企业的所有用户必然地参与联合事务；企业的某些用户可 以在不执行任意联合事务的情况下与企业的计算系统进行交互。 此外，给定企业的计算环境内的用户注册(例如在计算机系统中建立用户帐户) 不是必然被以下事实所改变，所述事实为，企业也可以参与到联合环境中。例如，用户仍可 以通过独立于联合环境的、传统的或已存在的注册过程而在一个域建立帐户。因此，在某些 情形中，当企业参与到联合计算环境中时，在企业建立用户帐户可以或可以不包括建立跨 联盟有效的帐户信息。 现在参考图3，框图描述了在给定域的已存在的数据处理系统与可被用于支持本 发明实施例的某些联合体系结构组件的集成。联合环境包括为用户提供多种服务的联合实 体。用户312与客户机设备314进行交互，客户机设备314可以支持浏览器应用316和多种 其它的客户机应用318。用户312与客户机设备314、浏览器316、或作为用户与其它设备和 服务之间的接口的任意其它软件截然不同。在某些情形中，以下描述可以做出在客户机应 用中进行明确动作的用户与代表用户进行动作的客户机应用之间的区分。不过，一般而言， 请求者是可以被假定是代表用户进行动作的居中者，诸如基于客户机的应用、浏览器、SOAP 客户机等。 浏览器应用316可以是，包括在移动设备上找到的那些浏览器在内的典型浏览 器，其包括许多模块，诸如HTTP通信组件320和标记语言(ML)解释器322。浏览器应用316 还可以支持插件，诸如web服务客户机324和/或可下载的小应用程序，它们可以或可以不 需要虚拟机运行时环境。Web服务客户机324可以使用简单对象访问协议(S0AP)，其是一 种用于定义在非集中化的分布式环境中对结构化和类型化的信息进行交换的轻量级协议。 SOAP是一种基于XML的协议，其包括三部分包封，定义了用于描述消息中有什么以及如何 处理该消息的框架；编码规则集合，用于表达应用定义的数据类型的实例；以及约定，用于 表示远程过程调用和响应。用户312可以使用浏览器应用316访问基于web的服务，但是 用户312还可以通过客户机设备314上的其它web服务客户机访问web服务。某些联合操 作可以经由用户浏览器使用HTTP重定向在联合环境中的实体之间交换信息。不过，应该 注意，本发明可以在多种通信协议上得到支持，并且不意味着被限于基于HTTP的通信。例 如，联合环境中的实体当必要时可以直接进行通信；消息不需要通过用户的浏览器进行重 定向。 此处的主题可以通过以下方式得到支持，所述方式使得联合环境所需的组件可以 与已存在的系统进行集成。图3描述了用于将这些组件实现为已存在系统的前端的一个实 施例。位于联合域的已存在组件可以被认为是传统应用或后端处理组件330，其包括类似 于图4所示方式的认证服务运行时(ASR)服务器332。当域控制对应用服务器334的访问 时，ASR服务器332负责认证用户，所述应用服务器334可以被认为是用于生成、检索、或以 另外方式支持或处理受保护资源335。域可以继续使用传统的用户注册应用336来注册用 户，用以访问应用服务器334。与传统操作有关地认证已注册用户所需的信息被存储在企业 用户注册表338中；企业用户注册表338也可以是联盟组件可访问的。
在加入联合环境之后，域可以继续在无需联合组件的干涉的情况下进行操作。换 句话说，域可以被这样配置，使得用户可以继续直接访问特定应用服务器或其它受保护资 源，而无需通过接触点服务器或实现该接触点服务器的功能的其它组件；以此方式访问系 统的用户将体验到典型的认证流程和典型的访问。不过，在这样做时，直接访问传统系统的 用户将不能建立对于域的接触点服务器已知的联合会话。 域的传统功能可以通过使用联盟前端处理340被集成到联合环境中，联盟前端处 理340包括接触点服务器342和信任代理服务器344 (或更简单地，信任代理344或信任服 务344)，所述信任代理服务器344自身与安全令牌服务(STS)346进行交互，所述安全令牌 服务346在下文中参考图4更详细描述。联盟配置应用348允许管理用户配置联盟前端组 件，以允许它们通过联盟接口单元350与传统的后端组件通过接口连接。联合功能可以在 截然不同的系统组件或模块中实现。在优选实施例中，用于执行联盟操作的大多数功能可 以由单个联盟应用内的逻辑组件的集合来实现；联合用户生命周期管理应用352包括信任 服务以及单次登录协议服务(SPS)354。信任服务344可以包括身份及属性服务(IAS)356， 其负责作为联盟功能一部分的身份映射操作，属性检索等。身份及属性服务356还可以在 单次登录操作期间由单次登录协议服务354使用。联盟用户注册表358可以在某些情形中 出于对联盟特定的目的被用于维护与用户有关的信息。 在给定企业的传统的或已存在的认证服务可以使用多种公知的认证方法或令牌， 诸如基于用户名/ 口令或智能卡令牌的信息。不过，在用于支持本发明的优选的联合计算 系统中，传统的认证服务的功能可以通过使用接触点服务器被用在联合环境中。用户可以 继续直接访问传统认证服务器，而无需通过接触点服务器，但是以此方式访问系统的用户 将体验典型的认证流程和典型的访问；根据本发明，直接访问传统认证系统的用户将不能 生成作为身份的证明的联合认证断言。联盟前端的角色之一是将在接触点服务器接收的联 合认证令牌翻译为传统的认证服务理解的格式。因此，经由接触点服务器访问联合环境的 用户将不再必须需要重新认证到传统的认证服务。优选地，用户将通过接触点服务器与信 任代理的组合被认证到传统的认证服务，从而其表现为就如同用户已加入到认证对话中。
现在参考图4，该框图描述了其中联合体系结构内的某些组件可被用于建立信任 关系的方式的示例。联合环境包括为用户提供多种服务的联合企业或类似实体。通过客户 机设备上的应用，用户可以试图访问位于多种实体(诸如企业410)的资源。位于每个联合 企业的接触点服务器(诸如位于企业410的接触点(POC)服务器412)是针对来自客户机 的用于访问资源的请求的、进入联合环境的入口点，所述资源由企业410支持并使其可用。 由于接触点服务器处理许多联盟需求，所以接触点服务器使现有的非联合体系结构(例如 传统的系统)内的现有组件上的影响最小化。接触点服务器提供会话管理、协议转换、以及 可能地发起认证和/或属性断言转换。例如，接触点服务器可以将HTTP或HTTPS消息翻译 成SOAP，反之亦然。如下文进一步更详细解释的，接触点服务器还可以被用于调用信任代理 来翻译断言，例如，从发布方接受的SAML令牌可被翻译为接收方理解的Kerberos令牌。
信任服务(也被称为信任代理、信任代理服务器、或信任服务)诸如位于企业410 的信任代理(TP)414，其建立和维护联盟中的两个实体之间的信任关系。信任服务通常具有 处理从发布方使用的格式到接收方理解的格式的认证令牌格式翻译(通过安全令牌服务， 其在下文进一步更详细描述)的能力。
总体地，使用接触点服务器和信任服务使得在现有的非联合系统集合上实现联合
体系结构的影响最小化。因此，示例性的联合体系结构需要为每个联合实体实现至少一个
接触点服务器以及至少一个信任服务，而不论该实体使企业、域、还是其它逻辑或物理实
体。但是，示例性的联合体系结构不是必须需要对现有的非联合系统集合进行任意改变。优
选地，针对给定联合实体存在单个信任服务，但是出于可用性目的可以存在信任服务组件
的多个实例，或者针对联合实体内的多个较小实体(例如，企业内的独立子公司)可以存在
多个信任服务。以下是可能的给定实体可以属于不止一个联盟，但是此情形将不会必然地
需要多个信任服务，因为单个信任服务可以能够管理多个联盟内的信任关系。
信任服务的一个角色可以是确定或负责确定另一域和/或该域中的信任服务所
需的令牌类型。信任服务具有处理从发布方使用的格式到接收方理解的格式的认证令牌格
式翻译的能力或责任。信任服务414还可以负责企业410发生的任意用户身份翻译或属性
翻译，或者此责任可以由不同的身份及属性服务(例如，如图3所示的身份及属性服务356)
所支持。此外，信任服务可以支持别名的实现，所述别名作为用户身份的代表，其在无需提
供与用户的真实世界身份有关的任意附加信息的情形下，唯一地标识用户。此外，信任服务
可以发布授权和/或会话凭证，以由接触点服务器使用。不过，信任服务可以调用信任调度
程序(broker)进行协助，如下文进一步描述的。可以需要身份翻译将对于发布方已知的用
户身份和属性映射到对于接收方有意义的用户身份和属性。此翻译可以由位于发布实体的
信任服务与位于接收实体的信任服务之一、或者二者所调用。 信任服务414或如上所述的不同的身份与属性服务可以包括被示为安全令牌服 务(STS)组件416的内在化组件(或与其进行交互)，其将提供令牌翻译并将调用认证服务 运行时(ASR)418证实和生成令牌。安全令牌服务提供信任服务所需的令牌发布和证实服 务，其可以包括身份翻译。因此，安全令牌服务到现有认证服务运行时的接口，或者其将认 证服务运行时并入该服务自身。不同于在信任服务内进行内在化，而是安全令牌服务组件 还可以被实现为独立组件，例如将由信任服务调用，或其可以在事务服务器内被内在化，例 如作为应用服务器的一部分。 例如，安全令牌服务组件可以接收发布Kerberos令牌的请求。作为将为其创建令 牌的用户的认证信息的一部分，该请求可以包含二进制令牌，所述二进制令牌包含用户名 和口令。安全令牌服务组件将针对例如LDAP运行时(典型认证)证实用户名和口令，并将 调用Kerberos KDC(密钥分配中心)以便为该用户生成Kerberos权证。该令牌被返回信 任服务，用以在企业内使用；不过，这种使用可以包括使令牌外在化，以便传送到联盟中的 另一域。 用户可能希望访问位于联合环境内的多个企业(诸如企业410和420)的资源。以 类似于上述针对企业410的方式，企业420包括接触点服务器422、信任服务424、安全令牌 服务(STS)426、以及认证服务运行时428。尽管用户可以直接发起与每家企业的单独事务， 但是用户可以发起与企业410的事务，该事务贯穿整个联合环境进行级联。企业410可能 需要与联合环境内的多个其它企业(诸如企业420)的协作以完成特定事务，即便当用户发 起事务时用户可能还不知道该必要性。企业420被涉及作为下游实体，而企业410可以在 必要时向企业420呈现断言，以促进用户的联合事务。 可能是这样的情况，信任服务不知道如何解释由相关联的接触点服务器接收的认证令牌和/或如何翻译给定用户身份与属性。在此情形中，信任服务可以选择调用位于信 任调度程序组件(诸如信任调度程序430)的功能。信任调度程序维持与独立的信任代理/ 服务的关系，从而提供信任服务之间的可传递的信任。使用信任调度程序允许联合环境内 的每个实体(诸如企业410和420)建立与信任调度程序的信任关系，而不是建立与联合环 境内的每个实体的多个独立的信任关系。例如，当企业420被涉及作为针对由位于企业410 的用户发起的事务的下游实体时，位于企业410的信任服务414可以被担保位于企业420 的信任服务424可以通过在必要时调用信任调度程序430的协助而理解来自信任服务414 的断言。尽管图4描述了具有单个信任调度程序的联合环境，但是联合环境可以具有多个 信任调度程序。 应该注意，尽管图4描述了作为截然不同的实体的接触点服务器412、信任服务 414、安全令牌服务组件416、以及认证服务运行时418，但是这些组件不是必须在单独的组 件上被实现。例如，这些单独组件的功能能够被实现为单个应用、单个物理设备上的多个应 用、或者多个物理设备上的多个分布式应用。此外，图4针对一家企业描述了单个接触点服 务器、单个信任服务、以及单个安全令牌服务器，但是可替换配置针对每个企业可以包括多 个接触点服务器、多个信任服务、以及多个安全令牌服务器。接触点服务器、信任服务、安
全令牌服务、以及其它联合实体可以用多种形式实现，诸如软件应用、对象、模块、软件库等等。 信任服务/STS可以能够接受和证实许多不同的认证凭证，所述认证凭证包括传 统凭证，诸如用户名和口令的组合、以及Kerberos权证；以及联合认证令牌格式，包括由第 三方产生的认证令牌。信任服务/STS可以允许接受作为其它地方的认证的证明的认证令 牌。该认证令牌由第三方产生并被用于指示出用户已经认证到该发布方。发布方产生认证 令牌，作为断言用户的已认证身份的手段。信任服务/STS还能够处理属性令牌或用于保护 通信会话或对话的令牌，例如，被用于以类似于SSL会话标识符的方式管理会话信息的令 牌。 安全令牌服务在必要时调用认证服务运行时。认证服务运行时支持能够认证用户 的认证服务。认证服务作为经由认证响应提供成功或失败的认证尝试的指示的认证授权机 构。信任服务/STS可以使认证服务内在化，例如以下情景，其中，存在对于不需要与现有的 传统基础设施进行交互的web服务的全新安装。否则，安全令牌服务组件将调用外部认证 服务用以证实认证令牌。例如，安全令牌服务组件可"拆开"包含用户名/ 口令的令牌，并 接着使用LDAP服务来访问用户注册表，以证实所呈现的凭证。 当被诸如应用服务器的另一组件使用时，安全令牌服务组件可以被用于产生单次 登录到传统的认证系统所需的令牌；该功能可以与单次登录协议服务(诸如图3中示出的 SPS 354)内的功能相结合或被其替换。因此，出于内部目的，即在企业内部，以及出于外部 目的，即跨越联盟中的多个企业，安全令牌服务组件可以被用于令牌翻译。作为内部目的的 示例，Web应用服务器可以经由IBM CICS(客户信息控制系统)事务网关与大型机通过接 口连接；CICS是一族应用服务器和连接器，其提供企业级在线事务管理和对于任务而言关 键的应用的连通性。Web应用服务器可以调用安全令牌服务组件将Kerberos权证(由Web 应用服务器内部使用)翻译为CICS事务网关所需的IBM RACF⑧过权证(passticket)。
图4中示出的实体可以使用"身份提供者"和"服务提供者"的术语来解释。作为建立和维护信任关系的一部分，身份提供者的信任服务可以确定服务提供者的信任服务需 要或接受什么样的令牌类型。由此，信任服务当从安全令牌服务调用令牌服务时使用此信 息。当需要身份提供者的信任服务为服务提供者产生认证断言时，信任服务确定所需的令 牌类型，并从安全令牌服务请求适当的令牌。 当服务提供者的信任服务从身份提供者接收认证断言时，信任服务知道它期望什 么类型的断言，以及它在服务提供者内的内部使用所需的什么类型的断言。因此，服务提供 者的信任服务请求安全令牌服务基于在所接收的认证断言中的令牌生成所需的内部使用 令牌。 信任服务和信任调度程序都具有将从身份提供者接收的断言翻译成服务提供者 理解的格式的能力。信任调度程序具有为存在直接信任关系的每个信任服务解释(一种或 多种)断言格式的能力，从而允许信任调度程序在身份提供者和服务提供者之间提供断言 翻译。此翻译可以由任一方通过其本地信任服务进行请求。由此，身份提供者的信任服务 可以在断言被发送到服务提供者之前请求对断言的翻译。同样地，服务提供者的信任服务 可以请求对从身份提供者接收的断言的翻译。 断言翻译包括用户身份翻译、认证断言翻译、属性断言翻译、或其它形式的断言翻 译。重申上述观点，断言翻译由联盟内的信任组件(例如信任服务和信任调度程序)处理。 信任服务可以在身份提供者处或在服务提供者处本地化执行翻译，或者信任服务可以调用 来自信任调度程序的协助。 假定身份提供者和服务提供者已经具有与信任调度程序的独立信任关系，则信任 调度程序可以在必要时动态地创建(即，调度(broker))发布方和依赖方之间的新的信任 关系。在由信任调度程序提供的初始信任关系调度操作之后，身份提供者和服务提供者可 以直接维护该关系，从而信任调度程序不需要被调用用于进一步的翻译需求。应该理解，对 认证令牌的翻译可以发生于三个可能的地点身份提供者的信任服务、服务提供者的信任 服务、以及信任调度程序。优选地，身份提供者的信任服务生成信任调度程序理解的认证断 言，以发送到服务提供者。接着服务提供者请求将来自信任调度程序的令牌翻译为服务提 供者可认出的格式。令牌翻译可以出现于认证断言的传送前、传送后、或传送前后。
典型地，存在必须管理的两类"信任域"企业信任域和联盟信任域。这两类信任 域之间的区别部分地基于用于管制与信任域的信任关系的商业协定以及用于建立信任的 技术。企业信任域包含由企业管理的那些组件；该信任域内的所有组件可以彼此绝对信任。 一般而言，因为所部署的技术在企业内创建了内在信任，例如通过要求组件之间的互认证 的SSL会话或者通过在单个紧密控制的数据中心内放置组件，从而物理控制和邻近证明了 绝对信任，所以不存在建立企业内的信任所需的商业协定。参考图2B，传统的应用和后端处 理系统可以表示企业信任域，其中多个组件在安全的内部网络上进行通信。
联盟信任域是跨企业边界的信任域；从一种角度，联盟信任域可以表示不同的企 业信任域之间的信任关系。联盟信任域由在联盟伙伴之间的跨企业边界的信任代理所建 立。信任关系涉及某种自引导(bootstrap)过程，通过该过程在信任代理之间建立初始信 任。此自引导过程的一部分可以包括建立共享密钥以及规则，所述规则定义了所期望的和 /或所允许的令牌类型和标识符翻译。 一般而言，此自引导过程可以在带外(out-of-band) 实现，因为此过程还可以包括商业协定的建立，所述商业协定对企业在联盟中的参与以及与此参与相关联的责任进行管制。 在示例性的联盟体系结构中，信任关系由信任代理所管理，所述信任代理可以包 括安全令牌服务(或与安全令牌服务相交互)，所述安全令牌服务基于在两个信任代理之 间预先建立的关系来证实并翻译从身份提供者接收的令牌。在联合企业不方便与另一联合 企业建立信任关系(以及令牌翻译)的情形中，可以调用信任调度程序；不过，联合企业将 需要建立与信任调度程序的关系。 现在参考图5，该框图描述了根据示例性的联合体系结构，在使用信任代理和信任 调度程序的联合域之间的示例性信任关系集合。尽管图4引入了信任调度程序，但是图5 示出了示例性的联合体系结构内的可传递的信任关系的重要性。 联合域502-506分别并入信任代理508-512。信任代理508具有与信任代理510 的直接信任关系514。信任调度程序520具有与信任代理510的直接信任关系516，以及信 任调度程序520具有与信任代理512的直接信任关系518。信任调度程序520被用于基于 与其它联盟伙伴的可传递的信任，代表联盟参与者建立信任关系。可传递的信任的原理允 许信任代理510和信任代理512经由信任调度程序520已经调度了信任关系522。信任代 理510和512 二者都不需要知道如何翻译或证实另一个的断言；可以调用信任调度程序来 将断言翻译为有效的、可信的、以及在其它信任代理处可理解的断言。 规定了与联合企业之间的信任关系有关的契约义务和责任的商业协定可以通过 使用ebXML(使用XML的电子商务)标准而用XML来表达。例如，直接信任关系可以在ebXML 文档中表示；共享直接信任关系的每个联合域将具有被表达为ebXML文档的契约的拷贝。 针对联盟内的各种实体的操作特性可以在ebXML编排法中被规定，并在ebXML注册表中被 发布；希望参与到特定联盟中(例如希望操作信任代理或信任调度程序)的任意企业将需 要符合已发布的需求，所述需求由该特定联盟针对联盟内的所有信任代理或信任调度程序 而规定。安全令牌服务可以解析这些ebXML文档以得到关于其中来自其它域的令牌将被翻 译的方式的操作细节。但是，应该理解，其它标准和机制可以被用于支持本发明，用于规定 其中与联盟内的信任关系被实现的方式有关的细节。 在给定用户会话期间，用户可以访问许多联合域以使用由这些域提供的web服 务。域可以使用标准规范来发布它们提供的服务的描述，所述标准规范诸如UDDI和WSDL， 二者都使用XML作为常用数据格式。用户通过同样遵守这些标准规范的应用找到可用的服 务和服务提供者。SOAP提供用于传送以XML表达的请求和响应的范例。联合环境内的实体 可以使用其中的这些实体。 在联盟中，用户期望具有单次登录经验，其中用户完成单次认证操作，并且此认证 操作在用户会话期间是足够的，而不管在该会话期间所访问的联盟伙伴。会话可以被定义 为从(以及包括)初始用户认证(即，登录)到退出的事务集合。在一个会话内，用户动作 将受到针对该会话授予用户的特权的部分管制。 上述的联合体系结构支持单次登录操作。为了促进单次登录体验，支持联合环境 的web服务还将支持使用由第三方生成的认证断言或安全令牌，以提供用户的认证的证 明。该断言将包含用户成功认证到发布方的某种证据连同该用户的标识符。例如，用户可 以完成与一个联盟伙伴的传统的认证操作，例如通过提供用户名和口令，联盟伙伴使用该 用户名和口令来为该用户构建认证凭证，并且接着联盟伙伴能够将由认证/发布方生成的SAML认证断言提供给不同的联盟伙伴。 联合环境还允许web服务或其它应用请求web服务，并且这些web服务也将被认 证。Web服务环境中的认证是用于校验web服务请求的所声明的身份的动作，从而企业可以 限制对已授权客户机的访问。请求或调用web服务的用户将几乎总是被认证，于是对于支 持本发明的联合环境内的认证的需要与用于用户认证的web服务的当前需求没有什么不 同。 对正访问企业的计算资源而没有参与联合会话的用户的认证不受联合基础设施 的出现的影响。例如，通过在HTTP/S上基于表格的认证机制进行认证以访问位于特定域的 非联合资源的现有用户不会受到在该域引入对联合环境的支持的影响。认证由接触点服务 器部分地处理，所述接触点服务器随后可以调用单独的信任代理或信任服务组件；接触点 服务器的使用使得对于现有域的基础设施的影响最小化。例如，接触点服务器可以被配置 为通过将由位于该域的后端或传统的应用和系统处理的所有非联合请求。
接触点服务器可以选择调用基于HTTP的认证方法，诸如基本认证、基于表格的认 证、或某种其它的认证方法。接触点服务器还通过支持对断言的处理而支持联盟域，所述 断言由用户呈现作为认证的证明，诸如SAML认证断言，其中所述断言已经在企业域之间跨 过；当断言/人工信号(artifact)在联盟协议的上下文中被接收时，单次登录协议服务被 用于识别所述断言/人工信号。接触点服务器可以调用信任服务，所述信任服务随后可以 调用其安全令牌服务，用于证实认证凭证/安全令牌。 对web服务或其它应用的认证包括与用户认证相同的过程。来自web服务的请求 承载了包含认证断言的安全令牌，并且该安全令牌将由信任服务用与由用户呈现的令牌相 同的方式被证实。来自web服务的请求应该伴有该令牌，因为web服务应该已经发现所请 求的服务需要什么样的认证断言/安全令牌，如UDDI中所宣传的。 现在参考图6，该框图描述了支持联合单次登录操作的联合环境。用户600通过客 户机设备和适当的客户机应用(诸如浏览器)想要访问由企业/域610提供的web服务， 所述企业/域610支持作为联合环境内的联合域的数据处理系统。域610支持接触点服务 器612和信任代理或信任服务614 ;类似地，域620支持接触点服务器622和信任代理或信 任服务624，而域630支持接触点服务器632和信任代理或信任服务634。如上所述，信任 代理/服务依赖于信任调度程序650的协助。附加的域和信任代理/服务可以参与到联合 环境中。图6被用于描述在域610和域620之间的联合单次登录操作；类似操作可以出现 在域610和域630之间。 用户完成与域610有关的认证操作；该认证操作由接触点服务器612处理。当用 户请求对需要认证身份(例如出于访问控制的目的或出于私人化的目的)的某种资源的访 问时，认证操作被触发。接触点服务器612可以调用传统的认证服务，或者其可以调用信任 代理614来证实用户所呈现的认证凭证。域610在用户的联合会话期间成为用户的身份提 供者或主域。 在稍后的某个时间点，用户发起位于联盟伙伴的事务，所述联盟伙伴诸如企业 620，其也支持联合域，由此触发联合单次登录操作。例如，用户可以发起位于域620的新事 务，或者用户的最初事务可以级联到位于其它域的一个或多个附加事务。作为另一示例，用 户可以经由接触点服务器612调用对域620中的资源的联合单次登录操作，例如通过选择在域610内托管的网页上的特殊链接，或者通过请求在域610内托管的门户页面，但是其显 示域620中托管的资源。接触点服务器612发送请求到信任代理614，以便为用户生成联 合单次登录令牌，其被格式化为可被域620理解或信任。信任代理614将此令牌返回接触 点服务器612，接触点服务器612将此令牌发送到域中的接触点服务器622。域610作为位 于域620的用户的发布方，域620作为依赖方。用户的令牌将与用户的请求一起被传送到 域620 ;该令牌可以使用HTTP重定向经由用户浏览器被发送，或者该令牌可以通过代表在 由信任代理614提供的令牌中标识的用户直接调用接触点服务器622的请求(在HTTP或 基于HTTP的SOAP上)而被发送。 接触点服务器622接收请求连同联盟单次登录令牌，并调用安全代理624。安全代 理624接收联盟单次登录令牌，证实该令牌，并且在假定该令牌有效并可信的情况下为用 户生成本地有效的令牌。信任代理624将本地有效的令牌返回接触点服务器622，接触点服 务器622在域620内为用户建立会话。当必要时，接触点服务器622可以发起位于另一联 合伙伴的联合单次登录。 在域620对令牌的证实由信任代理624处理，可能还有来自安全令牌服务的协助。 取决于由域610呈现的令牌的类型，安全令牌服务可能需要访问位于域620的用户注册表。 例如，域620可以提供包含用户的名称和口令的二进制安全令牌，以便针对位于域620的用 户注册表进行证实。因此，在此示例中，企业仅仅证实来自联合伙伴的安全令牌。域610和 620之间的信任关系确保了域620可以理解并信任由域610代表用户呈现的安全令牌。
联合单次登录不仅需要在依赖域对于代表用户呈现给依赖域的安全令牌的证实， 而且需要基于在安全令牌中包含的信息对本地有效的用户标识符和可能的与该标识符相 关联的属性的确定。直接信任关系以及建立这种关系所需的商业协定的一个结果是，至少 一方(或者发布域或者依赖域或者二者)将知道如何将由发布域提供的信息翻译为在依赖 域有效的标识符；位于依赖域的该标识符可以是由发布方断言的身份的一对一映射的结果 或者另一类型的映射的结果，例如身份到角色的多对一映射，即，不需要所述映射是针对本 地的发布方标识符的唯一的一对一映射。在上述简单示例中，假定发布域(即域610)能够 向依赖域(即域620)提供在域620中有效的用户标识符。在此情形中，依赖域不需要调用 任何身份映射功能。位于域620的信任代理624将为用户生成将为该用户担保的安全令 牌。被接受的令牌的类型、在令牌上需要的签名、以及其它需求都被预先建立，作为联盟的 商业协定的一部分。管制标识符翻译的规则和算法也被预先建立作为联盟的商业协定的一 部分，并且由针对令牌管理和交换的已商定的策略来定义。在两个参与者之间存在直接信 任关系的情形中，标识符翻译算法将已经为这两方建立，并且可能与联盟中的任意其它方 无关。 不过，不会总是以下情形，即，发布域将知道如何将用户从域610的本地标识符映 射到域620的本地标识符。在某些情形中，可以是依赖域知道如何进行此映射，而在另外 其它情形中，任一方都将不知道如何进行此翻译，在此情形中，可能需要调用第三方信任调 度程序。换句话说，在已调度的信任关系的情形中，发布域和依赖域彼此不具有直接信任关 系。不过，它们将具有与信任调度程序(诸如信任调度程序650)的直接信任关系。标识符 映射规则和算法将已经被建立作为此关系的一部分，并且信任调度程序将使用此信息来协 助已调度的信任关系所需的标识符翻译。
域620在接触点服务器622处接收由域610发布的令牌，接触点服务器622调用 信任代理624证实令牌以及执行身份映射。在此情形中，由于信任代理624不能将用户从 域610的本地标识符映射到域620的本地标识符，因此信任代理624调用信任调度程序 650，其证实令牌并执行标识符映射。在获得用户的本地标识符之后，信任代理624可能地 通过其安全令牌服务可以生成位于域620的后端应用所需的任意本地令牌，例如可能需要 Kerberos令牌来便利于从接触点服务器到应用服务器的单次登录。在获得本地有效的令牌 之后，当需要时，接触点服务器能够为用户构建本地会话。接触点服务器还可以处理对用户 请求的粗粒度的授权，以及将已授权的请求转发到域620内的适当的应用服务器。
联合用户生命周期管理(FULM)功能/服务包括以下功能用于支持或管理位于多 个联合域的、与给定用户的特定用户帐户或用户简档有关的联合操作。在标题为"Method and system for policy-based initiation offederation management，，的美国出片反物 No. 20080010665中描述了代表性的FULM功能，所述出版物的公开内容通过引用而并入此 处。在某些情形中，所述功能或操作被限于用户的给定联合会话。换句话说，联合用户生命 周期管理功能指代以下功能可能仅在联合计算环境内的单个用户会话的生命周期期间， 允许对跨多个联合伙伴的联合操作的管理。 每个联合域可以管理与位于每个联合域功能有关的某种用户帐户、用户简档或用 户会话。例如，特定联合域可以不管理特定联合域内的本地用户帐户或用户简档，但是该联 合域可以在成功完成唯一联合域的单次登录操作之后管理联合事务的本地用户会话。作为 由特定联合域支持的联合用户生命周期管理功能的一部分，联合域可以参与到单次登出操 作中，所述操作允许联合域在联合事务完成之后终止本地用户会话，从而提高安全性以及 促进资源的高效使用。 在对联合用户生命周期管理功能的使用的另一示例中，用户可以涉及需要多个联 合域的参与的在线事务。联合域可以在本地管理用户简档，以便在涉及联合域的用户的每 个联合会话期间调整用户体验。作为由特定联合域支持的联合用户生命周期管理功能的一 部分，联合域的本地用户简档中的信息可以以无缝方式在给定联合事务期间与下述信息一 起被使用，所述信息来自位于参与给定联合事务中的其它联合域的其它简档。例如，来自用 户的多个本地用户简档的信息可以用某种合并操作进行组合，使得用户信息以下述方式例 如在网页内可视地呈现给用户，所述方式使得用户不知道用户信息的不同来源或源。
联合用户生命周期管理功能还可以包括用于帐户链接和解除链接的功能。向用户 提供跨联盟伙伴的通用的唯一用户标识符，所述标识符使能与用户有关的单次登录和属性 检索(当必要时)，作为履行一个联盟伙伴的请求的一部分。此外，联盟伙伴可以通过使用 该通用的唯一用户标识符以便以匿名方式指代该用户，而从身份提供者请求附加属性。
现在参考图7A，并且如2006年7月7日提交的美国出版物No. 20080010665中所 述的，所述出版物的公开内容通过引用而并入，框图提供了用于实现联合用户生命周期管 理功能的联合域中的组件的附加细节。图7A描述了位于单个联合域的单元。在图7A中， 接触点服务器702被示为驻留在防火墙710和712之间的匿Z内，所述防火墙710和712 构成企业域的电子或物理前端；此外，联合用户生命周期管理应用/服务708电子地驻留在 防火墙712之后。信任服务714、单次登录协议服务716、以及身份及属性服务718当必要 时使用企业用户注册表720以及联盟用户注册表722 ;用户典型地是自然人，但也可以是使用计算资源的数据处理实体。 再次参考图7A，联合用户生命周期管理应用708还包括对于与联合用户生命周期 管理插件724通过接口连接、相交互、或以其它方式交互操作的支持。在图7A所示的示例 性的体系结构中，联合协议运行时插件提供多种类型的独立发布或开发的联合用户生命周 期管理标准或简档的功能，诸如WS联盟被动式客户机(WS-Federation Passive Client); 以及自由联盟ID-FF单次登录(Liberty Alliance ID-FF Single Sign On) (B/A、B/P以及 LECP)、注册名标识符、联盟终止通知、和单次退出。联合协议的不同集合可以在不同的URI 处进行访问。此方案允许联合用户生命周期管理应用在单个应用内同时支持联合用户生命 周期管理的多个标准或规范，例如WS联盟web服务规范以及自由联盟的规范，由此使得对 用于支持不同联盟协议的整个环境的配置影响最小化。 由接触点服务器通过在适当时将用户请求重定向和/或转发到联合用户生命周 期管理应用而调用联合用户生命周期管理功能。再次参考图7A，接触点服务器702接收用 户请求730，用户请求730接着被分析，以确定已经接收的请求的类型，其可以通过已经接 收的请求消息的类型所指示，或者如上所述的，通过确定请求消息内的目的地URI。当对受 保护资源的请求732继续被转发到应用服务器704时，对联合用户生命周期管理功能的请 求734(例如，调用单次登出操作的请求)被转发到联合用户生命周期管理应用708，其当必 要时调用适当的联合用户生命周期管理插件，以满足所接收的请求。当新的联盟协议或新 的联合功能被定义时，或者当现有联盟协议或联合功能以某种方式被修改或改善时，支持
可以通过插入新的支持模块而被简单添加，或者支持可以通过修改之前安装的插件而被改善。 图7A中的联合用户生命周期管理应用的示例性实现示出了 联合用户生命周期 管理应用能够支持多个同时的联合用户生命周期管理功能，同时提供"插件"功能，由此允 许新功能当需要时以插件的形式被添加到联合用户生命周期管理应用，而无需对现有基础 设施的任何改变。例如，假定所述主题使用基于Java 的联合用户生命周期管理应用来实 现，则对新的联盟协议(诸如新发布的单次登录协议)的支持可以通过将新开发的Java 类配置到联合用户生命周期管理应用的Java CLASSPATH而被添加，其中这些新的类支持 新标准以及用于支持所述主题的协议接口。因此，示例性的联合体系结构影响将在其中集 成联合用户生命周期管理解决方案的现有环境。联合用户生命周期管理应用可以被容易地 修改以支持新的协议/标准，因为它们的发展具有对整个基础设备的最小改变。支持新的 联合用户生命周期管理功能可能需要的任意改变都几乎独占地位于联合用户生命周期管 理应用中，这将需要配置联合用户生命周期管理应用以理解所添加的功能。
在其它联合组件中，例如在接触点服务器处，可以具有最小的配置改变，以便允许 整个的基础设备能够调用新的联合用户生命周期管理功能，同时继续支持现有的联合用户 生命周期管理功能。不过，联合用户生命周期管理应用在功能上独立于其余联合组件之 处在于，联合用户生命周期管理应用可能仅需要与联合环境的其它联合组件的最小交互。 例如，在示例性实施例中，如果联合用户生命周期管理信息(诸如，根据自由联盟简档的 Nameldentifier值)将被存储在外部可访问的联合用户生命周期管理数据存储库(其与对 于外部实体而言不可见的或不可访问的、私有的内部联合用户生命周期管理数据存储库相 反)中，则联合用户生命周期管理功能可以与基于企业的数据存储库(例如LDAP数据存储库)集成。 某些联合操作(诸如可能需要与用户进行最小交互来完成操作的那些操作)应该 以对用户造成最小麻烦的方式被执行，但是它们还应该以对于联合企业而言、特别是对于 可能需要跨企业内所有用户的那些类型的操作而言高效的方式被执行。与为了支持某些联 合协议所需的操作有关地，联合企业在实现那些操作的方式上可能没有太多灵活性，以及 对于用户以及联合企业的计算资源没有带来太多负担。联合企业可以被要求根据该联合企 业已经同意的联盟规范以某些方式执行某些动作。换句话说，联合企业可以被商业契约要 求实现某些联盟操作而不管这些操作的计算负担。 不过，联合环境内的功能的许多方面可以被分类为支持一个或多个商业目标的操 作，所述商业目标是联盟内的一家或多家企业所需要的，但不是支持联盟协议所必需的，或 者所述商业目标不是为了参与联盟中所必需的。此外，满足这些商业目标的操作的实现可 以触发执行多种联盟操作，其导致与参与的联盟伙伴的交互。由于所导致的用于支持对企 业特定的商业目标的动作可以具有跨联合环境的分支，因此其中实现支持操作的方式应该 以可扩展跨越联盟内的成千或成百万个用户的方式来完成。此外，负责管理企业内的联 合功能的系统管理员当实现企业想要的商业目标时，应该能够以便利的方式配置其计算资 源。 至此，2006年7月7日提交的美国出版物No. 20080010665提供了一种基于策略的 机制以及相关的计算基础设施，其提供了对基础设施的高效和可配置的管理以完成想要的 商业目标。所述的基础设施允许联合操作通过使用策略以及相关的策略管理机制以可扩展 方式被管理。现在参考图7B，框图描述了用于实现联合用户生命周期管理功能、同时也实现 用于完成可使用联合用户生命周期管理功能的多种商业目标的基于策略的机制的联合域 中的某些组件。图7B非常类似于图7A之处在于，两个图都示出了用于实现联合用户生命 周期管理功能的组件的示例性布置。与图7A对比，请求/响应消息730、受保护资源消息 732、以及FULM消息734被示为与企业的数据处理系统有关的进入和外出消息，由此强调了 该方案适用于对进入和外出数据流量的预处理和后处理。 图7B所示的系统已经被增强，以包括以下附加功能用于支持以使麻烦最小化的 方式对联合用户生命周期管理功能的基于策略的发起。在图7B中，FULM应用/服务708包 括策略过滤器/引擎736。当在FULM应用/服务708处从接触点服务器702接收进入的 FULM请求消息734时，或者当来自用于转发到接触点服务器702的多种组件的外出的FULM 响应消息正被FULM应用/服务708处理时，所述消息被策略过滤器/引擎736过滤，所述过 滤是通过检查任意策略(例如，存储在策略数据库738中)是否已经被配置，其需要对进入 或外出消息的附加的联盟相关处理。例如，策略可以需要在满足进入请求消息之前对该请 求的预处理。类似地，策略可以需要在返回外出响应消息之前对该响应的附加后处理。换 句话说，在用于进入/外出FULM消息的处理流的头/尾处放置策略过滤器/引擎736确保 了可以在发起或终止对FULM消息的处理之前，即，在发起对进入的FULM请求的处理之前或 在终止对外出的FULM响应的处理之前，执行附加预处理或后处理步骤。
在某些情形中，对策略的评估可以指示出需要附加的预处理或后处理，并且在其 它情形中，对策略的评估可以指示出不需要附加的预处理或后处理。从这种角度，策略引擎 736可以被看作是过滤进入和外出消息。策略引擎736将允许某些进入请求被立即满足而无需附加的预处理步骤，同时转移或挂起其它请求直到可以执行附加的预处理步骤为止。 类似地，策略引擎736将允许某些外出响应被立即转发而无需附加的后处理步骤，同时转 移或挂起其它响应直到可以执行附加的后处理步骤为止。 在可替换实施例中，策略引擎/过滤器可以关联于接触点服务器702和/或关联 于一个或多个应用服务器704。在这种实施例中，并且如将在下文中更详细描述的，一个或 多个FULM插件724提供数字权限管理(DRM)功能。它们有时在此被称为DRM插件。
现在参考图7C。框图示出了用于某些数据单元的附加细节，所述数据单元根据实 施例由策略引擎相关于FULM消息评估策略相关联地被处理。图7C包含类似于图7B示出 的单元，对于类似单元，使用相同参考标号示出。优选地，策略引擎的功能以下述方式被嵌 入联盟简档的处理中，所述方式使得当FULM请求被接收时或当FULM响应被返回时策略可 以被实施；在策略中指示的任意操作可以在对FULM请求的进一步处理之前或者在终止对 FULM响应的处理之前作为预处理或后处理的步骤执行。基于策略的预处理和后处理并非意 在排除在对FULM消息中的内容的运行时处理中可能在其它地方出现的策略的使用。策略 可以被存储在一个或多个数据存储库中，诸如策略数据库738。因为企业可以参与到不止一 个联盟中，即，可以支持用于多个联合计算环境的功能，所以FULM消息可以与不同联盟简 档有关地被处理，并且策略数据库738可以包含用于不同联盟简档的策略的不同集合。在 所示的此示例中，策略集合740适用于第一联盟中的用户，而策略集合742适用于第二联盟 中的用户；用户可以在多个联盟中注册，于是策略集合740和策略集合742不是必然地仅 适用于互斥的用户集合。策略集合744适用于当前企业内的所有用户，所述企业即，支持图 7A-7C中所示的数据处理环境的企业。策略集合746适用于企业内的特定独立用户。
图7C中示出的不同类型的策略仅示出了可以在企业内应用的某些策略的可实施 性；数据库内的策略不是必然地被存储作为图7C中所示的无关联的集合。策略可以用任意 适当的格式表示，诸如用XML(可扩展标记语言)定义、并被表示为XSLT(XSL转换或可扩展 样式表语言转换)的格式，XSLT可被用于将一种XML文档转换为另一种XML文档。策略引 擎736评估策略中的一个或多个规则。例如，当进入的简档请求在对简档请求的初始处理 之前被接收时，XSLT规则引擎可以被调用。所评估的策略748表示正被评估的策略、或已被 评估的策略。规则750表示策略中的条件表达式；条件表达式基于根据逻辑操作符评估的 参数或数据值的集合来指示出条件。如果表达式评估为逻辑或布尔"真"值，则判定该规则 被触发或激活；如果表达式评估为逻辑或布尔"假"值，则判定该规则未被触发或激活。从 一种角度，策略的规则可以被看成是"if-then"条件语句，仅当相关联的条件被评估为真，
或被评估为已满足时，所述条件语句导致某种附加处理。条件表达式中的一个或多个值可 以从用户注册表722中的用户条目754中的用户属性752获得。在此示例中，用户条目754 与用户相关联，初始的FULM消息代表用户被接收；例如，初始接收的FULM消息可以包含用 户标识符，所述用户标识符可被用于确定当初始的FULM消息被接收时可实施的策略。
如果策略中的规则被触发，则取决于消息是外出响应还是进入请求，对初始接收 的响应的处理的终结(conclusion)被挂起，或者对初始接收的请求的进一步处理被挂起。 以此方式，将为所接收的消息执行(例如由图7B中示出的FULM应用/服务708)的联盟协 议操作被推迟，直到随后的时间点为止。在挂起或推迟期间，图7B中示出的FULM消息734 可以被存储在适当位置(诸如挂起操作缓冲器)或某种其它的数据存储库，诸如用户注册表722中的用户条目754，或包含用于用户的会话管理的其它信息的会话高速缓存。
在策略中的规则已经被评估，从而其触发或激活附加的预处理或后处理之后，策 略接着被检查，以找到其中包含的关于当其规则被触发时将被执行的附加的预处理或后处 理的类型的信息。更具体地，对于进入的请求消息，策略指示出在执行可能与已经被挂起的 初始FULM请求相关联的任意其它联盟协议操作之前将执行的联盟协议操作。类似地，对于 外出的响应消息，策略指示出在执行可能与已经被挂起的外出FULM响应相关联的任意其 它联盟协议操作之前将执行的联盟协议操作。图7C示出了策略748包含了用于与规则750 相关联的已触发的联盟协议操作758的标识数据或指示数据。 策略748还可以包含关于一个或多个终结过程760，其指示出当已触发的联盟协 议操作758的终结时将执行的任意过程。例如，在已触发的联盟协议操作758被终结时，所 应用的策略信息762可以在用户条目754中进行设置，所述用户条目754指示出特定策略 已经被应用，即，被实施；每个这样的条目可以具有对其相关联的策略的引用或者对其相关 联的策略的标识符连同附加信息，诸如，策略被成功地还是不成功地实施的指示、指示出策 略何时被实施的一个或多个时间戳、以及其它相关信息。在某些情形中，即便已触发的联盟 协议操作758失败，与终结过程760有关的信息仍可以指示出初始接收的FULM消息可以被 允许继续进行，例如如下这些情形，其中，策略指示出非强制性的、或者非时间紧要的(因 为该策略可以在稍后某个时间点重新运行)联盟协议操作。在某些情形中，如果已触发的 联盟协议操作758已失败，则与终结过程760有关的信息可以指示出初始接收的FULM消息 无法继续进行，例如如下这些情形，其中，策略指示出强制性的、或者时间紧要的联盟协议 操作。取决于与终结过程760有关的信息，初始接收的FULM消息从适当的数据存储库(诸 如已挂起操作高速缓存756)中被检索，并接着被进一步处理或被拒绝。
数字权限管理(DRM)策略可以由一个或多个DRM插件实现，所述DRM插件由DRM 策略提供者为了服务提供者的利益而进行管理和操作，作为策略实施的一部分。DRM插件可 以被添加作为DRM资源，所述DRM资源被添加到服务提供者环境，并且如将会看到的，所述 插件被有利地用于在必要时处理附加DRM属性(下文被称为DRM特权)的检索。
如此处所使用的，"DRM特权"是描述进行由DRM策略控制的动作的能力的信息 (例如属性)。例如，给定的DRM特权可以(以给定费用)向用户提供对给定网站(例如 audible, com)的永久访问，以及在任意设备上播放音频书籍的能力。 如此处所使用的，"DRM策略"是描述在数字权限管理方案的上下文中，在用户可以 采取给定动作之前需要什么样的DRM特权的信息。例如，如果用户具有对Audible的预订， 以及在iTunes上播放下载内容的能力，则DRM策略可以使用户能够在iPod或GPS移动设 备上播放已下载的音乐。 DRM特权可以包括多个不同的动作或权限，并且DRM策略可以被DRM特权的许多不 同集合所填充。 启用DRM策略的联盟 通过作为背景的上述描述，下文描述启用DRM策略的联盟。如图8所示，联盟中的 参与者优选地包括第一联盟伙伴800、第二联盟伙伴802、第三联盟伙伴804、以及可选地包 括第四联盟伙伴806。第一联盟伙伴800可以是身份提供者(按照FULM功能)，或者其可以 是服务提供者，用于提供需要DRM策略一致性的服务。出于解释的目的，第一联盟伙伴800在此被称为身份提供者。第二联盟伙伴802是服务提供者，其(从终端用户的角度)提供 DRM内容。第三联盟伙伴是服务提供者，其管理终端用户的DRM特权808，以及可选地管理 DRM策略810，所述DRM策略810必须由第二联盟伙伴802实施。第四联盟伙伴806是DRM 策略"谕示(oracle)"，其管理DRM策略(与DRM特权相反)。DRM策略谕示功能可以是第 三联盟伙伴的功能，在此情形中不需要第四联盟伙伴。换句话说，第三和第四联盟伙伴804 和806可以共存于单个联盟伙伴中。 第一联盟伙伴800可以包括第三联盟伙伴804的功能，以便由此作为联盟中的身 份提供者和DRM提供者。其中这将会有用的一个示例场景是，终端用户具有允许无限访问 的音乐下载服务(诸如iTunes)的预订。 可替换地，第二联盟伙伴802可以包括第三联盟伙伴804的功能。在这种情形中， 第二联盟伙伴维护与其功能有关的DRM信息，并可选地在请求时将其提供给其它联盟伙 伴。其中这将会有用的一个示例场景是，音乐下载服务知道用户别名具有对服务的无限预 订。 第一联盟伙伴800可以包括第四联盟伙伴806的功能。在这种情形中，第一联盟 伙伴800作为身份提供者和DRM策略提供者，但是典型地，这种策略很可能是粗粒度的。其 中这将会有用的一个示例场景是，终端用户想要从身份提供者通过单次登录(SSO)访问音 乐下载服务，并且需要具有对该服务的有效预订的证明。 第二联盟伙伴802可以包括第四联盟伙伴806的功能。在这种情形中，第二联盟 伙伴802作为服务提供者和DRM策略提供者。其中这将会有用的一个示例场景是，服务提 供者是音乐下载服务，并且其知道，为了访问该服务，用户必须至少具有对该服务的一个月 的试用预订。 如已经说明的，第三联盟伙伴804可以包括第四联盟伙伴的功能。在这种情形中， 第三联盟伙伴作为用户的DRM特权的DRM提供者和DRM策略的服务提供者。例如，假定用 户具有对电影服务(例如NetFlix)的无限预订，并且，对于给定时间段(例如七月的一个 月)，所有服务用户具有对音乐下载服务的免费一个月试用，从而，通过应用该策略可以确 定，在该月内，用户具有对音乐下载服务的一个月试用的DRM特权。
以下是启用DRM策略的联盟的若干示例。
示例1 : 如图9所示，在第一示例中，用户901认证到第一联盟伙伴900，并请求到第二联 盟伙伴902的单次登录，从用户角度，所述第二联盟伙伴902提供内容。由此，第二联盟伙 伴902对应于前述的数字内容提供者。作为联盟的结果，假定第一联盟伙伴900知道(或 查询第四联盟伙伴906以发现)在第二联盟伙伴902处实施的DRM策略910，并且第一联盟 伙伴900知道(或查询第三联盟伙伴904以发现)用户的DRM特权908。接着第一联盟伙 伴900参考用户的DRM特权908构建对第二联盟伙伴902的单次登录消息。如2004年7 月21日提交的美国出版物No. 2006/0021018中所述，这可以被完成的典型方式是，包含用 户的DRM特权908的断言的指针被从第一联盟伙伴900发送到第二联盟伙伴902(典型地 通过HTTP302、基于浏览器的重定向)，并且作为响应，第二联盟伙伴902请求对于包含用户 的DRM特权908的断言的指针(也被称为人工信号)的交换。 如果第二联盟伙伴902已经知道其必须实施的策略，则其使用已断言的DRM特权908来评估该策略(诸如以上图7C中描述的)，由此基于该策略评估允许或不允许访问。不 过，如果第二联盟伙伴902不知道其必须实施的策略(或不具有评估与该策略的一致性的 能力)，则第二联盟伙伴生成到第四联盟伙伴906 (或者当该伙伴也是DRM策略谕示时，到 第三联盟伙伴)的"DRM策略评估"请求912。 DRM策略评估请求将DRM特权提供给第四联 盟伙伴906，其提供"是"或"否"答复。如果由第四联盟伙伴提供的答复为是，则允许访问； 如果答复为否，则不允许访问。 存在这样的可能性，第二联盟伙伴902知道其DRM策略，而且还知道第一联盟伙伴 没有提供使得第二联盟伙伴902能够评估策略所需的任意/全部信息。即便第一联盟伙伴 去到第三联盟伙伴并查询DRM策略，这也可以是真实存在的，因为第一联盟伙伴可能未被 允许检索或以其它方式获得所有所需的或相关的DRM特权，从而使得不完整信息被发送到 第二联盟伙伴。在此情形中，第二联盟伙伴902可以请求第三联盟伙伴904检索与用户的 DRM特权有关的附加信息，以便允许策略评估。 作为在之前段落中描述的方案的另一变型，第二联盟伙伴902知道其DRM策略，并 且使得用户的DRM信息(在本地)对其可用；在此场景中，第二联盟伙伴自身供应评估DRM 策略所需的缺失DRM特权，以确定是否允许访问。作为又一变型，假定第二联盟伙伴902知 道其DRM策略，并且使得用户的DRM信息(在本地)对其可用，但是其缺失DRM特权或具有 过期信息(诸如允诺(consent)、更新等)；在此场景中，第二联盟伙伴在针对DRM策略评估 DRM特权之前，查询用户以获得所需信息。
示例2 : 现在参考图IO，在此场景中，用户1001认证到第一联盟伙伴IOOO，并请求到第二 联盟伙伴1002的单次登录。作为联盟协定或其它方式的结果，假定第一联盟伙伴1000已 经知道在第二联盟伙伴1002处实施的DRM策略1010。在此场景中，第一联盟伙伴1000知 道(或查询第三联盟伙伴1004以发现)用户的DRM特权1008。不过，在此示例中，第一联 盟伙伴IOOO不知道或未被授权从第四联盟伙伴(或者当该伙伴是DRM策略谕示时，从第三 联盟伙伴)检索DRM策略1010 ;由此，第一联盟伙伴IOOO通过已知的DRM特权1008构建 必需人工信号/断言，并且接着借助于前述的DRM策略评估请求将断言提供给第四联盟伙 伴。第四联盟伙伴1008提供"是"或"否"答复。如前一样，如果由第四联盟伙伴提供的答 复为是，则由第一联盟伙伴允许访问；如果答复为否，则不允许访问。 以上标识的示例示出了可替换实施例，其中身份提供者自身具有针对一个或多个 DRM特权的集合实施DRAM策略的能力。根据此可替换实施例，身份提供者知道或者可以获 得DRM策略，并且其知道或者可以获得进行评估所需的DRM特权。
示例3 : 现在参考图ll，在此场景中，用户1101认证到第一联盟伙伴IIOO，并请求到第二 联盟伙伴1102的单次登录。在此示例中，假定第一联盟伙伴1100不知道在第二联盟伙伴 1102处实施的任何DRM策略1110有关的任何事。在此情形中，第一联盟伙伴1100通过已 知的相关属性构建人工信号/断言，所述相关属性可能包括或可能不包括DRM特权。同时， 第二联盟伙伴1102知道请求需要DRM特权，并且知道该特权将不会由第一联盟伙伴供应。 接着第二联盟伙伴1102必须获得DRM特权。存在这样做的若干选项。
第一选项是，出于履行请求的目的，第二联盟伙伴1102做出对第三联盟伙伴1104的查询，以检索用户的DRM特权1108。作为第二选项，第二联盟伙伴直接从用户llOl解锁 用户的DRM特权；在此，第二联盟伙伴调用与用户的直接交互来获得DRM特权。取代于调用 直接交互，第二联盟可以通过检索允诺以获得这些特权、检索到第三联盟伙伴的指针、并接 着使得第三联盟伙伴触发用户将特权发送到第二联盟伙伴，从而间接获得它们。在任意情 形中， 一旦交互完成且获得DRM特权，则第二联盟伙伴在本地存储所收集的DRM特权信息， 或者将其推送到第三联盟伙伴。DRM特权信息可以包括用户对DRM服务的预订的更新。
示例4 : 启用DRM策略的联盟的一个或多个组件(诸如身份提供者、服务提供者、DRM特权 提供者、或者DRM策略提供者)可以以分布式方式实现。现在参考图12，该框图描述了以下 场景，其中第一数据处理系统从身份提供者(仅借助于示例)内的第二数据处理系统检索 断言，所述身份提供者使用支持分布式断言检索的分布式数据处理系统实现。此类型的系 统在2008年1月10日公布的美国出版物No. 20090010288中进行了描述。在此示例中，身 份提供者1200是包含数据处理系统1202以及数据处理系统1208的分布式数据处理系统， 所述数据处理系统1202自身包含单次登录服务(SPS) 1204以及断言高速缓存1206，所述 数据处理系统1208自身包含SPS 1210和断言高速缓存1212。在某个时间点，数据处理系 统1202例如从以上参考图8描述的服务提供者接收到断言检索请求。数据处理系统1202 使用人工信号搜索其本地的断言高速缓存1206，所述人工信号是其之前从已接收的断言检 索请求中提取的；人工信号可被用作为搜索键或作为搜索键的基础。在此示例中，数据处理 系统1202没有在其本地数据存储库或高速缓存中定位到与人工信号相关联的断言。如果 在本地数据存储库中未找到断言，则取代于返回错误，数据处理系统1202尝试从包括身份 提供者在内的其它数据处理系统请求适当的断言。SPS 1204例如通过发送断言检索请求 1214到位于数据处理系统1208的SPS 1210，向身份提供者内的另一数据处理系统发布断 言检索请求。假定数据处理系统1208能够履行其接收的请求，数据处理系统1208检索断 言，从其本地数据存储库1212移除断言使得该断言无法被重新使用，并将断言返回数据处 理系统1202。接着身份提供者1200通过发送断言检索响应到服务提供者，履行从服务提供 者接收的初始断言检索请求。 身份提供者可以具有可能作为断言的源的多个数据中心，并且当第一数据处理系 统在其本地断言高速缓存中没有找到所请求的断言时，从服务提供者接收断言检索请求的 第一数据处理系统发起对包括身份提供者在内的所有其它数据处理系统或数据中心的搜 索。假定执行了成功的搜索，第一数据处理系统能够从身份提供者内的另一数据处理系统 检索所请求的断言。 第一数据处理系统可以用多种方式执行对所请求的断言的搜索。例如，可以用链 式方式执行搜索，其中数据处理系统当未找到所请求的断言时转发搜索；第一数据中心将 查询第二数据中心，而第二数据中心将随即查询第三数据中心，直到找到所请求的断言为 止，在此时，断言以起泡式或递归方式被返回到第一数据中心。当搜索进行时，每个数据中 心可以增加或追加标识符，所述标识符指示出哪些数据中心已经执行了搜索。可替换地，以 及如美国出版物No. 20080010288中所述的，可以以连续方式或轴辐式(hub-and-spoke)执 行搜索，其中第一数据处理系统依次查询每一个数据处理系统；第一数据中心作为轴心，并 且独立地查询每个数据中心(轮辐)。
在示例的DRM场景中，假定服务提供者是在线娱乐存储库的分布式数据中心实 现，并且进一步地，假定存在实施DRM的实体的单个实例，例如DRM策略谕示。用户使用web 浏览器以通常方式访问音乐存储库。假定用户已经访问存储库并购买了多个下载，由于现 有会话简档的原因，所述多个下载使用户有资格接收对在线视频的免费访问。在用户的结 账页面，服务提供者包括邀请用户访问该视频的链接。用户单击该链接，并被重定向到在线 视频店面，连同绑定了人工信号的请求。视频存储库接收所述绑定了人工信号的请求，解除 该请求的绑定，提取人工信号，并且将直接(例如HTTP/SOAP)请求返回到在线音乐存储库， 以检索用户的当前在线音乐简档。视频存储库尝试基于人工信号检索断言，以及当必要时 使用图12中所示的技术(以及如美国出版物No. 20080010288中所述内容)来这样做。在 获得其证实用户所需的信息后，提供视频。 现在参考图13，该框图描述了示例性的数字权限管理场景的进一步示例。用户/ 客户端1302发起事务，所述事务将请求1304发送到企业"A" 1306，其是数字内容提供者。 企业"B"1308是数字权限管理实体，诸如用于管理与联盟1310内的各伙伴之间的版权协定 有关的预订费用或其它版权限制的预订服务。系统管理员可以建立DRM策略1312，以使其 被策略过滤器/引擎1314实施。当联盟内的用户尝试联盟协议操作/简档时，例如请求检 索由请求1304所表示的受版权保护的内容，策略引擎将被调用，并且策略1312将被发现在 此时是可被实施的。策略1312可以要求在允许用户完成与受版权保护的内容有关的检索 事务之前，用户具有当前有效的预订。 尽管企业1306不管理预订，但企业1306可能在之前的事务期间曾获得与来自企 业1308的用户预订的过期时间或日期有关的信息。在之前的事务期间，企业1308可以存 储了过期时间作为用户属性。因此，用户1302的用户属性可以被企业1306用于确定用户 是否具有在联盟内接收受版权保护的内容的有效预订。如果在之前的事务期间没有存储用 户预订的到期时间，或者如果出于某种其它原因预订状态需要被验证，则对请求1304的处 理可以要求对企业130的单次登录操作，企业1308对于用户预订的授权机构性状态做出响 应，从而允许企业1306确定是否允许用户检索所请求的内容。 取决于用户预订的当前状态，如对通信策略的实施所要求的，在请求1304可以被 完成之前，可能需要与用户的附加协议操作和/或通信交互1316。例如，可以要求用户在通 信之前允诺在企业1306和企业1308之间的通信/事务。可替换地，可以要求用户允诺将 信息从企业1308发布到企业1306，例如，发布与用户预订的状态有关的信息。在另一可替 换实施例中，可以要求企业1306从用户获得其它信息，诸如不同于企业1308的预订服务的 身份，通过该预订服务，用户可以具有有效的预订帐户。 这些各种附加的通信需求可以被包含在通信策略1318中，通信策略1318记述了 其中将执行这些通信的方式。例如，可以使用直接通信作为联盟伙伴(即，独立于用户的后 向信道(back-channel)通信)来执行企业1306和企业1308之间的通信。可替换地，可以 使用间接通信作为联盟伙伴(即，经由用户客户机的前向信道(front-channel)通信)来 执行企业1306和企业1308之间的通信。 更一般地，此处所述的主题可以采用完全的硬件实施例、完全软件实施例、或者包 含硬件和软件单元两者的实施例的形式。在优选实施例中，本发明(包括客户机端的功能、 服务器端的功能、或二者)以软件实现，其包括但不限于固件、常驻软件、微码等。此外，如上所述，本发明可以采用可从计算机可用或计算机可读介质访问的计算机程序产品的形 式，计算机可用或计算机可读介质提供程序代码以由计算机或任何指令执行系统使用或与 它们结合使用。出于此说明的目的，计算机可用或计算机可读介质可以是能够包含、存储、 传送、传播或传输由指令执行系统、装置或设备使用或相结合使用的程序的任何装置。所述 介质可以是电、磁、光、电磁、红外或半导体系统(或装置或设备)或传播介质。计算机可读 介质的示例包括半导体或固态存储器、磁带、可移除计算机盘、随机存取存储器(RAM)、只读 存储器(R0M)、固定磁盘和光盘。光盘的当前示例包括只读存储器致密盘(CD-ROM)、读/写 致密盘(CD-R/W)和DVD。 上述功能的一种或多种也可以以被托管的方式实现为服务。 尽管上文描述了由本发明的某些实施例执行的操作的特定顺序，但是应该理解，
这种顺序是示例性的，因为可替换实施例可以以不同顺序执行所述操作，组合某些操作，重
叠某些操作等等。在说明书中对给定实施例的引用指示出所述实施例可以包括特定特征、
结构或特性，但是每个实施例可以不一定包括该特定特征、结构或特性。 最后系统的给定组件已经被单独地描述，但是本领域普通技术人员将认识到，某
些功能可以在给定指令、程序序列、代码部分等等中被组合或共享。 在已经描述了我们的发明之后，我们要求保护的内容如下。
权利要求
一种可在身份提供者实体处操作的、用于实施与一部分内容相关联的数字权限管理方案的方法，其中所述身份提供者实体与服务提供者实体一起参与到联盟中，所述方法包括获得并针对数字权限管理策略评估与请求访问所述一部分内容的终端用户相关联的一个或多个数字权限管理特权的集合；基于所述评估生成消息，所述消息包括与请求访问所述一部分内容的终端用户相关联的一个或多个数字权限管理特权的集合的引用；以及将所述消息转发给所述服务提供者实体。
1. 一种可在身份提供者实体处操作的、用于实施与一部分内容相关联的数字权限管理 方案的方法，其中所述身份提供者实体与服务提供者实体一起参与到联盟中，所述方法包 括获得并针对数字权限管理策略评估与请求访问所述一部分内容的终端用户相关联的 一个或多个数字权限管理特权的集合；基于所述评估生成消息，所述消息包括与请求访问所述一部分内容的终端用户相关联 的一个或多个数字权限管理特权的集合的引用；以及将所述消息转发给所述服务提供者实体。
2. 根据权利要求1所述的方法，其中所述消息是在所述终端用户被所述身份提供者 实体进行认证时，由所述身份提供者实体生成的单次登录消息。
3. 根据权利要求1所述的方法，进一步包括认证所述终端用户。
4. 根据权利要求1所述的方法，其中所述数字权限管理策略在所述身份提供者实体处 本地可用。
5. 根据权利要求1所述的方法，其中，当所述数字权限管理策略在所述身份提供者实 体处本地不可用时，所述方法进一步包括以下步骤生成包括所述一个或多个数字权限管理特权的集合的数字权限管理策略评估请求； 将所述数字权限管理策略评估请求转发到所述联盟中的实体；以及 接收对所述数字权限管理策略评估请求的响应。
6 根据权利要求5所述的方法，其中对所述数字权限管理策略评估请求的响应指示出 对所述给定一部分内容的访问被许可。
7. 根据权利要求1所述的方法，其中所述一个或多个数字权限管理特权的集合在所述 身份提供者实体处本地可用。
8. 根据权利要求1所述的方法，其中，当所述一个或多个数字权限管理特权的集合在 所述身份提供者实体处本地不可用时，所述方法进一步包括从所述联盟中的实体获得所 述一个或多个数字权限管理特权的集合。
9. 根据权利要求1所述的方法，其中，当所述一个或多个数字权限管理特权的集合在 所述身份提供者实体处本地不可用时，所述方法进一步包括从所述用户获得所述一个或 多个数字权限管理特权的集合。
10. 根据权利要求9所述的方法，其中所述一个或多个数字权限管理特权的集合直接 从所述用户获得。
11. 根据权利要求9所述的方法，其中，通过让用户使得第三实体将所述一个或多个数 字权限管理特权的集合提供给所述身份提供者，获得所述一个或多个数字权限管理特权的隹A 朱n o
12. 根据权利要求l所述的方法，进一步包括从所述联盟中的第三实体接收所述一个或多个数字权限管理特权的集合； 生成包括所述一个或多个数字权限管理特权的集合的数字权限管理策略评估请求； 将所述数字权限管理策略评估请求转发到所述联盟中的第四实体；以及 从所述第四实体接收对所述数字权限管理策略评估请求的响应。
13. 根据权利要求12所述的方法，其中所述第三实体在所述联盟内代表所述用户提供管理所述一个或多个数字权限管理特权的集合的服务。
14. 根据权利要求12所述的方法，其中所述第四实体在所述联盟内提供管理数字权限 管理策略的服务。
15. 根据权利要求12所述的方法，其中所述第三和第四实体是所述联盟内的单个实 体，其在所述联盟内代表用户管理所述一个或多个数字权限管理特权的集合并且还管理数 字权限管理策略。
16. 根据权利要求1所述的方法，其中所述消息包括对于包含与所述终端用户相关联 的所述一个或多个数字权限管理特权的集合的断言的指针，并且其中所述身份提供者请求 交换所述断言的指针，以获得所述一个或多个数字权限管理特权的集合。
17. —种可在身份提供者处操作的、用于实施与一部分内容相关联的数字权限管理方 案的方法，其中所述身份提供者参与到还包括服务提供者、数字权限管理特权提供者、以及数字权限管理策略提供者的联盟中，所述方法包括在给定事件时，确定一个或多个数字权限管理特权的集合是否可用于评估，所述一个 或多个数字权限管理特权的集合与请求访问所述一部分内容的终端用户相关联；如果所述一个或多个数字权限管理特权的集合不可用于评估，则从所述数字权限管理 特权提供者检索所述一个或多个数字权限管理特权的集合；确定数字权限管理策略是否将被评估并且是否可用；如果所述数字权限管理策略将被评估并且不可用，则从所述数字权限管理策略提供者 检索所述数字权限管理策略；以及针对所述数字权限管理策略评估所述一个或多个数字权限管理特权的集合；基于所述评估生成消息，所述消息包括与请求访问所述一部分内容的终端用户相关联 的一个或多个数字权限管理特权的集合的引用；以及将所述消息转发给所述服务提供者实体。
18. 根据权利要求17所述的方法，其中所述数字权限管理特权提供者和所述数字权限 管理策略提供者是所述联盟内的单个服务提供者。
19. 根据权利要求17所述的方法，其中所述身份提供者和所述数字权限管理特权提供 者是所述联盟内的单个服务提供者。
20. 根据权利要求17所述的方法，其中所述服务提供者和所述数字权限管理特权提供 者是所述联盟内的单个服务提供者。
21. 根据权利要求17所述的方法，其中所述身份提供者和所述数字权限管理策略提供 者是所述联盟内的单个服务提供者。
22. 根据权利要求17所述的方法，其中所述服务提供者和所述数字权限管理策略提供 者是所述联盟内的单个服务提供者。
23. —种用于实施与一部分内容相关联的数字权限管理方案的数据处理系统，包括 处理器；可由所述处理器执行的代码，用于确定一个或多个数字权限管理特权的集合是否可用 于评估，所述一个或多个数字权限管理特权的集合与请求访问所述一部分内容的终端用户 相关联；可由所述处理器执行的代码，用于如果所述一个或多个数字权限管理特权的集合不可用于评估，则从所述数字权限管理特权提供者检索所述一个或多个数字权限管理特权的集合.可由所述处理器执行的代码，用于确定数字权限管理策略是否将被评估并且是否可用；可由所述处理器执行的代码，用于如果所述数字权限管理策略将被评估并且不可用， 则从所述数字权限管理策略提供者检索所述数字权限管理策略；以及可由所述处理器执行的代码，用于针对所述数字权限管理策略评估所述一个或多个数 字权限管理特权的集合。
24. 根据权利要求23所述的数字处理系统，进一步包括可由所述处理器执行的代码，并且所述代码响应于所述评估，用于生成消息，所述消息 包括与请求访问所述一部分内容的终端用户相关联的一个或多个数字权限管理特权的集 合的引用；以及可由所述处理器执行的代码，用于将所述消息转发给服务提供者实体。
25. —种存储在计算机可读媒体中、并且在处理器中可执行用于实施与一部分内容相 关联的数字权限管理方案的计算机程序产品，包括用于实现权利要求1-22所述的任意方 法的代码。
26. —种用于实施与一部分内容相关联的数字权限管理方案的计算机系统，包括用于 实现权利要求1-22所述的任意方法的装置。
全文摘要
一种可在身份提供者处操作的方法实施与一部分内容相关联的数字权限管理(DRM)方案。身份提供者是参与到“联盟”中的实体，所述联盟具有一个多个其它实体，例如包括服务提供者(诸如内容提供者)、DRM特权提供者、以及DRM策略提供者。在一个实施例中，所述方法开始于使身份提供者获得并针对DRM策略评估与请求访问所述一部分内容的终端用户相关联的DRM特权集合。基于所述评估，身份提供者生成单次登录(SSO)消息，所述消息包括对DRM特权集合的引用。接着所述消息被转发给服务提供者实体，其向终端用户提供响应。
文档编号G06F21/00GK101727552SQ20091017976
公开日2010年6月9日 申请日期2009年10月15日 优先权日2008年10月16日
发明者H·M·欣顿 申请人:国际商业机器公司