CN103620615A - 访问控制体系架构 - Google Patents

Abstract

提供了一种访问控制系统体系架构。在一种实施例中，该体系架构包括模块化和解耦的组件，这允许异构解决方案的可组合性。

Description

访问控制体系架构

权益要求

本申请根据美国法典第35章119(e)条要求于2011年5月11日提交的临时申请No.61/485,025的权益，该申请的全部内容通用引用而被结合于此，如同在本文进行了完全阐述一样。

技术领域

本发明总体上涉及安全计算，而且更一般地说涉及用于计算系统的访问控制。

背景技术

现代商业依赖于控制并生成对商业运作至关重要的信息的各种应用与系统。不同的应用常常提供不同的服务与信息，而且不同的用户可能需要访问每个系统或应用中不同级别的信息。用户被准许的访问级别可以依赖用户的角色。例如，一个经理可能需要访问关于向他汇报的员工的某些信息，但是让那个经理去访问关于他要向其汇报的那些人的相同信息可能就不合适了。

早期不太复杂的应用把访问控制业务逻辑直接结合到应用代码中。即，举例来说，每个应用将需要用户具有单独的帐号、单独的策略逻辑和单独的许可。此外，当用户被这些应用中的一个认证时，因为对第一个应用的认证已经发生的事实并没有被共享，所以这种认证对企业中的其它应用保持未知。因而，在利用不同系统进行认证和访问控制的应用之间没有信任的概念。工程师们很快就意识到在一个企业当中让每个应用都有一个访问控制系统就好像让每辆汽车都有一个加油站一样，并决定认证与访问控制应作为共享资源而被更有效地实现和管理。这些共享资源被称为访问控制系统。

访问控制系统常常使用策略和其它业务逻辑来作出关于对特定资源是否应当准许特定的访问请求的决定。一旦作出应当准许访问的决定，令牌就被提供给请求者。这个令牌就像是可以打开看守受限数据的一扇门的钥匙。例如，用户可以尝试访问人力资源数据库来收集关于某些员工的信息，诸如工资信息。用户的web浏览器对应用进行请求，这需要认证。如果web浏览器不具有令牌，则要求用户登录到访问控制系统中。当用户被认证时，用户的浏览器接收代表可以用于访问人力资源应用的令牌的cookie（小型文字档案）。

为了方便访问控制系统的增殖，这种系统的开发者创建了代理开发套件，以便允许应用开发者容易地创建能够代表应用与访问控制系统交互的代理。这些代理代表在应用侧所需的逻辑，而且，与直接把访问控制逻辑包括到应用中相比，应用集成并且使用这些代理需要更少的代码。但是，代理是特定于为其开发代理套件的访问控制系统的。因此，如果一个企业的架构师或工程师希望改变由特定应用使用的访问控制系统，则与该应用关联的代理也必须被代替，以便符合新的访问控制系统的要求。此外，访问控制系统可能具有不同的特征，使得，即使代理是兼容的，一个访问管理器也将不提供该企业中的应用所需的服务。所有这些都使访问控制系统“粘手”，这意味着要把应用从它们对一个访问控制系统的依赖性切换到另一个是非常困难的或者成本低效的。

作为访问控制系统粘手的结果，许多企业或者使用多个访问控制系统或者使用容易与已经被企业采用的访问控制系统集成的应用。因而，应用组织到“筒仓（silo）”中，而且许多应用不能利用由它们与之不兼容的访问控制系统提供的服务。在这种企业中，因为必须对每个访问控制系统执行集成，所以变得难以铺开（roll out）新的访问控制特征。此外，由于利用相同访问控制系统的应用之间的界限是用户不容易识别的，因此用户常常由于缺乏通用的集成而困惑。

在应用全都使用相同访问控制系统的情况下，出于维持现有的访问控制系统的期望，企业架构师常常被局限在他们对应用的选择中。因此，即使一个特定的应用提供卓越的特征，架构师常常也将选择与已经在该企业中部署的访问控制系统兼容或者容易与之集成的不同应用，从而为了保持一致性而牺牲卓越的特征。

目前的访问控制解决方案面临若干挑战，而且现有产品已经处于要演进以便无缝地支持新兴企业和互联网访问控制需求的压力之下。这种演进是有问题的，因为这些产品使用的设计对于为了适应新兴需求而进行扩展是不切实际的。因此，新特征的添加常常是经较新的产品组件获得的，这造成了破坏性和耗时的集成与实现过程。

当涉及保护企业资源和使得企业用户能够访问这些资源的时候，公司有自由围绕最适合他们需求的协议标准和实现模型来选择和标准化他们的解决方案。但是，当涉及外部网络时，存在适应和吸引代表变化的信任级别的不断扩大的基数的用户群体（例如，业务合作伙伴群体、企业客户和一般的公共互联网消费者）的商业动机，及关联的交互模型。

企业必须跨不同管理模型与问题域保护变化类型的资源。另一方面，企业中的用户常常需要跨许多这种域对资源进行访问。

被诸如SOX或M&A活动之类的法规遵从性倡议所驱动，企业访问控制用户需要从功能性产品筒仓过渡到整合各种传统堆栈的面向过程的环境，使得访问控制与控制可以一致的方式应用到所有IT资产。但是缺乏一致的整合体系架构和迁移框架常常造成不可逾越的实现挑战。

访问控制供应商传统上利用专用于具体问题域的个别产品来解决以上挑战。访问控制解决方案的常见元素，即，用于编码断言的令牌类型、所涉及各方之间的信任模型及线协议（wire protocol）标准，全部是固有地独立的问题。但是传统的产品趋于在这些元素之间产生紧耦合。

图1图示了为不同环境裁剪过的不同产品的例子，每个产品代表对该产品的目标环境而言典型的具体耦合。因为以上紧耦合，所以多个个别的产品需要粘合到一起，以便解决异构的问题域。这种粘合/桥接最终成为整个安全布置中最薄弱的环节，因为被桥接的个别产品在其安全性模型与设计模式方面是不兼容的。

这些独立的产品也常常基于独立的技术堆栈，从而混合了为客户部署集成解决方案的挑战。

附图说明

图1图示了为不同环境裁剪过的不同产品的例子；

图2图示了根据本发明一个实施例的访问控制模型；

图3绘出了根据本发明一个实施例的访问控制体系架构；

图4绘出了根据本发明一个实施例的使得能够通过分层以无缝的方式创作或组合（compose）不同的访问控制解决方案的访问控制体系架构；

图5图示了利用分层方法的访问控制体系架构的更一般化的图；

图6是图示出可以在其上实现一个实施例的访问控制系统的简化框图；

图7是图示出可以在其上实现一个实施例的访问控制系统的功能的流程图；

图8是图示出可以在其上实现一个实施例的访问控制系统的功能的流程图；

图9示出了可应用于访问控制产品的迁移模式的例子；

图10示出了可应用于访问控制产品的迁移模式的例子；

图11是图示出根据本发明一个实施例可以使用的系统环境的物理组件的简化框图；及

图12是可用于实践本发明一个实施例的计算机系统的简化框图。

具体实施例

在以下描述中，为了解释，阐述了具体的细节，以便提供对本发明实施例的透彻理解。但是，很显然，本发明没有这些具体细节也可以实践。

一般性概述

根据本发明的一个实施例，提供了能够解决以上提到的挑战的访问控制体系架构。在一种实施例中，代替用于不同问题域的独立解决方案筒仓，该体系架构包括模块化和解耦的组件，从而允许异构解决方案的可组合性。特别地，该体系架构使能对异构编程语言实现的技术堆栈的组合。

