管理用于需要用户批准设备管理操作的细粒度策略的方法和系统

摘要

公开了一种用于管理客户端((116)、(118)、(120))上的操作的方法。该方法涉及接收来自第一应用服务提供商(ASP)(104)的用于在客户端((116)、(118)、(120))上执行第一操作的第一请求，并且确定第一被请求的操作需要用户批准并且未被预先批准。基于确定第一被请求的操作需要用户批准并且未被预先批准，生成包括用户批准方法的经扩展的授权令牌，其中用户批准方法在执行第一被请求的操作之前提示客户端((116)、(118)、(120))寻求用户批准，向客户端((116)、(118)、(120))发送经扩展的授权令牌，接收对用户批准方法的用户响应，并且当接收到的用户响应指示对于第一被请求的操作的批准时，在客户端上执行第一被请求的操作。

说明书

背景技术

当服务器对远程设备进行操作时，服务器可以被授权通过授权令牌在远程设备上执行一个或多个操作。授权令牌由服务器生成并且被发送到远程设备，并且还可以用于认证经由服务器请求在远程设备上执行操作的服务提供商。

发明内容

一般来说，在一方面，本文公开的实施例涉及一种用于管理客户端上的操作的方法，包括：接收来自第一应用服务提供商(ASP)的用于在客户端上执行第一操作的第一请求；确定第一被请求的操作需要用户批准并且未被预先批准；基于确定第一被请求的操作需要用户批准并且未被预先批准，生成包括用户批准方法的经扩展的授权令牌，其中用户批准方法在被请求的操作执行之前提示客户端寻求用户批准；向客户端发送经扩展的授权令牌；接收对用户批准方法的用户响应；以及当接收到的用户响应指示对于第一被请求的操作的批准时，在客户端上执行第一被请求的操作。

一般来说，在一方面，本文公开的实施例涉及一种用于管理客户端上的操作的方法，包括：由客户端接收包括用户批准方法的经扩展的授权令牌；在客户端上显示用户批准方法，从而在所请求的操作在客户端上执行之前提示使用客户端的用户接受或拒绝对在该客户端上执行操作的请求；以及对用户批准方法做出响应，其中，当用户接受执行操作的请求时，该操作在客户端上执行。

一般来说，在一方面中，本文公开的实施例涉及一种服务器，该服务器包括：可信授权机构，该可信授权机构被配置为接收来自应用服务提供商(ASP)的在客户端上执行操作的请求，确定所请求的操作是否被预先批准；以及约束生成引擎，该约束生成引擎被配置为当所请求的操作需要用户批准并且未被预先批准时生成包括用户批准方法的用户约束，其中该用户批准方法需要客户端的用户在客户端上执行所请求的操作之前批准或拒绝所请求的操作；可信授权机构还被配置为生成包括用户批准方法的经扩展的授权令牌、向客户端发送经扩展的授权令牌、接收对用户批准方法的用户响应，并且当接收到的用户响应指示对于所请求的操作的批准时在客户端上执行所请求的操作，其中用户批准方法在所请求的操作执行之前提示客户端寻求用户批准。

其它方面将从以下描述和所附权利要求中变得清楚。

附图说明

图1示出了根据本文公开的一个或多个实施例的示意图。

图2A和2B示出了根据本文公开的一个或多个实施例的授权令牌。

图3示出了根据本文公开的一个或多个实施例的流程图。

图4示出了根据本文公开的一个或多个实施例的计算机系统。

具体实施方式

现在将参考附图详细描述具体实施例。为了一致性，各个图中的相同元件由相同的标号指代。

在以下对实施例的详细描述中，阐述了许多具体细节，以便提供更透彻的理解。然而，对本领域普通技术人员将清楚的是，本文公开的实施例可以在没有这些具体细节的情况下实践。在其它情况下，未详细描述众所周知的特征以避免不必要地使描述复杂化。

一般来说，本文公开的一个或多个实施例提供用于通过利用在客户端设备上执行操作之前必须满足的具体条件(约束)对授权令牌进行扩展而从后端服务器管理不同细粒度策略的方法和系统。更具体而言，实施例涉及利用用户批准约束来对授权令牌进行扩展，从而在客户端设备上执行操作之前请求验证授权令牌的设备上实体(on-device entity)提示用户要求批准。

