使用活动目录和一次性口令令牌组合的双因素身份认证的制作方法

相关申请的交叉引用

本申请要求于2018年11月21日提交的美国非临时专利申请号16/198,249的优先权，其内容以引用方式整体明确并入本文。

本公开的方面涉及计算机硬件和软件。特别地，本公开的一个或多个方面总体上涉及用于生成和管理认证令牌以与虚拟化环境中的各种身份提供者所提供的多种服务进行交互的计算机硬件和软件。

背景技术：

认证系统可通过借由各种认证过程来认证用户的身份和权限来允许用户访问企业服务。依赖方在试图向客户端装置提供网络服务时可向认证系统提供认证请求，并且认证系统可与一个或多个系统对接以认证用户。认证系统可返回令牌，依赖方可使用所述令牌来提供对企业服务的访问。认证要求可被配置为客户端系统的一部分，并且可包括诸如活动目录(ad)或一次性口令(otp)的过程。

认证系统中的联合可跨多个系统和应用提供针对用户身份的共同认证过程。联合可使用行业标准(诸如oauth2.0标准)来实现。认证请求可通过负责处理认证过程的方面的软件模块。

技术实现要素：

以下呈现本文所述的各种方面的简化概述。此概述不是广泛概述，并且并非意图标识关键或重要元素或描绘权利要求的范围。以下概述仅以简化形式呈现一些概念，作为以下提供的更详细描述的介绍性序言。

联合到其他方会带来有关信任、代码流程和其他问题的挑战。当期望向多个身份服务进行认证时，可能会出现问题，并且一些依赖方可能无法自己实现与认证过程相关联的流程的特定要求。这些问题与计算机实现的认证系统相关联，并且根植于此类系统中所使用的计算机结构和功能。为了克服这些限制，并且克服在阅读和理解本说明书后将显而易见的其他限制，本文所述的方面涉及使用多联合认证系统中的自联合来支持组合式认证过程。

本文所述的方面可涉及一种基于插件的认证系统。所述认证系统可包括认证接口和对应于不同认证过程的多个插件。当所述认证接口从诸如企业服务器的依赖方接收到对认证客户端装置的请求时，所述认证接口可调用对应于与所述对认证的客户端请求相关联的认证过程的插件。依赖方可以是利用认证系统来认证客户端装置的服务器和/或其他计算机装置或服务。通常，依赖方可响应于对访问由认证系统保护的服务的客户端请求而请求所述认证系统认证客户端装置。在一些情况下，所述认证系统可用作通向诸如第三方系统的其他系统的接口，所述其他系统包括有效于安全地认证所述客户端装置的用户的信息和功能。根据本文进一步描述的一些方面，多个认证过程可在单个请求中组合，并且组合式过程可由对应插件来处置。对应于所述组合式认证过程的所述插件可自联合到所述认证接口，以处理组合式请求中的单独的认证过程中的每一个。例如，对应于所述组合式认证过程的所述插件可生成其自己的单独认证请求以供所述认证接口处置。所述认证接口可调用对应于所述单独认证过程中的每一个的相应插件，并且将结果返回给对应于所述组合式认证过程的所述插件。对应于所述组合式认证过程的所述插件可组合来自与所述单独认证过程相关联的所述插件中的每一个的结果，并且组合式认证令牌可通过所述认证接口返回给所述企业服务器。以这种方式进行的自联合可允许所述认证系统支持认证流程的组合。另外，自联合可允许所述认证系统将流程从一种形式改变为另一形式，诸如从认证代码流程改变为资源所有者流程。

因此，本文所述的一些方面可提供用于处理对应于多个认证过程的认证请求的方法、系统和计算机可读介质。认证接口可从企业服务器接收对使用第一类型的认证过程来认证客户端装置的第一请求。所述第一类型的认证过程可以是认证过程的组合。例如，所述第一类型的认证过程可包括通过第二类型的认证过程和第三类型的认证过程来认证用户。所述认证接口可基于所述第一请求调用对应于所述第一类型的认证过程的第一插件以生成第一认证令牌。所述第一插件可被配置来通过自联合到所述认证接口以从其他插件获得对应于所述第二认证过程的第二认证令牌和对应于所述第三认证过程的第三认证令牌来生成所述第一认证令牌，所述其他插件对应于那些认证过程。虽然所述企业服务器是到所述认证接口的所述第一请求中的所述依赖方(基于所述组合式认证过程)，但所述第一插件可被认为是到所述认证接口的对处置所述第二类型和所述第三类型的认证过程的单独请求中的依赖方。

例如，所述第一插件可生成对使用所述第二类型的认证过程来认证客户端装置的第二请求并将其发送到所述认证接口。所述认证接口可将第二认证令牌返回给所述第一插件，所述第二认证令牌是通过基于所述第二请求调用对应于所述第二类型的认证过程的第二插件来生成。所述第一插件可生成对使用所述第三类型的认证过程来认证所述客户端装置的第三请求并将其发送到所述认证接口。所述认证接口可将第三认证令牌返回给所述第一插件，所述第三认证令牌是通过基于所述第三请求调用对应于所述第三类型的认证过程的第三插件来生成。所述第一插件可在生成对应于所述组合式认证过程的所述第一认证令牌时组合所述第二认证令牌和所述第三认证令牌，并且将所述第一认证令牌提供给所述认证接口。所述认证接口可将所述第一认证令牌提供给所述企业服务器。所述企业服务器可使用所述第一认证令牌来向所述客户端装置提供对由所述第一认证过程保护的网络服务的访问权。

对应于所述组合式认证过程中所包括的单独类型的认证过程的插件可被配置来处置和/或处理对应于所述认证过程类型的认证流程。例如，对应于所述第二类型的认证过程的第二插件可采集用户凭证并且向资源所有者系统请求所述第二认证令牌。类似地，对应于所述第三类型的认证过程的第三插件可采集必要的凭证并向资源所有者系统进行认证。根据一些方面，所述认证系统可实现单点登录特征。如果所述用户先前已经向特定资源所有者系统和/或通过特定认证过程进行认证，则所述认证系统可提供所存储的单点登录凭证/令牌，而无需重新采集凭证并且向所述资源所有者系统重新认证。尽管单点登录凭证/令牌可与定时和/或使用限制相关联，但在所述单点登录系统的参数内在重新访问资源时，它们可允许用户避免复制凭证提示。

所述第一认证过程可包括基于不同凭证的认证过程的组合。例如，所述第二认证过程可以是基于向所述用户请求用户名和口令，诸如活动目录(ad)认证过程。在所述示例中，所述第三认证过程可以是基于两因素认证过程，诸如一次性口令(otp)认证过程。在此示例中，客户端应用可请求所述认证接口基于活动目录和一次性口令认证过程的组合来认证所述客户端装置/用户。客户端应用可包括例如用户通过客户端装置访问的服务器上的应用。所述客户端应用可使用网络资源和服务所提供的信息和/或功能向所述用户提供服务。所述网络资源和服务可通过一个或多个认证过程来保护，并且访问可通过所述认证系统来促进和/或控制。继续所述示例，所述认证接口可基于对认证的请求来调用对应于ad+otp的组合的插件。所述ad+otp插件可向所述认证接口作出其自己的请求，以调用适当插件来处置所述组合式请求的每个部分。因此，通过自联合，所述ad+otp插件可通过所述认证接口，以利用现有的和受管的代码路径来处理每种所请求认证类型的认证。

受益于以下进一步详细讨论的公开内容，将会理解这些和另外的方面。

附图说明

通过结合附图参考以下描述，可获得对本文所述方面及其优点的更完整的理解，其中相同的附图标记指示相同的特征，并且其中：

图1描绘根据本文所述的一个或多个说明性方面可使用的说明性计算机系统架构。

图2描绘根据本文所述的一个或多个说明性方面可使用的说明性远程访问系统架构。

图3描绘说明性的企业移动性管理系统。

图4描绘示例性基于插件的认证系统。

图5描绘根据本文所述的一些方面的结合自联合的示例性基于插件的认证系统。

图6描绘根据本文所述的一些方面的认证系统中的自联合的使用的示例性流程图。

图7描绘根据一些方面的实现组合式认证过程而无需自联合的示例性基于插件的认证系统。

图8描绘操作以将第一认证流程与第二认证流程进行组合的示例性基于插件的认证系统。

具体实施方式

在以下对各种实施方案的描述中，参考以上标识的附图，并且所述附图形成所述描述的一部分，并且在附图中以说明的方式示出其中可实践本文所述的方面的各种实施方案。应理解，在不脱离本文所述的范围的情况下，可利用其他实施方案，并且可进行结构和功能修改。各种方面能够具有其他实施方案并且能够以各种不同的方式来实践或实施。