在一个实施例中，本文所述的访问控制体系架构使能对新兴技术的支持并随着技术的演进无缝地适应关联的新协议。在一个实施例中，使能可适配客户的部署环境的综合的和异构的解决方案。本文描述在同时且无缝地适应用于不同群体的变化的信任模型和供应模型的同时支持不同线协议的访问控制解决方案。

在一个实施例中，本文所述的访问控制体系架构使能能够跨越一个机构的所有数据与资产的集成的跨企业访问控制。在一个实施例中，提供了更好地跨企业管理安全性风险的集成的跨企业访问控制解决方案。在一个实施例中，可以在迁移时段期间使能传统技术的系统性迁移以及传统技术与新技术的整合控制。

在一个实施例中，一种访问元数据存储库维护描述与访问服务关联的数据的访问元数据对象的存储库。从发出请求的实体接收访问请求，并且确定与该访问请求关联的请求类型。生成规格化的请求，并且至少部分地基于该规格化的访问请求和与所述请求类型关联的访问元数据对象选择满足第一规格化的访问请求的至少一部分的第一功能组件。在一个实施例中，第一功能组件生成响应的至少一部分，该响应被提供给发出请求的实体。在一个实施例中，在响应被提供给发出请求的实体之前，响应被转换成特定于协议的响应。在一个实施例中，一种计算机可读的非易失性存储介质包括代码段，当该代码段加载到计算机系统的一个或多个计算机中时，使系统执行下述方法。在一个实施例中，一种访问控制系统包括：访问元数据对象的访问元数据存储库，其中，访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据；输入/输出部分，配置为从第一发出请求的实体接收第一访问请求；服务控制部分，配置为确定与第一访问请求关联的第一请求类型；规格化部分，配置为生成第一规格化的访问请求；及组件控制引擎，配置为至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中访问元数据存储库、输入/输出部分、服务控制部分、规格化部分和组件控制引擎在一个或多个计算设备上实现。在一个实施例中，组件控制引擎进一步配置为向第一功能组件提供第一规格化的访问请求的至少一部分，而且，组件控制引擎进一步配置为使第一功能组件生成符合与第一访问请求关联的第一请求类型的第一响应的至少一部分，而且服务控制部分进一步配置为向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，第一发出请求的实体是作为被信任应用的第一应用，第一访问请求包括对与第二应用关联的安全令牌的请求，而且生成响应的至少一部分包括生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌。在一个实施例中，输入/输出部分进一步配置为从第二发出请求的实体接收第二访问请求，其中第二访问请求包括对与身份提供商关联的安全令牌的请求，规格化部分进一步配置为生成第二规格化的访问请求，组件控制引擎进一步配置为使第一功能组件生成授权对第三应用进行访问的第二令牌，第一功能组件配置为响应于接收到第一规格化的请求的至少一部分而生成第一令牌，而且第一功能组件配置为响应于接收到第二规格化的请求的至少一部分而生成第二令牌。在一个实施例中，请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。在一个实施例中，该系统进一步包括配置为存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库，而且第二功能组件配置为响应于确定第一规格化的访问请求不满足由访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应。在一个实施例中，输入/输出部分进一步配置为从第二发出请求的实体接收第二访问请求，服务控制部分进一步配置为确定与第二访问请求关联的第二请求类型，规格化部分进一步配置为生成第二规格化的访问请求，组件控制引擎进一步配置为至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件，规格化部分进一步配置为向第一功能组件提供第二规格化的访问请求的至少一部分，而且组件控制引擎进一步配置为使第一功能组件生成符合与第二访问请求关联的第二请求类型的第二响应的至少一部分，而且服务控制部分进一步配置为向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，访问控制方法包括维护访问元数据对象的访问元数据存储库，其中，访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据，从第一发出请求的实体接收第一访问请求，确定与第一访问请求关联的第一请求类型，生成第一规格化的访问请求，至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中该方法由一个或多个计算设备执行。在一个实施例中，该方法进一步包括：向第一功能组件提供第一规格化的访问请求的至少一部分，利用第一功能组件生成第一响应的至少一部分，其中该第一响应符合与第一访问请求关联的第一请求类型，以及向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，第一发出请求的实体是作为被信任应用的第一应用，第一访问请求包括对与第二应用关联的安全令牌的请求，生成响应的至少一部分包括生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌。在一个实施例中，该方法进一步包括：从第二发出请求的实体接收第二访问请求，其中第二访问请求包括对与身份提供商关联的安全令牌的请求，生成第二规格化的访问请求，生成授权对第三应用进行访问的第二令牌，其中第一令牌是由令牌生成引擎响应于在该令牌生成引擎接收到第一规格化的请求的至少一部分而生成的，其中第二令牌是由该令牌生成引擎响应于在该令牌生成引擎接收到第二规格化的请求的至少一部分而生成的。在一个实施例中，请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。在一个实施例中，该方法进一步包括：维护存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库，响应于确定第一规格化的访问请求不满足由访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应。在一个实施例中，该方法进一步包括：从第二发出请求的实体接收第二访问请求，确定与第二访问请求关联的第二请求类型，生成第二规格化的访问请求，至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件，向第一功能组件提供第二规格化的访问请求的至少一部分，利用第一功能组件生成第二响应的至少一部分，该第二响应符合与第二访问请求关联的第二请求类型，并且向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，用于执行访问控制的系统包括用于维护访问元数据对象的访问元数据存储库的装置，其中访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据，用于从第一发出请求的实体接收第一访问请求的装置，用于确定于第一访问请求关联的第一请求类型的装置，用于生成第一规格化的访问请求的装置及用于至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件的装置。在一个实施例中，该系统进一步包括用于向第一功能组件提供第一规格化的访问请求的至少一部分的装置，用于利用第一功能组件生成第一响应的至少一部分的装置，该第一响应符合与第一访问请求关联的第一请求类型，及用于向第一发出请求的实体提供第一响应的至所述部分的装置。在一个实施例中，第一发出请求的实体是作为被信任应用的第一应用，第一访问请求包括对与第二应用关联的安全令牌的请求，而且用于生成响应的至少一部分的装置包括用于生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌的装置。在一个实施例中，该系统进一步包括用于从第二发出请求的实体接收第二访问请求的装置，其中第二访问请求包括对与身份提供商关联的安全令牌的请求，用于生成第二规格化的访问请求的装置和用于生成授权对第三应用进行访问的第二令牌的装置，其中第一令牌是由令牌生成引擎响应于在该令牌生成引擎接收到第一规格化的请求的至少一部分而生成的，其中第二令牌是由该令牌生成引擎响应于在该令牌生成引擎接收到第二规格化的请求的至少一部分而生成的。在一个实施例中，请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。在一个实施例中，该系统进一步包括用于维护存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库的装置，和用于响应于确定第一规格化的访问请求不满足由访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应的装置。在一个实施例中，该系统进一步包括用于从第二发出请求的实体接收第二访问请求的装置，用于确定与第二访问请求关联的第二请求类型的装置，用于生成第二规格化的访问请求的装置，用于至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件的装置，用于向第一功能组件提供第二规格化的访问请求的至少一部分的装置，用于利用第一功能组件生成第二响应的至少一部分的装置，该第二响应符合与第二访问请求关联的第二请求类型，及用于向第一发出请求的实体提供第一响应的至少所述部分的装置。

分层的访问控制体系架构

图2图示了根据本发明一个实施例的访问控制模型。图2中所绘的体系架构绘出了独特的多层体系架构，每一层包括一类构建块。在图2中所绘出的实施例中，构建块包括：身份解决方案210、协议外观（facade）220、令牌处理引擎230、信任模型240和共享的服务250。

