CN109417557B - 认证访问托管应用的客户端的方法、系统和计算机可读介质 - Google Patents

Abstract

可以实现针对数据中心网络的特定租户定制的灵活认证技术。例如，管理员可以指定主要认证服务器，并且针对给定租户指定不同应用将在哪些数据中心处被托管。终端用户可以避免实现这种配置细节的复杂性。例如，即使在应用被配置为托管在不同的数据中心中时，也可以实现单点登录认证。因此，企业租户可以控制托管应用的位置，并且强制实现数据容纳场景，而不会以附加的任务妨碍用户。可以实现协作和应用到应用认证。

Description

认证访问托管应用的客户端的方法、系统和计算机可读介质

相关申请的交叉引用

本申请要求2016年6月6日提交的美国临时申请No.62/346,367的权益，该申请由此通过引用结合于此。

技术领域

本发明涉及一种用于对客户端进行认证的方法和计算系统。

背景技术

计算服务提供商面临着在提供统一、用户友好的计算平台和授予客户对此类平台的控制和定制能力之间的平衡做法。例如，在平台中包含专门的功能可能对一组应用有帮助，但对其他应用来说可能会增加复杂性。特别具有挑战性的领域是网络安全。

此外，即使企业内部和企业之间的合作成为常态，一个企业可能会向某些技术迁移，而另一企业会向其他技术迁移。因此，计算服务提供商面临的挑战是既要满足他们的客户，又要提供统一的平台。存在适应这种场景的系统，但是在现实世界的企业计算场景中会出现限制，特别是在网络安全的技术领域。

因此，还有改进的余地。

发明内容

提供发明内容以便以简化形式介绍一系列概念，将在下面的具体实施方式中进一步描述这些概念。发明内容并非旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。

在一个实施例中，一种对访问多个应用托管平台实例的集群的客户端进行认证的计算机实现的方法，包括：在应用托管平台的第二实例处，从客户端接收访问在集群的第二应用托管平台实例上托管的第二应用的请求，该客户端经由认证令牌被认证以访问在集群的第一应用托管平台实例上托管的第一应用；响应于请求，从客户端将认证令牌提取到应用托管平台的第二实例；将集群的应用托管平台实例中的一个应用托管平台实例确定为主要认证应用托管平台实例；向主要认证应用托管平台实例发送针对认证令牌的验证请求；从主要认证应用托管平台实例接收对认证令牌的验证确认；以及响应于接收到验证确认，向客户端准予对在第二应用托管平台实例上托管的第二应用进行访问。

在另一实施例中，一种计算系统，包括：一个或多个处理器；存储器；多个应用托管平台实例，其包括被配置为存储和验证认证令牌的相应平台认证服务、一个或多个相应托管的应用以及针对多个租户的租户特定认证配置信息；其中，应用托管平台实例的平台认证服务被配置为根据租户中的给定租户的租户特定认证配置信息而用作主要平台认证服务；并且其中，平台认证服务被配置为将认证请求从针对给定租户的托管的应用重定向到在租户特定认证配置信息中针对给定租户指定的主要平台认证服务。

在另一实施例中，一种或多种计算机可读介质，包括计算机可执行指令，该计算机可执行指令当被执行时，使得计算系统执行一种方法，该方法包括：在跨越支持多个租户的多个数据中心的计算集群中，从经由承载认证令牌被认证以访问第一应用的客户端接收访问第二应用的请求，该承载认证令牌由于由在针对多个租户中的特定租户的确认信息中指定的身份提供商进行的认证而被主要平台认证服务准予；从客户端提取承载认证令牌；针对客户端确定主要认证应用托管平台实例；向主要认证应用托管平台实例的主要平台认证服务发送认证请求以用于验证，其中，认证请求包括承载认证令牌、特定租户的租户标识符、第二应用的应用实例标识符以及第二应用的应用秘密；从主要平台认证服务接收指示认证请求有效的通信；以及响应于接收到认证请求有效的通信，准予由客户端对第二应用进行访问；其中，第一应用由在第一数据中心处执行的应用托管平台的第一实例托管，并且第二应用由在不同的第二数据中心处执行的应用托管平台的不同的第二实例托管。

如本文描述的，各种其他特征和优点可以根据需要包含到这些技术中。

附图说明

图1是实现租户感知分布式应用认证的示例系统的框图。

图2是实现租户感知分布式应用认证的示例方法的流程图。

图3是存储用于实现租户感知分布式应用认证的租户特定配置信息的示例系统的框图。

图4是实现租户感知分布式应用认证的配置的示例方法的流程图。

图5是可以存储为租户特定认证配置信息的、特定租户的示例关系的框图。

图6是在租户感知分布式应用认证场景中实现新用户供应的示例系统的框图。

图7是在租户感知分布式应用认证场景中供应新用户的示例方法的流程图。

图8是在租户感知分布式应用认证场景中认证对应用的访问的示例系统的框图。

图9是在租户感知分布式应用认证场景中认证对应用的访问的示例方法的流程图。

图10是当在租户感知分布式应用认证场景中访问第二应用时实现单点登录的示例系统的框图。

图11是当在租户感知分布式应用认证场景中访问第二应用时实现单点登录的示例方法的流程图。

图12是可以实现所描述的实施例的示例计算系统的示图。

具体实施方式

如本文描述的，可以为多个租户中的任何一个指定灵活的认证配置。可以实现对应用被托管的位置的控制，同时还可以实现诸如单点登录之类的此种用户功能。可以使用与身份提供商和审核相关的其他特征来实现如本文描述的技术。

如本文描述的，针对访问应用的认证可以分布在多个应用托管平台实例(例如，平台集群)之间。平台可以被设计成租户感知的，因为不同的租户可以指定不同的主要平台实例、不同的优选身份提供商、托管不同应用的不同位置等。这种信息可以由系统接收，作为在本文中描述的认证配置。

无论在哪里托管应用，针对访问应用的请求都可以针对主要平台认证服务进行验证，从而为应用产生独立于平台位置的认证路由。

如果客户端已经被认证，则可以针对主要平台认证服务无缝提取和验证认证令牌，从而产生异构应用托管位置之间的无缝单点登录。可以在配置信息中指定主要认证服务，从而产生每个租户可配置的主要平台认证服务规范和租户指定的主要认证平台实例(例如，其托管主要平台认证服务)。

管理员可以从这些技术中受益，因为即使当不同的系统位于不同的数据中心、不同的管辖区等时，也可以实现集中管理，而不是不同系统的混杂。可以保持对应用被托管的位置的控制。

用户也可以通过避免因累积的繁重管理任务导致的错误和停机时间而受益。此外，用户可以在不一定感知到这种复杂性的情况下跨数据中心的阵列无缝地访问各种应用。可以减少计算和网络资源，因为如本文描述的，可以避免多次登录。

因此，如本文描述的，可以增强针对访问应用的认证的整体性能。

示例1-实现租户感知

分布式应用认证的示例系统

图1是实现租户感知分布式应用认证的示例系统100的框图。

在该示例中，多个租户110A-N与用户标识符120相关联，用户标识符120经由一个或多个网络105访问在相应的数据中心130A-N处执行的多个应用托管平台实例135A-N。

如本文描述的，租户110A-N可以通过如本文描述的在配置信息中指定优选身份提供商服务来利用多个身份提供商服务190中的任何一个。平台认证服务140A-N可以初始地经由在租户特定配置信息中指定的身份提供商服务190对请求访问应用150A-N的客户端进行认证。平台认证服务可以基于租户特定配置信息将初始认证请求中继到身份提供商服务。可以支持多个不同的身份提供商服务。

应用托管平台实例135A-N中的任何一个可以包括相应的平台认证服务140A-N、供应的用户记录160A-N、存储的认证令牌记录170A-N、管理服务180A和认证配置信息185A-N。

因此，多个应用托管平台实例135A-N可以包括相应的平台认证服务140A-N，其被配置为存储和验证认证令牌(例如，存储为认证令牌记录170A-N)。实例还可以包括针对多个租户(例如，110A-N)的相应托管的应用150A-N和认证配置信息185A-N。

应用托管平台实例135A-N的平台认证服务140A-N中的优选的一个平台认证服务可以被配置为根据租户110A-N中的给定租户的租户特定配置信息185A-N而用作主要平台认证服务。

平台认证服务140A-N被配置为将来自针对给定租户的托管应用150A-N的认证请求重定向到租户特定配置信息185A-N中针对给定租户指定的主要平台认证服务。

重定向的认证请求可以包括对从请求客户端(例如，120)取回的认证令牌进行验证的请求并且从一个平台认证服务重定向到另一平台认证服务以用于验证。如本文描述的，从客户端的角度来看，这种重定向可以自动且无缝地实现。

如本文描述的，可以支持单点登录，使得在一个平台实例处访问应用的用户标识符可以在另一平台实例处访问应用，而不必重复登录过程。如本文描述的，租户可以指定应用托管平台实例135A-N中的一个作为主要认证平台实例。因此，针对认证的请求定向到在指定实例上托管的平台认证服务。