图1示出了根据一个或多个实施例的客户端/服务器拓扑的示意图。具体而言，图1示出了包括后端服务器(例如，激活管理器102)和多个客户端设备(116、118、120)的系统(100)，其中激活管理器(102)基于来自应用服务提供商(104)的输入与多个客户端设备(116、118、120)通信。下面描述系统(100)中的上面提到的组件中的每一个。

每个客户端(116、118、120)可以是便携式电子设备，诸如智能手机、平板设备、游戏设备或具有互联网能力的任何其它合适的电子设备。本说明书自始至终，术语“客户端”和“客户端设备”可以互换使用。在一个或多个实施例中，每个客户端(116、118、120)可以是可信执行环境(Trusted Execution Environment，TEE)客户端。更具体而言，TEE软件可以由客户端设备制造商安装，使得对于需要使用敏感数据的某些应用，TEE软件在客户端(116、118、120)上自动执行。使用敏感数据的安全应用的内容提供商必须遵守TEE平台和结构要求。

在一个或多个实施例中，TEE是客户端设备(例如，智能电话、平板设备或任何其它合适的电子设备)中的安全区域并且确保敏感数据在可信环境中被存储、处理和保护。更具体而言，客户端设备操作系统(OS)可以被划分为丰富执行环境(Rich ExecutionEnvironment，REE)和TEE。TEE是隔离的执行环境，具有自己的一组硬件组件和软件组件，TEE与REE并行运行但与REE分离，从而为丰富OS(Rich OS)环境提供安全性服务。REE是由丰富OS提供和管控的环境，它在TEE之外。丰富OS是更加健壮(robust)的OS，它是以功能和性能而非安全性作为关键目标开发的，并且因此以更低的安全性边界运行。从TEE的角度来看，REE和在REE上运行的应用被认为是不可信的。相反，TEE执行可信OS，该可信OS被设计为使用基于安全性的设计技术启用TEE。

在一个或多个实施例中，TEE是典型芯片组体系架构中的片上系统(SoC)的一部分，并且可以由SoC内的单独的片上安全性子系统构成，或者可以作为SoC组件(即，RAM、ROM、加密加速器、(一个或多个)处理核、外围设备等)中每一个的一部分操作。TEE的主要目的是通过超出REE控制的硬件机制来保护TEE的资产(assets)免受REE影响。例如，TEE提供数据和密钥的可信存储，其中数据的存储被绑定到设备，使得未授权的内部或外部攻击者不能访问、复制或修改包含在TEE中的数据。

就软件体系架构而言，TEE暴露多组应用编程接口(API)，以使得能够从REE和其它设备进行通信以在TEE中实现可信应用软件功能。更具体而言，可信OS是向在可信OS的顶部上运行的可信应用提供内部API的托管代码，以及启用来自其他执行环境的客户端设备API软件接口的专有方法。TEE体系架构启用安全性级别，其中该安全性级别足够用于应用服务提供商(104)可能希望在其上执行操作的相当数量的应用。在一个或多个实施例中，TEE被配置为在客户端设备上执行受安全性保护的敏感操作(诸如例如银行操作、支付操作等)。TEE体系架构在2011年12月的标题为“GlobalPlatform Device Technology TEE SystemArchitecture(全局平台设备技术TEE系统体系架构)”1.0版的文档中定义。在丰富操作环境中运行的应用与驻留在可信执行环境(TEE)中的应用之间的通信在2010年7月的标题为“GlobalPlatform Device Technology TEE Client API Specification(全局平台设备技术TEE客户端API规范)”1.0版的文档中定义。TEE系统体系架构和TEE客户端API规范通过引用整体并入。本发明不限于TEE体系架构的特定版本或客户端API规范的特定版本。