在一个实施例中，分层模型基于以上构建块。编排控制器组件用于编排在使用这些构建块的层之间的消息，从而允许根据层之间的需求而适配于层之间可用的通信能力的层之间的通信，而不是具体组件之间的硬编码的通信。这有助于方便新能力与综合解决方案的系统化开发。

可以在一个实施例中使能代表单个规范化现实世界物理实体的集合的可扩展基础和把协议定义的实体映射到它们对应的规范化表示的机制。例如，外部策略引擎可以利用在一个实施例中描述的多层访问模型而通信耦合到访问控制系统的共享服务层，由此扩展由访问模型提供的所有服务的功能性。这种能力允许同一物理实体（诸如服务、应用客户端或用户）成为跨问题域和协议的综合解决方案的一部分。

在一个实施例中，以使广泛范围的能客户部署环境为目的，用于识别和打包可共享功能组件的模式可以按不同的形式因子（诸如嵌入式、分布式等）部署。此外，在实施例中，可以表征充分利用同一可组合体系架构的一组专用服务外观，其中这组服务外观的目的在于方便传统技术的共存与整合控制，而且同时允许传统到新技术的逐步迁移。

在一个实施例中，多层访问控制系统利用把信息类型与信息生命周期解耦的基础设施来使能要外化的跨访问控制的控制与实施的外化与共享，而且因此允许策略决策与会话基础设施被解耦/外化。这种设计元素方便跨问题域与行政管理边界的策略的一致控制与实施（对企业资源的web单点登录（SSO）、用于合作伙伴的ID联盟、ID传播及对web服务的委派访问，等等）。

目前的访问控制产品是基于“筒仓”方法，如图1中所示。参考图1，筒仓A110、筒仓B120、筒仓C130和筒仓D140都包括不可以更改的静态元素集合。例如，客户门户应用可以使用只利用OpenID来认证的访问控制解决方案，而且可以不利用除筒仓D140之外的任何筒仓的功能性。在图1中所绘出的方法中，每个产品基本上是一个孤岛。因此，跨不同筒仓以一致的方式定义、管理和实施安全性在实践当中是不可能的。这种分裂暴露了企业安全性盔甲中的缝隙，而且互联网不断增长的使用显著增加了企业IT资产被损害的可能。为了解决以上问题，所需要的是产品从功能性筒仓到能够组合的单元的过渡。这是通过一种新的体系架构实现的，这种体系架构方便现有解决方案的阶段式的过渡，同时基于新兴标准同时交付广泛的异构解决方案。

图3绘出了根据本发明一个实施例的访问控制体系架构。图3中所绘出的实施例提供了一种多协议、综合的服务器体系架构。在一个实施例中，构建块与分层模型结合使用，从而允许产品和综合解决方案以独立于任何具体语言、平台或技术的方式起作用。

在一个实施例中，图3中所示的功能性分层允许组合任何现有的访问控制（AC）产品（现有的和将来的），同时确保代码重用。协议绑定310代表把认证协议消息映射到标准消息传送与传输协议的逻辑。协议绑定310负责分别对协议响应和请求编组和解组。控制器320代表通过调用功能组件履行协议请求所需的核心业务逻辑编排。用于访问的共享服务（SSA）330代表要由所有AM产品使用的共享服务器功能性。它是由高级状态引擎（基础组件）和低级无状态引擎（基础API）组成的。控制从协议绑定层310传递到控制器320，再传递到SSA层330。

在一个实施例中，用于可共享功能性的识别与打包的模式使得这种功能性有可能以不同的形式因子获得，以便支持广泛的解决方案。这种体系架构关注层之间的接口与分层以及实现层的实体/模块。每个层都提供具体的一组功能性，其中较低的层提供由其上面的层使用的设施。在一个实施例中，这种分层的方法使独立于打包形式因子的功能性的组合能够建立综合的解决方案（例如，如图4中所示）。

实施例通过允许各个层中的不同实体/模块通过组合方便不同产品的建立（例如，如图4中所示）。因此，新的特征/功能性和可管理性可以递增的方式引入。

图4绘出了包括各种解决方案410、打包产品420、独立实体430、单点登录认证（SSA）和其它平台API、连接器与插件450的体系架构。该图解提供了由分层方法而不是“筒仓”方法为访问控制提供的灵活性的例子。

图5图示了利用分层方法的访问控制体系架构的更一般性的图。在一个实施例中，访问控制体系架构的组成部分包括五种类型的实体：服务实体510、协议绑定520、控制器530、集成的功能组件540和具有API的功能组件550。

服务实体510代表作为独立软件组件打包到一起的一组功能性实体。（一个或多个）服务实体能够由一个客户进行行政管理和管理。

协议绑定层520代表把认证协议消息映射到标准消息传送和传输协议的逻辑。协议绑定负责对协议响应与请求编组和解组。

在一个实施例中，协议绑定可以执行依赖字节的线序（wireodering）的安全性处理和线数据优化（例如，MTOM），而且不执行协议请求/响应的任何语义处理。协议绑定层520充分利用底层平台提供的传输与消息协议绑定设施，而且可以在诸如句柄、拦截器、插件和库API的编程结构中实现。

控制器530代表通过调用功能组件履行协议请求所需的核心业务逻辑编排。在一个实施例中，控制器层530与协议绑定层解耦，而且与传输绑定无关。控制器层包括通过调用功能组件（引擎）和基础API来处理请求的逻辑。在一个实施例中，特定于产品的业务逻辑在控制器层530被隔离，以便使功能组件能够保持不知道对于执行它们个别功能而言不必要的细节。因而，在一个实施例中，从控制器层530传递到功能组件层540和550的消息被规格化成只包括每个功能组件所需的信息。因而，独立于产品的/一般化的逻辑被推送到引擎/基础API，以促进跨各种访问控制组件的模块化与代码重用。

功能组件代表良好定义功能性的单元。每个功能组件是紧耦合的并且与其它功能组件逻辑上分离。在一个实施例中，组件到组件的通信仅通过公共接口被允许。功能组件具有用户可见的关联配置并且要作为服务实体层510中更大服务实体的一部分结合其它功能实体一起使用。一个组件可以分解成子组件，以方便模块化和并行开发。集成的功能组件540与具有API的功能组件550区别在于它们与系统的集成水平。例如，为了扩展访问控制系统的功能性，集成的功能组件可以访问与另一个功能组件关联的API。这说明了分层访问控制体系架构的可扩展本质。以下的“引擎”代表可以在一个实施例中实现的功能实体的例子：

认证引擎：认证引擎负责通过利用具体的认证协议收集并验证用户的凭证来确立用户的身份。用户与控制器（视图）交互，该控制器把认证逻辑（模型+控制器）委托给认证引擎。用于凭证收集的用户交互是由诸如控制器、代理和拦截器的协议/web/表现层组件执行的。

认证引擎包括对于以下必要的所有功能：以各种组合应用各种认证方案；支持包括那些模型所需策略与控制标志的认证模型；定制和扩展认证过程的所有方面，包括技术、规则和协议；及与代理层交互以便驱动凭证收集。

授权引擎：授权引擎负责利用规定的认证协议确立要求者身份的过程。用户交互是通过诸如NG-AM控制器、代理和拦截器的协议/web/表现层组件为凭证收集执行的。

在一个实施例中，授权引擎包括对以下必要的功能：以各种组合应用各种认证方案；支持包括策略与控制标志的JAAS认证模型；定制和扩展认证过程的所有方面，包括技术、规则和协议；及与代理层交互以便驱动凭证收集。

在一个实施例中，授权引擎支持现有方案。集中式和分布式的身份仓库在一个实施例中也被支持。在一个实施例中，授权引擎与不同的控制标志组合而支持每资源多认证方案，而且与诸如协议绑定和代理环境的凭证收集细节无关。在一个实施例中，授权引擎可以把授权服务委托给远端或外部授权服务。