多个应用托管平台实例可以用作给定租户的平台集群。可以在不与身份提供商服务进一步交互的情况下，处理访问集群内的第二应用或后续应用的请求。

在本文的示例中的任何一个中，尽管在单个框中显示子系统中的一些子系统，但是实际上，这些子系统可以实现为具有一个以上设备的计算系统。组件之间的边界可以变化。例如，尽管数据中心130A被示出为单个实体，但是可以由跨多个建筑物的多个设备来实现。身份提供商190可以在数据中心130A-N中的一个数据中心内实现，以此类推。

实际上，本文所示的系统(例如，系统100)可以在复杂性方面变化，具有附加功能、更复杂的组件等。例如，附加服务可以作为应用托管平台实例135A-N的一部分来实现。可以包括附加组件来实现安全性、冗余、负载平衡、审核等。

实际上，具有大量用户标识符120的大量租户110可以访问大量平台实例135A-N。尽管用户标识符120被示出为与访问应用相关联，但是客户端也可以采取应用实例的形式，这些应用实例利用了如本文描述的认证技术。

所描述的计算系统可以经由有线或无线网络连接联网。可替代地，系统可以通过内联网连接来连接(例如，在公司环境、政府环境、教育环境、研究环境等中)。

系统100和在本文中描述的其他系统中的任何一个可以结合在本文中描述的硬件组件中的任何一个来实现，例如，下面描述的计算系统(例如，处理单元、存储器等)。在本文的示例中的任何一个中，输入、输出、记录、令牌、配置信息等可以存储在一个或多个计算机可读存储介质或计算机可读存储设备中。在本文中描述的技术对于操作系统或硬件的细节来说可以是通用的，并且可以应用于任何种类的环境中，以利用所描述的特征。

示例2-租户感知分布式应用认证的示例方法

图2是实现租户感知分布式应用认证的示例方法200的流程图，并且示例方法200可以在诸如图1所示的系统之类的系统中实现。可以支持多个租户。

实际上，可以在配置开始之前采取动作，例如，规划哪些应用托管平台实例将实例化，将在哪个(哪些)数据中心处对其进行实例化等。

在230处，如本文描述的，接收配置信息。对于给定的租户，这种配置信息可以包括哪个应用托管平台实例将用作主要认证平台实例、期望哪个身份提供商、在哪些平台实例处托管应用等的指示。这种配置信息可以存储为影响后续认证请求的配置记录。

在240处，根据配置信息来处理认证请求(例如，访问托管的应用)。如本文描述的，认证请求可以定向到配置信息中指示的主要认证平台实例处的平台认证服务。作为这种处理的一部分，保留在这种请求中涉及哪些用户标识符、其是否被准予、时间戳等的记录。

在250处，基于认证请求处理，根据需要输出认证审核。这种审核对于维护安全性、发现错误以及解决关于认证的技术问题可以是有用的。

在本文中描述的方法200和其他方法中的任何方法可以由存储在一种或多种计算机可读介质(例如，存储装置或其他有形介质)中或存储在一个或多个计算机可读存储设备中的计算机可执行指令(例如，使得计算系统执行该方法)来执行。这种方法可以以软件、固件、硬件或其组合来执行。这些方法可以至少部分地由计算系统(例如，一个或多个计算设备)执行。

在本文中描述的技术中的任何技术中，在仍然实现这些技术的同时，可以从替代角度描述所示的动作。例如，对于230，“接收认证配置信息”也可以针对不同视角描述为“发送认证配置信息”。

示例3-示例租户感知分布式应用认证

在本文的示例中的任何一个中，针对访问应用的认证的任务可以分布在多个应用托管平台实例(例如，平台集群)之间。例如，在一个实例处接收的请求可以重定向到另一平台实例以用于验证。平台可以被设计成租户感知的，因为不同的租户可以指定(例如，系统可以接收并存储在认证配置信息中)不同的主要认证平台实例、不同的优选身份提供商、托管应用的不同位置等。

如本文描述的，这些位置可以是不同租户的不同地理位置的指示。类似地，优选的主要认证平台实例可以在配置信息中表示为位置。确定主要实例然后可以采取在配置的位置处确定实例的形式。

因此，尽管可以存在用于认证的主要权威机构(例如，在指定位置处的平台实例处的平台认证服务)，但是应用本身可以分布在平台集群中的多个平台实例处，并且集群的平台实例协作，以经由主要权威机构实现认证。

如本文描述的，应用可以执行与认证相关的工作中的一些。例如，应用可以从客户端提取认证令牌，并向平台认证服务提交针对该令牌的认证请求(例如，检查认证令牌的有效性)。如果不存在认证令牌，则应用可以向平台认证服务这样指示，这可能导致登录或供应。

示例4-示例租户

在本文的示例中的任何一个中，可以支持多种租户。这种租户通常采取企业租户的形式，例如，公司、政府机构、研究机构或团体、教育机构或团体等。通过利用在本文中描述的技术，这种租户可以大大减少管理所需的资源，同时提供对在不同数据中心处托管的多种应用的访问。

实际上，租户用户标识符可以由物理上位于各种位置的用户使用。基于网络的门户可以用于在软件即服务(SaaS)场景中提供计算服务，使得租户用户可以从具有网络访问权的任何位置访问托管的应用。

示例5-示例应用托管平台

在本文的示例中的任何一个中，应用托管平台可以用于托管本文描述的应用。应用托管平台的任何数量的实例都可以实例化，以处理针对访问应用的传入请求。一组这种实例有时称为“平台集群”。

如本文描述的，给定的平台实例可以采取一组服务和配置信息的形式。一个实例可以与另一实例通信，以实现认证请求和应用访问请求的重定向。

如本文描述的，任何给定的租户都可以利用平台集群来实现分布式应用认证。尽管由这种平台集群托管的应用在本质上可以是多样和异构的，但是平台实例可以跨应用共享管理、认证和审核的通用方法。因此，可以实现对跨平台集群运行的应用的集中管理。同时，用户能够受益于这种集中管理以及其他益处，例如，单点登录、应用到应用认证等。

实际上，如本文描述的，平台实例通常限于在指定位置内执行。因此，从租户的角度来看，应用托管平台实例可以与位置(例如，数据中心)同义。因此，实际上，应用托管平台的特定实例可以被指定为位置(例如，数据中心)。因此，租户可以由此指定实例将位于哪个物理位置。因此，指定平台实例的任何描述都可以实现为指定数据中心或地理位置。实际上，平台的多个实例可以共存于同一位置，无论是由租户共享还是分离。

如本文描述的，应用托管平台可以支持多个应用，共享项目、研究、租户间协作等。这种实现方式可以包括多个应用、多个用户标识符(来自多个租户)以及用于在租户之间共享数据的设施。如本文描述的，托管租户可以继续控制托管应用的位置。然而，其他租户可以受益于托管租户允许的共享。

编排企业可以维护用于实现本文描述的技术的逻辑和工具包。那些希望添加与平台兼容的应用的人可以通过将这种逻辑和工具包包含到其应用中来实现这一点。应用的实际托管可以由租户自己、服务提供商、编排企业或第三方来完成。

示例6-示例平台认证服务

在本文的示例中的任何一个中，应用托管平台实例可以包括平台认证服务。如本文描述的，特定平台认证服务可由租户指定为是主要的。可替代地，平台实例可以指定为是主要的，因此平台认证服务是主要的。实际上，位置可以由管理员设计，并且平台可以处理认证配置信息的细节。例如，可以维护数据中心、位置、实例和服务之间或之中的映射，使得可以基于配置的指定租户特定位置来确定请求的适当目的地。

如本文描述的，平台认证服务可以响应请求。在示例中，应用经由认证请求与服务交互，并且服务可以直接处理这种请求(例如，通过检查存储的认证令牌)或将请求重定向到主要服务。因此，如本文描述的，服务可以被配置为确定传入请求的主要服务，并将该请求重定向到主要服务。

示例7-示例身份提供商

在本文的示例中的任何一个中，可以使用各种身份提供商(“IDP”)中的任何一个。这种身份提供商可以用于管理用户身份。例如，希望登录的用户可以定向到身份提供商，其中，提供用户名和密码来初始地认证用户。实际上，租户可以指定其自己的内部身份提供商服务或应用托管平台的内置身份提供商。可替代地，租户可以指定第三方身份提供商，从而将身份管理托管委托给第三方。

实际上，可以支持任何数量的身份提供商技术，包括网络门户、安全声明标记语言(SAML)、基于网络的单点登录、

活动目录等。

示例8-示例认证令牌

在本文的示例中的任何一个中，认证令牌可以采取多种形式。实际上，令牌是可以生成、存储、传送和验证的值。如本文描述的，可以生成、管理和存储这种令牌，作为可由主要认证平台实例访问的令牌记录。加密和其他技术可以用于安全目的。令牌生成可以根据需要而委托给另一权威机构。