返回到图1的描述，每个客户端(116、128、120)可以由用户(未示出)操作。用户可以是使用客户端设备的任何人或实体。客户端(116、118、120)可以由用户拥有，或者在用户的一个或多个实施例中，客户端(116、118、120)可以由例如公司、大学、政府机构或允许用户使用客户端的其它实体拥有。在一个或多个实施例中，用户被配置为接收在客户端(116、128、120)上执行操作的请求，其中这种需求需要用户批准。用户还被配置为在可以在客户端设备(116、128、120)上执行操作之前对这些要求批准的请求做出响应。

在一个或多个实施例中，激活管理器(102)是被配置为通过生成和发送授权令牌来管理用于对远程客户端设备的管理的不同细粒度策略的服务器。更具体而言，激活管理器(102)被配置为利用在客户端(116、118、120)上执行由应用服务提供商(ASP)(104)请求的操作之前必须满足的具体条件/约束来对授权令牌进行扩展。术语“激活管理器”和“服务器”在本文中可以互换使用。在一个或多个实施例中，激活管理器(102)包括可信授权机构(106)、约束生成引擎(110)和客户端到应用映射(112)。可信授权机构(106)是被配置为在客户端(116、128、120)上执行远程操作(诸如安装/部署应用、在客户端上升级软件、卸载应用等)的服务器侧授权机构。可信授权机构(106)经由互联网(122)、任何其它合适的网络或者使用一个或多个设备上的组件之间的任何其它形式的通信与每个客户端(116、128、120)通信。根据一个或多个实施例，授权令牌生成引擎(108)是可信授权机构内能够生成授权令牌的逻辑。如由授权令牌生成引擎(108)生成的授权令牌的结构在下面图2A-图2B中描述。

激活管理器(102)的约束生成引擎(110)被配置为收集用于生成授权令牌的具体使用条件的信息。具体而言，在一个或多个实施例中，约束生成引擎(110)可以收集关于以下的信息：客户端设备所处的环境、客户端设备的所有者、在客户端设备上执行某个操作的请求的源、部署在客户端设备上或要部署在客户端设备上的特定应用的提供者、针对操作的应用对平台或平台的安全性是否是必要的、自从上次用户批准以来的持续时间、用户所批准的请求的数量、可以被分组在一起从而需要单个用户批准的若干操作的脚本(scripting)，或任何其它合适的约束信息或其组合。

约束生成引擎(110)可以从ASP(104)或从与客户端(116、118、120)的环境(例如，物理位置)相关联的策略获得上面提到的类型的信息。例如，在一个或多个实施例中，当客户端(116、118、120)是位于现场的公司设备时，可以通过与该公司相关联的固有(ingrained)策略来获得约束信息。公司策略可以指示例如出于安全原因而强制执行(mandate)哪些操作。在另一个示例中，当客户端(116、118、120)是自带设备(bring-your-own-device,BYOD)场景中用户的个人电子设备时，与可以在该客户端(116、118、120)设备上执行的操作相关联的策略可以不同于当客户端(116、118、120)由公司拥有时的策略。使用上面提到的策略和信息类型，约束生成引擎(110)生成包括在由授权令牌生成引擎(108)生成的授权令牌中的使用条件。

客户端到应用映射(112)被配置为存储将每个客户端(116、118、120)映射到部署在客户端上的应用的数据结构(诸如表、列表等)。更具体而言，在一个或多个实施例中，客户端到应用映射(112)还被配置为存储关于所请求的操作是否已经被预先批准的指示，使得可信授权机构(106)可以确定何时不必为特定操作获得用户批准。例如，每次当使用客户端的用户批准或拒绝执行与客户端(116、118、120)上的特定应用相关联的操作的请求时，用户的响应可以被存储在客户端到应用映射(112)中。在一个或多个实施例中，其它间接用户动作也可以存储在客户端到应用映射(112)中，这些间接用户动作稍后可以被可信授权机构(106)用来确定操作是否被预先批准。这样的间接动作可以包括例如接受用于特定类别的应用的使用条款或许可协议，以及由拥有客户端设备的公司和/或客户端设备被带入其中的环境所批准的管理操作。客户端到应用映射(112)还可以存储安装在客户端设备上的应用的列表、特定类型的操作已经被用户批准的次数，以及自用户上次批准或拒绝特定类型的操作以来的持续时间。