在一个实施例中，授权引擎支持由另一个通过认证的用户（例如，管理员或者支持人员）扮演用户。在一个实施例中，授权引擎还能够支持用于凭证收集的多个代理交互模型。

在一个实施例中，授权引擎可以为所需的功能性充分利用其它引擎和/或基础API，所需的功能性诸如是会话持久性、令牌生成/验证，或者与系统关联的任何其它功能性。此外，在一个实施例中，授权引擎还支持认证策略和用例的迁移。

SSO引擎：SSO引擎负责向用户提供单点登录（SSO）体验。这意味着用户可以“登录”到一个应用并且使用那个令牌访问其它应用。这是通过管理用户会话生命周期来实现的，这涉及在有效用户会话中通过跨所有RP编排注销来方便全局注销。

在一个实施例中，SSO引擎支持注销编排与客户端状态处理。此外，SSO引擎提供对web代理的支持。例如，web代理可以用于“看守”对基于web的应用的访问。当对应用进行访问请求时，web代理拦截该请求，并且把该请求传递到访问控制系统。在请求被规格化之后，规格化的请求发送到SSO引擎，SSO引擎负责持久化并定位客户端会话状态。

在一个实施例中，SSO引擎支持会话索引、域范围和资源范围的信任模型及基于cookie的多域和多区SSO。在一个实施例中，SSO引擎为所需的功能性（例如，会话持久化、令牌生成）充分利用其它引擎和/或基础API。

联盟引擎：联盟引擎负责管理与合作伙伴的帐号链接及提供联盟会话控制服务。联盟引擎使用联盟协议来跨域使能基于标准的SSO。联盟引擎还在SSO环境中编排注销流。

在一个实施例中，联盟引擎支持多种联盟协议。联盟数据可以持久性地存储在诸如数据库系统或其它储存器的存储库中。在一个实施例中，联盟引擎支持各种认证机制，包括基于Infocard（信息卡）的认证。但是，其它特征与功能性也可以被外化。例如，在一个实施例中，可以外化安全性处理。

令牌引擎：令牌引擎负责为所有令牌管理整个令牌生命周期，包括安全令牌与凭证的生成、验证、取消和更新。它既包括本地的又包括利用用于外部操作的本地SSO桥的外部/委托操作。维护单个令牌控制引擎（而不是跨筒仓的多个令牌引擎）确保提高的安全性、可维护性和跨产品代码重复的消除。令牌引擎还包括用于跨协议/组件/服务器定位/解析与令牌关联的用户的安全令牌与凭证的功能性。在一个实施例中，令牌处理基础API负责处理凭证与令牌处理的机制或结构性方面。

在一个实施例中，令牌引擎包括用于任何给定令牌类型的多令牌生成、验证、取消和/或更新模块。此外，令牌引擎支持用户名、SAML和X.509（验证），而不需要与任何现有安全性产品/基础设施集成或者充分利用其，因为这些特征都包含在令牌引擎中了。在一个实施例中，令牌引擎支持让客户端提交证明令牌和其它身份证明数据作为输入的能力，而且还支持涉及多次交互的、像SPNEGO的挑战响应与协商协议。在实施例中，令牌引擎能够充分利用FIPS140-2密码模块用于密码处理，而且令牌引擎执行的任何X.509令牌处理都支持如NIST规定的联合处理规则。令牌引擎还公布元数据并且在运行时支持引擎功能性的动态发现。此外，令牌引擎能够被J2SE和J2EE客户端调用而且跨J2EE服务器是可移植的。还可以支持用于键入的令牌生命周期操作的可扩展插件模块。

在一个实施例中，令牌处理的结构性方面（构建）委托给令牌处理基础API。在一个实施例中，附加的定制令牌类型与定制的令牌处理也可以经令牌处理基础API获得。在一个实施例中，令牌的安全性处理被外化，而且可以为所需的功能性充分利用合作伙伴信任元数据引擎、其它引擎和/或基础API。

会话控制引擎：会话控制引擎负责管理用户会话和令牌上下文信息，支持用户/管理员启动的和基于超时的事件。会话控制引擎能够通过会话的使用编排全局封锁。会话控制引擎还负责管理：负责贯穿整个会话认证实体的令牌。用于维持会话的令牌的控制被称为令牌生命周期控制。会话控制引擎负责创建、更新和删除用户会话，跨协议/组件/服务器定位/解析与令牌关联的会话，并创建、更新和删除令牌上下文。

会话控制引擎可以在数据库或存储库中存储活动的会话。在一个实施例中，在会话到期之后，不活动的会话信息保持可用一段可配置的时间。例如，会话可以保持可用的时间可以经用户界面输入。

在实施例中，会话控制引擎还可以：能够关于具体的会话事件通知注册的监听者，支持存储器内和RDBMS会话持久性，支持分布式的存储器内会话持久性，通过用户名、GUID和用户名-提供商ID加索引，能够支持会话索引。

卡控制引擎：卡（包括iCard）使人能够组织他们的数字身份并选择他们想对任何给定交互使用的一个身份。卡控制引擎负责管理与CardSpace（卡空间）兼容的和其它卡类型的生命周期。这是支持以用户为中心的身份模型所需的关键功能性而且一有卡相关的协议消息就被IDP的控制器调用。

信任策略控制引擎：信任策略控制引擎基于这些策略使能信任策略信息和决策的控制和访问。信任策略控制引擎负责与交互中所涉及的对等实体的信任关系的控制。信任策略针对实体之间而不是用户之间的信任。例如，两个应用可以彼此建立信任关系，使那些应用能够彼此共享数据。

信任策略控制引擎包括对于以下必要的功能性：关于交互实体作出信任决定；管理信任关系；及把特定于协议的实体标识符解析/转换成规范表示。

合作伙伴元数据控制引擎：合作伙伴元数据控制引擎使能关于合作伙伴的元数据的控制与访问并且为了更好的控制与兼容而整合用于集中控制的元数据。一有管理员和协议操作就被调用。

在一个实施例中，合作伙伴元数据控制引擎包括对于创建、更新和选择元数据必要的功能。它还可以包括利用访问具体目标的具体协议定位/检索与合作伙伴交互所需的元数据的功能。合作伙伴元数据控制引擎维护用于所有合作伙伴信息的注册表，并且为了高性能而使用轻量级的存储机制。每个元数据对象是自描述的，而且因此合作伙伴元数据控制引擎可以存储符合元数据这方面所需的任何类型元数据。

本地SSO桥：本地SSO桥执行与和第三方SSO/策略服务的活动集成相关的功能，其中第三方SSO/策略服务采用特定于SSO策略服务的语义和复杂性。

基础API350代表可用于经API而不是经直接集成来使用访问控制系统的附加功能性。

结构性与功能性概述

图6是图示出一个实施例可以在其上实现的访问控制系统610的简化框图。在图6所示的实施例中，访问控制系统610是实体630、640、650、660和670的集合，每个实体都可以在诸如软件逻辑门、硬件逻辑门或者其任意组合的逻辑门中实现。在一个实施例中，访问控制系统610包括输入/输出（I/O）接口620。在另一个实施例中，I/O接口620不是访问控制系统610的一部分，但是耦合到访问控制系统610。I/O接口620可以配置为把访问控制系统610耦合到网络或者诸如键盘、鼠标或任何其它用户输入设备的用户输入设备。I/O接口620还可以配置为把访问控制系统610耦合到提供或拦截诸如输入612的信号或数据的其它设备或装置，包括网络、显示设备或者能够发送或显示输出614的传输介质设备。在一个实施例中，I/O接口620可以代表多个I/O接口。