认证令牌中可以包含附加信息。例如，主要(例如，发起、发布等)认证平台实例的指示可以包括在认证令牌中。因此，确定哪个实例是主要实例的过程可以通过检查认证令牌来完成。在令牌生成过程期间，基于租户特定配置信息将请求定向到主要实例，并且主要实例将自身的指示添加到认证令牌中。因此，后续请求可以重用这种配置信息，无论其是否在配置信息本身中确认。

认证令牌可以实现为会话令牌。因此，会话令牌可以在用户标识符或应用标识符的初始认证期间生成。因此，会话令牌与客户端的登录会话(例如，用户标识符或应用标识符)相关联。当会话由于登出或超时而结束时，令牌可以类似地自动无效。

认证令牌可以包括承载令牌。这种承载令牌可以用由主要认证平台实例生成和维护的密钥来验证。不同的密钥可以用于不同的租户和不同的平台实例。可以实现用户承载令牌和应用承载令牌。

可以通过将各种信息包括在明文(例如，伪随机值、令牌与其相关联的租户标识符、访问控制(例如，允许哪些应用)等)中来生成认证令牌。然后，可以用主要认证平台实例密钥来加密这种明文，以生成认证令牌。随后，当接收到令牌时，为了验证，可以在认证令牌记录中对其进行解密和查找(例如，由主要实例处的平台认证服务)，这可以指示哪个用户与认证令牌相关联。用户标识符不需要包含在令牌本身中。如果解密的令牌指示租户标识符与认证令牌记录中指示的租户标识符不匹配，则无论令牌值如何，该令牌都将被拒绝。令牌中指示的访问控制也可以被遵从(例如，如果尝试访问未经授权的应用，则不验证相关联的认证请求)。

因为认证令牌针对令牌的中心记录被验证，所以中心记录可以更新，以指示无效。例如，当用户注销时，会话的认证令牌可能无效。类似地，可以设置超时，使得令牌在某一段时间不活动之后自动变得无效。自动无效的周期可以在逐个租户基础上进行配置。

实际上，可以通过对响应针对验证的请求的服务进行访问来实现验证。例如，响应于包括认证令牌的请求，可以从服务接收验证结果。可以通过将提供的认证令牌与存储的认证令牌记录进行比较来实现验证。记录可以包括附加信息，例如，令牌是否仍然有效。

有效性可能要求进一步的信息，例如，相关联的租户。因此，当针对给定租户标识符创建认证令牌时，其可以在与租户标识符相关联的令牌记录中进行关联。随后，认证请求(例如，来自应用的确定认证令牌有效性的请求)可以包括租户标识符(例如，由于应用实例可以被配置为仅接受针对单个给定租户的请求，租户标识符可以由应用确定)。如果认证请求中的租户标识符不匹配，则平台认证服务不会确认有效性，而无论令牌值如何。

因为可以在安全信道(例如，SSL等)上进行会话，所以由于在本文中描述的各种特征，例如，伴随认证请求的租户标识符，可以避免针对认证的各种攻击。

示例9-示例基于地理的场景

在本文的示例中的任何一个中，托管应用的位置可以被指定为租户特定认证配置信息中的位置。这种位置可以包括物理位置，例如，地理位置(例如，数据中心)、管辖区(例如，监管机构)、区域等。例如，出于数据容纳、符合性或资源分配的原因，可以指定不同的国家。在一些情况下，管辖区或区域可以包含一个以上的地理位置(例如，不同的数据中心可以位于单个区域内的不同地理位置)。

租户特定配置信息可以指示将在特定位置托管应用。实际上，应用托管平台可以将位置映射到相应的应用托管平台实例。例如，一个或多个实例可以在第一位置实现，并且一个或多个实例可以在第二位置实现。因此，在实例处托管的应用位于其相应的位置。类似地，当确定主要实例时，可以使用位于配置信息中指示的位置处的实例。

在本文的示例中的任何一个中，指定不同的主要认证应用托管平台实例(例如，对于不同的租户)可以包括指定不同的位置。

因此，租户特定配置信息可以指示在第一管辖区内托管第一应用，在第二管辖区内托管第二应用。然后，应用可以包括将功能限于在管辖区内允许的功能的逻辑。例如，应用可能希望仅在管辖区的地理边界内保存数据。然后，数据在物理上位于管辖区内。租户特定信息可以指示在管辖区内托管应用。

在本文的示例中的任何一个中，第一应用托管平台实例可以在第一管辖区内，并且第二应用托管平台实例可以在不同的第二管辖区内。租户特定配置信息因此可以指定在不同的管辖区内托管不同的应用。

如本文描述的，用户可以继续利用这些应用，而无需考虑应用被托管的位置，因为平台的认证功能可以继续无缝认证，而不管应用托管在哪个平台实例处。

示例10-示例租户特定配置信息

在本文的示例中的任何一个中，可以收集租户特定配置信息并将其用于引导认证处理。图3是存储用于实现租户感知分布式应用认证的租户特定配置信息的示例系统300的框图。

在该示例中，应用托管平台实例330A包括管理服务，管理员可以通过该管理服务访问和更新认证配置信息385A，认证配置信息385A是针对各种租户380A-N存储的。如本文描述的，平台认证服务340A在处理认证请求时访问这种配置信息385A。这种平台实例330A可以用作在本文中描述的应用托管平台实例中的任何一个。

示出了特定租户的租户配置信息380A的示例细节，并且可以包括指定的身份提供商类型382(例如，管理租户身份的服务和这种服务使用的配置信息)、指定的主要认证应用托管平台实例384(例如，包括本地地或从平台集群中的其他平台实例定向地处理认证请求的平台认证服务)、应用配置386和策略信息388。还可以包括身份提供商的细节(例如，诸如网络地址之类的网络访问信息)。可以包括进一步的信息来容纳项目、研究等。如本文描述的，主要平台实例在被确定时或在被确定之前可以指定为位置，并转换为对该位置处的实例或在该位置处的实例处执行的服务的引用。

应用配置信息386可以包括指定将在哪些应用托管平台实例处托管哪些应用的信息。针对访问平台实例处超出允许范围的应用的请求可以重定向到指定的平台实例。如本文描述的，可以在第一实例处托管一个或多个应用，同时可以在不同的第二实例处托管一个或多个应用。平台集群可以根据需要进行缩放，以包括附加的实例。

如本文描述的，访问除主要认证托管平台实例之外的平台实例处的应用的请求可以重定向到主要实例，以用于认证。如本文描述的，可以实现单点登录。

可以在策略信息388中指定任何数量的其他策略。例如，可以支持IP访问限制、认证令牌过期时间段、密码策略、电子邮件限制、基于用户的应用访问控制、自动超时时段(例如，空闲会话超时)、数据共享许可等。

任何种类的其他配置场景都是可能的。例如，可以在租户、组或用户级别指定访问控制。

通常在给定租户的主要应用托管平台实例处管理配置信息。然而，这种数据可以根据需要跨平台实例同步。

示例11-实现配置的示例方法

图4是实现租户感知分布式应用认证的配置的示例方法400的流程图，并且示例方法400可以在诸如图3所示的系统之类的系统中实现。实际上，可以支持多个租户。

在430处，针对租户接收认证配置信息。例如，可以提供网络门户，管理员可以通过该网络门户经由各种用户接口输入或更新配置信息。如本文描述的，这种信息通常由针对租户指定的主要应用托管平台实例接收。

在440处，将接收到的认证配置信息存储为与租户相关联的。

在450处，如本文描述的，当接收到通过租户的用户标识符访问应用的请求时，应用这种认证配置信息。例如，可以如下面描述地处理认证请求。

示例12-与配置信息的示例租户关系

图5是在本文描述的示例中的任何一个中可以存储为租户特定认证配置信息的特定租户的示例关系500的框图。实际上，这种关系可以存储为映射、记录、表等。认证配置信息服务可以响应于针对其的请求而提供这种信息。例如，针对主要平台认证服务或主要认证应用托管平台实例的查询可以包括租户的标识符，或者可以暗示租户。响应可以提供所请求的服务或实例的身份或引用。

在本文的示例中的任何一个中，用户515A-N或应用实例517A-N可以指定为与租户510A相关联。这种关联可以在认证配置信息中表示，明确地包括在请求中，明确地包括在认证令牌中等。

该示例说明了不同的租户510A-N可以如何指定不同的身份提供商520A-N和不同的主要应用托管平台实例530A-N。一个以上的租户510A-N可以指定相同的身份提供商(例如，520A)。类似地，一个以上的租户510A-N可以针对主要应用托管平台实例指定相同的数据中心。