在一个或多个实施例中，ASP(104)被配置为通过激活管理器(102)请求在客户端设备上执行操作。ASP(104)可以是负责管理客户端设备上的应用的任何应用内容提供商。在一个或多个实施例中，ASP(104)可以是针对安全应用的内容提供商，诸如例如银行服务提供商、支付系统服务提供商等。当客户端设备不是操作该客户端设备的用户的个人设备时，ASP(104)也可以是拥有该客户端设备的公司或实体。在一个或多个实施例中，ASP(104)与激活管理器(102)的可信授权机构(106)具有可信关系。即，ASP(104)向激活管理器(102)预先认证，由此允许激活管理器(102)相信由ASP(104)提供的内容是安全内容。在一个或多个实施例中，ASP(104)可以请求在客户端上执行任何类型的设备管理操作。例如，ASP(104)可以请求在客户端设备的TEE环境中安装/部署应用。可替代地，ASP(104)可以请求执行对基本应用的安全性补丁更新、从客户端设备卸载应用，或者与在客户端设备上执行的应用相关联的任何其它合适的管理操作。

本发明不限于图1中所示的系统。

图2A和图2B示出了根据本文描述的实施例的授权令牌。具体而言，图2A示出了根据实施例的具有附加用户约束(210)的授权令牌(200)。授权令牌(200)是在尾部处利用加密签名签署的数据结构，该加密签名允许客户端设备在处理授权令牌之前验证执行远程操作的服务器的身份以及操作消息的完整性这二者。授权令牌(200)存储版本号(202)和通用唯一标识符(UUID)(204)，其中通用唯一标识符(UUID)(204)唯一地识别拥有能够验证授权令牌(200)的密钥的安全域(SD)。在一个或多个实施例中，当客户端是TEE客户端(即，已经安装并执行TEE的客户端设备)时，UUID(204)可以识别TEE内具有解密经加密签署的授权令牌并验证授权令牌签名(212)的密钥的SD子实体。本领域技术人员将认识到，在TEE中可以存在若干SD。

在一个或多个实施例中，授权令牌(200)还与各种使用条件相关联(206)。使用条件(206)可以指定一个或多个约束，其中这一个或多个约束限制授权令牌(200)的适用性并且为了执行所请求的操作必须满足这一个或多个约束。例如，设备ID约束(208)指定向其发送授权令牌的特定客户端设备。另一个约束可以是指定要在客户端设备上执行什么类型的操作的操作约束(未示出)。在一个或多个实施例中，用户约束(210)被附加到授权令牌，以定义ASP所请求的操作在客户端设备上执行之前是否需要用户批准方法。即，在授权令牌中包括用户约束(210)使得激活管理器能够在操作可以在客户端设备上执行之前向客户端设备上的接收软件发信号通知需要用户批准方法。通过将用户约束(210)和授权令牌(200)组合成一个传输，实施例提供了可以针对ASP所需的每个操作而定做(tailored)的动态用户约束(210)。

如上面所提到的，授权令牌(200)还可以与用来保护授权令牌的数字签名(212)形式的加密密钥相关联。可以使用仅被授权进行签名的人知道的私钥来生成数字签名。授权令牌(200)可以允许能够实现安全数字签名的私钥的安全的板上生成和存储，在这种情况下，授权令牌(200)可以用于用户认证，因为私钥也充当签名者的身份的证据。数字签名(212)在接收端上由在客户端设备上执行的软件来验证。用户约束(210)指定用户批准方法作为授权令牌(200)的一部分。