在一个实施例中，输入612可以包括来自诸如应用680的web应用或者诸如代理690的代理的输入。代理690可以配置为拦截来自用户的访问请求，诸如从用户的web浏览器软件或其它软件或硬件发布的访问请求。这些请求可以按输入612的形式全部或部分地指向访问控制系统610。

在一个实施例中，访问控制系统610包括配置为从I/O接口620接收输入612的I/O部分630。I/O部分630可以配置为在非临时性介质诸如易失性或非易失性存储介质中存储输入612或者与输入612关联的信息。例如，I/O部分630可以包括日志记录逻辑。在一个实施例中，I/O部分630通信耦合到服务控制部分640、元数据存储库650、规格化部分660和组件控制引擎670。

在一个实施例中，访问控制系统610包括服务控制部分640。服务控制部分640管理与服务实体层510关联的服务实体。举例来说，这些服务实体可以包括监听特定类型请求的特定于协议的监听者。在一个实施例中，当服务实体接收到一个请求时，那个请求传递到规格化部分660。

在一个实施例中，访问控制系统610包括规格化部分660。规格化部分660实现了以上关于协议绑定层520所讨论的特征。在一个实施例中，规格化部分660从服务控制部分640接收特定于协议的请求。然后，规格化部分660通过向组件控制引擎只提供非特定于协议的信息来规格化请求。此外，规格化部分660可以把来自元数据存储库650的元数据提供给组件控制引擎670，以便响应于规格化请求而描述从组件控制引擎670预期的响应细节。如本文所使用的，术语“规格化的请求”是与规格化的请求所基于的原始请求不同的请求。在一个实施例中，元数据存储库650用于存储元数据和其它数据。

在一个实施例中，访问控制系统610包括组件控制引擎670。组件控制引擎670编排与进入的请求关联的所有活动的执行。具体而言，基于由规格化部分提供的信息，组件控制引擎确定满足一个请求需要哪些功能组件540和550，并且引导那些组件执行它们各自的功能。

示例配置元数据

在一个实施例中，规格化部分660向组件控制引擎670提供配置元数据。配置元数据与其它元数据可以被称为访问元数据对象。在一个实施例中，这种元数据存储在元数据存储库650或者其它有形的存储介质中。元数据的目的是为了向组件控制引擎670提供帮助组件控制引擎670履行和编排请求的细节。具体而言，每个元数据对象都可以代表一种特定类型的请求，并且包括到组件控制引擎670的、关于如何处理请求的指令，包括在协议绑定层520兑现（honor）请求应当使用哪些功能组件以及规格化部分660预期什么类型的响应。

虽然任何配置元数据格式或数据源都可以用于实现上述层之间的通信，但是以下XML代码代表在一个实施例中可以使用的一种样本配置方案：

使用这种配置方案的一个更具体例子如下：

要被该配置捕捉的信息比配置信息的形式更重要。换句话说，配置在如上所示的XML中实现不是太重要，而更重要的是在配置文件中捕捉到对组件控制引擎670具有指导性的足够信息。可以在实施例中捕捉的信息包括产品行为、产品绑定、产品后端集成及产品扩展。

产品行为的例子包括授权、元数据&信任模型信息，包括诸如Windows native auth/username/X.509/的授权信息和诸如debug/timeout/audit/throttling信息的其它常见功能性。产品绑定的例子包括诸如HTTP basic/digest、OAP（Oracle访问协议）/SAML/OpenID简单签名、Infocard/Higgins信息的安全性信息。绑定还可以包括诸如元数据、HTTP传输、消息编码或者其它类似信息的非安全性信息。产品后端集成信息可以包括关于用户数据仓库、合作伙伴信任、ID管理员与访问控制基础设施及审计、日志记录和监视信息的信息。产品扩展可以包括绑定、集成和行为扩展。

处理访问控制请求

图7是图示出在其上可以实现一个实施例的访问控制系统的功能的流程图。在步骤710，接收请求。例如，请求可以是来自诸如应用680的应用或者诸如代理690的代理的请求。请求可以包括用于认证、授权或者功能组件层540和550所支持的任何其它服务的请求。在一个实施例中，请求可以由访问控制系统610作为输入612经I/O接口620接收。例如，在一个实施例中，I/O接口620可以向I/O部分630提供该请求，以进行处理。

在步骤720，生成规格化的请求。例如，规格化部分660生成可以包括比原始请求更多、更少或不同信息的请求的变更版本。在一个实施例中，原始请求可以包括没有包括在规格化的请求中的特定于协议的信息。

在步骤730，选择满足规格化的请求的至少一部分的功能组件。例如，如果请求是对令牌的请求，则令牌引擎可以被组件控制引擎670选择，作为满足该请求的功能组件。在一个实施例中，如果请求需要来自其它功能组件的附加服务，则那些组件也可以被组件控制引擎670选择，参与到兑现请求。

图8是图示出可以在其上实现一个实施例的访问管理系统的更具体功能的流程图。这些具体功能与图7的步骤720与730关联。

在步骤810，由服务控制部分640作出接收到什么类型请求的确定。例如，请求可以是web SSO请求。在步骤820，基于请求类型生成规格化的请求。例如，规格化的请求可以包括web SSO请求的一部分，没有特定于协议的信息。在步骤830，连同来自元数据存储库650的、描述编排对请求的响应的生成所需的信息的元数据一起，规格化的请求被发送到组件控制引擎670。

在步骤840，在组件控制引擎670处从规格化部分660接收规格化的请求。请求可以包括或者可以不包括访问元数据。在一种实施例中，如果请求不包括访问元数据，则可以从元数据存储库650检索访问元数据。在步骤850，基于规格化的请求与访问元数据，选择满足规格化的请求的至少一部分的功能组件。在步骤860，选定的组件生成对规格化的请求的响应的至少一部分。

在一个实施例中，响应于规格化的请求而生成的响应由组件控制部分670提供给规格化部分660，然后，规格化部分660把完整的响应提供给服务控制部分640。在一个实施例中，完整的响应可以包括由不同功能组件生成的若干个部分响应。例如，响应可以包括认证与授权信息，连同令牌一起，这些全都是由不同的功能组件生成的。因为特定于协议的信息由组件控制引擎基于配置元数据提供，所以响应可以利用特定于预期协议的格式发送到发出请求的实体。

在一个实施例中，发出请求的实体可以是应用或者为应用执行服务的代理。例如，代理可以拦截某些类型的请求，诸如授权请求，并且通过与访问控制系统610通信来处理那些请求。请求可以是对将允许应用访问第二应用的令牌的请求。响应于该请求，令牌引擎可以生成授权第一应用代表第一应用的用户作出与第二应用关联的变化的令牌。

在一个实施例中，请求可以包括对与身份提供商关联的令牌的请求。规格化部分660生成规格化的访问请求，这请求被提供给组件控制引擎670，而组件控制引擎670选择满足该请求的令牌引擎。因而，用于为第一请求生成令牌的相同令牌引擎也用于为第二个、不同类型的请求生成令牌。

在一个实施例中，一些或者全部功能性引擎保持相同的状态。那个状态以令牌或者cookie的形式有时候或者在每次服务器被访问时提供给每个功能性引擎。例如，用户可以访问资源并且利用提供对该资源的访问的功能组件来确立cookie。当发生另一次访问时，cookie归还给访问控制系统610。在一个实施例中，多个功能性引擎可以与该相同状态信息（即，相同的cookie）的一部分关联。这种状态信息经历协议绑定层，然后发送到控制器。控制器向所有功能性引擎提供状态信息访问。在一个实施例中，请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。