此外，租户510A-N可以指定应用位置记录540A-N。这种记录540B可以包括应用类型542A和托管该应用类型的应用的平台实例544A的指示。附加记录540N可以针对不同的应用类型542B指定相同或不同的实例544B。针对应用指定的平台实例544A-B可以与指定作为租户的主要认证应用托管平台实例的应用托管平台实例相同或不同。

如图所示，租户510A可以包括多个用户身份515A-N。出于认证的目的，应用实例517A-N也可以被视为属于租户，并且提供有凭证，从而允许这种应用实例517A-N参与并受益于如本文描述的平台。

虽然关系可能初始地看起来很复杂，但是从给定租户的角度来看，在跨多个数据中心执行的平台实例的集群内跨访问各种应用的各种用户保持集中控制和并发管理的同时，提供了关于认证的灵活性。因此，从租户的角度来看，管理工作可以减少。同时，用户通过能够访问各种各样的资源而无需维护各种各样的凭证来受益。

示例13-示例应用注册

在本文的示例中的任何一个中，应用可以向平台注册，供租户使用。作为注册过程的一部分，接收安装应用的位置。还可以接收关于如何访问应用的信息(例如，URL/URI)。如果同一应用类型的两个实例对于租户在不同位置执行，则可以实现两次不同的注册(例如，利用不同的URL/URI)。

希望访问应用的客户端通过指定URL/URI来访问应用，URL/URI将请求路由到应用正在执行的位置。然后，应用可以如本文描述地处理认证。

示例14-应用实例的示例附加安全层

在本文的示例中的任何一个中，附加安全层可以包含在技术中。例如，可以包含应用到平台认证，用于在应用与平台之间的通信(例如，平台认证服务等)。作为针对给定租户的应用实例的平台注册过程的一部分，应用实例可以指示用于访问应用的网络地址(例如，URL/URI)，并且平台可以向应用提供应用实例标识符和应用实例秘密。应用实例标识符和应用实例秘密之间的关联可以由认证服务的平台维护。应用实例秘密可以以加密或散列形式维护，以保护明文不受查看。

然后，在允许应用实例与平台之间的通信之前，标识符和秘密可以用于认证。尽管有时被描述为“认证请求”的一部分，但是实际上，请求可以采取应用实例与平台认证服务之间的多条消息的形式。可以基于相关联的认证令牌、提供的租户标识符、应用实例标识符和应用实例秘密来确定这种请求的有效性。平台实例可以将传入的应用实例秘密与维护的副本进行比较。

当应用请求验证认证令牌时，除了认证令牌之外，应用还可以提供应用实例标识符和应用实例秘密。平台认证服务可以另外认证应用实例标识符和应用实例秘密。无论认证令牌的值如何，未能提供应用实例凭证都会导致认证失败。

因此，每当应用实例向平台(例如，无论是本地还是远程的平台认证服务)发送通信时，都可以认证应用实例标识符和应用实例秘密。平台可以阻止与未能提供应用实例凭证的应用实例的通信。可以拒绝来自这种实例的任何请求。

示例15-示例新用户供应系统

图6是在租户感知分布式应用认证场景中实现新用户供应的示例系统600的框图，并且实例系统600可以在本文的示例中的任何一个中使用。

在该示例中，租户610的客户端620或租户代理被配置为发送针对访问作为租户的主要认证应用托管平台实例630的一部分执行的应用650的请求601。应用650可以如本文描述地被配置为初始地尝试认证请求(例如，通过如本文描述地提取认证令牌)。然而，如图所示，在客户端620处不存在认证令牌，因为尚未供应用户标识符。

实际上，可以向用户和/或管理员提供网络地址(例如，统一资源定位器/指示符)，通过该网络地址，可以利用诸如互联网浏览器之类的客户端来实现访问。对于未供应的用户标识符，对相同网络地址的访问可以导致如本文描述的供应。

应用650可以与客户端620通信，并且被配置为初始地尝试从客户端620提取602认证令牌。然而，在该示例中，没有令牌，因此尝试失败。应用650被配置为检测失败，因此，在没有认证令牌(例如，无令牌认证请求)的情况下，向本地平台认证服务640发送认证请求603。

平台认证服务640被配置为接收这种请求，并且在满足一个或多个先决条件(例如，客户端620的用户id被认证)之后开始生成令牌的过程。平台认证服务640与租户特定认证配置信息中指定的身份提供商690通信，并与身份提供商690交互，以认证用户id。

在该示例中，请求604实际上变成用户供应请求(例如，可以显示用于供应新用户的用户接口，并且可以处理新用户信息)。身份提供商690然后利用用户供应细节来响应605该请求，服务640将这些用户供应细节存储606在用户记录660中。

然后，用户标识符的后续访问与注册用户相关联。附加信息可以存储在认证配置信息685中，例如，哪些应用650可以经由用户标识符访问等。

如本文描述的，如果本地实例630不是主要认证实例，则信息可以中继到主要实例处的平台认证服务。因此，如认证配置信息685中指示的，平台认证服务640可以通过将请求603切换到主要平台认证服务来委托请求603。

所描述的处理还可以导致认证令牌生成，其被传递到应用650，以中继到客户端620，用于如本文描述的持久性。平台认证服务640然后可以控制用户标识符对本地应用650以及其他平台实例处的应用的访问。

示例16-供应新用户的示例方法

图7是在租户感知分布式应用认证场景中供应新用户的示例方法700的流程图，并且示例方法700可以在诸如图6所示的系统之类的系统中实现。实际上，这种方法通常由针对与用户相关联的租户指定的主要认证应用托管平台实例来执行。

在720处，从客户端接收通过未供应的用户标识符对应用进行访问的请求。这种请求通常由应用经由针对该应用指定的访问方法(例如，URL/URI)接收。

在730处，尝试认证访问请求。如本文描述的，通常通过从客户端提取认证令牌并对其进行验证来解决这种尝试。然而，在未供应的用户标识符的情况下，无法验证认证令牌(例如，其不存在、过期或以其他方式无效)。实际上，应用本身可以确定认证失败，因为客户端上不存在认证令牌(例如，提取认证令牌的请求失败)。不管是否存在令牌，仍然可以针对会话生成认证请求。

然后，应用可以向本地平台认证服务发送认证请求。如果认证配置信息指示本地服务不是针对租户的主要平台认证服务，则认证请求可以委托给主要平台认证服务。

在该示例中，没有供应用户标识符，因此没有认证令牌。响应于确定认证请求中没有令牌，主要平台认证服务中继认证请求，以进行登录。

因此，在740处，将认证请求中继到针对租户指定的身份提供商。因此，经由针对租户的配置信息来确定客户端的身份提供商，并且将请求中继到确定的身份提供商。因为该请求源自新的(例如，未供应的)用户标识符，所以处理该请求，作为供应请求。供应可以采取多种通信的形式(例如，以获取或创建用户标识符、密码、授权访问级别等)。例如，可以呈现用户接口，新用户通过该用户接口选择注册功能。

默认访问级别可以用于租户(例如，每个租户可配置为针对新供应的用户的租户特定默认访问级别)，从而新供应的用户标识符对基本的应用集具有访问权。可以通过在认证配置信息中指定附加应用来添加这些应用。还可以为新用户提供在试验时段内有效的试验访问。这种信息可以存储在认证配置信息中，以避免重复试验。

在750处，从身份提供商接收针对新用户标识符的供应细节。

在760处，将针对新用户标识符的供应细节存储在用户配置信息(例如，用户记录)中。

认证可以如本文描述的进行。例如，可以生成令牌，并在客户端处提供以用于持久性。

如本文描述的，用户标识符然后可以用于在当前或未来会话中访问托管的应用。

示例17-应用的示例网络地址

在本文的示例中的任何一个中，网络地址可以用于访问应用。针对不同租户的应用的不同实例可能有不同的网络地址。类似地，针对同一租户的应用的在不同位置处的不同实例可能具有不同的网络地址。

实际上，域名约定可以用于支持如本文描述的提取认证令牌。例如，服务提供商的基本域名(例如，“illumina.com”、“brand.illumina.com”等)可以针对应用跨网络地址通用。租户身份、位置身份和应用类型标识符可以附加到基本域名，以创建用于访问给定位置处的租户特定应用实例的网络地址(例如，URL、URI等)。

如本文描述的，如果客户端尝试访问以某种方式指定不允许应用执行的位置的网络地址(例如，如与请求相关联的租户的租户特定认证配置信息中所指示的)，则可以作为响应提供重定向的网络地址，这将客户端重定向到正确的网络地址。

因为租户和位置信息由网络地址暗示，所以针对访问特定网络地址的请求包含足够的信息来确定租户和位置(例如，由于该请求在应用实际执行的位置处由配置用于租户的应用接收)。因此，对平台认证服务的请求可以包括这种信息(例如，与该请求相关联的租户、应用类型等)，或者可以对其进行暗示。