应理解，本文使用的用语和术语是为了描述的目的且不应被视为限制性的。相反，本文使用的短语和术语应被给予它们最广泛的解释和含义。“包括”和“包含”及其变体的使用意指涵盖其后列出的项目及其等效物以及附加的项目及其等效物。术语“安装”、“连接”、“耦接”、“定位”、“接合”和类似术语的使用意包括直接和间接安装、连接、耦接、定位和接合。

如上所解释，本文所述的方面可利用基于插件的认证系统中的自联合来支持认证过程的组合。如以上和本文中进一步讨论的，认证系统中的联合可允许一个认证系统召用联合身份提供者的功能。联合可使用行业标准(诸如oauth2.0标准)来实现。通过联合，认证请求可通过负责处理认证过程的方面的软件模块。本文所述的方面可涉及“自联合”回到认证系统以实施复合工作流的各个部分的组件。

认证系统可提供来处理并响应来自依赖方的认证请求。认证系统可用作与各种联合身份提供者的接口。认证系统可使用一个或多个计算装置、处理器、存储器和/或其他计算硬件来实现，如本文进一步所讨论。认证系统可包括响应认证请求并实现系统所支持的认证过程的合适的软件代码模块。认证系统可包括对应于认证过程的插件，所述认证过程是两个或更多个其他认证过程的组合。此插件可通过自联合回到所述认证接口从而在次级认证过程中的每一个下生成其自己的认证请求来处置组合式认证过程。认证请求可包括要在认证客户端装置和/或用户时使用的认证过程的指示。指示可以是例如召用特定认证过程的显式请求和/或其中可基于要访问的资源的指示来确定认证过程的隐式请求。对应于组合式认证过程的自联合插件可允许认证系统支持指示组合式认证过程的认证请求。通过自联合实现的此“链式”认证过程可允许所述认证系统重复使用现有的代码路径并且避免与代码复制相关联的不利面。

作为一个示例，考虑以下认证系统，所述系统支持通过第一认证过程(诸如活动目录(ad))进行用户名和口令验证，并且支持通过第二认证过程(诸如一次性口令(otp))进行双因素验证。如果诸如企业服务器的依赖方想要通过ad过程来认证客户端装置，则依赖方可向认证系统发送认证请求。认证系统的认证接口可将认证请求路由到对应ad插件，所述ad插件可在向客户ad系统进行认证之前提示用户输入用户名和口令。但是，如果希望企业服务器使用ad和otp两者进行认证，则客户端应用可能需要生成两个单独的认证请求。本文所述的方面可提供对应于组合式认证过程(诸如ad+otp)的插件。这种ad+otp插件可自联合回到认证系统的认证接口，并且生成针对ad认证和otp认证的请求，所述请求将由相应的ad和otp插件处理。ad+otp插件可从认证接口接收针对ad和otp请求的所得认证令牌，并且可组合令牌以供客户端应用使用。组合式令牌可通过认证接口返回给企业服务器，使得用户可访问系统。

虽然本文的示例讨论了ad、otp和ad+otp认证过程，但是应理解，这些仅仅是示例性实施方案。本文所述的方面可适用于认证系统所支持的任何类型的认证过程，以及它们的任何组合。尽管使用了这些示例性认证过程，但是本文的讨论同样适用于其他类型和组合式认证过程。

但是在进一步讨论这些和其他方面之前，将要将讨论转向其中可实现本文所述的方面的示例性计算环境，如图1至图3所示。

计算机软件、硬件和网络可在多种不同的系统环境中利用，包括独立的、联网的、远程访问(亦称远程桌面)的、虚拟化的和/或基于云的环境等。图1示出可用于在独立和/或联网环境中实现本文所述的一个或多个说明性方面的系统架构和数据处理装置的一个示例。各种网络节点103、105、107和109可通过诸如互联网的广域网(wan)101互连。另外地或替代地可使用其他网络，包括私有内联网、公司网络、局域网(lan)、城域网(man)、无线网络、个人网络(pan)等。网络101是用于说明目的，并且可用更少或更多的计算机网络替换。局域网133可具有任何已知lan拓扑中的一种或多种，并且可使用多种不同协议中的一种或多种，诸如以太网。装置103、105、107和109以及其他装置(未示出)可通过双绞线、同轴电缆、光纤、无线电波或其他通信介质连接到一个或多个网络。

如本文所使用和附图中所描绘的术语“网络”不仅是指其中通过一个或多个通信路径将远程存储装置耦接在一起的系统，而且还是指可不时地耦接到具有存储能力的此类系统的独立装置。因此，术语“网络”不仅包括“物理网络”，而且还包括“内容网络”，它由跨所有物理网络驻留的(归因于单个实体的)数据组成。

这些组件可包括数据服务器103、web服务器105和客户端计算机107、109。数据服务器103提供对用于执行本文所述的一个或多个说明性方面的数据库和控制软件的总体访问、控制和管理。数据服务器103可连接到web服务器105，通过web服务器105，用户进行交互并根据请求获得数据。替代地，数据服务器103本身可充当web服务器并且可直接连接到互联网。数据服务器103可通过局域网133、广域网101(例如，互联网)、借由直接或间接连接或借由某种其他网络连接到web服务器105。用户可使用远程计算机107、109与数据服务器103交互，例如，使用通过由web服务器105托管的一个或多个对外公开的网站连接到数据服务器103的web浏览器。客户端计算机107、109可与数据服务器103结合使用以访问存储在其中的数据，或者可用于其他目的。例如，用户可使用互联网浏览器(如本领域中已知的)或通过执行通过计算机网络(诸如互联网)与web服务器105和/或数据服务器103通信的软件应用来从客户端装置107访问web服务器105。

服务器和应用可组合在相同物理机器上，并且保留单独的虚拟或逻辑地址，或者可驻留在单独的物理机器上。图1示出可使用的网络架构的仅一个示例，并且本领域技术人员应理解，所使用的特定网络架构和数据处理装置可变化，并且取决于它们所提供的功能，如本文进一步所描述。例如，web服务器105和数据服务器103所提供的服务可组合在单个服务器上。

每个组件103、105、107、109可以是任何类型的已知计算机、服务器或数据处理装置。例如数据服务器103可包括控制数据服务器103的总体操作的处理器111。数据服务器103还可包括随机存取存储器(ram)113、只读存储器(rom)115、网络接口117、输入/输出接口119(例如，键盘、鼠标、显示器、打印机等)以及存储器121。输入/输出(i/o)119可包括用于读取、写入、显示和/或打印数据或文件的多种接口单元和驱动器。存储器121可进一步存储用于控制数据处理装置103的总体操作的操作系统软件123、用于指示数据服务器103执行本文所述的方面的控制逻辑125、以及可结合或可不结合本文所述的方面使用的提供次级、支持和/或其他功能的其他应用软件127。控制逻辑在本文中也可称为数据服务器软件125。数据服务器软件的功能可以是指基于编码到控制逻辑中的规则自动做出的操作或决策、由向系统提供输入的用户手动做出的操作或决策、和/或基于用户输入的自动处理(例如，查询、数据更新等)的组合。

存储器121还可存储用于执行本文所述的一个或多个方面的数据，包括第一数据库129和第二数据库131。在一些实施方案中，第一数据库可包括第二数据库(例如，作为单独的表、报告等)。也就是说，取决于系统设计，信息可存储在单个数据库中，或可分离到不同的逻辑、虚拟或物理数据库中。装置105、107和109可具有与针对装置103所描述类似或不同的架构。本领域技术人员应理解，如本文所述的数据处理装置103(或装置105、107或109)的功能可分布在多个数据处理装置上，例如以将处理负载分布在多个计算机上，以基于地理位置、用户访问级别、服务质量(qos)等隔离交易。

一个或多个方面可在由一个或多个计算机或本文所述的其他装置执行的计算机可用或可读数据和/或计算机可执行指令中(诸如一个或多个程序模块中)体现。通常，程序模块包括在由计算机或其他装置中的处理器执行时执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。模块可用随后编译用于执行的源代码编程语言编写，或者可用诸如(但不限于)超文本标记语言(html)或可扩展标记语言(xml)的脚本语言编写。计算机可执行指令可存储在计算机可读介质诸如非易失性存储装置上。可利用任何合适的计算机可读存储介质，包括硬盘、cd-rom、光学存储装置、磁性存储装置和/或它们的任意组合。此外，如本文所述的表示数据或事件的各种传输(非存储)介质可以行进穿过信号传导介质(诸如金属线、光纤和/或无线传输介质(例如，空气和/或空间))的电磁波的形式在源与目的地之间传输。本文所述的各种方面可体现为方法、数据处理系统或计算机程序产品。因此，各种功能可全部或部分地体现在软件、固件和/或硬件或硬件等效物(诸如集成电路、现场可编程门阵列(fpga)等)中。特定数据结构可用于更有效地实现本文所述的一个或多个方面，并且此类数据结构预期在本文所述的计算机可执行指令和计算机可用数据的范围内。