在一个实施例中，访问策略存储库配置为存储用于确定是否应当准许访问请求的访问策略元数据。在一个实施例中，策略控制功能组件配置为响应于确定第一规格化的访问请求不满足访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应。例如，元数据可以规定与策略失败关联的错误消息。响应于确定请求不满足访问策略元数据规定的标准，可以返回这个错误消息。

访问控制系统中的策略实施

访问控制策略是指导决策并实现预期访问控制结果的一个慎重的动作计划。访问控制策略可应用于认证、授权与审计过程。认证策略用于确立请求者的身份，同时授权策略用于确定是否允许请求者对一个目标执行所请求的动作。

存在至少两种类型的策略实施。这些包括基于信息的策略实施和基于决策服务的策略实施。在基于信息的策略实施中，策略评估由实施点执行。此外，公布策略对象类型和方案，而且实施点对策略的结构与表示感兴趣并且知道它们。在基于决定的策略实施中，策略评估被策略实施点外包给决策服务。此外，实施点只对决策感兴趣，而对用于实施的策略的结构或表示不感兴趣或者不知道。

在一个实施例中，策略实施可以利用本文所述的分层方法在访问控制解决方案中实现。例如，在实施例中，策略引擎可以实现为集成的功能组件或者具有API的功能组件。在一个实施例中，与授权、风险、欺诈和信任经纪关联的策略决策是针对很多种信息访问与服务而构想得到的。在一个实施例中，因为插件友好的分层方法，所以任何策略都可以实现，但是已经具体考虑了以下这些：AuthN规则-凭证收集规则、链规则、强制AuthN；SSO–目的、范围、会话生命；I-card-类型、主张（claim）、数据处理；信任-发布者、接收方；联盟–帐号链接规则、简介支持、NameID选择；消息格式化–签名/加密的使用、编码与优化；审计与日志记录–级别到资源的映射；合作伙伴–元数据的使用；及安全令牌–发布/交换、令牌更新、取消、委托和扮演规则。

规范的迁移框架

以往的解决方案通过一个过程支持迁移，这个过程或者需要停机以便完全升级或者支持与广泛产品证明过程结合的共存特征以确保AM组件/产品的两个给定版本可以一起工作。证明过程不是可伸缩的，因为它非常耗时而且昂贵。作为关键系统，停机方法对于AM组件/产品是没有希望成功的。因而，需要一种新迁移体系架构来提供方便使能不同版本的AM组件/产品的共存的部署模型和设计模式，从而解决零停机需求。此外，隔离共存模块使得它们可以在不再需要的时候可以被除去/解除运行的能力是期望的。

更具体地说，在一种实施例中，提供了一种规范的迁移体系架构，该体系架构允许现有的和传统的访问控制解决方案以阶段性和最小破坏性的方式迁移。它还解除了客户端与服务器类型与版本彼此的耦合，由此在现有的部署中允许混合-n-匹配的传统的和较新的客户端和/或服务器。通过允许个别块/产品的点升级，保证现有体系架构将继续工作，这允许在访问控制产品的具体版本中客户的当前投资经得起考验（future-proofing）。

图9和图10示出了可应用于访问控制产品的两种迁移模式的例子。在一个实施例中，访问控制系统610方便AM部署的递增迁移，同时确保迁移过程中AM部署的可用性，因为AM部署的任何停机都会导致企业应用之间不可访问，所以这是极为必要的。

在图9中，客户想对传统应用的一个子集使用下一代SSO策略的表示。在一个实施例中，客户将需要利用策略数据迁移适配器把传统的策略迁移到新的NG-SSO/当前解决方案策略。传统策略服务器将把以上的策略处理经插件适配器委托给共存代理。例如，浏览器905可以连接到传统策略实施点910，以便请求对中继方920的访问。作为响应，传统策略实施点910和与共存代理950交互的协议适配器940通信。共存代理950访问NG-SSO服务器945。同时，传统策略935可以利用策略数据迁移适配器930迁移到NG-SSO服务器945。当NG-SSO策略实施点915与诸如中继方925的中继方关联时，交互可以直接与NG-SSO服务器945进行。对现有策略实施点的支持可以一直保持到迁移完成，以方便对NG-SSO服务器945的较小破坏性迁移。

在图10中，客户利用策略数据迁移适配器把传统策略迁移到NG-SSO策略。客户想继续使用传统PEP并且以递增的方式迁移到NG-SSO PEP。传统PEP现在经协议适配器与共存代理通信，其中协议适配器充当传统与NG-SSO服务器之间的协议桥。例如，浏览器1005可以连接到传统策略实施点1010，以便请求对中继方1020的访问。作为响应，传统策略实施点1010与策略服务器1030通信，然后策略服务器1030与插件适配器1035通信。插件适配器1035与共存代理1045交互，而且共存代理1045访问NG-SSO服务器1040。同时，传统策略可以利用策略数据迁移适配器1050从策略服务器1030迁移到NG-SSO服务器1040。当下一代单点登录策略实施点1015与诸如中继方1025的中继方关联时，可以直接与NG-SSO服务器1040进行交互。对现有策略实施点的支持可以一直保持到迁移完成，以方便对NG-SSO服务器1040的较小破坏性迁移。

本发明的一个实施例提供了能够支持多个访问控制产品的组合特征集合的单个产品。这种体系架构使得现有产品的覆盖范围是基于不同的中心、具有不兼容的体系架构而且是利用不同的语言和技术建立的。在一个实施例中，访问控制体系架构提高了可伸缩性与可维护性。有利地，所讨论的某些实施例提供了方便新能力与综合解决方案的系统开发的分层模型和编排控制器组件。有利地，本发明的某些实施例提供了代表单个规范现实世界物理实体集合的可扩展基础和把协议定义的实体映射到它们对应的规范表示的机制，由此允许相同的物理实体（例如服务、应用客户端或用户）成为跨问题域和协议的综合解决方案的一部分。有利地，某些实施例提供了用于识别和打包可以不同形式因子（诸如嵌入式、分布式等）部署的可共享功能组件的模式，由此使能广泛的客户部署环境。有利地，某些实施例提供了一组专用服务外观，充分利用相同的可组合体系架构、方便传统技术的共存与整合管理，同时允许传统到新技术的逐步迁移。有利地，某些实施例提供了一种基础设施，这种基础设施解除了信息类型与信息生命周期的耦合，以便使能跨要外化的访问控制系统的管理与实施的外化和共享，由此允许策略决策与会话基础设施解耦并外化。有利地，某些实施例方便策略跨问题域和行政管理边界的一致管理与实施（例如，用于企业资源的web SSO、用于合作伙伴的ID联盟、ID传播与对web服务的委托访问，等等）。

硬件概述

图11是图示出根据本发明一个实施例可以使用的系统环境1100的物理组成部分的简化框图。这个图仅仅是一个例子，它不应当过分限定权利要求的范围。本领域普通技术人员将认识到有许多变化、变更和修改。

如图所示，系统环境1100包括经网络1112与服务器计算机1110通信耦合的一个或多个客户端-计算设备1102、1104、1106、1108。在一组实施例中，客户端-计算设备1102、1104、1106、1108可以配置为运行上述图形界面的一个或多个组成部分。

客户端-计算设备1102、1104、1106、1108可以是通用个人计算机（包括例如运行各个版本Microsoft Windows和/或AppleMacintosh操作系统的个人计算机和/或膝上型计算机）、手机或PDA（运行诸如Microsoft Windows Mobile的软件，而且是使能互联网、电子邮件、SMS、Blackberry和/或其它通信协议的）和/或运行任意多种商业可用UNIX或像UNIX的操作系统（包括但不限于多种GNU/Linux操作系统）的工作站计算机。作为替代，客户端-计算设备1102、1104、1106、1108可以是能够经网络（例如，下述的网络1112）与服务器计算机1110通信的任何其它电子设备。虽然系统环境1100示为具有四个客户端计算设备和一个服务器计算机，但是任意数量的客户端计算设备和服务器计算机都可以支持。