请求客户端可以被配置为保存认证令牌并对这种请求做出响应。如上面描述的，用于访问应用实例的网络地址可以共享基本域名。域名还可以被配置为使得应用共享租户特定基本域(例如，具有附加的租户标识符的基本域)。请求客户端可以被配置为提供认证令牌，用于提取仅源自基本域名或租户特定域名内的请求。例如，互联网浏览器的cookie功能可以支持这种配置。cookie范围可以被配置为支持这种实现方式，同时拒绝访问用于cookie范围之外的地址的认证令牌。

示例18-示例客户端

在本文的示例中的任何一个中，客户端可以采取访问由所描述的平台实例托管的应用的任何程序的形式。例如，客户端可以采取互联网浏览器的形式，用户可以通过互联网浏览器经由网络连接访问应用功能。在这种场景中，用户标识符通常用于识别在认证系统中供应的用户。可以通过提供如由身份提供商处理的用户名和密码来实现初始认证(例如，登录)。互联网浏览器可以以各种方式保存并且稍后提供认证令牌，例如，经由cookie技术或允许服务器提取令牌的某种其他客户端侧持久存储机制。

在本文的示例中的任何一个中，客户端也可以采取应用实例的形式。换言之，可以经由本文描述的技术认证应用到应用请求。

示例19-示例应用到应用认证

在本文的示例中的任何一个中，应用可以包括逻辑(例如，作为平台兼容工具包的一部分来提供)，该逻辑保存并且稍后提供认证令牌，或者这种功能可以委托给托管平台实例。在这种场景中，应用类型的应用实例可以向类似于用户的平台认证服务注册。可以使用客户端标识符和客户端秘密。

支持应用的能力可以大大简化应用到应用通信场景的配置和管理。因此，访问与另外的应用通信的第一应用的用户将大大受益。提供给应用实例的承载令牌可以称为“应用承载令牌”，而不是“用户承载令牌”。

示例20-对应用的示例系统认证访问

图8是在租户感知分布式应用认证场景中认证对应用的访问的示例系统800的框图。当在单点登录场景中讨论时，应用850A有时称为在“第一应用托管平台实例”上执行的“第一”应用，因为可以实现对平台集群内的后续应用的访问而无需附加的登录活动。在该示例中，当访问请求开始时，没有令牌825。

在该示例中，与租户810相关联的客户端820发送访问由应用托管平台实例830A托管的应用850A的请求801。这种请求801可以包括诸如期望的应用、用户身份、租户等之类的细节。如本文描述的，可以暗示这种细节(例如，经由提供给用户的URL/URI来访问应用，因此对指定的URL/URI的任何访问是对与URL/URI相关联的应用的访问，并且是针对特定租户的)。

应用850A包含感知平台认证服务840A的逻辑。应用850A可以尝试从客户端820取回认证令牌，但是在该示例中，该尝试将失败。应用850A被配置为响应于失败，向服务840A发送认证请求802。

如图所示，首先咨询服务840A的本地实例。如本文描述的，服务840A然后可以将认证请求中继到在如针对租户810的配置信息885中指定的主要认证托管平台实例处执行的平台认证服务。在该示例中，本地服务840A是主要服务，因此其继续处理请求。

服务840A可以被配置为检查803用户记录860A，以确定是否供应用户。如果供应，则服务840A可以继续。

因为在请求802中没有提供令牌，所以服务840A被配置为然后确定由租户810在配置信息885中指定的优选身份提供商890，并向其发送认证请求804。

服务840A被配置为在身份提供商890成功认证时，创建认证令牌并将认证令牌写入认证令牌记录870A。服务还向应用850提供成功结果806和令牌，应用850被配置为将令牌传递回客户端820，客户端820保存令牌825，以供将来可能使用。

在本文的示例中的任何一个中，集群服务888A、888B可以用于注册平台实例及其位置；逻辑实例集群然后可以作为平台集群操作。例如，第一实例可以用作主端，并且后续注册实例可以通过向主端注册来加入集群。对服务888A、888B的请求可以返回哪个实例是主端的指示、提供与主端的通信等。当平台实例被实例化时，集群服务888A、888B可以向平台实例提供位置信息(例如，实例所位于的当前位置)，并且可以使位置信息对应用850A-B可用。因此，可以经由相应的集群服务888A、888B使应用850A、B是位置感知的。

出于说明的目的，应用850A被示出为托管在与认证服务840A相同的实例830A上。然而，应用可以托管在不同的实例上(例如，830B)。如果应用托管在不同的实例上(例如，这可以通过检查配置信息、请求等来确定)，则认证请求802可以与租户810的主要认证应用托管平台实例相关以用于认证。因此，优选的应用托管平台实例包括用作认证和准予的令牌的主要权威机构的平台认证服务。

示例21-认证对应用的访问的示例方法

图9是在租户感知分布式应用认证场景中认证对应用的访问的示例方法900的流程图，并且示例方法900可以在诸如图8所示的系统之类的系统中实现。

在930处，从与租户相关联的客户端接收访问应用的请求。如本文描述的，请求可以由客户端接收，并且可以被确定为针对给定租户发起。

在940处，将请求中继到本地平台认证服务。在该示例中，应用从客户端接收请求，并将其中继到托管该应用的平台实例的平台认证服务。

在一些情况下，请求可能被定向到不允许的平台实例。例如，租户特定配置信息可以指定特定应用类型的应用实例仅在特定平台实例(例如，数据中心)中执行。在这种情况下，请求可以重定向到允许的平台实例。因此，响应于确定租户特定配置信息指定所请求的应用将由不同的平台实例托管，请求可以重定向以用于托管在不同的平台实例处。

平台认证服务可以检查以了解请求用户是否被供应(例如，在用户记录中有记录)。如果请求用户被供应，则过程可以继续。

在950处，该请求作为认证请求中继到租户的优选身份提供商。客户端还可以直接与身份提供商交互，以实现登录。

在960处，在由身份提供商进行认证时，针对应用访问请求生成认证令牌。认证令牌本地存储在应用托管平台实例内。

在970处，准予客户端对应用进行访问。将认证令牌提供给客户端，客户端可以保存该令牌以用于后续请求。

示例22-示例典型场景

在本文的示例中的任何一个中，可以支持各种重复的认证场景。

在第一场景中，来自客户端的针对访问的初始请求是针对在租户的主要应用托管平台实例上托管的第一应用的。在初始登录之后，来自客户端的针对访问的第二请求是针对在不同的第二应用托管平台实例上托管的第二应用的。如本文描述的，针对第二请求的认证可以初始地由本地(例如，第二)平台实例处理，并且最终通过利用主要应用托管平台验证从客户端取回的令牌来实现。

在第二场景中，来自客户端的针对访问的初始请求是针对在除租户的主要应用托管平台实例之外的平台实例上托管的第一应用的。在这种情况下，接收请求的平台实例可以联系主要应用托管平台实例，并从其获得令牌，作为初始登录过程的一部分。在初始登录之后，来自客户端的针对访问的第二请求是针对在主要应用托管平台实例上托管的第二应用的。主要实例可以通过验证从客户端取回的令牌来本地处理针对访问的请求。

在第三场景中，来自客户端的针对访问的初始请求是针对在除租户的主要应用托管平台实例之外的平台实例上托管的第一应用的。在这种情况下，接收请求的平台实例可以联系主要应用托管平台实例，并从其获得令牌，作为初始登录过程的一部分。在初始登录之后，来自客户端的针对访问的第二请求是针对在除主要实例之外的另一平台实例上托管的第二应用的。如本文描述的，针对第二请求的认证可以初始地由本地(例如，第二)平台实例处理，并且最终通过利用主要应用托管平台验证从客户端取回的令牌来实现。

在涉及托管相应的三个应用的三个位置的示例实现方式中，供应第一租户以使用(例如，作为主要实例)位置一并访问应用一和三。供应第二租户以使用位置二并访问应用一和二。供应第三个租户以使用位置三并访问应用一和二。

涉及附加的应用和/或平台实例的其他认证场景是可能的。

示例23-认证令牌的示例提取

在本文的示例中的任何一个中，从客户端提取认证可以包括从客户端侧持久存储装置请求认证令牌。例如，cookie机制可以用于从客户端(例如，互联网浏览器)取回授权。

可以在没有进一步用户输入的情况下实现这种提取。因此，可以实现单点登录。因此，用户标识符不需要再次登录。

令牌可以提取到托管针对其请求访问的应用的平台实例(例如，由针对其请求访问的应用提取)，然后提供给主要认证平台实例以用于验证。

示例24-示例认证对象

当针对主要认证平台实例认证用户标识符时，可以将包含各种信息的认证对象提供回至调用应用。这种信息可以包括与租户相关联的主要认证平台实例的指示；针对用户启用的应用和相关联的应用实例以及应用内的针对用户标识符的一个或多个角色；以及特定于应用的容器、项目和研究及其许可。

示例25-实现单点登录的示例系统

图10是当在租户感知分布式应用认证场景中访问第二应用时实现单点登录的示例系统1000的框图。上面参考图8和图9描述的应用850A可以被认为是单点登录场景中的第一应用。

