多租户身份云服务的本地写入的制作方法

相关申请的交叉引用本申请要求于2018年4月4日提交的美国临时专利申请序列no.62/652,509的优先权，该申请的公开内容通过引用并入本文。一个实施例一般涉及身份管理，尤其涉及云系统中的身份管理。
背景技术：
：一般而言，基于云的应用(例如，企业公共云应用、第三方云应用等等)的使用正在飞速发展，其中访问来自各种设备(例如，桌面和移动设备)以及各种用户(例如，员工、合作伙伴、客户等等)。基于云的应用的丰富多样性和可访问性已经导致身份管理和访问安全性成为中心问题。云环境中的典型安全问题是未经授权的访问、账户劫持、恶意的内部人员等等。因而，需要安全地访问基于云的应用或位于任何地方的应用，而不管应用被何种设备类型或何种用户类型访问。技术实现要素：实施例在多租户云系统中执行写入操作，该多租户云系统包括：第一数据中心，适于认证第一多个注册客户端并位于第一地理区域；以及第二数据中心，适于认证第二多个注册客户端并位于与第一地理区域不同的第二地理区域。第二数据中心处的实施例从第一多个注册客户端中的第一客户端接收对在第二数据中心处针对资源执行第一写入的请求。第二数据中心处的实施例生成对第一数据中心的调用，该调用包括在第一数据中心处针对该资源的第二写入，第二写入包括特殊报头。第二数据中心处的实施例检索与第一写入对应的数据并将检索到的数据发送到第一数据中心。第一数据中心处的实施例基于第一写入对数据进行写入，对数据进行写入包括改变数据以生成改变的数据。附图说明图1-图5是提供基于云的身份管理的示例实施例的框图。图6是提供实施例的系统视图的框图。图6a是提供实施例的功能视图的框图。图7是实现云门的实施例的框图。图8图示了在一个实施例中实现多个租户的示例系统。图9是实施例的网络视图的框图。图10是一个实施例中的单点登录(“sso”)功能的系统架构视图的框图。图11是一个实施例中的sso功能的消息序列流。图12图示了一个实施例中的分布式数据网格的实例。图13图示了根据本发明的实施例的具有多个部署的数据中心(指定为“dc”)的公共云，每个数据中心形成“区域”。图14图示了根据本发明的实施例的具有附加json“元数据”列的数据库表。图15是根据实施例的用于使用基于多租户云的系统将资源从主身份云账户复制到分开区域中的远程数据中心中的复制云账户的功能的流程图。具体实施方式实施例允许租户对副本身份账户执行本地写入，而不必首先在主身份账户处执行写入。实施例使用全局签名密钥。本地写入允许以最小时延来实现副本账户处的更改，并且特别适合于需要立即生效的功能，诸如密码更改。实施例提供实现基于微服务的架构的身份云服务，并提供多租户身份和数据安全性管理以及对基于云的应用的安全访问。实施例支持对于混合云部署的安全访问(即，包括公共云和私有云的组合的云部署)。实施例保护云中和内部部署(on-premise)的应用和数据。实施例支持经由web、移动和应用编程接口(“api”)的多信道访问。实施例管理对于不同用户(诸如客户、合作伙伴和员工)的访问。实施例管理、控制和审计跨整个云以及内部部署的访问。实施例与新的和现有的应用和身份集成。实施例是水平可伸缩的。一个实施例是在无状态中间层环境中实现多个微服务以提供基于云的多租户身份和访问管理服务的系统。在一个实施例中，每个被请求的身份管理服务被分解成实时任务和近实时任务。实时任务由中间层中的微服务处理，而近实时任务被卸载到消息队列。实施例实现由路由层和中间层消耗以强制实施用于访问微服务的安全模型的访问令牌。因而，实施例提供基于多租户、微服务架构的云规模的身份和访问管理(“iam”)平台。一个实施例提供了使得组织能够为其新业务计划迅速开发快速、可靠和安全的服务的身份云服务。在一个实施例中，身份云服务提供多个核心服务，每个核心服务解决许多企业面临的独特挑战。在一个实施例中，身份云服务在以下方面支持管理员，例如，初始登入(on-boarding)/导入用户、导入具有用户成员的组、创建/更新/禁用/启用/删除用户、向/从组中分配/取消分配用户、创建/更新/删除组、重置密码、管理策略、发送激活等等。身份云服务还在以下方面支持最终用户，例如，修改简档、设置主要/恢复电子邮件、核实电子邮件、解锁其账户、更改密码、忘记密码时恢复密码等等。访问的统一安全性一个实施例保护云环境中以及内部部署环境中的应用和数据。该实施例保护任何人从任何设备对任何应用的访问。由于两个环境之间的安全性不一致会导致较高的风险，因此该实施例提供跨两种环境的保护。例如，这种不一致会使销售人员即使在已经叛逃到竞争对手之后仍能继续访问其客户关系管理(“crm”)账户。因而，实施例将在内部部署环境中提供的安全性控制扩展到云环境中。例如，如果一个人离开公司，那么实施例确保他们的账户在内部部署和云中都被禁用。一般而言，用户可以通过许多不同的渠道(诸如web浏览器、台式机、移动电话、平板电脑、智能手表、其它可穿戴设备等等)来访问应用和/或数据。因而，一个实施例提供跨所有这些渠道的安全访问。例如，用户可以使用他们的移动电话完成他们在台式机上开始的事务。一个实施例还管理对于各种用户(诸如客户、合作伙伴、员工等等)的访问。一般而言，应用和/或数据不仅可以由员工访问，而且可以由客户或第三方访问。虽然许多已知的系统在员工登入时采取安全措施，但是在向客户、第三方、合作伙伴等等给予访问时一般不采取相同级别的安全措施，从而导致由未妥善管理的各方造成的安全漏洞的可能。但是，实施例确保为每种类型的用户的访问而不仅仅是员工的访问提供足够的安全措施。身份云服务实施例提供了作为多租户、云规模的iam平台的身份云服务(“idcs”)。idcs提供认证、授权、审计和联合。idcs管理对公共云上以及内部部署系统上运行的自定义应用和服务的访问。在替代或附加的实施例中，idcs还可以管理对公共云服务的访问。例如，可以使用idcs在这样各种服务/应用/系统中提供单点登录(“sso”)功能。实施例基于用于设计、构建和递送云规模的软件服务的多租户、微服务架构。多租户是指让服务的一个物理实现安全地支持多个客户购买那个服务。服务是可以被不同客户端用于不同的目的的软件功能或软件功能集合(诸如检索指定的信息或执行一组操作)，以及控制该软件功能或该软件功能集合的使用的策略(例如，基于请求服务的客户端的身份)。在一个实施例中，服务是使得能够访问一个或多个能力的机制，其中访问是使用规定的接口提供的并且与由服务描述指定的约束和策略一致地被实施(exercised)。在一个实施例中，微服务是独立可部署的服务。在一个实施例中，术语微服务设想了一种软件架构设计模式，其中复杂应用由使用语言不可知的api彼此通信的小型独立进程组成。在一个实施例中，微服务是小的、高度解耦的服务，并且每个微服务可以专注于做一个小任务。在一个实施例中，微服务架构样式是将单个应用开发为一套小服务的做法，每个小服务在其自己的进程中运行并与轻量级机制(例如，http资源api)通信。在一个实施例中，相对于执行全部或许多相同功能的单件式服务，微服务更容易更换。而且，每个微服务可以被更新而不会对其它微服务产生不利影响。相比之下，对单件式服务的一部分的更新会不期望地或无意地对单件服务的其它部分产生负面影响。在一个实施例中，微服务可以围绕其能力被有益地组织。在一个实施例中，微服务集合中的每一个微服务的启动时间远小于笼统执行那些微服务的所有服务的单个应用的启动时间。在一些实施例中，这种微服务中的每一个微服务的启动时间是大约一秒或更少，而这种单个应用的启动时间可以是大约一分钟、几分钟或更长。在一个实施例中，微服务架构是指用于面向服务的架构(“soa”)的专业化(即，系统内任务的分离)和实现做法，以构建灵活的、独立可部署的软件系统。微服务架构中的服务是经网络彼此通信以便履行目标的进程。在一个实施例中，这些服务使用技术不可知的协议。在一个实施例中，服务具有小粒度并使用轻量级协议。在一个实施例中，服务是独立可部署的。通过将系统的功能分配到不同的小型服务中，增强了系统的内聚性并降低了系统的耦合度。这使得更容易随时改变系统以及向系统添加功能和质量。它还允许个体服务的架构通过不断的重构而出现，从而减少了对大型前期设计的需求，并且允许及早和持续地发布软件。在一个实施例中，在微服务架构中，应用作为服务的集合被开发，并且每个服务运行相应的进程并使用轻量级协议进行通信(例如，用于每个微服务的唯一api)。在微服务架构中，取决于要提供的服务，将软件分解成各个服务/能力可以以不同的粒度级别来执行。服务是运行时组件/进程。每个微服务是可以与其它模块/微服务交谈的自包含(self-contained)模块。每个微服务具有可以被其它微服务联系的未命名的通用端口。在一个实施例中，微服务的未命名的通用端口是微服务按照惯例暴露并允许同一服务中的任何其它模块/微服务与其交谈的标准通信信道(例如，作为常规的超文本传输协议(“http”)端口)。微服务或任何其它自包含的功能模块可以统称为“服务”。实施例提供多租户身份管理服务。实施例基于开放标准，以确保易于与各种应用集成，从而通过基于标准的服务来递送iam能力。实施例管理用户身份的生命周期，这需要确定和强制实施身份可以访问什么、谁可以被给予这种访问、谁可以管理这种访问等等。对于不一定在云中的应用，实施例在云中运行身份管理工作负载并且支持安全功能。由实施例提供的身份管理服务可以从云购买。例如，企业可以从云购买这种服务，以管理他们的员工访问他们的应用。实施例提供系统安全性、大规模可伸缩性、最终用户可用性和应用互操作性。实施例解决了云的增长和客户对身份服务的使用。基于微服务的基础解决了水平可伸缩性需求，同时服务的仔细编排解决了功能需求。实现这两个目标需要(尽可能)分解业务逻辑以实现具有最终一致性的无状态性，而大多数不受实时处理影响的操作逻辑通过卸载到高度可伸缩的异步事件管理系统而转移到近实时，具有有保证的递送和处理。实施例从网络层到数据层是完全多租户的，以便实现成本效率和系统管理的容易性。实施例基于行业标准(例如，openidconnect、oauth2、安全声明标记语言2(“saml2”)、用于跨域身份管理的系统(“scim”)、代表性状态转移(“rest”))等等)以便于与各种应用集成。一个实施例提供了云规模api平台并实现了用于弹性可伸缩性的水平可伸缩微服务。该实施例充分利用云原理并提供具有每租户数据分离的多租户架构。该实施例还提供了具有租户自助服务的每租户定制。该实施例经由api可用于与其它身份服务的按需集成，并提供持续的特征发布。一个实施例提供互操作性并充分利用对云中和内部部署的身份管理(“idm”)功能的投资。该实施例提供从内部部署轻量级目录访问协议(“ldap”)数据到云数据的自动化身份同步，反之亦然。该实施例在云和企业之间提供scim身份总线，并且允许混合云部署的不同选项(例如，身份联合和/或同步、sso代理、用户供应连接器等等)。因而，一个实施例是在无状态中间层中实现多个微服务以提供基于云的多租户身份和访问管理服务的系统。在一个实施例中，每个被请求的身份管理服务被分解成实时任务和近实时任务。实时任务由中间层中的微服务处理，而近实时任务被卸载到消息队列。实施例实现由路由层消耗以强制实施用于访问微服务的安全模型的令牌。因而，实施例提供了基于多租户、微服务架构的云规模的iam平台。一般而言，已知的系统提供对由不同环境提供的应用(例如，企业云应用、合作伙伴云应用、第三方云应用和客户应用)的孤立(siloed)访问。这种孤立的访问可能需要多个密码、不同的密码策略、不同的账户供应和解除供应方案、全异的审计等等。但是，一个实施例实现了idcs，以在这种应用上提供统一的iam功能。图1是具有idcs118的示例实施例的框图100，其提供了用于对用户和应用进行登入的统一身份平台126。该实施例跨各种应用(诸如企业云应用102、合作伙伴云应用104、第三方云应用110和客户应用112)提供无缝的用户体验。应用102、104、110、112可以通过不同的渠道来访问，例如，由移动电话用户108经由移动电话106、由台式计算机用户116经由浏览器114等等。web浏览器(通常称为浏览器)是用于检索、呈现和遍历万维网上的信息资源的软件应用。web浏览器的示例是mozillagooglemicrosoftinternet和appleidcs118提供用户的应用、(经由身份平台126)跨设备和应用的统一安全凭证以及(经由管理控制台122)统一的管理方式的统一视图124。idcs服务可以通过调用idcsapi142来获得。这种服务可以包括例如登录/sso服务128(例如，openidconnect)、联盟服务130(例如，saml)、令牌服务132(例如，oauth)、目录服务134(例如，scim)、供应服务136(例如，scim或任何经多协议的传输(“atom”))、事件服务138(例如，rest)以及授权服务140(例如，scim)。idcs118还可以提供与所提供的服务相关的报告和仪表盘120。集成工具一般而言，大型公司通常具有iam系统以保护对其内部部署应用的访问。业务实践通常都是围绕内部iam系统(诸如来自oracle公司的“oracleiam套件”)成熟和标准化的。甚至中小企业通常也会通过简单目录解决方案(诸如microsoftactivedirectory(“ad”))来围绕管理用户访问设计其业务进程。为了启用内部部署集成，实施例提供了允许客户将其应用与idcs集成的工具。图2是在云环境208中具有idcs202的示例实施例的框图200，其提供与内部部署206的ad204的集成。该实施例提供跨包括内部部署及第三方应用(例如，内部部署应用218和云208中诸如云服务210、云应用212、合作伙伴应用214和客户应用216的各种应用/服务)在内的所有应用的无缝用户体验。云应用212可以包括例如人力资本管理(“hcm”)、crm、人才获取(例如，来自oracle公司的oracletaleo云服务)、配置价格和报价(“cpq”)等等。云服务210可以包括例如平台即服务(“paas”)、java、数据库、商业智能(“bi”)、文档等等。应用210、212、214、216、218可以通过不同的渠道被访问，例如，由移动电话用户220经由移动电话222、由台式计算机用户224经由浏览器226等等。该实施例提供经由云208和企业206之间的scim身份总线234从内部部署ad数据到云数据的自动化身份同步。该实施例还提供saml总线228，用于将来自云208的认证联合到内部部署ad204(例如，使用密码232)。一般而言，身份总线是用于身份相关的服务的服务总线。服务总线为从一个系统到另一个系统传送消息提供平台。它是用于在受信任的系统之间交换信息的受控机制，例如，在面向服务的架构(“soa”)中。身份总线是根据基于标准http的机制(诸如web服务、web服务器代理等等)构建的逻辑总线。身份总线中的通信可以根据相应的协议(例如，scim、saml、openidconnect等等)。例如，saml总线是两个系统之间基于http的连接，用于传送用于saml服务的消息。类似地，scim总线用于根据scim协议传送scim消息。图2的实施例实现身份(“id”)桥接器230，其是可以与客户的ad204一起下载并安装在内部部署206的小二进制文件(例如，1mb尺寸)。id桥接器230监听来自客户选择的组织单位(“ou”)的用户和组(例如，用户组)，并将那些用户同步到云208。在一个实施例中，用户的密码232不同步到云208。客户可以通过将idcs用户的组映射到在idcs208中管理的云应用来管理用户的应用访问。每当用户的组成员资格在内部部署206被改变时，其对应的云应用访问自动改变。例如，从工程转移到销售的员工可以几乎即时访问销售云并失去对开发者云的访问。当这种改变反映在内部部署ad204中时，云应用访问改变是近实时完成的。类似地，对于离开公司的用户，对在idcs208中管理的云应用的访问被撤销。为了完全自动化，客户可以通过例如ad联合服务(“ad/fs”或实现saml联合的某种其它机制)在内部部署ad204和idcs208之间设置sso，使得最终用户可以用单个公司密码332访问云应用210、212、214、216以及内部部署应用218。图3是包括与图2中相同的组件202、206、208、210、212、214、216、218、220、222、224、226、228、234的示例实施例的框图300。但是，在图3的实施例中，idcs202提供与内部部署idm304(诸如oracleidm)的集成。oracleidm304是oracle公司提供iam功能的软件套件。该实施例提供跨包括内部部署和第三方应用在内的所有应用的无缝用户体验。该实施例经由云202和企业206之间的scim身份总线234从内部部署idm304到idcs208供应用户身份。该实施例还提供saml总线228(或openidconnect总线)，用于将来自云208的认证联合到内部部署206。在图3的实施例中，来自oracle公司的oracle身份管理器(“oim”)连接器302和来自oracle公司的oracle访问管理器(“oam”)联合模块306被实现为oracleidm304的扩展模块。连接器是具有关于如何与系统交谈的物理意识的模块。oim是被配置为管理用户身份(例如，基于用户应当和不应当访问的内容来管理不同系统中的用户账户)的应用。oam是提供访问管理功能的安全应用，访问管理功能诸如websso；身份上下文；认证和授权；策略管理；测试；记录；审计等等。oam具有对saml的内置支持。如果用户在idcs202中有账户，那么oim连接器302和oam联合306可以与oracleidm304一起使用，以创建/删除那个账户并且管理来自那个账户的访问。图4是包括与图2和图3中相同的组件202、206、208、210、212、214、216、218、220、222、224、226、234的示例实施例的框图400。但是，在图3的实施例中，idcs202提供将云身份扩展到内部部署应用218的功能。该实施例提供跨包括内部部署和第三方应用在内的所有应用的身份的无缝视图。在图4的实施例中，scim身份总线234用于使idcs202中的数据与称为“云高速缓存”402的内部部署ldap数据同步。下面更详细地公开云高速缓存402。一般而言，被配置为基于ldap进行通信的应用需要ldap连接。由于ldap需要在本地网络上，因此这种应用不能通过url建立ldap连接(不像例如连接到google的“www.google.com”)。在图4的实施例中，基于ldap的应用218做出到云高速缓存402的连接，并且云高速缓存402建立到idcs202的连接并随后在其被请求时从idcs202拉出数据。idcs202与云高速缓存402之间的通信可以根据scim协议来实现。例如，云高速缓存402可以使用scim总线234来向idcs202发送scim请求并作为回报接收对应数据。一般而言，完全实现应用包括构建消费者门户、在外部用户群体上运行营销活动、支持web和移动渠道以及处理用户认证、会话、用户简档、用户组、应用角色、密码策略、自助服务/注册、社会整合、身份联合等等。一般而言，应用开发人员不是身份/安全专家。因此，按需身份管理服务是期望的。图5是包括与图2-图4中相同的组件202、220、222、224、226、234、402的示例实施例的框图500。但是，在图5的实施例中，idcs202按需提供安全身份管理。该实施例按需提供与idcs202的身份服务的集成(例如，基于诸如openidconnect、oauth2、saml2或scim的标准)。应用505(其可以是内部部署的、在公共云中或在私有云中)可以调用idcs202中的身份服务api504。由idcs202提供的服务可以包括例如自助服务注册506、密码管理508、用户简档管理510、用户认证512、令牌管理514、社会整合516等等。在这个实施例中，scim身份总线234用于使idcs202中的数据与内部部署的ldap云高速缓存402中的数据同步。另外，在web服务器/代理(例如，nginx、apache等等)上运行的“云门(cloudgate)”502可以被应用505使用，以从idcs202获得用户websso和restapi安全性。云门502是通过确保客户端应用提供有效访问令牌和/或用户成功认证来保护到多租户idcs微服务的访问的组件，以便建立sso会话。云门502在下面进一步公开。云门502(类似于webgate/webagent的强制实施点)使得在被支持的web服务器后面运行的应用能够参与sso。一个实施例提供sso和云sso功能。在许多组织中，用于内部部署的iam和idcs的一般入口点是sso。云sso使用户能够用单一用户登录来访问多个云资源。组织常常想要联合他们的内部部署的身份。因而，实施例利用开放标准来允许与现有sso集成，以保持和扩展投资(例如，直到进行了到身份云服务方法的完全最终过渡)。一个实施例可以提供以下功能：·维护身份存储，以跟踪已被授权的用户账户、所有权、访问和许可，·与工作流集成，以促进应用访问所需的各种审批(例如，管理、it、人力资源、法律和合规性)，·为选择性设备(例如，移动和个人计算机(“pc”))提供saas用户账户，以访问包含许多私有和公共云资源的用户门户，·促进周期性管理鉴证(attestation)审查，以符合法规和当前的工作职责。除了这些功能之外，实施例还可以提供：·云账户供应，以管理云应用中的账户生命周期，·更健壮的多因素认证(“mfa”)集成，·广泛的移动安全能力，以及·动态认证选项。一个实施例提供自适应的认证和mfa。一般而言，密码和挑战问题被认为是不够的，并且易于受诸如网络钓鱼等常见攻击。如今的大多数商业实体都在寻求某种形式的mfa以降低风险。但是，为了被成功部署，解决方案需要由最终用户轻松供应、维护和理解，因为最终用户通常会抵制干扰其数字体验的任何事情。公司正在寻找安全地结合自带设备(“byod”)、社交身份、远程用户、客户和承包商的方式，同时使mfa成为无缝用户访问体验中几乎透明的组件。在mfa部署中，诸如oauth和openidconnect等行业标准对于确保现有多因素解决方案的集成和新型自适应认证技术的结合至关重要。因而，实施例将动态(或自适应)认证定义为在用户会话已经发起之后证明身份的可用信息(即，ip地址、位置、一天中的时间和生物测定)的评估。通过适当的标准(例如，开放认证(“oath”)和快速身份在线(“fido”))集成和可扩展身份管理框架，实施例提供了可以在it组织中被容易地采用、升级和集成的mfa解决方案，作为端到端安全iam部署的一部分。在考虑mfa和自适应策略时，组织必须在内部部署和云资源上实现一致的策略，这在混合idcs和内部部署iam环境中需要系统之间的集成。一个实施例提供用户供应和证实(certification)。一般而言，iam解决方案的基本功能是启用和支持整个用户供应生命周期。这包括为用户提供适合于他们在组织内的身份和角色的应用访问、证实他们具有正确的持续访问许可(例如，当他们的角色或在其角色内使用的任务或应用随时间变化时)，并且在他们离开组织时迅速地解除供应。这是重要的，不仅为了满足各种合规要求，而且还因为不适当的内部人员访问是安全漏洞和攻击的主要来源。身份云解决方案中的自动化用户供应能力不仅可以作为自身的重要组成部分，而且也可以作为混合iam解决方案的一部分，借此，对于当公司缩小规模、扩大规模、合并或指望将现有系统与iaas/paas/saas环境集成在一起时的过渡，idcs供应可以提供比内部部署解决方案更大的灵活性。idcs方法可以节省一次性升级的时间和精力，并确保必要的部门、分区和系统之间的适当集成。伸缩这项技术的需求常常在企业中悄然发现，并且跨企业立即递送可伸缩的idcs能力的能力可以提供灵活性、成本和控制方面的好处。一般而言，随着她/他的工作改变，员工随着年限被授予附加的特权(即，“特权蠕动(creep)”)。受到轻度监管的公司一般缺乏要求管理人员定期审计员工的特权(例如，访问网络、服务器、应用和数据)以中止或减慢导致超级特权账户的特权蠕动的“鉴证”处理。因而，一个实施例可以提供定期进行(至少一年一次)的鉴证处理。另外，随着并购，对这些工具和服务的需求将以指数形式增长，因为用户在saas系统上、内部部署、跨不同部门和/或正在被解除供应或重新分配。迁移到云可以进一步使这种情况复杂，并且处理可以迅速升级到超出现有的、常常是人工管理的证实方法。因而，一个实施例使这些功能自动化，并将复杂的分析应用于用户简档、访问历史记录、供应/解除供应和精细粒度赋权。一个实施例提供身份分析。一般而言，能够将身份分析与iam引擎集成以进行全面证实和鉴证对于确保组织的风险简档至关重要。正确部署的身份分析可以要求全面的内部策略强制实施。在积极主动的治理、风险和合规性(“grc”)企业环境中，非常需要跨云和内部部署提供统一的单个管理视图的身份分析，并且可以帮助提供闭环处理以降低风险和满足合规性法规。因而，一个实施例提供客户端能够容易定制的身份分析，以适应管理者、主管人员和审计人员所需的用于报告和分析的具体行业需求和政府法规。一个实施例提供自助服务和访问请求功能，以改进最终用户的体验和效率并降低服务台呼叫的成本。一般而言，虽然许多公司为员工部署了内部部署的自助访问请求，但是许多公司并没有在正式的公司范围之外充分扩展这些系统。除了员工使用，积极的数字客户体验增加商业信誉并最终有助于增加收入，并且公司不仅可以节省客户服务台呼叫和成本，而且还可以改进客户满意度。因而，一个实施例提供基于开放标准并且在必要时无缝地与现有访问控制软件和mfa机制集成的身份云服务环境。saas递送模式节省了以前投入于系统升级和维护的时间和精力，从而使专业it人员能够专注于更核心的业务应用。一个实施例提供特权账户管理(“pam”)。一般而言，无论是使用saas、paas、iaas还是内部部署应用，每个组织都容易受到具有超级用户访问凭证的内部人员(诸如系统管理员、主管人员、人事主管、承包商、系统集成商等等)对未经授权的特权账户的滥用的攻击。而且，外部威胁通常首先突破低级用户账户，以最终到达并利用企业系统内的特权用户访问控制。因而，一个实施例提供pam，以防止这种未经授权的内部人员账户使用。pam解决方案的主要组成部分是可以以各种方式递送的密码保险库(valult)，例如作为安装在企业服务器上的软件、作为同样企业服务器上的虚拟设备、作为打包的硬件/软件设备，或者作为云服务的一部分。pam功能类似于用于存储保存在信封中并定期改变的密码的物理保险箱，具有用于签入和签出的清单。一个实施例允许密码校验(passwordcheckout)以及设置时间限制、强制周期性改变、自动跟踪校验以及报告所有活动。一个实施例提供直接连接到所请求的资源而无需用户甚至知道密码的方式。这个能力还为会话管理和附加功能铺平了道路。一般而言，大多数云服务利用api和管理界面，其为渗透者提供了绕过安全性的机会。因而，一个实施例在pam实践中考虑这些漏洞，因为向云的移动给pam带来了新的挑战。现在许多中小型企业都在管理他们自己的saas系统(例如，office365)，而更大型的企业越来越多地拥有各自的业务单元，这些业务单元分别启动(spinningup)自己的saas和iaas服务。这些客户在身份云服务解决方案或其iaas/paas提供者身上发现自己具有pam能力，但在在处理这个责任方面经验不足。而且，在一些情况下，许多不同的地理位置分散的业务单元正试图将针对相同saas应用的管理责任隔离。因而，一个实施例允许客户在这些情况下将现有的pam链接到身份云服务的整体身份框架中，并且朝着更大的安全性和与确保伸缩到如业务需求规定的云负载要求的合规性移动。api平台实施例提供了将能力的集合作为服务来暴露的api平台。api被聚合到微服务中，并且每个微服务暴露api中的一个或多个。即每个微服务可以暴露不同类型的api。在一个实施例中，每个微服务仅通过其api来进行通信。在一个实施例中，每个api可以是微服务。在一个实施例中，基于要由服务提供的目标能力(例如，oauth、saml、管理员等等)将多个api聚合到该服务中。因此，类似的api不作为分开的运行时进程来被暴露。api是使得可用于使服务消费者使用由idcs提供的服务的东西。一般而言，在idcs的web环境中，url包括三部分：主机、微服务和资源(例如，主机/微服务/资源)。在一个实施例中，微服务的特征在于具有特定的url前缀，例如“主机/oauth/v1”，其中实际的微服务是“oauth/v1”，并且在“oauth/v1”下有多个api，例如请求令牌的api：“主机/oauth/v1/令牌”、认证用户的api：“主机/oauth/v1/授权”等。即，url实现微服务，并且url的资源部分实现api。因而，在同一微服务下聚合了多个api。在一个实施例中，url的主机部分识别租户(例如，"https://tenant3.identity.oraclecloud.com:/oauth/v1/token")。配置利用必要的端点与外部服务集成的应用以及保持那种配置最新通常是一个挑战。为了应对这一挑战，实施例在众所周知的位置暴露公开的发现api，从那里应用可以发现关于它们为了消费idcsapi而需要的idcs的信息。在一个实施例中，支持两个发现文档：idcs配置(其包括idcs、saml、scim、oauth和openidconnect配置，例如在<idcs-url>/.well-know/idcs-configuration)和行业标准openid连接配置(例如，<idcs-url>/.well-known/openid-configuration)。应用可以通过配置有单个idcsurl来检索发现文档。图6是在一个实施例中提供idcs的系统视图600的框图。在图6中，各种应用/服务602中的任何一个可以对idcsapi进行http调用，以使用idcs服务。这种应用/服务602的示例是web应用、本机应用(例如，被构建为在具体操作系统上运行的应用，诸如windows应用、ios应用、android应用等等)、web服务、客户应用、合作伙伴应用或者由公共云提供的任何服务(诸如软件即服务(“saas”)、paas和基础设施即服务(“iaas”))。在一个实施例中，需要idcs服务的应用/服务602的http请求经过oracle公共云big-ip应用604和idcsbig-ip应用606(或类似技术，诸如负载均衡器，或者实现适当的安全规则以保护流量的被称为云负载均衡器即服务(“lbaas”)的组件)。但是，请求可以以任何方式被接收。在idcsbig-ip应用606(或者如适用的，诸如负载均衡器或云lbaas的类似技术)，云供应引擎608执行租户和服务编排。在一个实施例中，云供应引擎608管理与正登入到云中的新租户或由客户购买的新服务实例相关联的内部安全工件(artifact)。然后，http请求由实现安全门(即，云门)的idcsweb路由层610接收，并提供服务路由以及微服务注册和发现612。取决于所请求的服务，http请求被转发到idcs中间层614中的idcs微服务。idcs微服务处理外部和内部http请求。idcs微服务实现平台服务和基础设施服务。idcs平台服务是分开部署的基于java的运行时服务，其实现了idcs的业务。idcs基础设施服务是分开部署的运行时服务，其为idcs提供基础设施支持。idcs还包括基础设施库，基础设施库是作为由idcs服务和共享库使用的共享库打包的公共代码。基础设施服务和库提供平台服务用于实现其功能所需的支持能力。平台服务在一个实施例中，idcs支持标准认证协议，因此idcs微服务包括诸如openidconnect、oauth、saml2、用于跨域身份管理的系统++(“scim++”)等等的平台服务。openidconnect平台服务实现标准的openidconnect登录/注销流。交互式的基于web的本机应用充分利用标准的基于浏览器的openidconnect流来请求用户认证，从而接收是传达用户经认证的身份的javascript对象标记(“json”)web令牌(“jwt”)的标准身份令牌。在内部，运行时认证模型是无状态的，从而以主机httpcookie(包括jwt身份令牌)的形式维护用户的认证/会话状态。经由openidconnect协议发起的认证交互被委托给受信任的sso服务，该服务为本地和联合登录实现用户登录/注销仪式。下面参考图10和图11公开这个功能的更多细节。在一个实施例中，根据例如openidfoundation标准来实现openidconnect功能。oauth2平台服务提供令牌授权服务。它提供了丰富的api基础设施，用于创建和验证传达进行api调用的用户权限的访问令牌。它支持一系列有用的令牌授予类型，从而使客户能够安全地将客户端连接到他们的服务。它实现了标准的双参与方(2-legged)和三参与方(3-legged)oauth2令牌授予类型。支持openidconnect(“oidc”)使得兼容的应用(oidc中继方(“rp”))与作为身份提供者(oidcopenid提供者(“op”))的idcs集成。类似地，将idcs作为oidcrp与社交oidcop(例如，facebook、google等等)集成使得客户能够允许对应用进行基于社交身份策略的访问。在一个实施例中，根据例如互联网工程任务组(“ietf”)请求评论(“rfc”)文案6749来实现oauth功能。saml2平台服务提供身份联合服务。它使得客户能够基于saml身份提供者(“idp”)和saml服务提供者(“sp”)关系模型与其合作伙伴建立联合协议。在一个实施例中，saml2平台服务实现标准saml2浏览器post登录和注销简档。在一个实施例中，根据例如ietf、rfc7522来实现saml功能。scim是用于自动化身份域或信息技术(“it”)系统之间的用户身份信息交换的开放标准，如由例如ietf，rfc7642、7643、7644提供的。scim++平台服务提供身份管理服务，并使客户能够访问idcs的idp特征。管理服务暴露覆盖身份生命周期、密码管理、组管理等的无状态rest接口(即api)集合，从而将这些工件作为web可访问的资源暴露。所有idcs配置工件都是资源，并且管理服务的api允许管理idcs资源(例如，用户、角色、密码策略、应用、saml/oidc身份提供者、saml服务提供者、密钥、证实、通知模板等等)。管理服务充分利用和扩展scim标准，以便为所有idcs资源上的创建、读取、更新、删除和查询(“crudq”)操作实现基于模式的restapi。此外，用于管理和配置idcs本身的所有idcs内部资源都作为基于scim的restapi暴露。对身份存储库618的访问被隔离到scim++api。在一个实施例中，例如，scim标准被实现，以管理如由scim规范定义的用户和组资源，而scim++被配置为使用由scim标准定义的语言支持附加的idcs内部资源(例如，密码策略、角色、设置等等)。管理服务在需要的地方利用标准scim2.0核心模式和模式扩展来支持scim2.0标准端点。此外，管理服务还支持若干个scim2.0兼容端点扩展，以管理其它idcs资源，例如用户、组、应用、设置等等。管理服务还支持远程过程调用样式(“rpc样式”)rest接口集合，其不执行crudq操作，而是代替地提供功能服务，例如“userpasswordgenerator”，“serpasswordvalidator”等等。idcs管理api使用oauth2协议进行认证和授权。idcs支持常见的oauth2场景，诸如用于web服务器、移动和javascript应用的场景。对idcsapi的访问受访问令牌的保护。为了访问idcs管理api，应用需要通过idcs管理控制台将应用注册为oauth2客户端或idcs应用(在这种情况下，oauth2客户端是自动创建的)并被授予期望的idcs管理角色。在进行idcs管理api调用时，应用首先从idcsoauth2服务请求访问令牌。在获取令牌之后，应用通过将访问令牌包括在http授权报头中来将访问令牌发送给idcsapi。应用可以直接使用idcs管理restapi，或者使用idcsjava客户端api库。基础设施服务idcs基础设施服务支持idcs平台服务的功能。这些运行时服务包括：事件处理服务(用于异步处理用户通知、应用预订和数据库审计)；作业调度器服务(用于调度和执行作业，例如，立即执行或在配置的时间执行不需要用户干预的长时间运行的任务)；高速缓存管理服务；存储管理服务(用于与公共云存储服务集成)；报告服务(用于生成报告和仪表盘)；sso服务(用于管理内部用户认证和sso)；用户界面(“ui”)服务(用于托管不同类型的ui客户端)；以及服务管理器服务。服务管理器是oracle公共云和idcs之间的内部接口。服务管理器管理由oracle公共云发布的命令，其中命令需要由idcs实现。例如，当客户在云商店购买东西之前先注册账户时，云会向idcs发送要求创建租户的请求。在这种情况下，服务管理器实现了云预期idcs支持的特定于云的操作。idcs微服务可以通过网络接口(即，http请求)调用另一个idcs微服务。在一个实施例中，idcs还可以提供允许使用数据库模式的模式服务(或持久性服务)。模式服务允许将管理数据库模式的责任委托给idcs。因而，idcs的用户不需要管理数据库，因为存在提供那个功能的idcs服务。例如，用户可以使用数据库以每个租户为基础来持久化模式，并且当数据库中没有更多的空间时，模式服务将管理获得另一个数据库和增加空间的功能，使得用户不需要必须自己管理数据库。idcs还包括数据存储，这些数据存储是idcs所需/生成的数据储存库，包括身份存储库618(存储用户、组等等)、全局数据库620(存储由idcs使用以配置自身的配置数据)、操作模式622(提供每个租户的模式分离并且以每个客户为基础来存储客户数据)、审计模式624(存储审计数据)、高速缓存集群626(存储高速缓存的对象，以加速性能)等等。所有内部和外部idcs消费者经基于标准的协议与身份服务进行集成。这使得能够使用域名系统(“dns”)来解决将请求路由到何处，并且使得消费应用与对身份服务的内部实现的理解解耦。实时任务和近实时任务idcs将所请求服务的任务分离成同步实时任务和异步近实时任务，其中实时任务仅包括用户继续前进所需的操作。在一个实施例中，实时任务是以最小延迟执行的任务，而近实时任务是在后台执行、无需用户等待它的任务。在一个实施例中，实时任务是基本上没有延迟或以可忽略的延迟被执行的任务，并且对于用户而言几乎是瞬间执行的。实时任务执行具体身份服务的主要业务功能。例如，当请求登录服务时，应用发送消息以认证用户的凭证，并作为回报获得会话cookie。用户体验到的就是登录系统。但是，结合用户的登录可以执行若干其它任务，诸如验证用户是谁、审计、发送通知等等。因而，验证凭证是实时执行的任务，使得用户被给予开始会话的httpcookie，但是与通知(例如，发送电子邮件以通知创建账户)、审计(例如，跟踪/记录)等相关的任务是可以异步执行的近实时任务，这样用户可以以最少的延迟继续前进。当接收到针对微服务的http请求时，对应的实时任务由中间层中的微服务执行，而剩余的近实时任务(诸如不必实时处理的操作逻辑/事件)被卸载到消息队列628，消息队列628支持具有有保证的递送和处理的高度可伸缩的异步事件管理系统630。因而，某些行为被从前端推送到后端，以使idcs能够通过减少响应时间中的等待时间来向客户提供高级服务。例如，登录处理可以包括凭证的验证、日志报告的提交、最后登录时间的更新等等，但是这些任务可以被卸载到消息队列并且近实时地而不是实时执行。在一个示例中，系统可能需要注册或创建新的用户。系统调用idcsscimapi，以创建用户。最终的结果是，当用户在身份存储库618中被创建时，用户得到包括重置他们的密码的链接的通知电子邮件。当idcs接收到注册或创建新用户的请求时，对应的微服务查看操作数据库(位于图6中的全局数据库620中)中的配置数据，并确定“创建用户”操作被标记有“创建用户”事件，这在配置数据中被识别为异步操作。微服务返回给客户端并且指示用户的创建成功完成，但是通知电子邮件的实际发送被推迟并被推送到后端。为了这样做，微服务使用消息传送api616将消息在作为存储的队列628中排队。为了从队列628中出队，作为基础设施微服务的消息传送微服务在后台连续地运行并且扫描队列628，以在队列628中查找事件。队列628中的事件由事件订户630处理，诸如审计、用户通知、应用订阅、数据分析等等。取决于由事件指示的任务，事件订户630可以与例如审计模式624、用户通知服务634、身份事件订户632等等通信。例如，当消息传送微服务在队列628中发现“创建用户”事件时，它执行对应的通知逻辑并向用户发送对应的电子邮件。在一个实施例中，队列628将由微服务614公布的操作事件以及由管理idcs资源的api616公布的资源事件排队。idcs使用实时高速缓存结构来增强系统性能和用户体验。高速缓存本身也可以作为微服务提供。idcs实现弹性高速缓存集群626，其随着idcs所支持的客户数量的伸缩而增长。高速缓存集群626可以利用下面更详细公开的分布式数据网格来实现。在一个实施例中，只写资源绕过高速缓存。在一个实施例中，idcs运行时组件向公共云监视模块636公布健康和操作度量，公共云监视模块636从公共云(诸如来自oracle公司的oracle公共云)收集这种度量。在一个实施例中，可以使用idcs来创建用户。例如，客户端应用602可以发布创建用户的restapi调用。管理服务(614中的平台服务)将调用委托给用户管理器(614中的基础设施库/服务)，该用户管理器进而在id存储库618中的特定于租户的id存储条带中创建用户。在“用户创建成功”时，用户管理器在审计模式624下审计对审计表的操作，并向消息队列628公布“identity.user.create.success”事件。身份订户632拾取事件并向新创建的用户发送“欢迎”电子邮件，包括新创建的登录细节信息。在一个实施例中，可以使用idcs向用户授予角色，从而导致用户供应动作。例如，客户端应用602可以发布授予用户角色的restapi调用。管理服务(614中的平台服务)将该调用委托给角色管理器(614中的基础设施库/服务)，该角色管理器在id存储库618中特定于租户的id存储条带状授予用户角色。在“角色授予成功”时，角色管理器在审计模式624下审计对审计表的操作，并向消息队列628公布“identity.user.role.grant.success”事件。身份订户632拾取事件并评估供应授权策略。如果在角色被授予时存在活动的应用授予，那么供应订户执行某种验证、发起账户创建、调出目标系统、在目标系统上创建账户并将账户创建标记为成功。这些功能中的每一个可以导致对应事件的公布，诸如“prov.account.create.initiate”、“prov.target.create.initiate”、“prov.target.create.success”或“prov.account.create.success”。这些事件可以具有其自己的聚合过去n天内在目标系统中创建的账户数量的业务度量。在一个实施例中，idcs可以被用于用户登录。例如，客户端应用602可以使用所支持的认证流之一来请求用户的登录。idcs对用户进行认证，并且在成功时在审计模式624下审计审计表中的操作。在失败时，idcs在审计模式624下审计失败，并在消息队列628中公布“login.user.login.failure”事件。登录订户拾取事件、更新其用于用户的度量，并确定是否需要执行对用户的访问历史的附加分析。因而，通过实现“控制反转”功能(例如，改变执行的流以在稍后时间安排操作的执行，使得操作在另一个系统的控制下)，实施例使得附加的事件队列以及订户能够被动态添加，以便在部署到更广泛的用户基础之前针对小的用户样本测试新功能，或者处理针对具体的内部或外部客户的具体事件。无状态功能idcs微服务是无状态的，这意味着微服务本身不维持状态。“状态”是指应用为了执行其功能而使用的数据。idcs通过将所有状态持久化到idcs数据层中特定于租户的储存库中来提供多租户功能。中间层(即，处理请求的代码)不具有与应用代码存储在相同位置的数据。因而，idcs在水平和垂直方面都具有高度的可伸缩性。垂直伸缩(或扩大/缩小)意味着向系统中的单个节点添加资源(或从中移除资源)，通常涉及将cpu或存储器添加到单个计算机。垂直可伸缩性允许应用扩大到其硬件的极限。水平伸缩(或扩大/缩小)意味着向系统中添加更多节点(或从中移除节点)，诸如将新计算机添加到分布式软件应用。水平可伸缩性允许应用几乎无限地伸缩，仅受网络提供的带宽量限制。idcs的中间层的无状态使得仅通过增加更多的cpu就可以水平伸缩，并且执行应用的工作的idcs组件不需要具有运行特定应用的指定物理基础设施。idcs中间层的无状态使得idcs具有高度的可用性，即使在向大量客户/租户提供身份服务时也是如此。每次通过idcs应用/服务都只关注cpu使用情况来执行应用事务本身，而不使用硬件来存储数据。伸缩是通过在应用运行时添加更多的片(slice)来完成的，而用于事务的数据存储在持久层上，在那里，在需要时可以添加更多的副本。idcs网络层、中间层和数据层可以各自独立和分开地进行伸缩。web层可以伸缩，以处理更多的http请求。中间层可以伸缩，以支持更多的服务功能。数据层可以伸缩，以支持更多的租户。idcs功能视图图6a是一个实施例中的idcs的功能视图的示例框图600b。在框图600b中，idcs功能堆栈包括服务、共享库和数据存储。服务包括idcs平台服务640b、idcs高级服务650b和idcs基础设施服务662b。在一个实施例中，idcs平台服务640b和idcs高级服务650b是分开部署的、实现idcs的业务的、基于java的运行时服务，而idcs基础设施服务662b是分开部署的、为idcs提供基础设施支持的运行时服务。共享库包括idcs基础设施库680b，该idcs基础设施库680b是作为由idcs服务和共享库使用的共享库被打包的公共代码。数据存储是idcs所需/生成的数据储存库，包括身份存储698b、全局配置700b、消息存储702b、全局租户704b、个性化设置706b、资源708b、用户瞬态数据710b、系统瞬态数据712b、每租户模式(受管理的exadata)714b、操作存储(未示出)、高速缓存存储(未示出)等等。在一个实施例中，idcs平台服务640b包括例如openidconnect服务642b、oauth2服务644b、saml2服务646b和scim++服务648b。在一个实施例中，idcs高级服务包括例如云sso和治理(governance)652b、企业治理654b、authn中介656b、联合中介658b和私人账户管理660b。idcs基础设施服务662b和idcs基础设施库680b提供idcs平台服务640b完成其工作所需的支持能力。在一个实施例中，idcs基础设施服务662b包括作业调度器664b、ui666b、sso668b、报告670b、高速缓存672b、存储装置674b、服务管理器676b(公共云控制)和事件处理器678b(用户通知、应用订阅、审计、数据分析)。在一个实施例中，idcs基础设施库680b包括数据管理器api682b、事件api684b、存储api686b、认证api688b、授权api690b、cookieapi692b、密钥api694b和凭证api696b。在一个实施例中，云计算服务602b(内部nimbula)支持idcs基础设施服务662b和idcs基础设施库680b的功能。在一个实施例中，idcs为idcs服务的消费者提供各种ui602b，诸如客户最终用户ui604b、客户管理ui606b、devops管理ui608b和登录ui610b。在一个实施例中，idcs允许应用(例如，客户应用614b、合作伙伴应用616b和云应用618b)的集成612b和固件集成620b。在一个实施例中，各种环境可以与idcs集成，以支持其访问控制需求。这种集成可以由例如身份桥622b(提供ad集成、wna和scim连接器)、apache代理624b或msft代理626b提供。在一个实施例中，内部和外部idcs消费者经基于标准的协议628b(诸如openidconnect630b、oauth2632b、saml2634b、scim636b和rest/http638b)与idcs的身份服务集成。这使得能够使用域名系统(“dns”)来解决将请求路由到何处，并且使得消费应用与对身份服务的内部实现的理解解耦。图6a中的idcs功能视图还包括公共云基础设施服务，其提供idcs为了用户通知(云通知服务718b)、文件存储(云存储服务716b)以及用于devops的度量/警告(云监视服务(em)722b和云度量服务(graphite)720b)而依赖的常见功能。云门在一个实施例中，idcs在web层中实现“云门”。云门是web服务器插件，它使web应用能够将用户sso外部化到身份管理系统(例如，idcs)，类似于与企业idm堆栈一起工作的webgate或webagent技术。云门充当保护对idcsapi的访问的安全守卫。在一个实施例中，云门由web/代理服务器插件实现，其提供用于基于oauth保护http资源的web策略强制实施点(“pep”)。图7是实现云门702的实施例的框图700，云门702在web服务器712中运行并充当被配置为使用开放标准(例如，oauth2，openidconnect等)与idcs策略决定点(“pdp”)集成的策略强制实施点(“pep”)，同时保护对应用的restapi资源和web浏览器714的访问。在一些实施例中，pdp在oauth和/或openidconnect微服务704上实现。例如，当用户浏览器706向idcs发送用于用户710的登录的请求时，对应的idcspdp验证凭证，然后决定凭证是否充足(例如，是否请求诸如第二密码的进一步的凭证)。在图7的实施例中，云门702可以既充当pep又充当pdp，因为它具有本地策略。作为一次部署的一部分，云门702作为oauth2客户端向idcs注册，从而使其能够针对idcs请求oidc和oauth2操作。其后，它根据请求匹配规则(如何匹配url，例如，通配符、正则表达式等等)来维护关于应用的受保护和不受保护的资源的配置信息。可以部署云门702，以保护具有不同安全策略的不同应用，并且受保护的应用可以是多租户的。在基于web浏览器的用户访问期间，云门702充当发起用户认证流的oidcrp718。如果用户710没有有效的本地用户会话，那么云门702将用户重定向到sso微服务并且与sso微服务一起参与oidc“授权码”流。该流以递送jwt作为身份令牌结束。云门708验证jwt(例如，查看签名、到期、目的地/观众等等)并且为用户710发布本地会话cookie。它充当会话管理器716，以保护web浏览器访问受保护的资源以及发布、更新并验证本地会话cookie。它还提供了用于移除其本地会话cookie的注销url。云门户702还充当http基本认证认证器，从而针对idcs验证http基本认证凭证。这种行为在无会话和基于会话(本地会话cookie)模式下均受支持。在这种情况下，不创建服务器侧的idcs会话。在restapi客户端708的编程访问期间，云门702可以充当应用的受保护的restapi714的oauth2资源服务器/过滤器720。它检查具有授权报头和访问令牌的请求的存在。当客户端708(例如，移动、web应用、javascript等等)呈现访问令牌(由idcs发布)以与受保护的restapi714一起使用时，云门702在允许访问api(例如，签名、到期、观众等等)之前验证访问令牌。原始访问令牌未经修改就被传递。一般而言，oauth用于生成客户端身份传播令牌(例如，指示客户端是谁)或者用户身份传播令牌(例如，指示用户是谁)。在这些实施例中，云门中oauth的实现基于jwt，jwt定义用于web令牌的格式，如由例如ietf、rfc7519提供的。当用户登录时，发布jwt。jwt由idcs签署，并支持idcs中的多租户功能。云门验证由idcs发布的jwt，以允许idcs中的多租户功能。因而，idcs在物理结构中以及在支撑安全模型的逻辑业务流程中提供多租户。租赁类型idcs指定三种类型的租赁：客户租赁、客户端租赁和用户租赁。客户或资源租赁指定idcs的客户是谁(即，正在为谁执行工作)。客户端租赁指定哪个客户端应用在试图访问数据(即，哪个应用正在做工作)。用户租赁指定哪个用户在使用该应用来访问数据(即，由谁来执行工作)。例如，当专业服务公司为仓储俱乐部提供系统集成功能并使用idcs为仓储俱乐部系统提供身份管理时，用户租赁与专业服务公司对应，客户端租赁是用于提供系统集成功能的应用，并且客户租赁是仓储俱乐部。这三种租赁的分离和识别在基于云的服务中启用多租户功能。一般而言，对于安装在内部部署的物理机器上的内部部署软件，由于用户需要在机器上物理地登录，因此不需要指定三种不同的租赁。但是，在基于云的服务结构中，实施例使用令牌来确定谁在使用什么应用来访问哪些资源。这三种租赁由令牌编码，由云门强制实施并由中间层的业务服务使用。在一个实施例中，oauth服务器生成令牌。在各种实施例中，令牌可以与除oauth以外的任何安全协议结合使用。解耦用户、客户端和资源租赁为idcs提供的服务的用户提供了实质性的业务优势。例如，它允许服务提供者了解业务(例如，医疗保健业务)的需求和他们的身份管理问题，以购买idcs提供的服务、开发消费idcs的服务的自己的后端应用，并向目标业务提供后端应用。因而，服务提供者可以扩展idcs的服务，以提供其期望的能力并将那里能力提供给某些目标业务。服务提供者不需要构建和运行软件来提供身份服务，而是可以代替地扩展和定制idcs的服务以适应目标业务的需求。一些已知的系统仅解决了客户租赁这单一的租赁。但是，这种系统在处理由用户(诸如客户用户、客户的合作伙伴、客户的客户端、客户端本身或者客户委托访问的客户端)的组合进行的访问时是不足够的。在实施例中定义和强制实施多种租赁促进对这各种用户的身份管理功能。在一个实施例中，idcs的一个实体不同时属于多个租户；它只属于一个租户，而“租赁”是工件存活的地方。一般而言，存在实现某些功能的多个组件，并且这些组件可以属于租户，或者它们也可以属于基础设施。当基础设施需要代表租户行事时，它代表租户与实体服务进行交互。在那种情况下，基础设施本身具有它自己的租赁，并且客户具有其自己的租赁。在提交请求时，请求中可以涉及多种租赁。例如，属于“租户1”的客户端可以执行用于获得让“租户2”指定“租户3”中的用户的令牌的请求。作为另一个示例，存在于“租户1”中的用户可以需要在由“租户2”拥有的应用中执行动作。因此，用户需要去“租户2”的资源命名空间并为他们自己请求令牌。因而，授权的委托通过识别“谁”可以对“谁”做“什么”来完成。作为又一个示例，为第一组织(“租户1”)工作的第一用户可以允许为第二组织(“租户2”)工作的第二用户有权访问由第三组织(“租户3”)托管的文档。在一个示例中，“租户1”中的客户端可以请求让“租户2”中的用户访问“租户3”中的应用的访问令牌。客户端可以通过转到“http://tenant3/oauth/token”来调用对令牌的oauth请求。客户端通过在请求中包括“客户端断言”将自己识别为存在于“租户1”中的客户端。客户端断言包括客户端id(例如，“客户端1”)和客户端租赁“租户1”。作为“租户1”中的“客户端1”，该客户端有权调用对“租户3”上的令牌的请求，并且客户端想要用于“租户2”中的用户的令牌。因而，“用户断言”也作为同一个http请求的一部分被传递。所生成的访问令牌将在作为应用租赁(“租户3”)的目标租赁的上下文中发布，并将包括用户租赁(“租户2”)。在一个实施例中，在数据层中，每个租户被实现为分离的条带。从数据管理的角度来看，工件存在于租户中。从服务的角度来看，服务知道如何与不同的租户共事，而多租赁是服务的业务功能中的不同维度。图8图示了实施例中实现多租赁的示例系统800。系统800包括客户端802，客户端802请求由理解如何与数据库806中的数据共事的微服务804提供的服务。数据库包括多个租户808，并且每个租户包括对应租赁的工件。在一个实施例中，微服务804是通过https://tenant3/oauth/token请求的oauth微服务，用于获得令牌。在微服务804中使用来自数据库806的数据执行核实客户端802的请求是合法的oauth微服务的功能，并且如果是合法的，那么使用来自不同租赁808的数据来构造令牌。因而，系统800是多租户的，因为，通过不仅支持进入每个租赁的服务，而且还支持代表不同租户行事的服务，它可以在跨租户环境中工作。系统800是有利的，因为微服务804在物理上与数据库806中的数据解耦，并且通过在更靠近客户端的位置复制数据，微服务804可以作为本地服务被提供给客户端并且系统800可以管理服务的可用性并在全球提供。在一个实施例中，微服务804是无状态的，这意味着运行微服务804的机器不维护将服务指向任何具体租户的任何标记。代替地，例如，可以在进入的请求的url的主机部分上标记租赁。那种租赁指向数据库806中的租户808之一。当支持大量租户(例如，数百万租户)时，微服务804不能具有到数据库806的相同数量的连接，而是代替地使用连接池810，其在数据库用户的上下文中提供到数据库806的实际物理连接。一般而言，通过向底层驱动器或提供者供给连接字符串来构建连接，连接字符串被用于寻址具体的数据库或服务器并提供实例和用户认证凭证(例如，“server＝sql_box；database＝common；userid＝uid；pwd＝password；”)。一旦连接已经建立，它就可以被打开和关闭，并且可以设置特性(例如，命令超时长度，或事务(如果存在的话))。连接字符串包括由数据提供者的数据访问接口规定的键-值对的集合。连接池是所维护的数据库连接的高速缓存，使得在将来需要对数据库的请求时可以重用连接。在连接池中，在创建连接之后，它被放在池中并被再次使用，使得不必建立新连接。例如，当微服务804和数据库808之间需要10个连接时，在连接池810中将存在10个打开的连接，全部在数据库用户的上下文中(例如，与具体的数据库用户相关联，例如，谁是那个连接的所有者、谁的凭证正在验证中、是数据库用户吗、是系统凭证吗等)。连接池810中的连接是为可以访问任何东西的系统用户创建的。因此，为了正确处理由代表租户处理请求的微服务804进行的审计和特权，在与指派给具体租户的模式所有者相关联的“代理用户”812的上下文中执行数据库操作。这个模式所有者只能访问为其创建模式的租赁，并且租赁的价值是模式所有者的价值。当请求数据库806中的数据时，微服务804使用连接池810中的连接来提供那个数据。因而，多租赁是通过使无状态的、弹性的中间层服务在特定于租户的数据存储绑定的上下文中(例如，与其相关联)处理传入的请求来实现的，其中特定于租户的数据存储绑定是以每个请求为基础的在与资源租赁相关联的数据存储代理用户上下文中(例如，与其相关联)创建的数据连接之上建立的，并且数据库可以独立于服务进行伸缩。以下提供了用于实现代理用户812的示例功能：dboperation＝<preparedbcommandtoexecute>dbconnection＝getdbconnectionfrompool()dbconnection.setproxyuser(resourcetenant)result＝dbconnection.executeoperation(dboperation)在这个功能中，微服务804将在从连接池810拉出的连接上的“代理用户”设置设置为“租户”，并且在使用连接池810中的数据库连接的同时在租户的上下文中执行数据库操作。当将每个表分条以针对不同租户配置同一个数据库中的不同列时，一个表可以包括混合在一起的所有租户的数据。相反，一个实施例提供租户驱动的数据层。该实施例不为不同租户将同一个数据库分条，而是代替地为每个租户提供不同的物理数据库。例如，多租赁可以通过使用可插拔数据库(例如，来自oracle公司的oracle数据库12c)来实现，其中每个租户被分配分离的分区。在数据层，资源管理器处理请求，然后请求用于该请求的数据源(与元数据分离)。该实施例依据请求执行到相应数据源/存储的运行时切换。通过将每个租户的数据与其他租户隔离，该实施例提供了改进的数据安全性。在一个实施例中，各种令牌编码不同的租赁。url令牌可以识别请求服务的应用的租赁。身份令牌可以编码将被认证的用户的身份。访问令牌可以识别多个租赁。例如，访问令牌可以对作为这种访问的目标的租赁(例如，应用租赁)以及被给予访问的用户的用户租赁进行编码。客户端断言令牌可以识别客户端id和客户端租赁。用户断言令牌可以识别用户和用户租赁。在一个实施例中，身份令牌至少包括指示用户租户名字(即，用户所在的地方)的声称/声明。与授权令牌相关的“声称”(如由安全领域的普通技术人员所使用的)是一个主题对自己或另一个主题做出的声明。例如，声明可以是关于名字、身份、密钥、组、特权或能力。声称由提供者发布，并且它们被给予一个或多个值，然后被打包在由发布者发布的安全令牌中，通常称为安全令牌服务(“sts”)。在一个实施例中，访问令牌至少包括指示在对访问令牌做出请求时的资源租户名字(例如，客户)的声称/声明、指示用户租户名字的声称、指示做出请求的oauth客户端的名字的声称以及指示客户端租户名字的声称。在一个实施例中，访问令牌可以根据以下json功能来实现：在一个实施例中，客户端断言令牌包括至少指示客户端租户名字的声称以及指示做出请求的oauth客户端的名字的声称。本文描述的令牌和/或多种租赁可以在除idcs以外的任何其它基于多租户云的服务中实现。例如，本文描述的令牌和/或多租赁可以在saas或企业资源规划(“erp”)服务中实现。图9是一个实施例中的idcs的网络视图900的框图。图9图示了在一个实施例中在应用“区”904之间执行的网络交互。基于所需的保护级别和到各种其它系统(例如，ssl区、无ssl区等等)的连接的实现，将应用分成区。一些应用区提供需要从idcs内部进行访问的服务，而一些应用区提供需要从idcs外部进行访问的服务，并且一些应用区域是开放访问。因而，针对每种区强制实施相应的保护级别。在图9的实施例中，服务到服务通信是使用http请求来执行的。在一个实施例中，idcs使用本文描述的访问令牌不仅提供服务，而且还保护对idcs自身的访问以及在idcs自身内的访问。在一个实施例中，idcs微服务通过rest性的接口暴露并由本文所述的令牌保护。在图9的实施例中，各种应用/服务902中的任何一个都可以对idcsapi进行http调用，以使用idcs服务。在一个实施例中，应用/服务902的http请求经历oracle公共云负载均衡外部虚拟ip地址(“vip”)906(或其它类似技术)、公共云web路由层908以及idcs负载均衡内部vip应用910(或其它类似的技术)，以被idcsweb路由层912接收。idcsweb路由层912接收来自idcs的外部或内部的请求，并且跨idcs平台服务层914或idcs基础设施服务层916路由它们。idcs平台服务层914包括从idcs外部调用的idcs微服务，诸如openidconnect、oauth、saml、scim等等。idcs基础设施服务层916包括支持从idcs的内部调用的微服务，以支持其它idcs微服务的功能。idcs基础设施微服务的示例是ui、sso、报告、高速缓存、作业调度器、服务管理器、用于制作密钥的功能等等。idcs高速缓存层926支持用于idcs平台服务层914和idcs基础设施服务层916的高速缓存功能。通过强制实施在外部访问idcs和idcs内部的安全性，idcs的客户可以被提供对于他们运行的应用的杰出的安全合规性。在图9的实施例中，除了基于结构化查询语言(“sql”)通信的数据层918和基于ldap通信的id存储层920之外，oauth协议也被用于保护idcs内的idcs组件(例如，微服务)之间的通信，并且用于保护来自idcs外部的访问的相同令牌也被用于idcs内的安全性。即，web路由层912使用相同的令牌和协议来处理它接收到的请求，而不管请求是从idcs外部还是从idcs内部接收到的。因而，idcs为保护整个系统提供了单一一致的安全模型，由此允许卓越的安全合规性，因为在系统中实现的安全模型越少，系统越安全。在idcs云环境中，应用通过进行网络调用来进行通信。网络调用可以基于适用的网络协议，诸如http、传输控制协议(“tcp”)、用户数据报协议(“udp”)等等。例如，通过将应用“y”作为http统一资源定位符(“url”)暴露，应用“x”可以基于http与应用“y”通信。在一个实施例中，“y”是暴露各自与能力对应的多个资源的idcs微服务。当“x”(例如，另一个idcs微服务)需要调用“y”时，它构造包括“y”和需要被调用的资源/能力的url(例如https://host/y/resource)，并进行对应的rest调用，该rest调用经过web路由层912并被定向到“y”。在一个实施例中，idcs之外的调用者可以不需要知道“y”在哪里，但是web路由层912需要知道应用“y”在哪里运行。在一个实施例中，idcs实现发现功能(由oauth服务的api实现)，以确定每个应用在哪里运行，因此不需要静态路由信息的可用性。在一个实施例中，企业管理器(“em”)922提供将内部部署的和基于云的管理扩展到idcs的“单一虚拟管理平台(singlepaneofglass)”。在一个实施例中，是来自chefsoftware公司的配置管理工具的“chef”服务器924为各种idcs层提供配置管理功能。在一个实施例中，服务部署基础设施和/或持久性存储模块928可以将oauth2http消息发送到idcsweb路由层912，以进行租户生命周期管理操作、公共云生命周期管理操作或其它操作。在一个实施例中，idcs基础设施服务层916可以将id/密码http消息发送到公共云通知服务930或公共云存储服务932。云访问控制–sso一个实施例支持用于实现云规模的sso服务的轻量级云标准。轻量级云标准的示例是http、rest以及通过浏览器提供访问的任何标准(因为web浏览器是轻量级的)。相反，soap是重量级云标准的示例，其需要更多的管理、配置和工具来构建客户端。该实施例对于应用使用openidconnect语义来针对idcs请求用户认证。该实施例使用轻量级的基于httpcookie的用户会话跟踪来在idcs处跟踪用户的活动会话，而无需有状态的服务器端会话支持。该实施例对于应用使用基于jwt的身份令牌，以在将经认证的身份映射回其自己的本地会话时使用。该实施例支持与联合的身份管理系统的集成，并且暴露用于企业部署的samlidp支持，以针对idcs请求用户认证。图10是一个实施例中的idcs中的sso功能的系统架构视图的框图1000。该实施例使得客户端应用能够充分利用基于标准的web协议来发起用户认证流。需要将sso与云系统集成的应用可以位于企业数据中心中、远程合作伙伴数据中心中，或者甚至由客户内部部署操作。在一个实施例中，不同的idcs平台服务实现sso的业务，诸如openidconnect，用于处理来自所连接的本机应用(即，利用openidconnect与idcs集成的应用)的登录/注销请求；samlidp服务，用于处理来自所连接的应用的基于浏览器的登录/注销请求；samlsp服务，用于编排针对外部samlidp的用户认证；以及内部idcssso服务，用于编排包括本地或联合登录流的最终用户登录仪式以及用于管理idcs主机会话cookie。一般而言，http可以带表单或不带表单工作。当它带表单工作时，表单就会在浏览器中被看到。当它不带表单工作时，它作为客户端到服务器的通信。openidconnect和saml都需要能够呈现表单，这可以通过存在浏览器来实现，或者通过充当浏览器起作用的应用虚拟执行。在一个实施例中，通过idcs实现用户认证/sso的应用客户端需要作为oauth2客户端在idcs中注册，并且需要获得客户端标识符和凭证(例如，id/密码、id/证书等等)。图10的示例实施例包括共同提供登录能力的三个组件/微服务，包括两个平台微服务：oauth21004和saml21006，以及一个基础设施微服务：sso1008。在图10的实施例中，idcs提供“身份元系统”，其中在不同类型的应用(诸如需要三参与方oauth流并充当openidconnect中继方(“rp”，将其用户认证功能外包给idp的应用)的基于浏览器的web或本机应用1010、需要双参与方oauth流并充当openidconnectrp的本机应用1011以及充当samlsp的web应用1012)上提供sso服务1008。一般而言，身份元系统是用于数字身份的可互操作架构，从而允许基于多种底层技术、实现和提供者来采用数字身份的集合。ldap、saml和oauth是提供身份能力并且可以是用于构建应用的基础的不同安全标准的示例，并且身份元系统可以被配置为在这种应用之上提供统一的安全系统。ldap安全模型指定用于处理身份的具体机制，并严格保护系统的所有次通过。开发saml，以允许一组应用安全地与属于不同安全域中的不同组织的另一组应用交换信息。由于这两个应用之间没有信任，因此开发了saml，以允许一个应用对另一个不属于同一组织的应用进行认证。oauth提供了openidconnect，它是用于执行基于web的认证的轻量级协议。在图10的实施例中，当openid应用1010连接到idcs中的openid服务器时，其“通道”请求sso服务。类似地，当saml应用1012连接到idcs中的saml服务器时，其“通道”也请求sso服务。在idcs中，相应的微服务(例如，openid微服务1004和saml微服务1006)将处理每个应用，并且这些微服务从sso微服务1008请求sso能力。通过针对每个协议添加微服务，然后对于sso能力使用sso微服务1008，可以扩展这个架构，以支持任意数量的其它安全协议。sso微服务1008发布会话(即提供ssocookie1014)并且是架构中具有发布会话的权限的唯一系统。idcs会话通过浏览器1002使用ssocookie1014来实现。浏览器1002还使用本地会话cookie1016来管理其本地会话。在一个实施例中，例如，在浏览器内，用户可以使用基于saml的第一应用并且登录，并且随后使用由诸如oauth之类的不同协议构建的第二应用。在同一浏览器内的第二应用上向用户提供sso。因而，浏览器是状态或用户代理并且维护cookie。在一个实施例中，sso微服务1008提供登录仪式1018、id/密码恢复1020、首次登录流1022、认证管理器1024、httpcookie管理器1026以及事件管理器1028。登录仪式1018实现基于客户设置和/或应用上下文的sso功能，并且可以根据本地表单(即，基本auth)、外部samlidp、外部oidcidp等等进行配置。使用id/密码恢复1020来恢复用户的id和/或密码。当用户第一次登录时(即，sso会话尚不存在时)，实现首次登录流1022。认证管理器1024在成功认证时发布认证令牌。httpcookie管理器1026将认证令牌保存在ssocookie中。事件管理器1028公布与sso功能相关的事件。在一个实施例中，oauth微服务1004和sso微服务1008之间的交互是基于浏览器重定向，使得sso微服务1008使用html表单挑战用户、验证凭证并发布会话cookie。在一个实施例中，例如，oauth微服务1004可以从浏览器1002接收授权请求，以根据三参与方oauth流认证应用的用户。oauth微服务1004然后充当oidc提供者1030、将浏览器1002重定向到sso微服务1008，并沿着应用上下文传递。取决于用户是否具有有效的sso会话，sso微服务1008验证现有会话或者执行登录仪式。在成功认证或验证后，sso微服务1008将认证上下文返回到oauth微服务1004。然后oauth微服务1004用授权(“az”)代码将浏览器1002重定向到回调url。浏览器1002将az代码发送到oauth微服务1004，以请求所需的令牌1032。浏览器1002还在http授权报头中包括其客户端凭证(当在idcs中注册为oauth2客户端时获得的)。作为回报，oauth微服务1004向浏览器1002提供所需的令牌1032。在一个实施例中，提供给浏览器1002的令牌1032包括由idcsoauth2服务器签署的jw身份和访问令牌。这个功能的进一步细节在下面参考图11公开。在一个实施例中，例如，oauth微服务1004可以从本机应用1011接收授权请求，以根据双参与方oauth流来认证用户。在这种情况下，oauth微服务1004中的认证管理器1034执行对应的认证(例如，基于从客户端1011接收到的id/密码)，并且令牌管理器1036在成功认证后发布对应的访问令牌。在一个实施例中，例如，saml微服务1006可以从浏览器接收ssopost请求，以认证充当samlsp的web应用1012的用户。然后，saml微服务1006充当samlidp1038，将浏览器1002重定向到sso微服务1008，并沿着应用上下文传递。取决于用户是否具有有效的sso会话，sso微服务1008验证现有会话或者执行登录仪式。在成功认证或验证后，sso微服务1008将认证上下文返回给saml微服务1006。然后saml微服务用所需的令牌重定向到sp。在一个实施例中，例如，saml微服务1006可以充当samlsp1040并前往远程samlidp1042(例如，活动目录联合服务(“adfs”))。一个实施例实现标准saml/ad流。在一个实施例中，saml微服务1006和sso微服务1008之间的交互是基于浏览器重定向，使得sso微服务1008使用html表单挑战用户、验证凭证并发布会话cookie。在一个实施例中，通过防火墙1044执行idcs内的组件(例如，1004、1006、1008)与idcs外的组件(例如，1002、1011、1042)之间的交互。登录/注销流图11是在一个实施例中由idcs提供的sso功能的消息序列流1100。当用户使用浏览器1102访问客户端1106(例如，基于浏览器的应用或移动/本机应用)时，云门1104充当应用强制实施点并执行在本地策略文本文件中定义的策略。如果云门1104检测到用户没有本地应用会话，那么需要对用户进行认证。为了这样做，云门1104将浏览器1102重定向到oauth2微服务1110，以发起针对oauth2微服务1110的openidconnect登录流(范围＝“openid简档”的三参与方az授予流)。浏览器1102的请求遍历idcs路由层web服务1108和云门1104并到达oauth2微服务1110。oauth2微服务1110构造应用上下文(即，描述应用的元数据，例如，连接应用的身份、客户端id、配置，应用可以做什么等等)，并将浏览器1102重定向到sso微服务1112以便登录。如果用户具有有效的sso会话，那么sso微服务1112验证现有会话而不开始登录仪式。如果用户不具有有效的sso会话(即，不存在会话cookie)，那么sso微服务1112根据客户的登录偏好(例如，显示有品牌的登录页面)来发起用户登录仪式。为了这样做，sso微服务1112将浏览器1102重定向到以javascript实现的登录应用服务1114。登录应用服务1114在浏览器1102中提供登录页面。浏览器1102将restpost发送到包括登录凭证的sso微服务1112。sso微服务1112生成访问令牌并将其发送到restpost中的云门1104。云门1104将认证信息发送到管理scim微服务1116，以验证用户的密码。管理scim微服务1116确定成功的认证，并向sso微服务1112发送对应的消息。在一个实施例中，在登录仪式期间，登录页面不显示同意页面，因为“登录”操作不需要进一步的同意。相反，在登录页面上声明隐私政策，以通知用户关于向应用暴露的某些简档属性。在登录仪式期间，sso微服务1112尊重客户的idp偏好，并且如果被配置，那么重定向到idp，以针对经配置的idp进行认证。在成功认证或验证后，sso微服务1112利用包含用户的认证令牌的新创建/更新的sso主机httpcookie(例如，在由“hosturl”指示的主机的上下文中创建的cookie)将浏览器1102重定向回到oauth2微服务1110。oauth2微服务1110将az代码(例如，oauth概念)返回给浏览器1102并重定向到云门1104。浏览器1102将az代码发送到云门1104，并且云门1104将restpost发送到oauth2微服务1110，以请求访问令牌和身份令牌。这两个令牌都被限定到oauth微服务1110(由观众令牌声称来指示)。云门1104从oauth2微服务1110接收令牌。云门1104使用身份令牌将用户的经认证的身份映射到其内部账户表示，并且它可以将这个映射保存在其自己的httpcookie中。然后，云门1104将浏览器1102重定向到客户端1106。然后浏览器1102到达客户端1106，并从客户端1106接收对应的响应。从这个时候开始，浏览器1102可以无缝地访问应用(即，客户端1106)，只要该应用的本地cookie是有效的就可以。一旦本地cookie失效，认证过程就重复。云门1104还使用在请求中接收的访问令牌来从oauth2微服务1110或scim微服务获得“userinfo”。访问令牌足以访问用于“profile(简档)”作用域允许的属性的“userinfo”资源。经由scim微服务访问“/me”资源也是足够的。在一个实施例中，默认情况下，接收到的访问令牌仅适用于在“profile”范围下所允许的用户简档属性。访问其它简档属性是基于由云门1104发布的az授予登录请求中提交的附加(可选)范围来授权的。当用户访问另一个oauth2集成的连接应用时，重复相同的处理。在一个实施例中，sso集成架构使用相似的openidconnect用户认证流来进行基于浏览器的用户注销。在一个实施例中，具有现有应用会话的用户访问云门1104，以发起注销。可替代地地，用户可能已经在idcs侧发起了注销。云门1104终止特定于该应用的用户会话，并且发起针对oauth2微服务1110的oauth2openid提供者(“op”)注销请求。oauth2微服务1110重定向到杀死用户的主机ssocookie的sso微服务1112。sso微服务1112针对如在用户的ssocookie中被跟踪的已知注销端点发起重定向的集合(oauth2op和samlidp)。在一个实施例中，如果云门1104使用saml协议来请求用户认证(例如，登录)，那么在saml微服务和sso微服务1112之间开始相似的处理。云高速缓存一个实施例提供被称为云高速缓存的服务/能力。在idcs中提供云高速缓存，以支持与基于ldap的应用(例如，电子邮件服务器、日历服务器、一些业务应用等等)的通信，因为idcs不根据ldap进行通信，而此类应用被配置为仅基于ldap进行通信。通常，云目录经由restapi暴露，并且不根据ldap协议进行通信。一般而言，管理跨公司防火墙的ldap连接需要特殊的配置，这些配置难以建立和管理。为了支持基于ldap的应用，云高速缓存将ldap通信翻译为适合与云系统进行通信的协议。一般而言，基于ldap的应用经由ldap使用数据库。应用可以可替代地被配置为经由诸如sql之类的不同协议来使用数据库。但是，ldap在树结构中提供资源的分层表示，而sql将数据表示为表和字段。因而，ldap可能更适合搜索功能，而sql可能更适合于事务功能。在一个实施例中，由idcs提供的服务可以在基于ldap的应用中使用，以例如认证应用的用户(即，身份服务)或者为该应用强制实施安全策略(即，安全服务)。在一个实施例中，与idcs的接口是通过防火墙并基于http(例如，rest)的。通常，公司防火墙不允许访问内部ldap通信，即使通信实现了安全套接字层(“ssl”)，并且不允许通过防火墙暴露tcp端口。但是，云高速缓存在ldap和http之间进行翻译，以允许基于ldap的应用到达由idcs提供的服务，并且防火墙将对http开放。一般而言，ldap目录可以在一系列业务(诸如营销和开发)中使用，并且定义用户、组、工作等等。在一个示例中，营销和开发业务可以具有不同的有针对性的客户，并且对于每个客户，可以有其自己的应用、用户、组、工作等等。可以运行ldap高速缓存目录的一系列业务的另一个示例是无线服务提供者。在这种情况下，由无线服务提供者的用户进行的每个呼叫都针对ldap目录来认证用户的设备，并且ldap目录中的对应信息中的一些可以与计费系统同步。在这些示例中，ldap提供了在运行时在物理上隔离正在被搜索的内容的功能。在一个示例中，无线服务提供者可以在使用由idcs提供的服务以支持短期营销活动的同时处理用于其核心业务(例如，常规呼叫)的自身的身份管理服务。在这种情况下，当云高速缓存具有它针对云运行的单个用户集合和单个组集合时，云高速缓存将“扁平化”ldap。在一个实施例中，可以在idcs中实现任何数量的云高速缓存。分布式数据网格在一个实施例中，idcs中的高速缓存集群是基于分布式数据网格来实现的，如在例如美国专利公开no.2016/0092540中所公开的，其公开内容通过引用结合于此。分布式数据网格是一种系统，其中计算机服务器的集合在一个或多个集群中一起工作，以管理分布式或集群环境中的信息和相关操作(诸如计算)。分布式数据网格可以被用于管理跨服务器共享的应用对象和数据。分布式数据网格提供低响应时间、高吞吐量、可预测的可伸缩性、持续可用性和信息可靠性。在特定的示例中，分布式数据网格(诸如来自oracle公司的oraclecoherence数据网格)存储存储器中的信息，以实现更高的性能，并且在保持那种信息的副本跨多个服务器同步时采用冗余，从而在服务器发生故障的情况下确保系统的弹性和数据的持续可用性。在一个实施例中，idcs实现诸如coherence之类的分布式数据网格，使得每个微服务可以请求访问共享的高速缓存对象而不被阻塞。coherence是专有的基于java的存储器内数据网格，其被设计为比传统的关系型数据库管理系统具有更好的可靠性、可伸缩性和性能。coherence提供了点对点(即，没有中央管理器)、存储器内的分布式高速缓存。图12图示了分布式数据网格1200的示例，其存储数据并向客户端1250提供数据访问并实现本发明的实施例。“数据网格集群”或“分布式数据网格”是包括多个计算机服务器(例如，1220a、1220b、1220c和1220d)的系统，这些多个计算机服务器在一个或多个集群(例如，1200a、1200b、1200c)中一起工作，以在分布式或集群环境中存储和管理信息和相关操作(诸如计算)。虽然分布式数据网格1200被示为在集群1200a中包括四个服务器1220a、1220b、1220c、1220d，具有五个数据节点1230a、1230b、1230c、1230d和1230e，但是分布式数据网格1200可以包括任意数量的集群以及每个集群中任意数量的服务器和/或节点。在实施例中，分布式数据网格1200实现本发明。如图12中所示，分布式数据网格通过在一起工作的多个服务器(例如，1220a、1220b、1220c和1220d)上分布数据来提供数据存储和管理能力。数据网格集群的每个服务器可以是常规的计算机系统，诸如像具有一到两个处理器插槽和每个处理器插槽两到四个cpu核心的“商品x86”服务器硬件平台。每个服务器(例如，1220a、1220b、1220c和1220d)被配置有一个或多个cpu、网络接口卡(“nic”)和存储器，其中存储器包括例如至少4gb的ram，高达64gbram或更多。服务器1220a被示为具有cpu1222a、存储器1224a和nic1226a(这些元件在其它服务器1220b、1220c、1220d中也存在，但未示出)。可选地，每个服务器也可以提供有闪存(例如，ssd1228a)，以提供外溢(spillover)存储容量。在被提供时，ssd容量优选地是ram的尺寸的十倍。数据网格集群1200a中的服务器(例如，1220a、1220b、1220c、1220d)使用高带宽nic(例如，pci-x或pcie)连接到高性能网络交换机1220(例如，千兆以太网或更好)。集群1200a优选地包含最少四个物理服务器，以避免在故障期间丢失数据的可能性，但是典型的安装具有多得多的服务器。每个集群中存在的服务器数量越多，故障转移和故障回复的效率越高，并且服务器故障对集群的影响更小。为了最小化服务器之间的通信时间，每个数据网格集群理想地限于提供服务器之间的单跳通信的单个交换机1202。因此，集群可以受到交换机1202上的端口数量的限制。因此，典型的集群将包括4到96个物理服务器。在分布式数据网格1200的大多数广域网(“wan”)配置中，wan中的每个数据中心具有独立但互连的数据网格集群(例如，1200a、1200b和1200c)。wan可以例如包括比图12中所示的多得多的集群。此外，通过使用互连但独立的集群(例如，1200a、1200b、1200c)和/或在彼此远离的数据中心中定位互连但独立的集群，分布式数据网格可以保护到客户端1250的数据和服务，防止由于自然灾害、火灾、洪水、延长的掉电等造成的一个集群中的所有服务器的同时丢失。一个或多个节点(例如，1230a、1230b、1230c、1230d和1230e)在集群1200a的每个服务器(例如，1220a、1220b、1220c、1220d)上操作。在分布式数据网格中，节点可以是例如软件应用、虚拟机等，并且服务器可以包括节点在其上操作的操作系统、管理程序等(未示出)。在oraclecoherence数据网格中，每个节点都是java虚拟机(“jvm”)。取决于服务器上可用的cpu处理能力和存储器，可以在每个服务器上提供多个jvm/节点。可以根据分布式数据网格的需要添加、开始、停止和删除jvm/节点。运行oraclecoherence的jvm在被开始时自动加入集群。加入集群的jvm/节点被称为集群成员或集群节点。每个客户端或服务器包括用于传送信息的总线或其它通信机制，以及耦合到总线以用于处理信息的处理器。处理器可以是任何类型的通用或专用处理器。每个客户端或服务器还可以包括用于存储要由处理器执行的信息和指令的存储器。存储器可以由随机存取存储器(“ram”)、只读存储器(“rom”)、诸如磁盘或光盘的静态存储器或任何其它类型的计算机可读介质的任意组合组成。每个客户端或服务器还可以包括通信设备，诸如网络接口卡，以提供对网络的访问。因此，用户可以直接与每个客户端或服务器进行接口，或者通过网络或其它任何方式进行远程接口。计算机可读介质可以是可由处理器访问的任何可用介质，并且包括易失性和非易失性介质、可移动和不可移动介质以及通信介质。通信介质可以包括计算机可读指令、数据结构、程序模块或者经调制的数据信号(诸如载波或其它传输机制)中的其它数据，并且包括任何信息传递介质。处理器还可以经由总线耦合到显示器，诸如液晶显示器(“lcd”)。键盘和光标控制设备(诸如计算机鼠标)也可以耦合到总线，以使得用户能够与每个客户端或服务器进行交互。在一个实施例中，存储器存储在由处理器执行时提供功能的软件模块。这些模块包括为每个客户端或服务器提供操作系统功能的操作系统。这些模块还可以包括用于提供云身份管理功能的云身份管理模块以及本文公开的所有其它功能。客户端可以访问网络服务，诸如云服务。在一个实施例中，web服务可以在来自oracle公司的weblogicserver上实现。在其它实施例中，可以使用web服务的其它实现。web服务访问存储云数据的数据库。本地写入一般而言，诸如oracle公共云(“opc”)之类的公共云旨在通过使诸如虚拟机(“vm”)、应用和存储之类的资源经互联网对公众可用来向全球客户提供和支持iaas、paas和saas服务。公共云已知具有多个数据中心，每个数据中心位于不同的地理区域，以向位于最靠近相应数据中心的客户以最小等待时间提供服务。在实施例中，公共云服务可以部署在覆盖由物理边界分开的客户的不同数据中心(称为“区域”)中。图13示出了根据一个实施例的具有多个部署的数据中心(指定为“dc”)的公共云1300，每个数据中心形成“区域”。例如，数据中心1301位于加拿大的城市中，数据中心1302位于德国的城市中，并且数据中心1303位于澳大利亚的城市中。在实施例中，一个或多个数据中心被集成到一个“岛”中，该“岛”由一个或多个“控制平面”部署(指定为“cp”)管理。岛是集成到一个“云”中并由一个控制平面管理的区域的集合。例如，控制平面1310管理数据中心1301、1304、1305、1306和1307，而控制平面1311管理数据中心1308和1309。基于可伸缩性要求和不同区域中的客户负载，典型的控制平面部署可以服务一个或多个区域。在控制平面组件服务多于一个区域的情况下，在一个实施例中，该组件需要特权来用单个身份与所有区域交互。对于购买/获得各种公共云服务的每个用户/客户，由云1300维护客户账户。可供客户使用的一种服务可以是上面公开的多租户身份管理服务或idcs，其可以被实现为控制平面组件并且分开部署在每个区域(即，每个数据中心)中以保护那个区域的资源。如所讨论的，在一个实施例中，未被部署在特定区域中的控制平面需要特殊特权来与它未被部署的区域中的组件或租户交互。例如，在一个区域中定义的控制平面组件可能期望访问位于另一个区域的idcs客户租赁(即，托管在不同的idcs部署中)。这要求在这些部署之间以允许被分配给一个区域中的idcs的组件/客户针对其它区域中的idcs调用idcsapi(例如，访问图6的idcs微服务614的特定微服务)的方式建立信任。在已知的解决方案中，在一个区域中定义并分配给一个区域的用户只能从该区域而不能从其它区域访问资源和获得认证。作为对照，在实施例中，在一个区域中具有新颖的访问令牌(称为“全局访问令牌”或“全局令牌”)的用户可以使用相同的全局令牌访问另一个区域(即，远程区域)中的资源。实施例涉及如何在区域之间建立信任以便管理各种idcs区域以允许提供资源和认证功能，而无论用户/客户位于何处。通常，需要向用户提供全局令牌以允许跨区域信任功能。然后，该全局令牌由目的地信任中心消耗。例如，“客户端”(即，用户或用于访问服务的任何应用或程序方法)可以仅存在于芝加哥中的数据中心1307中(它最初被建立的地方)。每个客户端都有其自己的身份并且需要验证自己并获取令牌。假设客户端在云1300的任何其它数据中心(诸如位于悉尼的数据中心1303)(即，其它数据中心中的idcs部署)中不存在或没有足迹。因此，如果客户端物理地位于悉尼附近，则该客户端无法通过悉尼数据中心进行认证，因为它在那里不存在。为了解决这个问题，实施例生成全局访问令牌以提供所需的跨区域信任。因此，客户端将在芝加哥进行认证，然后请求在悉尼兑换全球访问令牌。芝加哥dc1307将生成全局令牌并使用全局私钥对全局令牌进行签名。全局私钥在所有dc中都可用。在实施例中，全局访问令牌仅用于访问idcsrestapi，使得使用该全局令牌跨区域访问非idcsrestapi将导致错误。悉尼dc1303中的idcs部署在被呈现全局令牌时会消耗全局令牌并进行验证。然后，即使客户端未在悉尼中定义，该客户端还可以访问悉尼中的资源。在实施例中，客户端仅需要在单个idcs部署中定义，但仍然可以访问其它部署中的资源。图14是根据实施例的使用远程数据中心区域中的基于多租户云的iam系统和全局访问令牌来访问远程数据中心中的资源的功能的流程图。在一个实施例中，图14(以及下面的图15)的流程图的功能由存储在存储器或其它计算机可读或有形介质中的软件实现，并由处理器执行。在其它实施例中，该功能可以由硬件(例如，通过使用专用集成电路(“asic”)、可编程门阵列(“pga”)、现场可编程门阵列(“fpga”)等等)或者由硬件和软件的任何组合执行。在1402处，客户端或任何基础设施组件期望访问该客户端没有物理足迹的区域(即，客户端不是登记客户或是未注册的远程区域)中的资源。在一个实施例中，通过针对位于远程区域中的idcs部署调用idcsapi来访问“资源”，并且资源是idcsrestapi资源。idcsapi可以对应于用于执行idcs任务的许多微服务之一，诸如图6的微服务614，或者它可以是结合图7的714描述的restapi。实施例中的客户端可以是oracle云控制平面实例，诸如psm(paas服务管理器)、租户自动化系统(“tas”)、存储控制平面等等。在1404处，客户端获取该客户端具有足迹的区域中或者该客户端被注册的区域(即，期望的资源被管理的不同数据中心/区域)中的全局访问令牌。在一个实施例中，全局令牌可以在同一岛上的另一个区域中进行兑换，或者在另一个实施例中可以在公共云1300的任何其它区域中进行兑换。在一个实施例中，客户端仅在一个idcs区域/部署中被注册。在1406处，然后在远程区域(即，客户端没有物理足迹的区域)中验证全局访问令牌。在一个实施例中，“全局访问令牌发布者”通过检查客户端的角色成员资格(称为“全局客户端角色”)来验证全局令牌获取请求的特权，并向客户端发布全局访问令牌。在一个实施例中，基础设施组件将其操作请求连同全局访问令牌发送到目标端点，该目标端点可能位于与发布全局令牌的区域不同的区域中。在1408处，然后通过使云门(例如，图7的云门702)将请求转发到实际资源(即，远程区域的idcs)并且然后使azfilter在远程区域中消耗全局令牌来消耗全局访问令牌。azfilter是部署在idcs中的授权模块，每次调用idcsrestapi时都将调用该授权模块，以确保客户端具有必要的特权(在访问令牌中指定)来调用该特定的idcsrestapi。保护所请求的资源端点的云门代理通过使用“全局令牌发布者”的“公钥”来验证全局令牌是由属于同一岛(在一个实施例中)的idcs部署和签名机构的签名来发布的。在1410处，然后在远程区域中访问期望的资源。在一个实施例中，使用了规范(canonical)模型，因为给定岛的不同区域中的所有idcs部署都被配置为彼此信任或信任“全局受信任的实体”。在组件没有物理足迹的远程区域中执行操作的任何请求总是伴随着由全球受信任的实体签名的全局令牌。由于预先建立的信任，全局令牌可以在岛的任何区域中或在其它实施例中在公共云的任何区域中被验证。在一个实施例中，岛中的每个idcs部署被配置为全局访问令牌发布者。在一个实施例中，全局访问令牌仅在发布其的岛内有效。向每个全局访问令牌发布者供应称为“全局签名密钥”的签名密钥。在一个实施例中，向每个idcs部署供应相同的全局签名密钥。在另一个实施例中，向每个idcs部署供应其自己的“认证密钥”，该认证密钥可以用于从中央机构获取签名密钥。该认证密钥还可以用于从该中央机构检索所有受信任的idcs部署的公钥。这还使得在区域idcs部署中能够滚动签名密钥。在另一个实施例中，一个或多个全局令牌发布者被分开部署而不是作为idcs部署的一部分进行组合。在实施例中，向在岛中具有跨区域交互要求的每个基础设施组件供应具有高特权角色(即，全球idcs客户端角色)的oauth客户端。在实施例中，全局idcs客户端角色是向其成员授予跨区域idcs特权的idcs角色。在实施例中，该角色仅在'idcs-cloudinfra-<region>'租赁中被播种，作为具有应用id'idcsappid'的idcs应用的一部分，并且只能被授予'idcs-cloudinfra-<region>'租赁中所选择的控制平面组件。在实施例中，全局idcs客户端角色仅可以作为idcs播种工具的一部分被授予，该播种工具调用为控制平面组件播种安全工件的/sm/v1/appservices端点。全局idcs客户端角色指示该客户端可以获取全局令牌并且可以在本地idcs部署以及其它远程idcs部署中同等地兑换该令牌。idcs范围“globalclient”由idcsaz策略授予全局idcs客户端角色。客户端基于其可能具有的其它角色获取api访问特权。在一个实施例中，使用如下参数定义全局idcs客户端角色：displayname:“globalidcsclient”adminrole:falseavailabletousers:falseavailabletogroups:falseavailabletoclients:true在实施例中，全局密钥对是用于对全局令牌进行签名的密钥。该签名密钥对存在于idcs-oracle租赁中的每个idcs部署中，并且存储在cross_idcs_key别名下并由idcs-cloudinfra-<region>oauth服务用于对全局令牌进行签名。可以使用idcs系统控制台手动重新生成/重新上传全局密钥对。在一个实施例中，所有idcs部署具有相同的全局密钥对，因此本地全局密钥对的公钥也将是所有远程idcs部署的全局公钥。在另一个实施例中，每个idcs部署具有不同的全局密钥对，因此本地idcs部署需要能够存储每个远程idcs-cloudinfra-<region>租赁的全局公钥。在一个实施例中，全局令牌是oauth访问令牌，其可以仅由客户端具有足迹的一个区域中的“全局idcs客户端”获取，并且由请求区域中的oauth服务器使用全局密钥来签名。在一个实施例中，oauth访问令牌或“身份令牌”至少包括指示用户租户名字(即，用户所在的地方)的声称/声明。与授权令牌相关的“声称”(如由安全领域的普通技术人员所使用的)是一个主题对自己或另一个主题做出的声明。例如，声明可以是关于名字、身份、密钥、组、特权或能力。声称由提供者发布，并且它们被给予一个或多个值，然后被打包在由发布者发布的安全令牌中，通常称为安全令牌服务(“sts”)。在一个实施例中，访问令牌至少包括指示在对访问令牌做出请求时的资源租户名字(例如，客户)的声称/声明，指示用户租户名字的声称、指示做出请求的oauth客户端的名字的声称以及指示客户端租户名字的声称。在一个实施例中，访问令牌可以根据以下json功能来实现：在一个实施例中，客户端断言令牌包括至少指示客户端租户名字的声称以及指示做出请求的oauth客户端的名字的声称。在一个实施例中，全局访问令牌可以在同一岛内的另一个区域中进行兑换。全局访问令牌是具有以下除了常规oauth访问令牌的标准oauth声称之外的加粗和加下划线的oauth声称的访问令牌：为了获取全局访问令牌，在一个实施例中，执行全局idcs客户端的归属区域(即，客户端具有物理足迹的区域)中的以下事件序列：1.客户端将访问令牌请求发送到https://idcs-cloudinfra-<region1>.identity.oraclecloud.com/oauth2/v1/tokens·资源租赁＝idcs-cloudinfra-<region1>，和·观众＝idcs-cloudinfra-<region1>.identity.oraclecloud.com2.“idcs-cloudinfra-<region1>”区域中的oauthserver针对“全局idcs客户端”角色检查oauthclient的角色。3.在普通场景中，客户端没有“全局idcs客户端”角色。oauth服务器将其识别为常规客户端，并发布具有经认证的特权的常规令牌。4.如果客户端具有“全局idcs客户端”角色，则a.oauth服务器推断它需要'globalkey'来对令牌进行签名并从idcs部署配置中获取该令牌b.'全局令牌'用以下建造：·token.iss＝https://idcs-cloudinfra-uscom-central-1.identity.oraclecloud.com·token.clientid＝<用globalclient角色请求客户端>·token.gt＝true·token.locationid＝locationid(又称islandid)·token.audience＝https://idcs-cloudinfra-<region1>.identity.oraclecloud.com5.oauthserver用“全局签名密钥”对令牌进行签名，并将“全局令牌”返回给请求客户端。为了验证全局访问令牌，在一个实施例中，执行全局idcs客户端的远程区域(即，客户端不具有物理足迹的区域)中的以下事件序列：1.全局idcs客户端尝试通过呈现“全局令牌”来访问资源2.该请求被idcscg(云门)拦截3.在idcs-cloudinfra-<region2>中注册的idcscg检查令牌并遵循以下逻辑4.如果token.gt属性未被设置或为false，则：a.令牌是常规令牌。b.如果资源租赁的公共签名密钥尚未在高速缓存中，则获得它。c.idcscg用公钥验证令牌。d.如果令牌有效，则·将请求转发给idcse.否则发送失败响应(401)5.如果token.gt属性被设置并且其值为true，则是'全局令牌'a.cg将调用在idcs内部url上暴露的新的getglobalkey(tenant)api，以检索发布者元素中指定的租赁的全局密钥。如果为不同部署给予了不同的全局密钥，则这是需要的。如果没有，则cg应该已具有globalkey。最初，api可以为所有区域返回相同内容。b.az策略还引入了新的范围“globalidcsclient”，从而允许它调用getglobalkey(tenant)api。这个范围只能给cg，因为这个调用将只能由cg进行。c.idcscg将核实签名和令牌的各种元素，诸如到期。任何验证失败导致：·“http/1.1401未经授权的www-认证：承载错误＝“invalid_token”，error_description＝“<text>”，其中<text>是“令牌过期”、“令牌签名”、“令牌观众”、“令牌租户”。d.一旦签名被核实，它就通过'locationid'验证令牌，即·idcscg将使用发现api来发现本地部署的“locationid”。·将发现的'locationid'值与令牌的'token.locationid'属性进行比较。·如果没有匹配，则抛出“未经授权”错误。·如果匹配，cg将检查客户端是否还有租户范围。交叉租户范围1.获取访问令牌的观众url(idcs-cloudinfra-<region1>)2.替换“资源租赁”的租户值(idcs-<tenant>)3.针对访问令牌的aud声称验证目标url6.一旦已验证令牌，cg就将请求转发给idcs，其中(区域2中https://idcs-<tenant>.identity.oraclecloud.com/<endpoint>)7.请求到达区域2中的https://idcs-<tenant>.identity.oraclecloud.com/<endpoint>'中的idcs服务。一旦已验证全局令牌，为了兑换全局访问令牌，cg就将请求转发给实际资源，在这种情况下为idcs，并且azfilter将消耗全局令牌：1.'区域2'中的authz过滤器评估对令牌的授权a.azfilter然后将评估全局访问令牌中列出的范围。·如果范围没有被识别——它将忽略并记录错误。(idcs版本不匹配)。并返回401——未经授权的响应。·如果角色不匹配——它将忽略并记录错误。b.azfilter将构建idcssubject，其中clientid存储在全局访问令牌中。c.当调用idcs管理服务上的rest服务时，这将在审计事件中作为actorid进行审计。d.引入actortenantname以由azfilter初始化并由eventmanager写入审计。在一个实施例中，下游组件将需要确保他们没有正在尝试使用全局访问令牌中提供的clientid来定位idcs应用，因为这将导致远程idcs部署中的错误——因为客户端未在那里被定义。如所公开的，全局访问令牌允许客户端访问该客户端不具有idcs实例的副本区域中的资源。但是，客户端希望做的可能不仅仅是访问另一个区域中的资源。例如，对于已知系统，如果客户端想要在一个区域(例如，芝加哥或“主”数据中心)中创建身份云账户或idcs部署，则客户将创建该账户。但是，如果该同一客户想要在另一个区域(例如，阿姆斯特丹)中使用其身份，以使用该区域中的工作负载，那么该客户必须首先在阿姆斯特丹创建新的身份云账户，这导致为同一客户创建两个分开的身份账户。否则，该客户可以保持与第一区域的通信，但是如果客户是在阿姆斯特丹中并且被迫使用芝加哥中的工作负载，则会导致大的时延。作为对照，本发明的实施例将自动把芝加哥(即“主”数据中心)中的客户的身份云账户复制到阿姆斯特丹(即“副本”数据中心)或任何其它区域。在一个实施例中，将给予客户/租户在芝加哥使用来自阿姆斯特丹的现有账户的选项，这将导致信息被引导至阿姆斯特丹，并且然后将连续捕获并复制更改。这需要将来自一个区域的一些或所有数据/资源在另一个区域中被复制。另外，结合以上公开的全局访问令牌的使用，可以使用写入url或读取url访问实施例中来自idcs系统或特定idcs实例的数据。对于读取url(即读取数据)，已知的系统将访问最近的区域/数据中心处的该数据，以便最小化数据已被复制到其它区域时的时延。但是，对于写入url(即，更改数据或添加新数据)，已知的idcs系统中的默认情况是访问客户的主数据中心处而不是地理上最近的数据中心处的数据。但是，在一些情况下，当期望使用最近的数据中心(称为“本地写入”)以便进行立即数据更改(即最小时延)时，客户端将使用读取url(也称为“全局url”)来执行写入(即数据的更改)。这通常不被允许，因为任何写入都应该在主区域上进行并且然后被复制到副本区域上，因此会导致意外的复制和时序问题。因此，为了在副本站点处的本地idcs实例上适应本地写入，需要与主站点同步。图15是图示根据本发明的实施例的在客户端/客户/租户的主idcs实例/区域/数据中心1502和副本idcs实例/区域/数据中心1504之间执行本地写入的功能的流程图。在1506处，在租户(“租户1”)的副本区域1504处接收到针对资源“应用(apps)”的本地写入请求。该请求被接收为url：“https://...tenant1/admin/v1/apps...”，其指示管理服务1501(即图6的614中的平台服务)是所请求的微服务并且执行大多数功能。在实施例中，本地写入请求功能仅可用于以下资源：应用、应用角色(approles)、组、用户、授权。在其它实施例中，该功能可以用于所有系统资源。在1510处，确定本地写入租户是否是主区域。在图15的示例中，答案是“否”，因为主区域1502是租户1的主区域。因此，在1512处，基于识别出的支持本地写入的资源列表，确定资源是否需要本地写入。如果所有资源支持本地写入，则不需要1512处的功能。如果在1512为“是”，则在1514处，通过对主区域1502进行调用来实现对主区域的写入。生成的调用1551使用主区域1502的云门1550(“cg”)，并使用类似于初始写入url的url进行写入。但是，来自主区域1502的响应将返回附加信息(例如，所有属性)。主url上的写入包括使用全局签名密钥签名的特殊报头(“本地写入报头”)。这防止任何客户端无任何限制地访问数据。主区域1502通过使用全局签名密钥解密值来验证/认证报头。特殊报头的示例如下：报头名称值详细信息local_write区域名称包含发起请求的区域的名称local_write_tsputc-time以utc发起请求时的时间在主区域1502的管理服务1571内，在1552处，确定主区域1502是租户1的主区域。在1554处，确定请求是否包括本地写入报头。如果在1554处为“是”，则在1562处，管理服务1571读取并写回属性。作为本地写入请求的一部分的所有属性将被写入到主区域和副本区域两者中。在1580处，管理服务1571从租户数据库1564请求并接收租户请求数据。在1581处，检索到的数据(即租户1期望更改的数据)被发送到副本。返回在副本1504处，在1514处，对在1581处从主区域1502发送的数据实现写入(即更改数据)。复制服务1520然后将修正的数据存储在租户数据库1522中，并且然后将修正的数据复制到主区域1502以及存储租户1的数据的任何其它副本。再次参考1512，该资源可以是例如不在列表上的“策略”。策略资源不在本地写入列表上，因为它不需要立即更新副本1504上的数据。作为对照，对于“用户”资源，诸如更改用户密码，需要(在主区域1502上更改之后)立即对副本1504进行更改。因此，不是在1514处进行本地写入，而是在1590处以http307重定向响应的形式将请求重定向回客户端。idcs将经由http307重定向响应把租户的写入url提供给客户端。客户端预期遵循来自http状态307的重定向url(即写入url)执行写入操作。在一个实施例中，单个url既用于读取又用于写入。在其它实施例中，将使用两个不同的url，一个用于读取，一个用于写入。这允许使用arm库在idcs的中间层(即微服务)中进行决策，而不是路由层。具体而言，租户可以使用单个url(读取url)既执行读取操作又执行写入操作。对于支持本地写入的资源，idcs将在客户端的额外努力下负责更新主区域和副本区域。对于不是本地写入范围的一部分的资源，经由读取url到达副本的请求将导致“具有写入url作为响应的http307重定向”，以便客户端自动遵循重定向url在主区域中执行写入操作。这允许客户端的应用使用一个url用于所有操作，而不必使用两个不同的url(即用于读取的读取url和用于写入的写入url)。抽象资源管理器(“arm”)是idcs库，其管理使用idcs微服务(例如，管理服务、oauth服务等)发生的所有与数据相关的操作。在arm中做出本地写入决策允许idcs控制资源级别本地写入范围。如所公开的，使用全局url(即全局访问令牌)做出的客户端/工作负载请求将被路由到具有相应的租户足迹的最近idcs。本地写入基于给定租户的出生地和资源范围来管理请求。“出生地”是租户首先被创建的数据中心。“资源范围”是支持本地写入的资源。路由决策发生在中间层，该中间层给与完全控制以分析请求有效负载并执行选择性的本地写入或重定向。实施例从url发现向客户端提供抽象，并且不需要修改其服务来决定写入到哪里。实施例利用高效的双重写入技术向本地工作负载提供立即读取一致性，该双重写入技术使用直接数据库提供者执行本地写入以避免验证开销。如果没有这个特征，客户端/服务将需要发现写入url来在主区域中执行写入操作。利用这个特征，客户端/服务可以使用一个url(即“抽象”)对客户端/服务附近的副本/主区域中的支持本地写入的资源执行读取和写入操作。另外，实施例经由直接数据库提供者执行副本中的写入以获得更好的性能。实施例通过使用能够理解异构模式的复制服务避免模式依赖性来处理异构写入。即使当主区域运行与副本区域不同的(即异构)模式/版本时，实施例也工作。实施例由于不违反允许经由从源的复制/协调进行故障管理的单个主架构，因此使得能够实现客户端无关的容错能力。实施例在副本区域中写入(即单个主复制)之前首先在主区域中执行写入以避免冲突，并维护主区域作为用于协调的真实情况的源。最后，实施例使用利用特殊签名报头的安全握手。如所公开的，实施例允许租户对副本身份账户执行本地写入，而不必首先在主身份账户处执行写入。实施例使用全局签名密钥。本地写入允许以最小时延实现副本账户处的更改，并且特别适合于需要立即生效的功能，诸如密码更改。另外，实施例允许使用单个类型的url(即全局url)用于读取和写入操作两者。本文具体地图示和/或描述了若干实施例。但是，应当认识到的是，在不背离本发明的精神和预期范围的情况下，所公开的实施例的修改和变化被上述教导涵盖并在所附权利要求的范围内。当前第1页12