进一步参考图2，本文所述的一个或多个方面可在远程访问环境中实现。图2描绘根据本文所述的一个或多个说明性方面可使用的示例性系统架构，其包括说明性计算环境200中的计算装置201。计算装置201可用作被配置来向客户端访问装置提供虚拟机的单服务器或多服务器桌面虚拟化系统(例如，远程访问或云系统)中的服务器206a。计算装置201可具有用于控制服务器及其相关联组件(包括ram205、rom207、输入/输出(i/o)模块209和存储器215)的总体操作的处理器203。

i/o模块209可包括计算装置201的用户可通过其提供输入的鼠标、小键盘、触摸屏、扫描仪、光学读取器和/或触针(或一个或多个其他输入装置)，并且还可包括用于提供音频输出的一个或多个扬声器以及用于提供文本、视听和/或图形输出的一个或多个视频显示装置。软件可存储在存储器215和/或其他存储装置内，以向处理器203提供指令，以用于将计算装置201配置成专用计算装置，以便执行如本文所述的各种功能。例如，存储器215可存储由计算装置201使用的软件，诸如操作系统217、应用219和相关联数据库221。

计算装置201可在支持与一个或多个远程计算机诸如终端240(也称为客户端装置)的连接的联网环境中操作。终端240可以是个人计算机、移动装置、膝上型计算机、平板电脑或服务器，其包括以上关于计算装置103或201描述的许多或所有元件。图2中描绘的网络连接包括局域网(lan)225和广域网(wan)229，但是也可包括其他网络。当在lan联网环境中使用时，计算装置201可通过网络接口或适配器223连接到lan225。当在wan联网环境中使用时，计算装置201可包括调制解调器227或其他广域网接口，以用于通过wan229诸如计算机网络230(例如，互联网)建立通信。应理解，所示网络连接是说明性的，并且可使用在计算机之间建立通信链路的其他手段。计算装置201和/或终端240也可以是包括各种其他组件诸如电池、扬声器和天线(未示出)的移动终端(例如，移动电话、智能电话、个人数字助理(pda)、笔记本电脑等)。

本文所述的方面也可与众多其他通用或专用计算系统环境或配置一起操作。可适用于本文所述的方面的其他计算系统、环境和/或配置的示例包括但不限于个人计算机、服务器计算机、手持或膝上型装置、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人计算机(pc)、小型计算机、大型计算机、包括任何上述系统或装置的分布式计算环境等。

如图2所示，一个或多个客户端装置240可与一个或多个服务器206a-206n(在本文中通常称为“一个或多个服务器206”)通信。在一个实施方案中，计算环境200可包括安装在一个或多个服务器206与一个或多个客户端机器240之间的网络设备。网络设备可管理客户端/服务器连接，并且在一些情况下，可在多个后端服务器206之间负载平衡客户端连接。

在一些实施方案中，一个或多个客户端机器240可称为单个客户端机器240或单个群组的客户端机器240，而一个或多个服务器206可称为单个服务器206或单个群组的服务器206。在一个实施方案中，单个客户端机器240与多于一个服务器206通信，而在另一实施方案中，单个服务器206与多于一个客户端机器240通信。在又另一实施方案中，单个客户端机器240与单个服务器206通信。

在一些实施方案中，客户端机器240可通过以下非详尽术语中的任一者来引用：一个或多个客户端机器；一个或多个客户端；一个或多个客户端计算机；一个或多个客户端装置；一个或多个客户端计算装置；本地机器；远程机器；一个或多个客户端节点；一个或多个端点；或一个或多个端点节点。在一些实施方案中，服务器206可通过以下非详尽术语中的任一者来引用：一个或多个服务器；本地机器；远程机器；一个或多个服务器场；或一个或多个主机计算装置。

在一个实施方案中，客户端计算机240可以是虚拟机。虚拟机可以是任何虚拟机，而在一些实施方案中，虚拟机可以是由类型1或类型2管理程序(例如，由citrixsystems、ibm、vmware开发的管理程序或任何其他管理程序)管理的任何虚拟机。在一些方面，虚拟机可由管理程序管理，而在其他方面，虚拟机可由在服务器206上执行的管理程序或在客户端240上执行的管理程序管理。

一些实施方案包括客户端装置240，所述客户端装置240显示由在服务器206或其他远程定位的机器上远程执行的应用生成的应用输出。在这些实施方案中，客户端装置240可执行虚拟机接收器程序或应用以在应用窗口、浏览器或其他输出窗口中显示输出。在一个示例中，所述应用是桌面，而在其他示例中，所述应用是生成或呈现桌面的应用。桌面可包括图形外壳，所述图形外壳为其中可集成本地和/或远程应用的操作系统的实例提供用户接口。如本文所使用，应用是在操作系统(以及任选地，还有桌面)的实例已经加载之后执行的程序。

在一些实施方案中，服务器206使用远程呈现协议或其他程序来将数据发送到瘦客户端或在客户端上执行的远程显示应用，以呈现由在服务器206上执行的应用生成的显示输出。瘦客户端或远程显示协议可以是以下非穷举协议列表中的任一种：由佛罗里达州劳德代尔的思杰系统有限公司开发的独立计算架构(ica)协议；或由华盛顿州雷蒙德的微软公司制造的远程桌面协议(rdp)。

远程计算环境可包括多于一个服务器206a-206n，使得服务器206a-206n在逻辑上一起分组到服务器场206中，例如在云计算环境中。服务器场206可包括在地理上分散而在逻辑上分组在一起的服务器206，或者彼此邻近定位同时在逻辑上分组在一起的服务器206。在一些实施方案中，服务器场206内在地理上分散的服务器206a至206n可使用wan(广域网)、man(城域网)或lan(局域网)进行通信，其中不同地理区域可表征为：不同的大陆；大陆的不同区域；不同的国家；不同的州；不同的市；不同的校园；不同的房间；或前述地理位置的任何组合。在一些实施方案中，服务器场206可作为单个实体来管控，而在其他实施方案中，服务器场206可包括多个服务器场。

在一些实施方案中，服务器场可包括执行基本上类似类型的操作系统平台(例如，windows、unix、linux、ios、android、symbian等)的服务器206。在其他实施方案中，服务器场206可包括执行第一类操作系统平台的第一群组的一个或多个服务器，以及执行第二类型的操作系统平台的第二群组的一个或多个服务器。

服务器206可根据需要配置为任何类型的服务器，例如，文件服务器、应用服务器、web服务器、代理服务器、设备、网络设备、网关、应用网关、网关服务器、虚拟化服务器、部署服务器、安全套接字层(ssl)vpn服务器、防火墙、web服务器、应用服务器，或者配置为主应用服务器、执行活动目录的服务器，或执行提供防火墙功能、应用功能或负载平衡功能的应用加速程序的服务器。也可使用其他服务器类型。

一些实施方案包括第一服务器206a，所述第一服务器206a从客户端机器240接收请求，将请求转发到第二服务器206b(未示出)，并且利用来自第二服务器206b(未示出)的响应来响应由客户端机器240生成的请求。第一服务器206a可获取可用于客户端机器240的应用的枚举，以及与托管应用的枚举内标识的应用的应用服务器206相关联的地址信息。然后，第一服务器206a可使用web接口来呈现对客户端请求的响应，并且与客户端240直接通信以向客户端240提供对所标识应用的访问权。一个或多个客户端240和/或一个或多个服务器206可通过网络230(例如，网络101)传输数据。

图3是说明性企业移动性管理系统300。在这种情况下，左手侧表示具有客户端代理304的注册移动装置302，客户端代理304与网关服务器306(其包括访问网关和应用控制器功能)交互，以访问各种企业资源308和服务309，诸如exchange、sharepoint、公钥基础设施(pki)资源、kerberos资源、证书签发服务，如右手侧上方所示。虽然未具体示出，但是移动装置302也可与企业应用商店(storefront)交互以选择和下载应用。