在该示例中，与租户1010相关联的客户端1020对令牌1025具有访问权，并经由访问请求1001尝试访问第二应用1050B。实际上，访问请求1001不包括令牌1025。然而，访问请求可以采取网络地址的形式，根据该网络地址可以确定租户1010。因为网络地址可以如本文描述地配置，所以应用实例和租户标识符在请求1001中暗示。

如本文描述的，客户端1020不需要包含将存储的令牌1025识别为令牌本身的逻辑。相反，可以简单地响应于针对客户端侧保存的变量的请求而提供令牌1025。

应用1050B可以被配置为执行一些初始处理，以确定针对访问的请求是否来自未经认证的会话。如果如此确定，则应用1050B可以通过从客户端1020提取认证令牌1025来进行进一步处理。在该示例中，提取成功，因为在客户端1020处存在认证令牌1025。

平台实例1030B的托管的应用被配置为将未经认证的访问请求转发1002到本地平台认证服务1040B。服务1040B被配置为确定该服务是否是针对租户1010的主要服务。在该示例中，服务1085不是(例如，如认证配置信息1085B中所指示的)主要服务，因此服务1040B发送委托响应1003，以将请求切换到主要服务1040A。随后，应用1050B可以与主要平台认证服务1040A通信，以完成认证。

应用1050B可以被配置为将认证令牌发送到服务1040A，作为认证请求1004的一部分。应用托管平台实例1030A的主要平台认证服务1040A在认证配置信息1085B中被指示为优选实例。

平台认证服务1040A(例如，用作主要权威机构)然后针对存储的认证令牌1070A(例如，作为图8和图9所示的过程的一部分生成)检查1005认证令牌。服务1040A被配置为在成功验证由请求应用1050B提供的认证令牌时发送认证请求有效响应1006。作为有效性处理的一部分，可以如本文描述地验证其他信息项。应用1050B被配置为然后允许访问与客户端1020的会话。

如图所示，由于令牌1025的存在，身份提供商1090在随后的认证期间不需要参与或咨询，令牌1025由租户1010在配置信息(例如，在1085A和1085B中)中指示为主要的服务进行认证。

如本文描述的集群服务1088A、1088B可以用于注册平台实例及其位置；逻辑实例集群然后可以作为平台集群操作。

如示例中所示，元数据1044A、1044B可以用于查找信息，以处理请求。例如，元数据1044A、1044B可以格式化来自1085A、1085B的配置信息，使得可以容易地对其进行检查(例如，元数据用作认证配置信息的高速缓存)。例如，元数据1044A、1044B可以存储租户标识符到其相应相关联的主要位置(例如，主要认证应用托管平台实例)的映射。因此，针对认证的请求(例如，其包括租户标识符)可以立即路由到主要平台实例，因为该实例可以经由映射利用传入的请求租户标识符来确定。可替代地，可以从认证配置信息1085A、1085B咨询这种信息。

从客户端的角度来看，可以实现单点登录，因为由应用托管平台自动提取令牌，而无需客户端进行肯定动作。因此，不需要执行后续登录活动。

示例26-实现单点登录的示例方法

图11是当在租户感知分布式应用认证场景中访问第二应用时实现单点登录的示例方法1100的流程图，并且例如示例方法1100可以在诸如图10所示的系统之类的系统中实现。实际上，方法1100可以由第二应用托管平台实例1030B来执行。上面参考图8和图9描述的应用850A可以被认为是单点登录场景中的第一应用。方法1100可以对访问多个应用托管平台实例的集群的客户端进行认证。这种集群可以包括第一实例1030A、第二实例1030B以及如本文描述的其他平台实例。

在1130处，从客户端接收访问由第二应用托管平台实例托管的第二应用的请求。如本文描述的，可以在与在第一应用托管平台实例处托管的第一应用的会话期间，接收这种请求。第一应用和第二应用由不同的应用托管平台实例托管，并且任何一个应用可以在主要应用托管平台实例上托管。客户端已经经由认证令牌被认证，以访问在应用托管平台的另一实例上托管的第一应用(例如，如上面参考图8和图9描述的)。

可以使用具有公共或部分公共的租户特定域名或域名部分的域来访问第一应用和第二应用，如本文描述的。

在1140处，响应于该请求，从客户端提取授权令牌。实际上，可能没有授权令牌(或者授权令牌已过期等)，在这种情况下，接下来是与图8和图9所示的场景类似的场景。如本文描述的，应用可以提取令牌，并且对其具有访问权，因为使用具有共性的域来访问第一应用和第二应用。

平台实例集群中的实例(例如，包括平台实例1030A、1030B以及集群中的任何其他实例)中的一个实例可以被确定为主要认证应用托管平台实例。实际上，主要认证实例可以与托管应用的实例相同或不同。

租户特定配置信息可以指定主要认证平台应用托管实例。不同的租户可以指定不同的主要认证应用托管实例(例如，通过指定不同的位置、数据中心等)，并且这种偏好被存储为租户特定认证配置信息，如本文描述的。与请求相关联的租户被暗示，因为该请求并定向到与租户相关联的网络地址(例如，与租户特定域名相关联)。

在该示例中，平台认证服务读取这种租户特定配置信息，以确定主要应用托管平台实例不是本地实例，因此将令牌提供给主要平台，该主要平台验证令牌，并且响应于检查先前准予的令牌而提供令牌有效的确认。验证请求可以包括认证令牌，或者以其他方式提供对认证令牌的访问(例如，经由引用)。

如本文描述的，本地平台认证服务可以将请求切换到请求应用，使得其不再参与请求(例如，应用和主要服务直接交互)。

在1150处，利用主要认证应用托管平台实例(例如，其可能不是本地的)来验证认证令牌。可以向主要认证应用托管平台实例发送针对认证令牌的验证请求。

在1160处，响应于接收到令牌有效的确认，针对请求客户端准予对在应用托管平台实例的第二实例处托管的第二应用的访问。

然后，客户端可以访问第二应用的功能。

如上面描述的，可以通过重用由于关于第一应用的认证而已经存储在客户端处的认证令牌，来执行从客户端提取认证令牌。在平台实例被指定为与数据中心或其他位置相关联的情形中，平台实例可以与数据中心或其他位置同义。

示例27-示例应用

在本文的示例中的任何一个中，应用可以采取各种程序中的任何一种的形式。实际上，逻辑可以包含在应用中，使得其可以成功地与平台交互。例如，如本文描述的，认证请求可以发送到平台认证服务。也可以包括用于处理对其他应用的传入请求的逻辑。

示例28-示例应用重定向

在本文的示例中的任何一个中，租户特定配置信息可以指定在哪些应用托管平台实例上托管应用。对除了租户特定配置信息指定将在其上托管应用的平台实例以外的平台实例的请求重定向到租户特定配置信息指定将在其上托管第二应用的平台实例。

以此方式，租户可以控制在什么实例处访问应用。因此，可以如本文描述地强制实现数据的物理容纳。

示例29-示例应用到应用实现方式

在应用到应用实现方式中，由具有客户端标识符和客户端秘密的应用实例发出来自客户端的请求。应用实例初始地经由客户端标识符和客户端秘密认证，以访问第一应用。应用实例保存认证令牌，并在来自平台实例的提取请求时提供该认证令牌。

然后，如本文描述的，应用实例可以经由认证令牌认证，以访问第二应用。在这种情况下，应用实例用作如本文描述的客户端。

示例30-示例用户接口

在本文的示例中的任何一个中，用户接口可以呈现在客户端处，以便于访问应用。例如，可以提供图标或下拉菜单，用户可以通过该图标或下拉菜单选择期望的应用。图标或下拉菜单可以包括对针对给定应用的优选平台实例的引用。这种用户接口元件可以作为允许访问多个应用的用户接口的一部分来提供，并且可以包含在应用本身中。例如，一个应用可以显示访问另一应用的选项。

如本文描述的，不同的应用可以托管在不同的平台实例处。对应用的底层引用可以包括被配置为托管如在配置信息中指示的应用的平台实例的指示。因此，当生成用户接口时，可以放置这种引用，使得渲染的用户接口(例如，在互联网浏览器中)包括将应用请求定向到允许的平台实例的用户接口元件。

如果用户以某种方式获取或制造对不允许的平台实例的引用，则可以如本文描述地实现应用重定向。

示例31-示例审核

在本文的示例中的任何一个中，当处理认证请求时，可以生成审核追踪。例如，任何失败或成功的访问尝试都可以与相关联的细节(例如，请求用户标识符、IP地址、请求的应用、认证结果)一起写入审核日志。还可以记录针对认证请求重定向到其他实例以及针对托管的应用重定向到其他位置。

随后，这种日志可以作为认证审核输出。管理员可以出于各种目的访问这种日志，例如，负载规划、问题解决、安全审核等。

示例32-示例实现方式