图2B示出了根据实施例的用户约束(210)的构造。用户约束(210)可以包括标签(220)、长度(222)、用户批准方法(224)和可选的消息(226)。具体而言，标签(220)是从可以包括在授权令牌的使用条件内的其它约束中唯一地识别用户约束的常数值。当存在标签(220)时，在继续在客户端设备上的操作之前，利用用户批准方法(224)来提示客户端的用户以批准或拒绝所请求的操作。长度(222)字段指定用户约束(210)的长度，其中用户约束(210)包括可以可选地被包括作为用户约束(210)的一部分的任何消息(226)。在一个或多个实施例中，用户批准方法(224)识别呈现给用户以接受或拒绝所请求的操作的机制。例如，用户批准方法(224)可以是向用户显示的具有“是”和“否”或“接受”和“拒绝”按钮的消息、需要用户输入个人标识码(PIN)代码或密码以接受用于执行操作的请求的认证机制、生物识别数据提示(例如，以获得用户的指纹或视网膜扫描)，或者可以用来捕获用户关于执行操作的请求的反馈的任何其它合适的批准方法。在一个或多个实施例中，附加在授权令牌中的所选择的批准方法可以由请求在客户端上执行操作的ASP指定。可替代地，服务器可以基于所存储的针对具体类型的操作的策略来确定为特定操作选择的批准方法的类型。

在一个或多个实施例中，用户约束(210)的消息(226)部分是具有额外信息的可选的可定制消息，其中该额外信息可以被显示/呈现给用户以帮助用户做出是接受还是拒绝所请求的操作的决定。例如，如果ASP请求从客户端卸载应用，则ASP可以向服务器指定显示指示为什么指定的应用被卸载的消息。在一个或多个实施例中，可定制消息(226)可以指定用于操作的(一个或多个)目标应用和/或请求执行操作的ASP的名称。作为另一个示例，可以用标准消息“正在您的设备上安装应用X”提示用户。也可以向用户显示解释在安装应用之前用户必须同意的许可协议的条款和条件的额外消息。在一个或多个实施例中，包括在附加的用户消息中的信息是为了帮助用户确定经由用户批准方法是接受还是拒绝所请求的操作。

本发明不限于图2A-图2B中所示的认证令牌结构。

图3示出了根据一个或多个实施例的流程图。更具体而言，图3描述了由服务器(或激活管理器)执行以实现实施例的过程。虽然顺序地呈现和描述了这些流程图中的各个步骤，但是普通技术人员将认识到，这些步骤中的一些或全部可以以不同的次序执行、可以组合或省略，并且这些步骤中的一些或全部可以并行地执行。此外，这些步骤可以主动地或被动地执行。作为示例，根据一个或多个实施例，可以通过检查所存储的数据以测试该数据是否与被测试的条件一致来执行确定步骤。

当后端服务器在客户端设备上执行远程操作时，服务器提供具有加密签名的授权令牌，其中该加密签名允许设备在处理授权令牌之前验证请求操作的服务器的身份和操作消息的完整性这二者。在这个过程中，可能存在需要终端用户批准的情况。例如，在安装应用之前，可能需要用户批准以便确保用户接受该特定应用的安装，以防止执行由恶意应用触发的不期望的操作。还可能存在不需要终端用户批准的其它情况。例如，当后端服务器正在推送内容以升级公司所拥有的设备的软件时，或者当操作对于设备或设备的安全性是必要的并且不能被终端用户拒绝时。图3中描述的过程涉及在需要这种用户批准时对授权令牌进行扩展以包括用户批准方法。

在步骤302中，由服务器从ASP接收请求。具体而言，ASP请求经由服务器在客户端设备上执行操作。操作可以包括但不限于在客户端设备上部署/安装应用、升级安装在客户端设备上的软件、更新应用、从客户端设备卸载应用、将数据推送到客户端设备上，或者可以由ASP在客户端设备上执行的任何其它合适的操作。作为具体示例，拥有客户端设备的公司可能希望安装防止用户从指定的网站下载内容到客户端设备上的软件。在这种情况下，拥有客户端设备的公司是ASP，并且要执行的操作是用于安全性目的的软件的安装。