服务器计算机1110可以是通用计算机、专用服务器计算机（包括例如LINUX服务器、UNIX服务器、中程服务器、大型机、机架式服务器等）、服务器场、服务器群集或者任何其它适当的布置和/或组合。服务器计算机1110可以运行包括以上任意所讨论的那些的操作系统，及任何商业可用的服务器操作系统。服务器计算机1110还可以运行多种服务器应用和/或中间层应用中任何一者，包括web服务器、Java虚拟机、应用服务器、数据库服务器等。在各种实施例中，服务器计算机1110适于运行提供上述诊断功能性的一个或多个web服务或软件应用。例如，服务器计算机1110可以配置为执行在上述各个流程图中所描述的各种方法。

如所示出的，客户端-计算设备1102、1104、1106、1108和服务器计算机1110经网络1112通信耦合。网络1112可以是可以利用任何多种商业可用的协议（包括但不限于TCP/IP、SNA、IPX、AppleTalk等）来支持数据通信的任何类型网络。仅仅是作为例子，网络1112可以是局域网（LAN），诸如以太网、令牌环网等；广域网；虚拟网络，包括但不限于虚拟专用网（VPN）；互联网；内联网；外联网；公共交换电话网络（PSTN）；红外线网络；无线网络（例如，在任何IEEE802.11协议套件、本领域已知的蓝牙协议和/或任何其它无线协议下运行的网络）；和/或这些和/或其它网络的任意组合。在各种实施例中，客户端-计算设备1102、1104、1106、1108和服务器计算机1110能够通过网络1112访问数据库1114。在某些实施例中，客户端-计算设备1102、1104、1106、1108和服务器计算机1110每个都具有其自己的数据库。

系统环境1100还可以包括一个或多个数据库1114。数据库1114可以对应于本公开内容中描述过的集成存储库的实例及任何其它类型的数据库或数据存储组件。数据库1114可以驻留在多个位置。作为例子，数据库1114可以驻留在计算机1102、1104、1106、1108、1110中一个本地（和/或驻留在其中）的存储介质上。作为替代，数据库1114可以远离计算机1102、1104、1106、1108、1110中的任何一个或全部和/或与这些计算机中的一个或多个（例如，经网络1112）通信。在一组实施例中，数据库1114可以驻留在本领域技术人员熟悉的存储区域网络（SAN）中。类似地，根据需要，用于执行归因于计算机1102、1104、1106、1108、1110的功能的任何必要文件都可以本地存储在各自的计算机上和/或远端存储在数据库1114上。在一组实施例中，数据库1114是关系数据库，诸如可以从Oracle公司获得的Oracle11g，该数据库适于响应于SQL格式化命令而存储和检索数据。在各种实施例中，数据库1114存储用于提供如上所述诊断能力的数据。

图12是可以用于实践本发明一个实施例的计算机系统的简化框图。计算机系统1200可以充当图1中所绘出的处理系统102。在各种实施例中，计算机系统1200可以用于实现上述系统环境1100中说明的任何计算机1102、1104、1106、1108、1110。如图12中所示，计算机系统1200包括经总线子系统1204与多个外围子系统通信的处理器1202。这些外围子系统可以包括存储子系统1206，包括存储器子系统1208和文件存储子系统1210、用户接口输入设备1212、用户接口输出设备1214和网络接口子系统1216。

总线子系统1204提供用于让计算机系统1200的各种组件与子系统如预期的那样彼此通信的机制。虽然总线子系统1204示意性地示为单根总线，但是总线子系统的备选实施例可以利用多根总线。

网络接口子系统1216提供到其它计算机系统、网络和门户网站的接口。网络接口子系统1216充当用于从计算机系统1200接收数据和把数据发送到其它系统的接口。

用户接口输入设备1212可以包括键盘，诸如鼠标、轨迹球、触垫或图形平板、扫描仪、条形码扫描仪、结合到显示器中的触摸屏的点选设备，诸如语音识别系统、麦克风的语音输入设备及其它类型的输入设备。总的来说，术语“输入设备”的使用是要包括用于把信息输入到计算机系统1200中的所有可能类型的设备与机制。

用户接口输出设备1214可以包括显示子系统、打印机、传真机或者诸如音频输出设备的非可见显示等。显示子系统可以是阴极射线管（CRT）、诸如液晶显示器（LCD）的平板设备或者投影设备。总的来说，术语“输出设备”的使用是要包括用于从计算机系统1200输出信息的所有可能类型的设备与机制。

存储子系统1206提供非临时性的计算机可读存储介质，用于存储提供本发明功能性的基本编程与数据结构。当被处理器执行时提供本发明功能性的软件（程序、代码模块、指令）可以存储在存储子系统1206中。这些软件模块或指令可以由处理器1202执行。存储子系统1206还可以提供用于存储根据本发明使用的数据的存储库。存储子系统1206可以包括内存子系统1208和文件/盘存储子系统1210。

内存子系统1208可以包括多种存储器，包括用于在程序执行过程中存储指令与数据的主随机存取存储器（RAM）1218和其中存储固定指令的只读存储器（ROM）1220。文件存储子系统1210为程序和数据文件提供持久性（非易失性）存储，而且可以包括硬盘驱动器、软盘驱动器连同关联的可拆卸介质、光盘只读存储器（CD-ROM）驱动器、光驱、可拆卸介质盒及其它类似的存储介质。

计算机系统1200可以是各种类型，包括个人计算机、便携式计算机、工作站、网络计算机、大型机、信息站、服务器或者任何其它数据处理系统。由于计算机与网络不断变化的本质，图12中所绘出的计算机系统1200的描述仅仅是要作为用于说明计算机系统优选实施例的一个具体例子。具有比图12中所绘出的系统更多或更少组件的许多其它配置也是可能的。

Claims (27)

1.一种访问控制系统，包括：

访问元数据对象的访问元数据存储库，其中该访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据；

输入/输出部分，配置为从第一发出请求的实体接收第一访问请求；

服务控制部分，配置为确定与第一访问请求关联的第一请求类型；

规格化部分，配置为生成第一规格化的访问请求；及

组件控制引擎，配置为至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件；

其中访问元数据存储库、输入/输出部分、服务控制部分、规格化部分和组件控制引擎是在一个或多个计算设备上实现的。

2.如权利要求1所述的系统，其中：

组件控制引擎进一步配置为向第一功能组件提供第一规格化的访问请求的至少一部分；及

组件控制引擎进一步配置为使第一功能组件生成符合与第一访问请求关联的第一请求类型的第一响应的至少一部分；及

服务控制部分进一步配置为向第一发出请求的实体提供第一响应的至少所述部分。

3.如权利要求1-2中任何一项所述的系统，其中：

第一发出请求的实体是作为被信任应用的第一应用；

第一访问请求包括对与第二应用关联的安全令牌的请求；及

生成响应的至少一部分包括生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌。

4.如权利要求3所述的系统，其中：

输入/输出部分进一步配置为从第二发出请求的实体接收第二访问请求，其中第二访问请求包括对与身份提供商关联的安全令牌的请求；

规格化部分进一步配置为生成第二规格化的访问请求；

组件控制引擎进一步配置为使第一功能组件生成授权对第三应用进行访问的第二令牌；

其中第一功能组件配置为响应于接收到第一规格化的请求的至少一部分而生成第一令牌；及