在本文的示例中的任何一个中，实现方式可以针对基因组学项目和研究，涉及跨在不同位置托管的不同应用进行协作和数据共享。可以支持分析和临床决策制定。基于计算资源选择和租户选择，可以在不同的地理区域中托管应用。

租户可以从一个地理位置进行管理，并为部署在多个地理位置中的应用提供登录(SSO)能力。

认证系统可以部署在不同的地理位置，并形成租户感知认证集群。在许多情况下，不要求新软件(例如，客户端)，因为可以使用当前软件(例如，互联网浏览器)。

服务提供商可以在单个位置管理租户的应用访问和策略，并向租户提供对各种认证方案(例如，身份提供商)和地理位置的选择，以用于认证。

企业租户用户可以登录一个系统，以访问部署在多个地理位置的多个应用。

企业租户可以控制认证请求被发起和服务的位置，从而降低审核成本。

认证服务器(例如，平台实例)可以形成集群，并且租户可以从任何地理位置访问应用。

该系统可以是可扩展的。认证服务器可以水平扩展，并且每个服务器可以在服务器之间发布其节点信息(例如，包括健康状况)。因此，可以降低操作成本。

示例33-示例其他方法实现

在任何示例中，可以使用一种方法来访问应用。来自本文的任何示例的技术可以包含到以下方法中。

在跨越支持多个租户的多个数据中心的计算集群中，可以从经由承载认证令牌被认证以访问第一应用的客户端接收访问第二应用的请求，该承载认证令牌由于由针对多个租户中的特定租户的确认信息中指定的身份提供商进行的认证而被主要平台认证服务准予。

可以从客户端提取承载认证令牌。可以在无需用户进一步输入的情况下，执行这种提取。

可以针对客户端确定主要认证应用托管平台实例。例如，租户特定配置信息可以指示主要实例。基于与传入请求相关联的租户，可以根据租户标识符到平台实例引用的映射来确定主要实例。

可以向与主要认证应用托管平台实例相关联的主要平台认证服务发送认证请求以用于验证。认证请求可以包括承载认证令牌、特定租户的租户标识符、第二应用的应用实例标识符和第二应用的应用秘密。

响应于发送的认证请求，可以从主要平台认证服务接收指示认证请求有效的通信。承载令牌、租户标识符、应用实例标识符和应用实例秘密也可以作为对请求的验证的一部分进行验证。否则，验证失败。

响应于接收到认证请求有效的通信，可以准予由客户端访问第二应用。

在这种场景中，第一应用可以由在第一数据中心处执行的应用托管平台的第一实例托管，并且第二应用可以由在不同的第二数据中心处执行的应用托管平台的不同的第二实例托管。

如本文描述的，可以通过指定共享公共基本域名的网络位置(例如，URL、URI等)来访问第一应用和第二应用。

示例34-示例附加信息

在本文的示例中的任何一个中，如本文描述的，可以支持用于认证的单个入口点。这种单个入口点可以服务于在任何地理位置供应的任何应用；因此，审核可以集中到单个地理位置。

认证服务器(例如，应用托管平台实例)可以与其他认证服务器通信并发布租户信息。针对租户的传入请求然后路由到适当的认证服务器。

具有自己的单点登录解决方案的企业租户可以无缝集成，从而减少集成点的数量。

示例35-示例计算系统

图12示出了合适的计算系统1200的一般化示例，在该计算系统1200中可以实现若干所描述的创新。计算系统1200不旨在对使用范围或功能提出任何限制，因为这些创新可以在包括专用计算系统的多样的计算系统中实现。实际上，计算系统可以包括所示的计算系统的多个联网实例。

参考图12，计算系统1200包括一个或多个处理单元1210、1215和存储器1220、1225。在图12中，该基本配置1230包括在虚线内。处理单元1210、1215执行计算机可执行指令。处理单元可以是中央处理单元(CPU)、专用集成电路(ASIC)中的处理器或任何其他类型的处理器。在多处理系统中，多个处理单元执行计算机可执行指令，以增加处理能力。例如，图12示出了中央处理单元1210以及图形处理单元或协同处理单元1215。有形存储器1220、1225可以是可由(多个)处理单元访问的易失性存储器(例如，寄存器、高速缓存、RAM)、非易失性存储器(例如，ROM、EEPROM、闪速存储器等)或者这两者的某种组合。存储器1220、1225以适于由(多个)处理单元执行的计算机可执行指令的形式存储实现本文描述的一个或多个创新的软件1280。

计算系统可能具有附加功能。例如，计算系统1200包括存储装置1240、一个或多个输入设备1250、一个或多个输出设备1260以及一个或多个通信连接1270。诸如总线、控制器或网络之类的互连机制(未示出)将计算系统1200的组件互连。通常，操作系统软件(未示出)为在计算系统1200中执行的其他软件提供操作环境，并协调计算系统1200的组件的活动。

有形存储装置1240可以是可移除的或不可移除的，并且包括磁盘、磁带或盒式磁带、CD-ROM、DVD或可以用于以非暂时性方式存储信息并且可以在计算系统1200内访问的任何其他介质。存储装置1240存储用于实现本文描述的一个或多个创新的软件1280的指令。

(多个)输入设备1250可以是触摸输入设备(例如，键盘、鼠标、笔或轨迹球)、语音输入设备、扫描设备或向计算系统1200提供输入的另一设备。对于视频编码，(多个)输入设备1250可以是相机、视频卡、TV调谐器卡，或接受模拟或数字形式的视频输入的类似设备，或者将视频样本读入计算系统1200的CD-ROM或CD-RW。(多个)输出设备1260可以是显示器、打印机、扬声器、CD-写入器或提供来自计算系统1200的输出的另一设备。

(多个)通信连接1270使得能够通过通信介质与另一计算实体通信。通信介质传达信息，例如，计算机可执行指令、音频或视频输入或输出、或调制数据信号中的其他数据。调制数据信号是这样的信号：以在信号中编码信息的方式设置或改变该信号的特性中的一个或多个特性。通过示例而非限制，通信介质可以使用电、光、RF或其他载体。

可以在计算机可执行指令的一般上下文中描述这些创新，例如，在目标真实或虚拟处理器上在计算系统中执行的程序模块中包括的那些指令。通常，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、库、对象、类、组件、数据结构等。在各种实施例中，可以根据需要在程序模块之间组合或分割程序模块的功能。可以在本地或分布式计算系统内执行用于程序模块的计算机可执行指令。

为了呈现的目的，详细描述使用“确定”和“使用”等术语来描述计算系统中的计算机操作。这些术语是计算机执行的操作的高级抽象，并且不应该与人类执行的动作混淆。对应于这些术语的实际计算机操作取决于实现方式而变化。

示例36-计算机可读介质

本文中的任何计算机可读介质可以是非暂时性的(例如，易失性存储器(例如，DRAM或SRAM)、非易失性存储器(例如，磁存储装置、光存储装置)等)和/或有形的。本文中描述的任何存储动作可以通过存储在一个或多个计算机可读介质(例如，计算机可读存储介质或其他有形介质)中来实现。描述为存储的任何事物(例如，在实现期间创建和使用的数据)可以存储在一种或多种计算机可读介质(例如，计算机可读存储介质或其他有形介质)中。计算机可读介质可以限于不包括信号的实现方式。

可以通过一个或多个计算机可读介质(例如，计算机可读存储介质或其他有形介质)或一个或多个计算机可读存储设备(例如，存储器、磁存储装置、光存储装置等)中的计算机可执行指令来实现本文中描述的任何方法。这种指令可以使得计算设备执行该方法。可以用各种编程语言来实现本文描述的技术。

进一步描述

可以实现以下实施例中的任何一个。

条款1、一种对访问多个应用托管平台实例的集群的客户端进行认证的计算机实现的方法，该方法包括：

在应用托管平台的第二实例处，从客户端接收访问在集群的第二应用托管平台实例上托管的第二应用的请求，该客户端经由认证令牌被认证以访问在集群的第一应用托管平台实例上托管的第一应用；

响应于请求，从客户端将认证令牌提取到应用托管平台的第二实例；

将集群的应用托管平台实例中的一个应用托管平台实例确定为主要认证应用托管平台实例；

向主要认证应用托管平台实例发送针对认证令牌的验证请求；

从主要认证应用托管平台实例接收对认证令牌的验证确认；以及

响应于接收到验证确认，向客户端准予对在第二应用托管平台实例上托管的第二应用进行访问。

条款2、一种或多种计算机可读介质，包括计算机可执行指令，计算机可执行指令当被执行时，使得计算系统执行条款1的方法。

条款3、条款1的方法，其中：

验证请求包括认证令牌。

条款4、条款1或3中任一项的方法，其中：

主要认证应用托管平台实例是在租户特定配置信息中指定的；并且

将集群的实例中的一个实例确定为主要认证应用托管平台实例是经由租户特定配置信息来执行的。

条款5、条款4的方法，其中：