当服务器(例如，图1中的102)接收到执行操作的请求时，服务器首先确定该操作是否被预先批准(步骤304)。可以以两种方式之一进行这种确定。在一个或多个实施例中，ASP可以在用于执行操作的请求中指示该操作不需要用户批准。例如，当操作是必须执行的安全性操作时，可以根据ASP的请求绕过用户批准。在另一个实施例中，服务器(更具体而言，服务器的约束生成引擎)可以检查存储在服务器上的客户端-应用映射，以确定操作是否已经被批准。在一个或多个实施例中，当操作被预先批准时，在客户端上执行操作而不需要用户批准(步骤306)。更具体而言，对于预先批准的操作，使用默认批准策略，该默认批准策略在操作被执行之前可以提示用户要求批准或者可以不提示用户要求批准，这取决于客户端的平台级配置。在一个或多个实施例中，预先批准的操作可以包括例如在已经由用户批准的许可证的上下文中在客户端上部署(一个或多个)应用。更具体而言，如果用户先前已经接受特定的协议条款或许可协议，则这个信息被存储在服务器上的客户端-应用映射中。约束生成引擎可以发现ASP所请求的操作落入这种先前接受的许可协议中，并且因此将所请求的操作标记为被预先批准的。其它类型的被预先批准的操作可以包括部署安全性补丁或出于安全性原因在客户端上执行任何操作。

当操作未被预先批准时，服务器检查存储在服务器上的客户端到应用映射，以确定是否存储了将允许服务器绕过用户批准的任何其它信息(步骤308)。例如，如果用户先前已经在某个时间段内批准操作(例如，如果上一次请求用户批准相同操作或相同类型的操作是在不到30天前)，则可以绕过用户批准。这种基于诸如自上次用户批准以来的持续时间的参数的策略也可以存储在客户端到应用映射中或存储在服务器中的其它地方。服务器可以考虑的其它参数包括例如客户端设备的所有者、客户端设备的位置等。例如，如果客户端设备连接到公司内联网和/或客户端设备的所有者是公司，则操作可以被认为不需要任何用户批准。当客户端到应用映射基于由服务器收集和存储的一个或多个参数指示用户不需要批准操作时，过程前进到步骤306，并且在客户端上执行操作而无需任何用户批准方法。即，由服务器生成授权令牌，该授权令牌具有加密签名以向客户端验证服务器的身份，其中该授权令牌覆盖指示需要客户端批准的任何默认策略。

如果没有用户批准可以或应当被绕过的指示，则在客户端设备上执行操作之前需要用户批准(步骤308)。在这个阶段，就是否应当将给用户的具体定制消息包括在用户批准约束中做出第二确定(步骤310)。在一个或多个实施例中，定制消息可以提供正被执行的操作的细节，以帮助用户就是批准还是拒绝所请求的操作做出确定。可替代地，定制消息可以包括例如请求执行操作的ASP的名称，使得用户知道哪个实体正在客户端设备上执行操作。在一个或多个实施例中，给用户的消息的细节可以由ASP提供。在一个或多个实施例中，策略可以指示服务器何时应当向用户提供某些信息(例如，请求要在客户端上执行的操作的实体的名称)。例如，如果用户正在使用公司客户端设备，则公司可以请求在设备上执行特定操作。在这种情况下，可以将公司的名称作为伴随(accompany)要求批准的请求的定制消息的一部分提供给用户。本领域的普通技术人员将认识到，定制的用户消息可以包括适于帮助用户接受或拒绝所需操作的任何信息。

当不需要具体消息伴随用户批准方法时，这指示服务器仅向授权令牌附加用户约束以用于提示用户批准或者拒绝在客户端设备上执行操作的请求(步骤314)。更具体而言，服务器的授权令牌生成引擎生成具有附加的用户批准方法的授权令牌。用户批准方法可以是例如“接受”/“拒绝”按钮、提示用户输入个人标识码代码或密码、提示用户要求生物识别数据(例如，指纹)，或者需要使用客户端设备的用户的动作以接受或者拒绝在客户端上执行操作的请求的任何其它合适的用户批准方法。当ASP或服务器确定消息应当伴随用户批准方法时，服务器生成具有附加的用户批准方法和给用户的定制消息的授权令牌(步骤312)。本领域技术人员将认识到，定制消息可以在显示批准方法之前和/或与用户批准方法同时出现在客户端设备上。在这个上下文中，“同时”可以对应于其中定制消息在时间段TP1期间显示并且执行用户批准方法的结果(例如，显示“接受”/“拒绝”按钮、提示用户输入个人标识码代码或密码、提示用户要求生物识别数据等)在时间段TP2期间显示的场景，其中在TP1和TP2之间存在至少一些重叠。