客户端代理304充当可使用高清用户体验(hdx)/ica显示远程协议访问的托管在企业数据中心中的windowsapp/桌面的ui(用户界面)中介。客户端代理304还支持移动装置302上的本机应用(诸如本机ios或android应用)的安装和管理。例如，上图中示出的受管应用310(邮件、浏览器、包装应用)都是在移动装置302上本地执行的本机应用。客户端代理304和此架构的应用管理框架用于提供策略驱动的管理能力和特征，诸如到企业资源/服务308的连接性和sso(单点登录)。客户端代理304处理对企业的初级用户认证，通常是对具有到其他网关服务器组件的sso的访问网关(ag)306的认证。客户端代理304从网关服务器306获得控制移动装置302上的受管应用310的行为的策略。

本机应用310与客户端代理304之间的安全进程间通信(ipc)链路312表示管理通道，所述管理通道可允许客户端代理供应将由“包装”每个应用的应用管理框架314强制实施的策略。ipc通道312还可允许客户端代理304供应实现到企业资源308的连接性和sso的凭证和认证信息。最后，ipc通道312可允许应用管理框架314召用由客户端代理304实现的用户接口功能，诸如在线和离线认证。

客户端代理304与网关服务器306之间的通信本质上是来自包装每个本机受管应用310的应用管理框架314的管理通道的扩展。应用管理框架314可向客户端代理304请求策略信息，客户端代理304继而可向网关服务器306请求策略信息。应用管理框架314可请求认证，并且客户端代理304可登录到网关服务器306的网关服务部分(也称为netscaler访问网关)。客户端代理304还可调用网关服务器306上的支持服务，所述支持服务可产生输入材料以得到用于本地数据保管库316的加密密钥，或者可提供可实现对受pki保护的资源的直接认证的客户端证书，如以下更全面解释的。

更详细地，应用管理框架314“包装”每个受管应用310。这可通过显式构建步骤或通过构建后处理步骤来结合。应用管理框架314可在应用310首次启动时与客户端代理304“配对”，以初始化安全ipc通道312并且获得用于所述应用的策略。应用管理框架314可强制实施所述策略的在本地应用的相关部分(诸如客户端代理登录依赖性)，以及限制可使用本地os服务的方式或者它们与受管应用310交互的方式的遏制策略中的一些。

应用管理框架314可使用由客户端代理304通过安全ipc通道312提供的服务来促进认证和内部网络访问。对私有和共享数据保管库316(容器)的密钥管理也可通过受管应用310与客户端代理304之间的适当交互来管理。保管库316可仅于在线认证之后可用，或者如果策略允许，则可在离线认证之后变得可用。首次使用保管库316可需要在线认证，并且离线访问在再次需要在线认证之前可限于至多策略刷新周期。

对内部资源的网络访问可通过访问网关306从单独受管应用310直接进行。应用管理框架314可代表每个受管应用310负责组织网络访问。客户端代理304可通过提供于在线认证之后获得的合适的有时间限制的次级凭证来促进这些网络连接。可使用多种网络连接模式，诸如反向web代理连接和端到端vpn式隧道318。

邮件和浏览器受管应用310具有特殊状态，并且可利用对于任意包装应用通常可能不可用的设施。例如，邮件应用310可使用允许它在延长的时间段内访问exchange服务器308而无需完全的ag登录的特殊后台网络访问机制。浏览器应用310可使用多个私有数据保管库316来隔离不同种类的数据。

此架构可支持各种其他安全特征的结合。例如，在一些情况下，网关服务器306(包括其网关服务)可能不需要验证活动目录(ad)口令。在一些情况下，ad口令是否可用作一些用户的认证因素可由企业自行决定。如果用户在线或离线(即连接或未连接到网络)，则可使用不同的认证方法。

加强认证(stepupauthentication)是以下特征：其中网关服务器306可标识被允许访问需要强认证的高度机密数据的受管本机应用310，并且确保仅在执行适当的认证之后才被准许访问这些应用，即使这意味着用户在先前较弱的登录级别之后需要重新认证也是如此。

这种解决方案的另一安全特征是对移动装置302上的数据保管库316(容器)的加密。可对保管库316进行加密，使得包括文件、数据库和配置的所有装置上数据都受到保护。对于在线保管库，密钥可存储在服务器(网关服务器306)上，而对于离线保管库，密钥的本地副本可通过用户口令或生物计量验证来保护。如果数据在移动装置302上本地存储在安全容器316中或者在这种情况时，可优选的是利用至少aes256加密算法。

也可实现其他安全容器特征。例如，可包括记录特征，其中可记录发生在受管应用310内的安全事件并将其报告给后端。可支持数据擦除，诸如如果受管应用310检测到篡改或者在这种情况时，可用随机数据重写相关联加密密钥，而不在文件系统上留下用户数据被破坏的提示。屏幕截图保护可以是另一特征，其中应用可防止将任何数据存储在屏幕截图中。例如，可将密钥窗口的隐藏特性设置为是(yes)。这可致使隐藏当前显示在屏幕上的任何内容，从而产生任何内容通常将驻留在其中的空白屏幕截图。

可防止本地数据传输，例如通过防止例如通过将任何数据复制或发送到外部应用而将任何数据本地传输到应用容器之外。键盘高速缓存特征可操作以禁用针对敏感文本字段的自动校正功能。ssl证书验证可能够操作以使得应用专门验证服务器ssl证书，而不是将其存储在钥匙串中。可使用加密密钥生成特征，使得使用由用户供应的口令短语或生物计量数据来生成用于加密移动装置302上的数据的密钥(如果需要离线访问的话)。如果不需要离线访问，则可用随机生成并且存储在服务器端的另一密钥对其进行异或运算。密钥派生函数可操作以使得从用户口令生成的密钥使用kdf(密钥派生函数，尤其是基于口令的密钥派生函数2(pbkdf2))，而不是创建其密码散列。后者使得密钥容易受到暴力破解或字典攻击。

此外，可在加密方法中使用一个或多个初始化向量。初始化向量将致使相同加密数据的多个副本产生不同密文输出，从而防止重放和密码分析攻击两者。这也将防止攻击者解密任何数据，即使是利用被盗的加密密钥。此外，可使用认证后解密，其中仅在用户已经在应用内认证之后才解密应用数据。另一特征可涉及存储器中的敏感数据，所述敏感数据仅在需要时才保留在存储器中(而不是磁盘中)。例如，登录凭证可在登录后从存储器中擦除，并且由于加密密钥和objective-c实例变量中的其他数据可容易被参考，因此不对其进行存储。替代地，可为它们手动分配存储器。

可实施不活动超时，其中在策略限定的不活动时段之后，终止用户会话。

可通过其他方式防止来自应用管理框架314的数据泄漏。例如，如果受管应用310被置于后台中或者在这种情况时，可在预定(可配置)时间段之后清除存储器。在后台运行时，可拍摄应用的最后显示屏幕的快照，以加快前台运行进程。屏幕截图可能包含机密数据，因此应清除。

另一安全特征可涉及使用otp(一次性口令)320而不使用ad(活动目录)322口令来访问一个或多个应用。在一些情况下，一些用户不知道(或不被准许知道)他们的ad口令，因此这些用户可使用otp320进行认证，诸如通过使用硬件otp系统，如securid(otp也可由不同供应商诸如entrust或gemalto提供)。在一些情况下，在用户利用用户id进行认证之后，可通过otp320向用户发送文本。在一些情况下，这可仅实现用于在线使用，提示是单个字段。

对于通过企业策略被准许离线使用的受管应用310，可实现离线口令以用于离线认证。例如，企业可能希望以这种方式访问storefront。在这种情况下，客户端代理304可要求用户设置自定义离线口令，并且不使用ad口令。网关服务器306可提供策略来控制和强制实施关于口令的最小长度、字符类组成和年限的口令标准，诸如由标准windows服务器口令复杂性要求所描述，但这些要求可被修改。

另一特征可涉及为某些应用310实现客户端凭证作为次级凭证(以便通过应用管理框架微vpn特征来访问受pki保护的web资源)。例如，受管应用310可利用这种证书。在这种情况下，可支持使用activesync协议的基于证书的认证，其中来自客户端代理304的证书可通过网关服务器306检索并且在钥匙串中使用。每个受管应用310可具有一个相关联客户端证书，所述一个相关联客户端证书由在网关服务器306中限定的标签标识。

网关服务器306可与企业专用web服务交互以支持发布客户端证书，以允许相关的受管应用对内部受pki保护的资源进行认证。

客户端代理304和应用管理框架314可被增强以支持获得客户端证书并使用客户端证书来向内部受pki保护的网络资源进行认证。可支持多于一个证书，以便匹配各种级别的安全性和/或隔离要求。证书可由邮件和浏览器受管应用310使用，并且最终由任意包装应用310使用(前提是这些应用使用其中应用管理框架调解https请求合理的web服务式通信模式)。