不同的主要认证应用托管平台实例是针对不同的租户接收的。

条款6、条款5的方法，其中：

接收不同的主要认证应用托管平台实例包括针对不同的租户接收不同地理位置的指示。

条款7、条款4-6中任一项的方法，其中：

租户特定配置信息指定第二应用要在平台实例中的哪个平台实例上被托管。

条款8、条款7的方法还包括：

将请求重定向到除租户特定配置信息指定第二应用要在其上被托管的平台实例之外的平台实例，到租户特定配置信息指定第二应用要在其上被托管的平台实例。

条款9、条款1或3-8中任一项的方法，其中：

从客户端提取认证令牌包括从客户端侧持久存储装置请求认证令牌。

条款10、条款1或3-9中任一项的方法，其中：

来自客户端的请求是由具有客户端标识符和客户端秘密的应用实例发出的；

应用实例初始地经由客户端标识符和客户端秘密被认证以访问第一应用；

应用实例保存认证令牌；并且

应用实例经由认证令牌被认证以访问第二应用。

条款11、条款1或3-10中任一项的方法，其中：

从客户端提取认证令牌是通过重用由于向第一应用认证而已经被存储在客户端处的认证令牌来执行的。

条款12、条款11的方法，其中：

认证令牌包括租户标识符已经被加密到其中的承载令牌；

验证请求包括请求租户标识符；并且

如果请求租户标识符与包含在认证令牌中的租户标识符不匹配，则验证失败。

条款13、条款11或12中任一项的方法，其中：

认证令牌与登录会话相关联；并且

当登录会话结束时，认证令牌无效。

条款14、条款11-13中任一项的方法，其中：

认证令牌包括主要认证应用托管平台实例的指示。

条款15、一种计算系统，包括：

一个或多个处理器；

存储器；

多个应用托管平台实例，其包括被配置为存储和验证认证令牌的相应平台认证服务、一个或多个相应托管的应用以及针对多个租户的租户特定认证配置信息；

其中，应用托管平台实例的平台认证服务被配置为根据租户中的给定租户的租户特定认证配置信息而用作主要平台认证服务；并且

其中，平台认证服务被配置为将认证请求从针对给定租户的托管的应用重定向到在租户特定认证配置信息中针对给定租户指定的主要平台认证服务。

条款16、条款15的计算系统，其中：

主要平台认证服务在租户特定配置信息中被指定为地理位置。

条款17、条款15-16中任一项的计算系统，其中：

重定向的认证请求包括对从请求客户端取回的认证令牌进行验证的请求并且从一个平台认证服务被重定向到另一平台认证服务以用于验证。

条款18、条款15-17中任一项的计算系统，其中：

平台认证服务初始地经由在租户特定配置信息中指定的身份提供商服务来认证请求对应用进行访问的客户端。

条款19、条款17的计算系统，其中：

多个应用托管平台实例用作针对给定租户的实例的集群；并且

在不与身份提供商服务进一步交互的情况下，对集群内的第二应用或后续应用进行访问的请求被处理。

条款20、条款15-19中任一项的计算系统还包括：

在租户特定配置信息中指定的身份提供商服务；

其中，平台认证服务基于租户特定配置信息向身份提供商服务中继初始认证请求，并且支持多个身份提供商服务。

条款21、一种或多种计算机可读介质，包括计算机可执行指令，该计算机可执行指令当被执行时，使得计算系统执行一种方法，该方法包括：

在跨越支持多个租户的多个数据中心的计算集群中，从经由承载认证令牌被认证以访问第一应用的客户端接收访问第二应用的请求，该承载认证令牌由于由在针对多个租户中的特定租户的确认信息中指定的身份提供商进行的认证而被主要平台认证服务准予；

从客户端提取承载认证令牌；

针对客户端确定主要认证应用托管平台实例；

向主要认证应用托管平台实例的主要平台认证服务发送认证请求以用于验证，其中，认证请求包括承载认证令牌、特定租户的租户标识符、第二应用的应用实例标识符以及第二应用的应用秘密；

从主要平台认证服务接收指示认证请求有效的通信；以及

响应于接收到认证请求有效的通信，准予由客户端对第二应用进行访问；

其中，第一应用由在第一数据中心处执行的应用托管平台的第一实例托管，并且第二应用由在不同的第二数据中心处执行的应用托管平台的不同的第二实例托管。

替换物

来自任何示例的技术可以与其他示例中的任何一个或多个示例中描述的技术组合。鉴于所公开技术的原理可以应用到的许多可能的实施例，应当认识到，所示的实施例是所公开技术的示例，并且不应当被视为对所公开技术的范围的限制。相反，所公开的技术的范围包括所附权利要求涵盖的内容。因此，要求保护所有落入权利要求的范围和精神内的内容。

Claims (14)

1.一种对访问具有多个应用托管平台实例的集群的客户端进行认证的计算机实现的方法，所述方法包括：

在所述集群的第二应用托管平台实例处，从客户端接收访问在所述第二应用托管平台实例上托管的第二应用的请求，所述客户端经由认证令牌被认证以访问在所述集群的第一应用托管平台实例上托管的第一应用；

响应于所述请求，从所述客户端将所述认证令牌提取到所述第二应用托管平台实例；

使用租户特定认证配置信息，将所述集群的应用托管平台实例中的一个应用托管平台实例确定为主要认证应用托管平台实例，所述租户特定认证配置信息包括指定的主要认证应用托管平台实例，其中所述租户特定认证配置信息是可按每个租户配置的；

向所述主要认证应用托管平台实例发送针对所述认证令牌的验证请求；

从所述主要认证应用托管平台实例接收对所述认证令牌的验证确认；以及

响应于接收到验证确认，向所述客户端准予对在所述第二应用托管平台实例上托管的所述第二应用进行访问。

2.根据权利要求1所述的方法，其中：

所述验证请求包括所述认证令牌。

3.根据权利要求1所述的方法，其中：

所述主要认证应用托管平台实例是在所述租户特定认证配置信息中指定的。

4.根据权利要求3所述的方法，其中：

不同的主要认证应用托管平台实例是针对不同的租户接收和存储的。

5.根据权利要求4所述的方法，其中：

接收和存储不同的主要认证应用托管平台实例包括针对所述不同的租户接收和存储不同地理位置的指示。

6.根据权利要求3所述的方法，其中：

所述租户特定配置信息指定所述第二应用要在所述多个平台实例中的哪个平台实例上被托管。

7.根据权利要求6所述的方法，还包括：

将对于除所述租户特定配置信息指定所述第二应用要在其上被托管的平台实例之外的平台实例的请求重定向到所述租户特定配置信息指定所述第二应用要在其上被托管的平台实例。

8.根据权利要求1所述的方法，其中：

从所述客户端提取所述认证令牌包括从客户端侧持久存储装置请求所述认证令牌。

9.根据权利要求1所述的方法，其中：

来自所述客户端的所述请求是由具有客户端标识符和客户端秘密的应用实例发出的；

所述应用实例初始地经由所述客户端标识符和所述客户端秘密被认证以访问所述第一应用；

所述应用实例保存所述认证令牌；并且

所述应用实例经由所述认证令牌被认证以访问所述第二应用。

10.根据权利要求1所述的方法，其中：

从所述客户端提取所述认证令牌包括提取由于向所述第一应用认证而已经被存储在所述客户端处的所述认证令牌。

11.根据权利要求10所述的方法，其中：

所述认证令牌包括租户标识符已经被加密到其中的承载令牌；

向所述主要认证应用托管平台实例发送的所述验证请求包括请求租户标识符；并且

如果所述请求租户标识符与包含在所述认证令牌中的所述租户标识符不匹配，则验证失败。

12.一种或多种计算机可读介质，包括计算机可执行指令，所述计算机可执行指令当被执行时，使得计算系统执行根据权利要求1所述的方法。

13.一种计算系统，包括：

一个或多个处理器；

存储器；

多个应用托管平台实例，其包括被配置为存储和验证认证令牌的相应平台认证服务、一个或多个相应托管的应用以及针对多个租户的租户特定配置信息，所述租户特定配置信息包括租户特定认证配置信息；

其中，所述应用托管平台实例的平台认证服务被配置为根据所述租户中的给定租户的所述租户特定认证配置信息而用作主要平台认证服务，所述租户特定认证配置信息是可按每个租户配置的；

其中，所述租户特定配置信息包括应用配置信息，所述应用配置信息指定将在哪些应用托管平台实例处托管哪些应用，并且是可按每个租户配置的；以及

其中，所述平台认证服务被配置为将认证请求从针对所述给定租户的托管的应用重定向到在所述租户特定认证配置信息中针对所述给定租户指定的所述主要平台认证服务。

14.根据权利要求13所述的计算系统，其中：

重定向的认证请求包括对从请求客户端取回的认证令牌进行验证的请求并且从一个平台认证服务被重定向到另一平台认证服务以用于验证。

Images