一旦由服务器生成授权令牌(具有或不具有给用户的定制消息)，包括附加的用户约束(作为使用条件的一部分)的授权令牌就被发送到客户端设备(步骤316)。在一个或多个实施例中，当客户端是TEE客户端时，具有附加的用户约束的授权令牌由安装在客户端设备上的TEE软件接收。TEE软件包括解密授权令牌的经加密的签名并验证令牌的真实性(authenticity)的能力。例如，一个或多个解密密钥可以存储在客户端设备的TEE中。当客户端不是TEE客户端时，客户端设备操作系统可以被配置为解密授权令牌的经加密的签名。在任一种情况下，客户端设备的用户都经由在客户端设备上执行的用户接口接收用户批准方法以及消息(如果与授权令牌一起生成了消息的话)，并且通过读取消息并接受或拒绝在客户端上执行操作的请求来相应地做出响应。当用户批准执行操作的请求时(步骤318)，在设备上执行操作(步骤320)。用户响应由服务器接收并且由服务器记录在客户端到应用映射中，使得所收集的数据可以用于将来关于对来自ASP的特定请求是否需要用户批准的确定。

以下示例示出了根据一个或多个实施例生成和发送经扩展的授权令牌的过程。本领域技术人员将认识到，本发明不限于下面描述的示例。

考虑用户将他/她自己的设备带到用户工作的企业或公司的工作场所的场景。客户端设备可以安装用于工作目的的应用，即，其中这些应用的服务提供商是企业本身。在一个或多个实施例中，企业可以具有例如关于为了安全性目的而更新安装在设备上的某些应用的具体策略，以及关于当设备连接到企业的内联网时可以安装什么类型的应用的策略。在这个场景中，假定企业希望执行对在客户端设备上执行的应用的更新，出于安全性原因该更新是强制执行的。在这种情况下，操作可以是被预先批准的操作，这是因为该操作是由企业请求的，并且客户端设备连接到企业的内联网。授权令牌由后端服务器生成，被发送到客户端设备，并且操作被执行而无需任何用户约束。

在不同的场景中，假定对应用的更新不是出于安全性原因而强制执行的，但是企业保持(remain)请求操作的ASP。在这种情况下，可以提示用户批准或不批准所请求的操作。即，在被发送到客户端设备之前，生成经扩展的授权令牌，该经扩展的授权令牌具有附加的用户批准方法。为了帮助用户就接受还是拒绝所请求的操作做出决定，可以向用户显示将操作的请求者识别为该企业的具体用户消息。更具体而言，经扩展的授权令牌包括在执行远程操作之前向用户显示的具体用户消息。在这种情况下，用户可以看到他/她的雇主希望在客户端设备上执行远程操作，并倾向于接受所请求的操作。

在一个或多个实施例中，当上述示例中描述的客户端设备是启用TEE的设备时，当用户批准约束是授权令牌的一部分时，与来自TEE的终端用户的交互通过可信用户接口(UI)执行。可信UI防止REE中的任何恶意应用干扰用户批准或伪装为用户批准UI。可信UI以与在客户端未启用TEE时用户所看到的UI在视觉上不同的方式呈现可信UI自身。

作为另一个示例，在一个或多个实施例中，可能存在用户未注意他/她的客户端设备的情境。在这种情况下，客户端设备可以接收执行具有一个或多个用户批准约束的管理操作的请求，但是用户未注意该设备。在一个或多个实施例中，用户批准机制可以设置有超时，使得当用户在有限的时间段内没有回应用户批准提示时，操作会超时。在这种情况下，可以将适当的错误消息返回给后端服务器，使得服务器可以区分拒绝操作的用户和未注意客户端设备的用户。如果操作由于用户没有响应用户批准方法而超时，则服务器可以稍后重试该操作。可替代地，当用户使用用户批准方法拒绝操作时，可以在存储在服务器上的映射中记载这个信息，并且该操作可以被永久地取消。