关于ios的应用管理客户端证书支持可依赖于在每个使用时段将公钥加密标准(pkcs)12blob(二进制大对象)导入每个受管应用310中的ios钥匙串中。应用管理框架客户端证书支持可使用具有私有存储器内密钥存储的https实现方式。客户端证书可能不存在于ios钥匙串中，也可能无法保存，除非在受到严格保护的“仅在线”数据值中。

还可通过要求移动装置302向企业进行认证(且反之亦然)来实现相互ssl以提供另外的安全性。还可实现用于向网关服务器306进行认证的虚拟智能卡。

有限和完全的kerberos支持都可以是另外的特征。完全支持特征涉及使用ad口令或可信客户端证书进行到活动目录(ad)322的完全kerberos登录并且获得kerberos服务票据以响应http协商认证挑战的能力。有限支持特征涉及思杰访问网关企业版(agee)中的受约束委派，其中agee支持召用kerberos协议变换，因此它可响应于http协商认证挑战而获得并使用kerberos服务票据(受到受约束委派限制)。这种机制在反向web代理(也称为公司虚拟私有网络(cvpn))模式下以及当http(但不是https)连接在vpn和微vpn模式下被代理时工作。

另一特征可涉及应用容器锁定和擦除，所述应用容器锁定和擦除可在越狱或寻根检测时自动地发生，并且作为来自管理控制台的推送命令发生，并且可包括远程擦除功能，即使在受管应用310未在运行时也是如此。

可支持企业应用商店和应用控制器的多站点架构或配置，其允许在发生故障的情况下从若干不同位置中的一个服务用户。

在一些情况下，受管应用310被允许通过api(例如，openssl)访问证书和私钥。企业的可信受管应用310可被允许利用应用的客户端证书和私钥来执行特定的公钥操作。可相应地标识并处理各种用例，诸如如果应用表现得像浏览器并且不需要证书访问或者在这种情况时，如果应用读取“我是谁”的证书或者在这种情况时，如果应用使用证书来构建安全会话令牌或者在这种情况时，以及如果应用使用私钥来对重要数据(例如，事务日志)进行数字签名或进行临时数据加密或者在这种情况时。

如以上所讨论，本公开的方面涉及利用认证系统中的自联合来提供增强的认证过程。本公开的一个或多个方面可结合在以上结合图1至图3讨论的计算机系统架构、远程访问系统架构和/或企业移动性管理系统中的一者或多者中、体现在其中、和/或使用其来实现。例如，网关服务器306可被配置来提供基于插件的认证系统，诸如思杰的athena认证系统产品。基于插件的认证系统可被配置来联合到多个第三方认证系统(也称为联合提供者)。此联合可使用oauth2.0流程通过安全地重定向到联合提供者并进行令牌交换来进行。认证接口本身可不为联合提供者本身收集凭证。替代地，插件软件模块可与第三方认证系统对接，以检索用户凭证并对用户进行认证。

图4描绘根据本文所述的一个或多个方面的这种基于插件的认证系统的说明性示例。特别地，图4示出计算环境400，其包括客户端装置405、依赖方410、认证系统420以及多个联合身份提供者441、443、445、447。联合身份提供者的示例包括客户ad服务器441、客户aad服务器443、客户okta服务器445和一次性口令服务器447，如以下进一步所讨论。每个所示的实体可包括一个或多个物理组件，诸如一个或一个以上处理器、存储器、通信接口等。

依赖方410可以是向客户端装置405提供服务的服务器，并且可以是任何类型的计算装置，包括例如服务器、计算机、膝上型计算机、平板电脑、智能电话或包括处理器的其他装置(例如，计算装置201)。依赖方410可通过通信接口(例如，无线接口、lan接口、wlan接口)与客户端装置405和其他装置和/或实体(诸如认证系统420)通信，以请求对访问网络服务和数据的认证，如以下更详细讨论的。依赖方410可以是企业服务器，其可以是负责提供和管理可由一个或多个企业用户通过客户端装置405访问的虚拟的基于云的环境的服务器。在示例性用例中，依赖方410可以是企业的服务器，员工登录所述服务器以进行对访问企业的虚拟的基于云的环境(例如，虚拟桌面、虚拟应用、虚拟移动应用或一个或多个其他虚拟服务)的认证。

认证系统420可以是企业身份提供者服务器，并且可包括至少一个处理器、存储器和通信接口。处理器可执行存储在存储器中的指令，以致使认证系统420执行一个或多个功能，诸如检索对应于来自依赖方410的认证请求的认证令牌。通信接口可包括一个或多个网络接口，认证系统420可通过其与计算环境400中的一个或多个其他系统和/或装置(诸如依赖方410和/或联合身份提供者441、443、445、447)通信。

认证系统420可以是负责在企业网络中提供身份管理平台的服务器。具体地，认证系统420可负责生成、更新和管理供企业用户和/或其相应装置用于向虚拟的基于云的环境进行认证并访问其资源(例如，计算环境400中所提供的资源)的认证令牌。这样，依赖方410可代表用户装置(例如，客户端装置405)从认证服务器420获得认证令牌，所述认证令牌使得用户装置能够访问企业系统中的服务和资源。例如，依赖方可指导用户登录由认证系统420提供的身份管理平台，并且从身份管理平台(例如，联合身份提供者，诸如客户ad服务器441)获得认证令牌。

由于成功完成企业网络中的认证过程(例如，登录)，认证系统420可向经认证用户(例如，成功向联合身份提供者认证的用户)发布认证令牌。在一个示例中，客户端装置的用户可使用他们的现有认证凭证(所述认证凭证可以是用户名和口令、生物计量测量(例如，指纹扫描、视网膜扫描、面部识别、语音识别等))、输入提供给指定用户装置的访问代码(例如，用户的智能电话可能会接收到包含要输入到由依赖方提供的门户中的代码的消息)、或用于访问企业网络的任何其他认证手段来登录虚拟化的基于云的环境。响应于用户装置的成功登录，认证系统420可为经认证用户发布认证令牌，并且将认证令牌转发给依赖方410，这继而可使得用户装置能够对企业网络内的虚拟化的基于云的环境中的服务和资源进行单点登录(sso)访问。以这种方式，认证系统420可向依赖方410提供所请求的认证令牌。

计算环境400可包括可负责生成、更新和管理用于在公共网络中用于访问第三方系统的用户令牌的一个或多个联合身份提供者，诸如联合身份提供者441、443、445、447。在一些情况下，联合身份提供者服务器可能无法识别和解译由认证系统420发布的认证令牌。因此，使得用户装置能够访问企业系统的认证令牌可能不足以准许用户装置访问第三方系统。在这种情境下，认证系统420可将通过依赖方410来自用户装置的对访问第三方系统的请求重定向到由对应联合身份提供者服务器管理和认证的登录页面。

这可使用认证接口425和对应认证过程插件431、433、435、437来实现。认证系统420可通过认证接口425接收对认证的请求。认证接口425可检查对认证的请求并确定所指示认证过程。例如，认证请求可使用请求中所包括的参数或其他信息来显式地指示对应认证过程。作为另一示例，认证请求可隐式地指示对应认证过程。认证接口可基于所请求资源的类型来确定对应认证过程。作为其一个示例，当认证请求指示用户正在请求访问使用客户ad服务器441保护的邮件服务器时，认证接口可确定应使用ad认证过程。可将请求路由到对应于所指示认证过程的插件(例如，插件431、433、435、437)。插件可与对应于所指示认证过程的联合身份提供者服务器(例如，服务器441、443、445和/或447)协调地进行认证过程，并且检索对应认证令牌。插件可将认证令牌返回给认证接口425，认证接口425可将其传递给依赖方410。

一个或多个联合身份提供者服务器可以是负责提供用于联合登录访问公共网络中的第三方系统的身份平台的服务器。具体地，联合身份提供者服务器441可负责生成、更新和管理供用户装置用于访问使用活动目录(ad)认证过程保护的第三方系统的令牌。认证系统420可提供ad插件431以处理并转发向客户ad服务器441进行认证的请求，并且认证系统420可被配置来响应于认证而接收并返回与客户ad服务器441相关联的认证令牌。类似地，客户azuread服务器443可管理对由azure活动目录(aad)认证过程保护的资源的访问，并且aad插件433可处置认证系统420的处理。客户okta服务器445可管理对由okta身份管理服务保护的资源的访问，并且okta插件435可认证系统420的处理。totp服务器447可提供用于保护一些网络资源的基于时间的一次性口令(otp)，并且otp插件437可认证系统420的处理。这样，依赖方410可代表用户装置从联合身份提供者服务器获得认证令牌，所述认证令牌使得用户装置能够访问第三方系统中的服务和资源。例如，作为由ad服务器441提供的ad认证过程的一部分，依赖方410可指导客户端装置405的用户利用其用户名和口令登录身份平台(诸如由认证系统420和/或客户ad服务器441提供的网页)，并且获得ad认证令牌。

