访问控制体系架构的制作方法
【专利摘要】提供了一种访问控制系统体系架构。在一种实施例中，该体系架构包括模块化和解耦的组件，这允许异构解决方案的可组合性。
【专利说明】访问控制体系架构
[0001]权益要求
[0002]本申请根据美国法典第35章119(e)条要求于2011年5月11日提交的临时申请N0.61/485, 025的权益，该申请的全部内容通用引用而被结合于此，如同在本文进行了完全
阐述一样。
【技术领域】
[0003]本发明总体上涉及安全计算，而且更一般地说涉及用于计算系统的访问控制。
【背景技术】
[0004]现代商业依赖于控制并生成对商业运作至关重要的信息的各种应用与系统。不同的应用常常提供不同的服务与信息，而且不同的用户可能需要访问每个系统或应用中不同级别的信息。用户被准许的访问级别可以依赖用户的角色。例如，一个经理可能需要访问关于向他汇报的员工的某些信息，但是让那个经理去访问关于他要向其汇报的那些人的相同信息可能就不合适了。
[0005]早期不太复杂的应用把访问控制业务逻辑直接结合到应用代码中。即，举例来说，每个应用将需要用户具有单独的帐号、单独的策略逻辑和单独的许可。此外，当用户被这些应用中的一个认证时，因为对第一个应用的认证已经发生的事实并没有被共享，所以这种认证对企业中的其它应用保持未知。因而，在利用不同系统进行认证和访问控制的应用之间没有信任的概念。工程师们很快就意识到在一个企业当中让每个应用都有一个访问控制系统就好像让每辆汽车都有一个加油站一样，并决定认证与访问控制应作为共享资源而被更有效地实现和管理。这些共享资源被称为访问控制系统。
[0006]访问控制系统常常使用策略和其它业务逻辑来作出关于对特定资源是否应当准许特定的访问请求的决定。一旦作出应当准许访问的决定，令牌就被提供给请求者。这个令牌就像是可以打开看守受限数据的一扇门的钥匙。例如，用户可以尝试访问人力资源数据库来收集关于某些员工的信息，诸如工资信息。用户的web浏览器对应用进行请求，这需要认证。如果web浏览器不具有令牌，则要求用户登录到访问控制系统中。当用户被认证时，用户的浏览器接收代表可以用于访问人力资源应用的令牌的cookie (小型文字档案)。
[0007]为了方便访问控制系统的增殖，这种系统的开发者创建了代理开发套件，以便允许应用开发者容易地创建能够代表应用与访问控制系统交互的代理。这些代理代表在应用侧所需的逻辑，而且，与直接把访问控制逻辑包括到应用中相比，应用集成并且使用这些代理需要更少的代码。但是，代理是特定于为其开发代理套件的访问控制系统的。因此，如果一个企业的架构师或工程师希望改变由特定应用使用的访问控制系统，则与该应用关联的代理也必须被代替，以便符合新的访问控制系统的要求。此外，访问控制系统可能具有不同的特征，使得，即使代理是兼容的，一个访问管理器也将不提供该企业中的应用所需的服务。所有这些都使访问控制系统“粘手”，这意味着要把应用从它们对一个访问控制系统的依赖性切换到另一个是非常困难的或者成本低效的。[0008]作为访问控制系统粘手的结果，许多企业或者使用多个访问控制系统或者使用容易与已经被企业采用的访问控制系统集成的应用。因而，应用组织到“筒仓(silo)”中，而且许多应用不能利用由它们与之不兼容的访问控制系统提供的服务。在这种企业中，因为必须对每个访问控制系统执行集成，所以变得难以铺开(roll out)新的访问控制特征。此夕卜，由于利用相同访问控制系统的应用之间的界限是用户不容易识别的，因此用户常常由于缺乏通用的集成而困惑。
[0009]在应用全都使用相同访问控制系统的情况下，出于维持现有的访问控制系统的期望，企业架构师常常被局限在他们对应用的选择中。因此，即使一个特定的应用提供卓越的特征，架构师常常也将选择与已经在该企业中部署的访问控制系统兼容或者容易与之集成的不同应用，从而为了保持一致性而牺牲卓越的特征。
[0010]目前的访问控制解决方案面临若干挑战，而且现有产品已经处于要演进以便无缝地支持新兴企业和互联网访问控制需求的压力之下。这种演进是有问题的，因为这些产品使用的设计对于为了适应新兴需求而进行扩展是不切实际的。因此，新特征的添加常常是经较新的产品组件获得的，这造成了破坏性和耗时的集成与实现过程。
[0011]当涉及保护企业资源和使得企业用户能够访问这些资源的时候，公司有自由围绕最适合他们需求的协议标准和实现模型来选择和标准化他们的解决方案。但是，当涉及外部网络时，存在适应和吸引代表变化的信任级别的不断扩大的基数的用户群体(例如，业务合作伙伴群体、企业客户和一般的公共互联网消费者)的商业动机，及关联的交互模型。
[0012]企业必须跨不同管理模型与问题域保护变化类型的资源。另一方面，企业中的用户常常需要跨许多这种域对资源进行访问。
[0013]被诸如SOX或M&A活动之类的法规遵从性倡议所驱动，企业访问控制用户需要从功能性产品筒仓过渡到整合各种传统堆栈的面向过程的环境，使得访问控制与控制可以一致的方式应用到所有IT资产。但是缺乏一致的整合体系架构和迁移框架常常造成不可逾越的实现挑战。
[0014]访问控制供应商传统上利用专用于具体问题域的个别产品来解决以上挑战。访问控制解决方案的常见元素，即，用于编码断言的令牌类型、所涉及各方之间的信任模型及线协议(wire protocol)标准，全部是固有地独立的问题。但是传统的产品趋于在这些元素之间产生紧耦合。
[0015]图1图示了为不同环境裁剪过的不同产品的例子，每个产品代表对该产品的目标环境而言典型的具体耦合。因为以上紧耦合，所以多个个别的产品需要粘合到一起，以便解决异构的问题域。这种粘合/桥接最终成为整个安全布置中最薄弱的环节，因为被桥接的个别产品在其安全性模型与设计模式方面是不兼容的。
[0016]这些独立的产品也常常基于独立的技术堆栈，从而混合了为客户部署集成解决方案的挑战。
【专利附图】
【附图说明】
[0017]图1图示了为不同环境裁剪过的不同产品的例子；
[0018]图2图示了根据本发明一个实施例的访问控制模型；
[0019]图3绘出了根据本发明一个实施例的访问控制体系架构；[0020]图4绘出了根据本发明一个实施例的使得能够通过分层以无缝的方式创作或组合(compose)不同的访问控制解决方案的访问控制体系架构；
[0021]图5图示了利用分层方法的访问控制体系架构的更一般化的图；
[0022]图6是图示出可以在其上实现一个实施例的访问控制系统的简化框图；
[0023]图7是图示出可以在其上实现一个实施例的访问控制系统的功能的流程图；
[0024]图8是图示出可以在其上实现一个实施例的访问控制系统的功能的流程图；
[0025]图9示出了可应用于访问控制产品的迁移模式的例子；
[0026]图10示出了可应用于访问控制产品的迁移模式的例子；
[0027]图11是图示出根据本发明一个实施例可以使用的系统环境的物理组件的简化框图；及
[0028]图12是可用于实践本发明一个实施例的计算机系统的简化框图。
具体实施例
[0029]在以下描述中，为了解释，阐述了具体的细节，以便提供对本发明实施例的透彻理解。但是，很显然，本发明没有这些具体细节也可以实践。
[0030]一般件概沭
[0031]根据本发明的一个实施例，提供了能够解决以上提到的挑战的访问控制体系架构。在一种实施例中，代替用于不同问题域的独立解决方案筒仓，该体系架构包括模块化和解耦的组件，从而允许异构解决方案的可组合性。特别地，该体系架构使能对异构编程语言实现的技术堆栈的组合。
[0032]在一个实施例中，本文所述的访问控制体系架构使能对新兴技术的支持并随着技术的演进无缝地适应关联的新协议。在一个实施例中，使能可适配客户的部署环境的综合的和异构的解决方案。本文描述在同时且无缝地适应用于不同群体的变化的信任模型和供应模型的同时支持不同线协议的访问控制解决方案。
[0033]在一个实施例中，本文所述的访问控制体系架构使能能够跨越一个机构的所有数据与资产的集成的跨企业访问控制。在一个实施例中，提供了更好地跨企业管理安全性风险的集成的跨企业访问控制解决方案。在一个实施例中，可以在迁移时段期间使能传统技术的系统性迁移以及传统技术与新技术的整合控制。
[0034]在一个实施例中，一种访问元数据存储库维护描述与访问服务关联的数据的访问元数据对象的存储库。从发出请求的实体接收访问请求，并且确定与该访问请求关联的请求类型。生成规格化的请求,并且至少部分地基于该规格化的访问请求和与所述请求类型关联的访问元数据对象选择满足第一规格化的访问请求的至少一部分的第一功能组件。在一个实施例中，第一功能组件生成响应的至少一部分，该响应被提供给发出请求的实体。在一个实施例中，在响应被提供给发出请求的实体之前，响应被转换成特定于协议的响应。在一个实施例中，一种计算机可读的非易失性存储介质包括代码段，当该代码段加载到计算机系统的一个或多个计算机中时，使系统执行下述方法。在一个实施例中，一种访问控制系统包括:访问元数据对象的访问元数据存储库，其中，访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据；输入/输出部分，配置为从第一发出请求的实体接收第一访问请求；服务控制部分，配置为确定与第一访问请求关联的第一请求类型；规格化部分，配置为生成第一规格化的访问请求；及组件控制引擎，配置为至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中访问元数据存储库、输入/输出部分、服务控制部分、规格化部分和组件控制引擎在一个或多个计算设备上实现。在一个实施例中，组件控制引擎进一步配置为向第一功能组件提供第一规格化的访问请求的至少一部分，而且，组件控制引擎进一步配置为使第一功能组件生成符合与第一访问请求关联的第一请求类型的第一响应的至少一部分，而且服务控制部分进一步配置为向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，第一发出请求的实体是作为被信任应用的第一应用，第一访问请求包括对与第二应用关联的安全令牌的请求，而且生成响应的至少一部分包括生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌。在一个实施例中，输入/输出部分进一步配置为从第二发出请求的实体接收第二访问请求，其中第二访问请求包括对与身份提供商关联的安全令牌的请求，规格化部分进一步配置为生成第二规格化的访问请求，组件控制引擎进一步配置为使第一功能组件生成授权对第三应用进行访问的第二令牌，第一功能组件配置为响应于接收到第一规格化的请求的至少一部分而生成第一令牌，而且第一功能组件配置为响应于接收到第二规格化的请求的至少一部分而生成第二令牌。在一个实施例中，请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。在一个实施例中，该系统进一步包括配置为存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库，而且第二功能组件配置为响应于确定第一规格化的访问请求不满足由访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应。在一个实施例中，输入/输出部分进一步配置为从第二发出请求的实体接收第二访问请求，服务控制部分进一步配置为确定与第二访问请求关联的第二请求类型，规格化部分进一步配置为生成第二规格化的访问请求，组件控制引擎进一步配置为至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件，规格化部分进一步配置为向第一功能组件提供第二规格化的访问请求的至少一部分，而且组件控制引擎进一步配置为使第一功能组件生成符合与第二访问请求关联的第二请求类型的第二响应的至少一部分，而且服务控制部分进一步配置为向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，访问控制方法包括维护访问元数据对象的访问元数据存储库，其中，访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据，从第一发出请求的实体接收第一访问请求，确定与第一访问请求关联的第一请求类型，生成第一规格化的访问请求，至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中该方法由一个或多个计算设备执行。在一个实施例中，该方法进一步包括:向第一功能组件提供第一规格化的访问请求的至少一部分，利用第一功能组件生成第一响应的至少一部分，其中该第一响应符合与第一访问请求关联的第一请求类型，以及向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，第一发出请求的实体是作为被信任应用的第一应用，第一访问请求包括对与第二应用关联的安全令牌的请求，生成响应的至少一部分包括生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌。在一个实施例中，该方法进一步包括:从第二发出请求的实体接收第二访问请求，其中第二访问请求包括对与身份提供商关联的安全令牌的请求，生成第二规格化的访问请求，生成授权对第三应用进行访问的第二令牌，其中第一令牌是由令牌生成引擎响应于在该令牌生成引擎接收到第一规格化的请求的至少一部分而生成的，其中第二令牌是由该令牌生成引擎响应于在该令牌生成引擎接收到第二规格化的请求的至少一部分而生成的。在一个实施例中，请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。在一个实施例中，该方法进一步包括:维护存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库，响应于确定第一规格化的访问请求不满足由访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应。在一个实施例中，该方法进一步包括:从第二发出请求的实体接收第二访问请求，确定与第二访问请求关联的第二请求类型，生成第二规格化的访问请求，至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件，向第一功能组件提供第二规格化的访问请求的至少一部分，利用第一功能组件生成第二响应的至少一部分，该第二响应符合与第二访问请求关联的第二请求类型，并且向第一发出请求的实体提供第一响应的至少所述部分。在一个实施例中，用于执行访问控制的系统包括用于维护访问元数据对象的访问元数据存储库的装置，其中访问元数据存储库中的多个访问元数据对象中的每个访问元数据对象都描述与访问服务关联的数据，用于从第一发出请求的实体接收第一访问请求的装置，用于确定于第一访问请求关联的第一请求类型的装置，用于生成第一规格化的访问请求的装置及用于至少部分地基于第一规格化的访问请求和与第一请求类型关联的访问元数据对象来选择满足第一规格化的访问请求的至少一部分的第一功能组件的装置。在一个实施例中，该系统进一步包括用于向第一功能组件提供第一规格化的访问请求的至少一部分的装置，用于利用第一功能组件生成第一响应的至少一部分的装置，该第一响应符合与第一访问请求关联的第一请求类型，及用于向第一发出请求的实体提供第一响应的至所述部分的装置。在一个实施例中，第一发出请求的实体是作为被信任应用的第一应用，第一访问请求包括对与第二应用关联的安全令牌的请求，而且用于生成响应的至少一部分的装置包括用于生成授权第一应用代表第一应用的用户作出与第二应用关联的改变的第一令牌的装置。在一个实施例中，该系统进一步包括用于从第二发出请求的实体接收第二访问请求的装置，其中第二访问请求包括对与身份提供商关联的安全令牌的请求，用于生成第二规格化的访问请求的装置和用于生成授权对第三应用进行访问的第二令牌的装置，其中第一令牌是由令牌生成引擎响应于在该令牌生成引擎接收到第一规格化的请求的至少一部分而生成的，其中第二令牌是由该令牌生成引擎响应于在该令牌生成引擎接收到第二规格化的请求的至少一部分而生成的。在一个实施例中，请求包括识别与第一功能组件关联的状态和与第二功能组件关联的状态的综合状态信息。在一个实施例中，该系统进一步包括用于维护存储用于确定是否应当准许访问请求的访问策略元数据的访问策略存储库的装置，和用于响应于确定第一规格化的访问请求不满足由访问策略元数据规定的标准而生成对第一发出请求的实体的包括与访问策略元数据关联的信息的响应的装置。在一个实施例中，该系统进一步包括用于从第二发出请求的实体接收第二访问请求的装置，用于确定与第二访问请求关联的第二请求类型的装置，用于生成第二规格化的访问请求的装置，用于至少部分地基于第二规格化的访问请求和与第二请求类型关联的访问元数据对象来选择满足第二规格化的访问请求的至少一部分的第一功能组件的装置，用于向第一功能组件提供第二规格化的访问请求的至少一部分的装置，用于利用第一功能组件生成第二响应的至少一部分的装置，该第二响应符合与第二访问请求关联的第二请求类型，及用于向第一发出请求的实体提供第一响应的至少所述部分的装置。
[0035]分层的访问控制体系架构
[0036]图2图示了根据本发明一个实施例的访问控制模型。图2中所绘的体系架构绘出了独特的多层体系架构，每一层包括一类构建块。在图2中所绘出的实施例中，构建块包括:身份解决方案210、协议外观(facade) 220、令牌处理引擎230、信任模型240和共享的服务250。
[0037]在一个实施例中，分层模型基于以上构建块。编排控制器组件用于编排在使用这些构建块的层之间的消息，从而允许根据层之间的需求而适配于层之间可用的通信能力的层之间的通信，而不是具体组件之间的硬编码的通信。这有助于方便新能力与综合解决方案的系统化开发。
[0038]可以在一个实施例中使能代表单个规范化现实世界物理实体的集合的可扩展基础和把协议定义的实体映射到它们对应的规范化表示的机制。例如，外部策略引擎可以利用在一个实施例中描述的多层访问模型而通信耦合到访问控制系统的共享服务层，由此扩展由访问模型提供的所有服务的功能性。这种能力允许同一物理实体(诸如服务、应用客户端或用户)成为跨问题域和协议的综合解决方案的一部分。
[0039]在一个实施例中，以使广泛范围的能客户部署环境为目的，用于识别和打包可共享功能组件的模式可以按不同的形式因子(诸如嵌入式、分布式等)部署。此外，在实施例中，可以表征充分利用同一可组合体系架构的一组专用服务外观，其中这组服务外观的目的在于方便传统技术的共存与整合控制，而且同时允许传统到新技术的逐步迁移。
[0040]在一个实施例中，多层访问控制系统利用把信息类型与信息生命周期解耦的基础设施来使能要外化的跨访问控制的控制与实施的外化与共享，而且因此允许策略决策与会话基础设施被解耦/外化。这种设计元素方便跨问题域与行政管理边界的策略的一致控制与实施(对企业资源的web单点登录(SSO)、用于合作伙伴的ID联盟、ID传播及对web服务的委派访问，等等)。
[0041]目前的访问控制产品是基于“筒仓”方法，如图1中所示。参考图1，筒仓A110、筒仓B120、筒仓C130和筒仓D140都包括不可以更改的静态元素集合。例如，客户门户应用可以使用只利用OpenID来认证的访问控制解决方案，而且可以不利用除筒仓D140之外的任何筒仓的功能性。在图1中所绘出的方法中，每个产品基本上是一个孤岛。因此，跨不同筒仓以一致的方式定义、管理和实施安全性在实践当中是不可能的。这种分裂暴露了企业安全性盔甲中的缝隙，而且互联网不断增长的使用显著增加了企业IT资产被损害的可能。为了解决以上问题，所需要的是产品从功能性筒仓到能够组合的单元的过渡。这是通过一种新的体系架构实现的，这种体系架构方便现有解决方案的阶段式的过渡，同时基于新兴标准同时交付广泛的异构解决方案。
[0042]图3绘出了根据本发明一个实施例的访问控制体系架构。图3中所绘出的实施例提供了一种多协议、综合的服务器体系架构。在一个实施例中，构建块与分层模型结合使用，从而允许产品和综合解决方案以独立于任何具体语言、平台或技术的方式起作用。
[0043]在一个实施例中，图3中所示的功能性分层允许组合任何现有的访问控制(AC)产品(现有的和将来的)，同时确保代码重用。协议绑定310代表把认证协议消息映射到标准消息传送与传输协议的逻辑。协议绑定310负责分别对协议响应和请求编组和解组。控制器320代表通过调用功能组件履行协议请求所需的核心业务逻辑编排。用于访问的共享服务(SSA) 330代表要由所有AM产品使用的共享服务器功能性。它是由高级状态引擎(基础组件)和低级无状态引擎(基础API)组成的。控制从协议绑定层310传递到控制器320，再传递到SSA层330。
[0044]在一个实施例中，用于可共享功能性的识别与打包的模式使得这种功能性有可能以不同的形式因子获得，以便支持广泛的解决方案。这种体系架构关注层之间的接口与分层以及实现层的实体/模块。每个层都提供具体的一组功能性，其中较低的层提供由其上面的层使用的设施。在一个实施例中，这种分层的方法使独立于打包形式因子的功能性的组合能够建立综合的解决方案(例如，如图4中所示)。
[0045]实施例通过允许各个层中的不同实体/模块通过组合方便不同产品的建立(例如，如图4中所示)。因此，新的特征/功能性和可管理性可以递增的方式引入。
[0046]图4绘出了包括各种解决方案410、打包产品420、独立实体430、单点登录认证(SSA)和其它平台AP1、连接器与插件450的体系架构。该图解提供了由分层方法而不是“筒仓”方法为访问控制提供的灵活性的例子。
[0047]图5图示了利用分层方法的访问控制体系架构的更一般性的图。在一个实施例中，访问控制体系架构的组成部分包括五种类型的实体:服务实体510、协议绑定520、控制器530、集成的功能组件540和具有API的功能组件550。
[0048]服务实体510代表作为独立软件组件打包到一起的一组功能性实体。(一个或多个)服务实体能够由一个客户进行行政管理和管理。
[0049]协议绑定层520代表把认证协议消息映射到标准消息传送和传输协议的逻辑。协议绑定负责对协议响应与请求编组和解组。
[0050]在一个实施例中，协议绑定可以执行依赖字节的线序(wire odering)的安全性处理和线数据优化(例如，ΜΤ0Μ)，而且不执行协议请求/响应的任何语义处理。协议绑定层520充分利用底层平台提供的传输与消息协议绑定设施，而且可以在诸如句柄、拦截器、插件和库API的编程结构中实现。
[0051]控制器530代表通过调用功能组件履行协议请求所需的核心业务逻辑编排。在一个实施例中，控制器层530与协议绑定层解耦，而且与传输绑定无关。控制器层包括通过调用功能组件(引擎)和基础API来处理请求的逻辑。在一个实施例中，特定于产品的业务逻辑在控制器层530被隔离，以便使功能组件能够保持不知道对于执行它们个别功能而言不必要的细节。因而，在一个实施例中，从控制器层530传递到功能组件层540和550的消息被规格化成只包括每个功能组件所需的信息。因而，独立于产品的/一般化的逻辑被推送到引擎/基础API，以促进跨各种访问控制组件的模块化与代码重用。
[0052]功能组件代表良好定义功能性的单元。每个功能组件是紧耦合的并且与其它功能组件逻辑上分离。在一个实施例中，组件到组件的通信仅通过公共接口被允许。功能组件具有用户可见的关联配置并且要作为服务实体层510中更大服务实体的一部分结合其它功能实体一起使用。一个组件可以分解成子组件，以方便模块化和并行开发。集成的功能组件540与具有API的功能组件550区别在于它们与系统的集成水平。例如，为了扩展访问控制系统的功能性，集成的功能组件可以访问与另一个功能组件关联的API。这说明了分层访问控制体系架构的可扩展本质。以下的“引擎”代表可以在一个实施例中实现的功能实体的例子:
[0053]认证引擎:认证引擎负靑通过利用具体的认证协议收集并验证用户的凭证来确立用户的身份。用户与控制器(视图)交互，该控制器把认证逻辑(模型+控制器)委托给认证引擎。用于凭证收集的用户交互是由诸如控制器、代理和拦截器的协议/web/表现层组件执行的。
[0054]认证引擎包括对于以下必要的所有功能:以各种组合应用各种认证方案；支持包括那些模型所需策略与控制标志的认证模型；定制和扩展认证过程的所有方面，包括技术、规则和协议；及与代理层交互以便驱动凭证收集。
[0055]授权引擎:授权引擎负责利用规定的认证协议确立要求者身份的过程。用户交互是通过诸如NG-AM控制器、代理和拦截器的协议/web/表现层组件为凭证收集执行的。
[0056]在一个实施例中，授权引擎包括对以下必要的功能:以各种组合应用各种认证方案；支持包括策略与控制标志的JAAS认证模型；定制和扩展认证过程的所有方面，包括技术、规则和协议；及与代理层交互以便驱动凭证收集。
[0057]在一个实施例中，授权引擎支持现有方案。集中式和分布式的身份仓库在一个实施例中也被支持。在一个实施例中，授权引擎与不同的控制标志组合而支持每资源多认证方案，而且与诸如协议绑定和代理环境的凭证收集细节无关。在一个实施例中，授权引擎可以把授权服务委托给远端或外部授权服务。
[0058]在一个实施例中，授权引擎支持由另一个通过认证的用户(例如，管理员或者支持人员)扮演用户。在一个实施例中，授权引擎还能够支持用于凭证收集的多个代理交互模型。
[0059]在一个实施例中，授权引擎可以为所需的功能性充分利用其它引擎和/或基础API，所需的功能性诸如是会话持久性、令牌生成/验证，或者与系统关联的任何其它功能性。此外，在一个实施例中，授权引擎还支持认证策略和用例的迁移。
[0060]SSO引擎=SSO引擎负责向用户提供单点登录(SSO)体验。这意味着用户可以“登录”到一个应用并且使用那个令牌访问其它应用。这是通过管理用户会话生命周期来实现的，这涉及在有效用户会话中通过跨所有RP编排注销来方便全局注销。
[0061]在一个实施例中，SSO引擎支持注销编排与客户端状态处理。此外，SSO引擎提供对web代理的支持。例如，web代理可以用于“看守”对基于web的应用的访问。当对应用进行访问请求时，web代理拦截该请求，并且把该请求传递到访问控制系统。在请求被规格化之后，规格化的请求发送到SSO引擎，SSO引擎负责持久化并定位客户端会话状态。
[0062]在一个实施例中，SSO引擎支持会话索引、域范围和资源范围的信任模型及基于cookie的多域和多区SS0。在一个实施例中，SSO引擎为所需的功能性(例如，会话持久化、令牌生成)充分利用其它引擎和/或基础API。
[0063]联盟引擎:联盟引擎负责管理与合作伙伴的帐号链接及提供联盟会话控制服务。联盟引擎使用联盟协议来跨域使能基于标准的SS0。联盟引擎还在SSO环境中编排注销流。[0064]在一个实施例中，联盟引擎支持多种联盟协议。联盟数据可以持久性地存储在诸如数据库系统或其它储存器的存储库中。在一个实施例中，联盟引擎支持各种认证机制，包括基于Infocard (信息卡)的认证。但是，其它特征与功能性也可以被外化。例如，在一个实施例中，可以外化安全性处理。
[0065]令牌引擎:令牌引擎负责为所有令牌管理整个令牌生命周期，包括安全令牌与凭证的生成、验证、取消和更新。它既包括本地的又包括利用用于外部操作的本地SSO桥的外部/委托操作。维护单个令牌控制引擎(而不是跨筒仓的多个令牌引擎)确保提高的安全性、可维护性和跨产品代码重复的消除。令牌引擎还包括用于跨协议/组件/服务器定位/解析与令牌关联的用户的安全令牌与凭证的功能性。在一个实施例中，令牌处理基础API负责处理凭证与令牌处理的机制或结构性方面。
[0066]在一个实施例中，令牌引擎包括用于任何给定令牌类型的多令牌生成、验证、取消和/或更新模块。此外，令牌引擎支持用户名、SAML和X.509 (验证)，而不需要与任何现有安全性产品/基础设施集成或者充分利用其，因为这些特征都包含在令牌引擎中了。在一个实施例中，令牌引擎支持让客户端提交证明令牌和其它身份证明数据作为输入的能力，而且还支持涉及多次交互的、像SPNEGO的挑战响应与协商协议。在实施例中，令牌引擎能够充分利用FIPS140-2密码模块用于密码处理，而且令牌引擎执行的任何X.509令牌处理都支持如NIST规定的联合处理规则。令牌引擎还公布元数据并且在运行时支持引擎功能性的动态发现。此外，令牌引擎能够被J2SE和J2EE客户端调用而且跨J2EE服务器是可移植的。还可以支持用于键入的令牌生命周期操作的可扩展插件模块。
[0067]在一个实施例中，令牌处理的结构性方面(构建)委托给令牌处理基础API。在一个实施例中，附加的定制令牌类型与定制的令牌处理也可以经令牌处理基础API获得。在一个实施例中，令牌的安全性处理被外化，而且可以为所需的功能性充分利用合作伙伴信任元数据引擎、其它引擎和/或基础API。
[0068]会话控制引擎:会话控制引擎负责管理用户会话和令牌上下文信息，支持用户/管理员启动的和基于超时的事件。会话控制引擎能够通过会话的使用编排全局封锁。会话控制引擎还负责管理:负责贯穿整个会话认证实体的令牌。用于维持会话的令牌的控制被称为令牌生命周期控制。会话控制引擎负责创建、更新和删除用户会话，跨协议/组件/服务器定位/解析与令牌关联的会话，并创建、更新和删除令牌上下文。
[0069]会话控制引擎可以在数据库或存储库中存储活动的会话。在一个实施例中，在会话到期之后，不活动的会话信息保持可用一段可配置的时间。例如，会话可以保持可用的时间可以经用户界面输入。
[0070]在实施例中，会话控制引擎还可以:能够关于具体的会话事件通知注册的监听者，支持存储器内和RDBMS会话持久性，支持分布式的存储器内会话持久性，通过用户名、GUID和用户名-提供商ID加索引，能够支持会话索引。
[0071]卡控制引擎:卡(包括iCard)使人能够组织他们的数字身份并选择他们想对任何给定交互使用的一个身份。卡控制引擎负责管理与CardSpace (卡空间)兼容的和其它卡类型的生命周期。这是支持以用户为中心的身份模型所需的关键功能性而且一有卡相关的协议消息就被IDP的控制器调用。
[0072]信任策略控制引擎:信任策略控制引擎基于这些策略使能信任策略信息和决策的控制和访问。信任策略控制引擎负责与交互中所涉及的对等实体的信任关系的控制。信任策略针对实体之间而不是用户之间的信任。例如，两个应用可以彼此建立信任关系，使那些应用能够彼此共享数据。
[0073]信任策略控制引擎包括对于以下必要的功能性:关于交互实体作出信任决定；管理信任关系；及把特定于协议的实体标识符解析/转换成规范表示。
[0074]合作伙伴元数据控制引擎:合作伙伴元数据控制引擎使能关于合作伙伴的元数据的控制与访问并且为了更好的控制与兼容而整合用于集中控制的元数据。一有管理员和协议操作就被调用。
[0075]在一个实施例中，合作伙伴元数据控制引擎包括对于创建、更新和选择元数据必要的功能。它还可以包括利用访问具体目标的具体协议定位/检索与合作伙伴交互所需的元数据的功能。合作伙伴元数据控制引擎维护用于所有合作伙伴信息的注册表，并且为了高性能而使用轻量级的存储机制。每个元数据对象是自描述的，而且因此合作伙伴元数据控制引擎可以存储符合元数据这方面所需的任何类型元数据。
[0076]本地SSO桥:本地SSO桥执行与和第三方SSO/策略服务的活动集成相关的功能，其中第三方SSO/策略服务采用特定于SSO策略服务的语义和复杂性。
[0077]基础API350代表可用于经API而不是经直接集成来使用访问控制系统的附加功能性。
[0078]结构性与功能性概述
[0079]图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接口。
[0080]在一个实施例中，输入612可以包括来自诸如应用680的web应用或者诸如代理690的代理的输入。代理690可以配置为拦截来自用户的访问请求，诸如从用户的web浏览器软件或其它软件或硬件发布的访问请求。这些请求可以按输入612的形式全部或部分地指向访问控制系统610。
[0081]在一个实施例中，访问控制系统610包括配置为从I/O接口 620接收输入612的I/O部分630。I/O部分630可以配置为在非临时性介质诸如易失性或非易失性存储介质中存储输入612或者与输入612关联的信息。例如，I/O部分630可以包括日志记录逻辑。在一个实施例中，I/O部分630通信耦合到服务控制部分640、元数据存储库650、规格化部分660和组件控制引擎670。
[0082]在一个实施例中，访问控制系统610包括服务控制部分640。服务控制部分640管理与服务实体层510关联的服务实体。举例来说，这些服务实体可以包括监听特定类型请求的特定于协议的监听者。在一个实施例中，当服务实体接收到一个请求时，那个请求传递到规格化部分660。
[0083]在一个实施例中，访问控制系统610包括规格化部分660。规格化部分660实现了以上关于协议绑定层520所讨论的特征。在一个实施例中，规格化部分660从服务控制部分640接收特定于协议的请求。然后，规格化部分660通过向组件控制引擎只提供非特定于协议的信息来规格化请求。此外，规格化部分660可以把来自元数据存储库650的元数据提供给组件控制引擎670，以便响应于规格化请求而描述从组件控制引擎670预期的响应细节。如本文所使用的，术语“规格化的请求”是与规格化的请求所基于的原始请求不同的请求。在一个实施例中，元数据存储库650用于存储元数据和其它数据。
[0084]在一个实施例中，访问控制系统610包括组件控制引擎670。组件控制引擎670编排与进入的请求关联的所有活动的执行。具体而言，基于由规格化部分提供的信息，组件控制引擎确定满足一个请求需要哪些功能组件540和550，并且引导那些组件执行它们各自的功能。
[0085]示例配置元数据
[0086]在一个实施例中，规格化部分660向组件控制引擎670提供配置元数据。配置元数据与其它元数据可以被称为访问元数据对象。在一个实施例中，这种元数据存储在元数据存储库650或者其它有形的存储介质中。元数据的目的是为了向组件控制引擎670提供帮助组件控制引擎670履行和编排请求的细节。具体而言，每个元数据对象都可以代表一种特定类型的请求，并且包括到组件控制引擎670的、关于如何处理请求的指令，包括在协议绑定层520兑现(honor)请求应当使用哪些功能组件以及规格化部分660预期什么类型的响应。
[0087]虽然任何配置元数据格式或数据源都可以用于实现上述层之间的通信，但是以下XML代码代表在一个实施例中可以使用的一种样本配置方案:
[0088]
【权利要求】
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.一种程序，使处理器: 从第一客户端接收第一访问请求， 确定第一访问请求的第一请求类型， 生成第一规格化的访问请求，及 至少部分地基于第一规格化的访问请求和存储在存储设备中并且对应于第一请求类型的访问元数据对象，选择满足第一规格化的访问请求的至少一部分的第一功能组件，其中存储设备中的多个访问元数据对象中的每个访问元数据对象都描述对应于访问服务的数据。
【文档编号】G06F21/62GK103620615SQ201280029065
【公开日】2014年3月5日 申请日期:2012年5月11日 优先权日:2011年5月11日
【发明者】U·丝瑞尼瓦萨, V·莫图库图, R·R·S·特拉帕提 申请人:甲骨文国际公司