本文公开的一个或多个实施例可以在几乎任何类型的计算系统上实现而与所使用的平台无关。具体而言，图1中所描述的激活管理器/服务器(102)和每个客户端可以在任何类型的计算系统上实现。例如，计算系统可以是一个或多个移动设备(例如，膝上型计算机、智能电话、个人数字助理、平板计算机，或其它移动设备)、台式计算机、服务器、服务器机箱中的刀片(blade)，或者包括至少最小处理能力、存储器以及(一个或多个)输入设备和输出设备以执行一个或多个实施例的任何其它类型的一个或多个计算设备。例如，如图4中所示，计算系统(400)可以包括(一个或多个)计算机处理器(402)、相关联的存储器(404)(例如，随机存取存储器(RAM)、高速缓存存储器、闪存存储器，等等)、(一个或多个)存储设备(406)(例如，硬盘、诸如光盘(CD)驱动器或数字多功能盘(DVD)驱动器的光盘驱动器、闪存记忆棒，等等)，以及大量其它元件和功能。(一个或多个)计算机处理器(402)可以是用于处理指令的集成电路。例如，(一个或多个)计算机处理器可以是处理器的一个或多个核或微核。计算系统(400)还可以包括(一个或多个)输入设备(410)，诸如触摸屏、键盘、鼠标、麦克风、触摸板、电子笔，或任何其它类型的输入设备。另外，计算系统(400)可以包括(一个或多个)输出设备(408)，诸如屏幕(例如，液晶显示器(LCD)、等离子体显示器、触摸屏、阴极射线管(CRT)监视器、投影仪，或其它显示设备)、打印机、外部储存器，或任何其它输出设备。这些(一个或多个)输出设备中的一个或多个可以与输入设备相同或不同。计算系统(400)可以经由网络接口连接(未示出)连接到网络(412)(例如，局域网(LAN)、诸如互联网的广域网(WAN)、移动网络，或任何其它类型的网络)。(一个或多个)输入设备和输出设备可以本地或远程(例如，经由网络(412))连接到(一个或多个)计算机处理器(402)、存储器(404)和(一个或多个)存储设备(406)。存在许多不同类型的计算系统，并且以上提到的(一个或多个)输入设备和输出设备可以采取其它形式。

执行实施例的计算机可读程序代码形式的软件指令可以全部或部分地、暂时或永久地存储在非临时性计算机可读介质上，非临时性计算机可读介质诸如CD、DVD、存储设备、软盘、带、闪存存储器、物理存储器，或任何其它计算机可读存储介质。具体而言，软件指令可以对应于计算机可读程序代码，其中该计算机可读程序代码在由(一个或多个)处理器执行时被配置为执行实施例。

另外，以上提到的计算系统(400)的一个或多个元件可以位于远程位置处并且经网络(414)连接到其它元件。另外，实施例可以在具有多个节点的分布式系统上实现，其中每个部分可以位于分布式系统内的不同节点上。在一个实施例中，节点对应于不同的计算设备。可替代地，节点可以对应于具有相关联的物理存储器的计算机处理器。节点可以替代地对应于具有共享存储器和/或资源的计算机处理器或计算机处理器的微核。

本文公开的一个或多个实施例可以使得能够基于例如客户端设备的环境实现不同的用户批准策略。例如，自带设备环境策略可以与公司所拥有的设备策略和个人使用设备策略不同。此外，策略可以取决于ASP。例如，免费的、广告赞助的应用和付费应用可以不服从相同的用户批准策略。此外，客户端或其安全性必需的应用可能需要绕过用户批准策略。通过用指定用户批准方法和可选的定制消息的额外约束来对授权令牌进行扩展，本文公开的实施例提供了经由用户批准策略管理客户端设备上的远程操作的健壮的动态的方法。

虽然本发明已经关于有限数量的实施例进行了描述，但是受益于本公开的本领域技术人员将认识到，可以设计出不背离如本文公开的实施例的范围的其它实施例。相应地，本文公开的实施例的范围应当仅由所附权利要求来限定。