使用这些插件可允许系统管理员根据需要配置认证流程。每个插件可负责处置不同的认证过程。如以上所例示，ad插件431可被配置来与客户ad服务器441对接。ad插件431可与客户ad服务器441协调以检索用户凭证(例如，用户名和口令)，对用户进行认证，并且检索ad认证令牌。ad插件431可将ad认证令牌转换成供在企业网络中并且通过认证系统420使用的标准格式。例如，认证系统420可利用公共数据格式来向依赖方提供身份/认证令牌，并且所述格式可不同于服务器441、443、445和/或447所采用的格式。可通过应用接口425将转换的标准格式令牌返回给依赖方410。依赖方410可能永远不可访问用户的用户名和口令，因为此步骤由认证系统420的对应插件安全地处置。

图5示出包括认证系统520的计算环境500，所述认证系统520可使用自联合523来支持复合或组合式认证流程。在图5的示例中，依赖方510可请求让客户端装置505访问由组合式活动目录(ad)和一次性口令(otp)认证过程保护的资源的授权。认证系统520可包括认证接口525(其可对应于认证接口425)、ad插件431和otp插件437。作为对图4系统的改进，认证系统520还可包括ad+otp插件535，其可被配置来使用回到认证接口525的自联合523来处置组合式ad+otp认证过程。

如以上关于图4所讨论，图5中的依赖方510可向认证接口525发送对认证的请求。认证接口525可检查对认证的请求，确定对应认证过程，并且将认证请求的处置传递给合适的插件软件模块。例如，依赖方510可向认证接口发送对认证的请求，所述对认证的请求指示依赖方510想要使用组合式ad和otp认证过程来认证客户端装置505。在所述示例中，由依赖方510发送到认证系统520的认证请求可包括指示所请求的认证类型是ad+otp的参数。认证接口525可确定认证请求指示组合式ad+otp过程，并且可调用ad+otp插件535来处置请求。作为响应，ad+otp插件535处理请求以便以认证系统的格式生成组合式ad+otp认证令牌，如以下进一步所描述。

ad+otp插件535可利用回到认证接口525的自联合523来处理组合式认证过程的ad认证组件和otp认证组件。ad+otp插件535可向认证接口525作出其自己的认证请求。即，ad+otp插件535自身可充当依赖方来作出次级请求。根据本文的方面，这种自联合可提供在支持多种类型的联合的授权系统中实现复合授权流程的有益且优质的解决方案。例如，这种自联合允许认证系统520重复使用现有代码路径，并且避免与复制用于处理相同认证过程的代码逻辑相关联的复杂性。应用接口525可通过调用适用于处置的插件(在本示例中将是ad插件431和otp插件437)来处理由ad+otp插件535(作为依赖方)作出的认证请求中的每一个。ad插件431和otp插件437分别与客户ad服务器441和otp服务器447对接，以接收用户凭证，对用户凭证进行认证，并且生成ad或otp认证令牌。这些单独的认证令牌可通过认证接口525返回给ad+otp插件535，所述ad+otp插件535可组合令牌并且通过认证接口525将组合式ad+otp认证令牌返回给原始依赖方510。

图6指示由认证系统520和计算环境500中的其他元件执行的处理流程。具体地，图6示出对应于依赖方510对使用复合ad和otp认证过程来认证客户端装置505的请求的处理流程。图6所示的步骤由依赖方510、认证接口525、ad+otp插件535、ad插件431、客户ad服务器441、otp插件437和otp服务器447执行。ad+otp插件535可利用回到认证接口525的自联合(参见步骤604-606和624-626)来执行复合ad和otp认证过程。

在步骤600处，依赖方510可向认证接口525发送对认证客户端装置505的请求。请求可指示应使用ad和otp认证过程来认证客户端装置505。步骤600可由请求访问企业系统的一个或多个服务或资源的客户端装置505的用户来提示。例如，用户可尝试登录虚拟桌面、web应用或移动应用以访问虚拟的基于云的企业系统，其中企业服务器可与企业身份提供者服务器(例如，认证系统520)所提供的特定企业身份服务集成。随后，企业服务器可作为依赖方510代表用户装置将此类请求转发到认证接口525以进行认证。请求可视情况指示关于用户和/或用户装置的信息。然而，依赖方510本身通常并不从用户或用户装置获取或请求用户凭证(例如，用户名和口令)。因为认证系统525及其插件(如ad插件431)安全地采集用户凭证，所以依赖方510不需要访问用户凭证。

在步骤602处，认证接口525可检查从依赖方510接收的对认证的请求，并且确定适用于处置与请求相关联的认证类型的插件。例如，认证接口525可基于认证请求中(显式地或隐式地)指示要访问的资源是使用ad+otp认证来保护的参数而确定ad+otp插件535对应于所请求的认证过程类型(例如，复合ad+otp认证)。如图所示，对认证用户装置的请求可通过由认证接口525对适用于处置的插件(例如，ad+otp插件535)的调用来转发到插件。

已经被调用来处置对认证用户装置的请求，ad+otp插件535可执行处置请求中所指示的复合认证过程的每个组件认证过程的逻辑。在所示示例中，ad+otp插件535可执行被配置来生成用于用户装置的ad认证请求的逻辑和被配置来生成用于用户装置的otp认证请求的逻辑。如本文进一步所讨论，ad+otp插件535可接收两个次级认证请求的结果，将所得认证令牌组合成组合式令牌，并且响应来自出自步骤602的认证接口525调用的调用。在一些实施方案中，所述系统可使用ad令牌和otp令牌来生成可由认证系统520在以后的请求中识别的单个令牌。组合式令牌在认证系统520之外可能没有含义，但是依赖方可在以后的请求中将组合式令牌呈现给认证系统520，并且认证系统520可使用先前检索的ad令牌和otp令牌来支持单点登录(sso)特征。在其他实施方案中，可将ad令牌和otp令牌组合成将所有或至少一部分信息存储在ad令牌和otp令牌中的单个数据结构。

因此，在步骤604处，ad+otp插件535可自联合回到认证接口525，并且在步骤606处，向认证接口525发送对使用ad认证过程来认证用户装置的请求。

应用接口525可从ad+otp插件535接收对使用ad认证过程来认证用户装置的请求，并且可将ad+otp插件535视为所述请求的依赖方。应用界面525可就像其他请求一样处置来自ad+otp插件535的请求。例如，应用接口525可确定来自ad+otp插件535的请求对应于ad认证过程，并且可确定ad插件431应处置所述请求。因此，在步骤608处，应用接口535可调用ad插件431来处置从作为依赖方的ad+otp插件535接收的ad认证请求。虽然图6指示顺序处置，但在一些实施方案中，可结合并行处置。同时处理两种认证过程可提高处置认证请求的速度。

在步骤610处，ad插件431可获得与正在认证的用户和/或用户装置相关联的用户凭证。ad插件431可通过生成让用户装置的用户输入凭证(诸如用户名和口令)的提示来获得用户凭证。在步骤612处，ad插件431可请求向客户ad服务器441认证用户装置。客户ad服务器441可以是联合身份提供者，并且可与企业托管认证系统520和/或第三方网络相关联。请求可以是获得第二认证令牌，即ad认证令牌(第一认证令牌是要创建的组合式ad+otp令牌)。请求可包括所采集的用户凭证。在步骤614处，客户ad服务器441可基于请求中的凭证来认证用户。如果用户成功地认证，则在步骤616处，客户ad服务器441可用ad认证令牌来响应ad插件431。例如，作为用户成功登录虚拟的基于云的企业系统的结果，客户ad服务器441可发布ad认证令牌。虽然步骤610示出ad插件431获取用户凭证，但在一些实现方式中，客户ad服务器441可操作以针对凭证提示用户。

在步骤618处，ad插件431可任选地将所接收的ad认证令牌转换成与认证系统520相关联的标准和/或专门格式。如以上所指出，认证系统520可以认证系统520所使用的通用格式(其与联合身份提供者所提供的格式不同)向依赖方提供认证令牌。这可允许在利用认证系统520的其他应用之间重复使用，并且可支持共同管理的系统通过认证系统520提供的不同应用之间的单点登录(sso)特征。在步骤620处，可将标准形式ad认证令牌(或原始ad认证令牌)返回给认证接口525。在步骤622处，认证接口525可将ad认证令牌返回给ad+otp插件535，从而完成ad+otp插件535(作为依赖方)对使用ad认证过程来认证用户装置的请求。