其中第一功能组件配置为响应于接收到第二规格化的请求的至少一部分而生成第二令牌。

5.如权利要求1-4中任何一项所述的系统，其中请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。

6.如权利要求1-5中任何一项所述的系统，进一步包括：

访问策略存储库，配置为存储用于确定是否应当准许访问请求的访问策略元数据；

第二功能组件，配置为响应于确定第一规格化的访问请求不满足访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应。

7.如权利要求1-6中任何一项所述的系统，其中：

输入/输出部分进一步配置为从第二发出请求的实体接收第二访问请求；

服务控制部分进一步配置为确定与第二访问请求关联的第二请求类型；

规格化部分进一步配置为生成第二规格化的访问请求；

组件控制引擎进一步配置为至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件；

规格化部分进一步配置为向第一功能组件提供第二规格化的访问请求的至少一部分；及

组件控制引擎进一步配置为使第一功能组件生成符合与第二访问请求关联的第二请求类型的第二响应的至少一部分；及

服务控制部分进一步配置为向第一发出请求的实体提供第一响应的至少所述部分。

8.一种访问控制方法，包括：

维护访问元数据对象的访问元数据存储库，其中访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据；

从第一发出请求的实体接收第一访问请求；

确定与第一访问请求关联的第一请求类型；

生成第一规格化的访问请求；

至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象，选择满足第一规格化访问请求的至少一部分的第一功能组件；

其中该方法是由一个或多个计算设备执行的。

9.如权利要求8所述的方法，进一步包括：

向第一功能组件提供第一规格化的访问请求的至少一部分；

利用第一功能组件生成第一响应的至少一部分，第一响应符合与第一访问请求关联的第一请求类型；及

向第一发出请求的实体提供第一响应的至少所述部分。

10.如权利要求8-9中任何一项所述的方法，其中：

第一发出请求的实体是作为被信任应用的第一应用；

第一访问请求包括对与第二应用关联的安全令牌的请求；

生成响应的至少一部分包括生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌。

11.如权利要求10所述的方法，进一步包括：

从第二发出请求的实体接收第二访问请求，其中第二访问请求包括对与身份提供商关联的安全令牌的请求；

生成第二规格化的访问请求；

生成授权对第三应用进行访问的第二令牌；

其中第一令牌是由令牌生成引擎响应于在该令牌生成引擎接收到第一规格化的请求的至少一部分而生成的；

其中第二令牌是由该令牌生成引擎响应于在该令牌生成引擎接收到第二规格化的请求的至少一部分而生成的。

12.如权利要求8-11中任何一项所述的方法，其中请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。

13.如权利要求8-12中任何一项所述的方法，进一步包括：

维护存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库；

响应于确定第一规格化的访问请求不满足由访问策略元数据规定的标准，生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应。

14.如权利要求8-13中任何一项所述的方法，进一步包括：

从第二发出请求的实体接收第二访问请求；

确定与第二访问请求关联的第二请求类型；

生成第二规格化的访问请求；

至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象，选择满足第二规格化的访问请求的至少一部分的第一功能组件；

向第一功能组件提供第二规格化的访问请求的至少一部分；

利用第一功能组件生成第二响应的至少一部分，第二响应符合与第二访问请求关联的第二请求类型；及

向第一发出请求的实体提供第一响应的至少所述部分。

15.一种用于执行访问控制的系统，包括：

用于维护访问元数据对象的访问元数据存储库的装置，其中访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据；

用于从第一发出请求的实体接收第一访问请求的装置；

用于确定与第一访问请求关联的第一请求类型的装置；

用于生成第一规格化的访问请求的装置；及

用于至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件的装置。

16.如权利要求15所述的系统，进一步包括：

用于向第一功能组件提供第一规格化的访问请求的至少一部分的装置；

用于利用第一功能组件生成第一响应的至少一部分的装置，其中第一响应符合与第一访问请求关联的第一请求类型；及

用于向第一发出请求的实体提供第一响应的至少所述部分的装置。

17.如权利要求15-16中任何一项所述的系统，其中：

第一发出请求的实体是作为被信任应用的第一应用;

第一访问请求包括对与第二应用关联的安全令牌的请求；及

用于生成响应的至少一部分的装置包括用于生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌的装置。

18.如权利要求17所述的系统，进一步包括：

用于从第二发出请求的实体接收第二访问请求的装置，其中第二访问请求包括对与身份提供商关联的安全令牌的请求；

用于生成第二规格化的访问请求的装置；

用于生成授权对第三应用进行访问的第二令牌的装置；

其中第一令牌是由令牌生成引擎响应于在该令牌生成引擎接收到第一规格化的请求的至少一部分而生成的；

其中第二令牌是由该令牌生成引擎响应于在该令牌生成引擎接收到第二规格化的请求的至少一部分而生成的。

19.如权利要求15-18中任何一项所述的系统，其中请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。

20.如权利要求15-19中任何一项所述的系统，进一步包括：

用于维护存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库的装置；

用于响应于确定第一规格化访问请求不满足由访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应的装置。

21.如权利要求15-20中任何一项所述的系统，进一步包括：

用于从第二发出请求的实体接收第二访问请求的装置；

用于确定与第二访问请求关联的第二请求类型的装置；

用于生成第二规格化的访问请求的装置；

用于至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件的装置；

用于向第一功能组件提供第二规格化的访问请求的至少一部分的装置；

用于利用第一功能组件生成第二响应的至少一部分的装置，第二响应符合与第二访问请求关联的第二请求类型；及

用于向第一发出请求的实体提供第一响应的至少所述部分的装置。

22.一种存储可以由一个或多个处理器执行的多条指令的计算机可读非易失性存储介质，当这多条指令被处理器执行时，执行权利要求8-14中任何一项所述的方法。

23.一种包括代码段的计算机可读非易失性存储介质，当代码段加载到计算机系统的一个或多个计算机中时，使该系统执行权利要求8-14中任何一项所述的方法。

24.一种系统，包括：

存储访问元数据对象的存储设备，其中存储设备中的多个访问元数据对象中的每个访问元数据对象都描述对应于访问服务的数据；及

计算设备，该计算设备

从第一客户端接收第一访问请求，

确定第一访问请求的第一请求类型，

生成第一规格化的访问请求，及

至少部分地基于第一规格化的访问请求和存储在存储设备中并且对应于第一请求类型的访问元数据对象，选择满足第一规格化的访问请求的至少一部分的第一功能组件。

25.一种方法，包括：

由计算设备从第一客户端接收第一访问请求；

由计算设备确定第一访问请求的第一请求类型；

由计算设备生成第一规格化的访问请求；及

至少部分地基于第一规格化的访问请求和存储在存储设备中并且对应于第一请求类型的访问元数据对象，由计算设备选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中存储设备中的多个访问元数据对象中的每个访问元数据对象都描述对应于访问服务的数据。

26.一种存储指令的计算机可读非易失性存储介质，使处理器：

从第一客户端接收第一访问请求，

确定第一访问请求的第一请求类型，

生成第一规格化的访问请求，及

至少部分地基于第一规格化的访问请求和存储在存储设备中并且对应于第一请求类型的访问元数据对象，选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中存储设备中的多个访问元数据对象中的每个访问元数据对象都描述对应于访问服务的数据。

27.一种程序，使处理器：

从第一客户端接收第一访问请求，

确定第一访问请求的第一请求类型，

生成第一规格化的访问请求，及

至少部分地基于第一规格化的访问请求和存储在存储设备中并且对应于第一请求类型的访问元数据对象，选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中存储设备中的多个访问元数据对象中的每个访问元数据对象都描述对应于访问服务的数据。

Images