在步骤624处，ad+otp插件535可进一步自联合到认证接口525，以处置由依赖方510在步骤600中发起的复合ad+otp认证过程的其余otp部分。在步骤626处，ad+otp插件535可生成对使用otp认证过程来认证用户装置的请求并将其发送给认证接口525。同样，在此次级认证过程调用中，ad+otp插件535可充当依赖方。

类似于ad认证请求，应用接口525可从ad+otp插件535接收对使用otp认证过程来认证用户装置的请求，并且可将ad+otp插件535视为所述请求的依赖方。应用接口525可确定来自ad+otp插件535的请求对应于otp认证过程，并且可确定otp插件437应处置所述请求。如以上所解释，认证请求可包括(显式地和/或隐式地)指示将用于认证用户对资源的访问的认证过程类型的信息，诸如参数。认证系统520可选择对应于参数所指示的认证过程类型的插件。因此，在步骤628处，应用接口535可调用otp插件43来处置从作为依赖方的ad+otp插件535接收的otp认证请求。

在步骤630处，otp插件437可获得用户一次性口令(otp)凭证或访问多因素认证装置的证明。例如，otp插件437可致使向用户的移动装置的注册sms号码发送文本消息，或者可从用户的认证装置接收基于时间的一次性口令作为输入。在步骤632处，otp插件437可请求向otp服务器447认证用户装置。otp服务器447可以是联合身份提供者，并且可与企业托管认证系统520和/或第三方网络相关联。请求可以是获得第三认证令牌，即otp认证令牌。请求可包括所采集的用户凭证，例如，一次性口令。如果otp服务器447被配置来以另一方式确认多因素认证，例如让用户的认证装置直接向otp服务器447发送消息，则请求可能不需要凭证，但可包括标识请求和要认证的用户装置的信息。在步骤634处，otp服务器447可使用已知技术基于请求中的凭证和/或对应于请求的otp/多因素认证信息来认证用户。例如，otp服务器可向与用户相关联的移动电话发送sms消息，并且用户可将一次性代码输入由otp服务器447和/或认证系统520提供的页面中。如果用户成功地认证，则在步骤636处，otp服务器447可使用otp认证令牌来响应otp插件437。例如，作为用户使用otp认证成功登录到虚拟的基于云的企业系统的结果，otp服务器447可发布otp认证令牌。虽然步骤630示出otp插件437获取用户凭证，但在一些实现方式中，otp服务器447可操作以针对凭证提示用户。

在步骤638处，otp插件437可任选地将所接收的otp认证令牌转换成与认证系统520相关联的标准和/或专门格式。在步骤640处，可将标准形式otp认证令牌(或原始otp认证令牌)返回给认证接口525。在步骤642处，认证接口525可将otp认证令牌返回给ad+otp插件535，从而完成ad+otp插件535(作为依赖方)对使用otp认证过程来认证用户装置的请求。

在步骤644处，ad+otp插件535可将通过应用接口525从ad插件431和otp插件437接收的ad和otp认证令牌进行组合，以响应于来自步骤600的依赖方510对基于复合ad+otp认证过程来认证用户装置的原始请求而生成第一令牌。如以上所讨论，呈认证系统520所使用的特殊格式的组合式令牌可允许从始发应用和/或其他应用到所述系统的对通过认证系统520利用单点登录(sso)特征来访问网络资源的以后的请求。在步骤646处，ad+otp插件535可将组合式ad+otp认证令牌返回给认证接口525。在步骤648处，响应于来自步骤600的对使用复合ad+otp认证来认证用户装置的请求，认证接口525可将组合式ad+otp认证令牌返回给和/或通过依赖方510，从而完成对原始请求的响应。虽然组合式令牌被示出为被返回给认证接口525并通过认证接口525，但在一些实施方案中，ad+otp插件535可将组合式令牌直接返回给依赖方510。

这种方式的自联合可允许有益的代码路径重复使用，并且利用现有工作流来支持复合认证过程。这可避免复制代码路径，其中多个插件各自包括处理给定类型的认证过程的逻辑。通过重复使用现有的代码路径，自联合可简化自定义认证工作流的实现方式。通过允许自定义认证工作流结合第三方认证模块而无需访问基础代码，自联合还可支持与第三方认证代码和系统的集成。

ad+otp认证令牌(或其他认证令牌)可使得由依赖方510管理的用户装置(诸如客户端装置505)能够访问网络资源并且使用网络资源建立会话。例如，客户端装置505和/或认证系统520可将认证令牌提供给与网络资源相关联的会话管理器。会话管理器可依赖于认证令牌作为用户身份已通过对应认证过程进行认证的证明。会话管理器可基于确认认证令牌的有效性来与客户端装置505建立会话。通过会话，客户端装置505可访问网络资源和服务。在一些实施方案中，ad+otp认证令牌(或其他认证令牌)可进一步使得用户装置能够使用由企业身份服务器(例如，认证系统520)提供的企业身份服务来对一个或多个资源进行单点登录(sso)访问。例如，企业服务器(依赖方)可从企业身份提供者服务器接收认证令牌。作为一个示例，依赖方510可将ad+otp认证令牌(或由认证系统520获得并返回给依赖方510或从那些令牌派生的其他认证令牌)存储在企业系统的密钥存储库中。在一些情况下，认证令牌可特定于认证系统520并且可由认证系统520来解译，这可使得用户装置能够对企业网络内由企业系统提供的各种服务和资源进行sso访问。sso可以是对企业系统中多个相关但独立的服务和资源的访问控制的特性。例如，用户可利用单个id和口令登录以访问所连接的系统而无需使用不同的用户名或口令，或者在每个系统处无缝地登录。因此，单个认证可通过在与认证系统520集成的企业系统中无缝地传递认证令牌来提供对多个应用、服务和资源的访问。

在一些情况下，当用户装置尝试使用联合身份服务进行登录时，联合身份提供者服务器可以saml令牌、openid连接身份令牌、oauth访问令牌或其他形式的令牌的格式发布成功登入的证据。特别地，此类认证令牌可使得由企业服务器(例如，依赖方510)管理的用户装置(例如，客户端装置505)能够使用联合身份服务对第三方系统进行单点登录访问。在一些情况下，联合身份提供者所发布的成功登录的证据的类型可从认证或身份令牌变化到来自联合身份提供者服务器的专门声明或断言。

对于来自企业服务器的对访问第三方系统的后续请求，企业服务器(例如，依赖方510)可向企业身份提供者服务器呈现认证令牌。具体地，作为一个示例，先前在步骤648处由企业身份提供者服务器向企业服务器发布的ad+otp认证令牌稍后可用于支持对相同或其他网络服务的sso。作为另一示例，在用户装置先前已经通过ad认证过程进行认证的情况下，认证系统525、依赖方510和/或客户端装置505可已经具有ad认证令牌。在ad+otp认证过程期间，ad插件431可确定先前已经接收与ad认证过程相关联的用户凭证并且与ad认证过程相关联的单点登录(sso)令牌可供所述系统使用。在ad插件确定sso令牌可用的情况下，ad插件可返回sso令牌作为ad认证令牌。在一些情况下，针对所述用户或用户装置发布给企业身份提供者服务器的认证令牌可以是临时令牌。作为一个示例，认证令牌可持续一小时。在这些情境下，认证令牌可需要刷新。

图7示出根据一些方面的替代实施方案。计算环境700包括认证系统720，但ad+otp插件735实现复合认证过程而无需自联合到认证接口525。代替自联合回到认证接口525以处置复合认证过程的ad和otp子组件，ad+otp插件735可包括自行处置ad认证过程和otp认证过程的逻辑。

在图7的示例中，依赖方710可请求对访问由组合式活动目录(ad)和一次性口令(otp)认证过程保护的资源的授权。认证系统720可包括ad+otp插件735，其可被配置来处置组合式ad+otp认证过程而无需使用回到认证接口525的自联合(如直接接口723所示)。

依赖方710可向认证接口525发送对认证的请求。ad+otp插件735可处置指示依赖方710想要使用组合式ad和otp认证过程来认证客户端装置705的对认证的请求。ad+otp插件735可处理请求以便以认证系统的格式生成组合式ad+otp认证令牌。在此实施方案中，ad+otp插件735可利用直接接口723(例如，ad+otp插件733自己调用ad服务器441和otp服务器447的api，而不是通过自联合到ad插件431或otp插件437来与客户ad服务器441和otp服务器447协调)，而不是通过应用接口525并使用ad插件421和otp插件437进行自联合。ad+otp插件735可执行与由ad插件421和otp插件437执行的步骤(参见图6)相似的步骤来获得ad认证令牌和otp认证令牌。ad+otp插件735可将ad认证令牌和otp认证令牌进行组合，并通过认证接口525将其返回给依赖方710。

如以上所讨论，自联合可在降低认证系统520的复杂性方面提供众多益处。但是，图7中没有自联合的替代实施例也可提供益处，诸如允许消除跨负责单独认证过程的两个不同插件的冗余步骤。因此，在一些实施方案中，认证系统720可配置有支持复合工作流的插件，并且用于每个工作流的对应插件可视情况利用自联合。对于一些复合工作流，自联合可提供上述益处。对于其他复合工作流，特别是由具有冗余步骤的认证过程组成的那些工作流，可在没有自联合的情况下实现对应插件。因此，设想到混合系统，其中一些复合工作流通过自联合来处置，并且其他复合工作流通过不进行自联合的直接接口逻辑处置。

图8示出可将一种类型的认证流程转变成另一类型的过程。特别地，本文讨论的关于认证系统的方面可使得所述系统能够将由依赖方发起的授权代码流程转变成适用于向联合身份提供者认证的资源所有者流程。联合身份提供者服务器可被配置为在资源所有者流程中起作用，所述资源所有者流程可包括：接收用户凭证、将其提供给服务器、以及接收回认证令牌。一些依赖方也可支持资源所有者流程，诸如在依赖方是可安全地接收用户凭证的应用或服务的情况下。资源所有者流程可与oauth认证框架相关联，并且可包括在所述框架下授予的资源所有者口令凭证。但其他依赖方可能无法支持资源所有者流程，诸如在依赖方是无法安全地接收用户凭证的应用或服务(例如，不可信应用)的情况下。这些无法支持资源所有者流程的其他依赖方可替代地实现授权代码流程，以利用其他系统(诸如本文讨论的认证系统)来代表他们实现资源所有者流程并获得认证令牌。授权代码流程可与开放id连接(oidc)认证层相关联，所述oidc认证层可位于oauth2.0认证框架顶部。在授权代码流程中，依赖方可指示它想要向身份提供者进行认证。身份提供者在授权代码流程中采集凭证，认证用户，并且将授权令牌和/或代码返回给依赖方。依赖方能够使用此代码来获得对受保护资源的访问，尽管无权访问用户凭证。

在一些认证系统中，依赖方可实现oidc授权代码流程，而不是oauth资源所有者流程。这可归因于系统的设计考虑，例如，在所述系统中，受管应用并不意图安全地处置客户端凭证。但一些身份提供者可能需要oauth资源所有者流程。根据本文所述的一些方面，可提供插件以在认证系统中将授权代码流程转换成资源所有者流程。

图8示出计算环境800，其中认证系统820操作以向客户ad服务器441认证用户装置。图8描绘两个依赖方：可不支持资源所有者流程的依赖方810(例如，其未被配置来安全地接收用户凭证)，以及可支持资源所有者流程的依赖方815(例如，其可安全地接收用户凭证)。

支持资源所有者流程851的依赖方815可通过认证接口825向认证系统820发送对认证用户装置的请求。依赖方815可采集凭证并将其包括在请求中。认证接口825可将从依赖方815接收的资源所有者流程请求路由到对应插件，诸如adro流插件831。adro流插件831可以是被配置来处理对ad认证的资源所有者流程请求并与客户ad服务器441对接的插件软件模块。adro流插件831可向客户ad服务器441提供凭证并且接收回ad令牌，如关于图4和ad插件431所描述。adro流插件731可将ad令牌转换成标准格式，并且可将转换的令牌(或原始ad令牌)返回给依赖方815。

认证系统820可进一步操作以将授权代码流程转变为资源所有者流程，以在身份提供者支持oauth资源所有者流程的情况下联合需要oidc授权代码流程的依赖方。例如，不支持资源所有者流程的依赖方810可通过认证接口825发起使用认证系统820来认证用户装置的oidc授权代码流程853。认证接口825可确定adac流插件835对应于来自依赖方810的请求，并且可将来自依赖方810的请求传递给adac流插件835。adac流插件835支持资源所有者流程，并且可发起对应于从依赖方810接收的授权代码流程中的所请求认证过程的资源所有者流程855a或855b。作为ro流程的一部分，adac流插件835可获得与用户相关联的凭证854，例如通过致使生成让用户提供用户名和口令的提示。然后，adac流插件835可通过适用于由客户ad服务器441认证的资源所有者流程来请求对用户装置进行认证。acac流插件835可通过上述自联合技术和/或通过与adro流插件831的直接通信来实现这种资源所有者流程，如图8中所示。例如，资源所有者流程855a可通过认证接口825使用自联合来实现，而资源所有者流程855b可通过adac流插件835与adro流插件831之间的直接通信(例如，api调用)来实现。adro流插件831可如上所述前进，并且可获得用户装置的ad令牌。此令牌可返回给adac流插件835，后者可将令牌(或转换的令牌)返回给依赖方810。因此，即使依赖方810不支持资源所有者流程，认证系统820也能够将由依赖方810发起的资源所有者流程转换成资源所有者流程并实施认证过程。

作为一个示例，依赖方815可以是支持资源所有者流程的web应用。当依赖方815需要认证用户装置时，依赖方815可将用户重定向到请求用户名、口令和多因素认证令牌(例如)的身份提供者网站。但依赖方810可以是不访问用户凭证(诸如用户名和口令)的工作区应用。工作区应用可向认证系统820发起授权代码流程，并且认证系统820(通过adac流插件835)可提示用户输入凭证。因此，adac流插件835可实现授权代码流程与资源所有者流程之间的协议变换。这可通过借由认证接口825自联合到adro流插件831来完成。

本公开的一个或多个方面可在由一个或多个计算机或其他装置执行以进行本文所述的操作的计算机可用数据或计算机可执行指令中(诸如一个或多个程序模块中)体现。通常，程序模块包括在由计算机或其他数据处理装置中的一个或多个处理器执行时进行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。计算机可执行指令可作为计算机可读指令存储在计算机可读介质(诸如硬盘、光盘、可移动存储介质、固态存储器、ram等)上。在各种实施方案中，可根据需要组合或分布程序模块的功能。此外，功能可全部或部分地体现在固件或硬件等效物(诸如集成电路、专用集成电路(asic)、现场可编程门阵列(fpga)等)中。特定数据结构可用于更有效地实现本公开的一个或多个方面，并且此类数据结构预期在本文所述的计算机可执行指令和计算机可用数据的范围内。

本文所述的各种方面可体现为方法、设备，或者体现为存储计算机可执行指令的一个或多个计算机可读介质。因此，那些方面可采取完全硬件实施方案、完全软件实施方案、完全固件实施方案或以任何组合方式组合软件、硬件和固件方面的实施方案的形式。此外，如本文所述的表示数据或事件的各种信号可以行进穿过信号传导介质(诸如金属线、光纤或无线传输介质(例如，空气或空间))的光波或电磁波的形式在源与目的地之间传输。通常，一种或多种计算机可读介质可以是和/或包括一种或多种非暂时性计算机可读介质。

如本文所述，各种方法和动作可跨一个或多个计算服务器和一个或多个网络操作。功能可以任何方式分布，或者可位于单个计算装置(例如，服务器、客户端计算机等)中。例如，在替代实施方案中，以上讨论的计算平台中的一个或多个可在由一个或多个物理计算装置提供的一个或多个虚拟机中实现。在此类布置中，每个计算平台的各种功能可由一个或多个虚拟机执行，并且以上讨论的计算平台之间的任何和/或所有通信可对应于由一个或多个虚拟机访问、移动、修改、更新和/或以其他方式使用数据。

本公开的方面已经就其说明性实施方案加以描述。本领域普通技术人员回顾本公开将想到在所附权利要求的范围和精神内的众多其他实施方案、修改和变型。例如，说明性附图中描绘的步骤中的一个或多个可以不同于所列举的次序来执行，并且根据本公开的方面，一个或多个所描绘步骤可以是任选的。

虽然已经用特定于结构特征和/或方法动作的语言描述了主题，但应理解，在所附权利要求中限定的主题不必限于以上描述的特定特征或动作。相反，以上所述的特定特征和动作被描述为以下权利要求的示例性实现方式。