Patent ID: 12218952

DETAILED DESCRIPTION

Disclosed are various approaches for enabling an enrolled client device of a user to access content and applications (that are being managed by a management service of an enterprise) via a second enrolled client device of the user. In cases, where the user has multiple client or user devices enrolled with the management service and used for accessing enterprise resources, there might be situations where some of the enrolled devices are offline either due to circumstances beyond the user's control or due intentional actions of the user, such that the offline device is unable to communicate with the management service to show compliance with enterprise policies. In such cases, users are currently prevented by the management service from accessing content or applications due to the offline status of the enrolled device. To solve this dilemma and in accordance with embodiments of the present disclosure, a peer-to-peer (P2P) offline access mode provides a communication channel for the offline enrolled device to communicate information, via an online enrolled device of the user, showing that the offline device is compliant with enterprise policies and can be trusted to access online content. For example, the health of the offline device can be verified using a secure P2P channel with the second enrolled client device, thus allowing the offline client device to show compliance with enterprise polices and be enabled to access enterprise resources, such as data content and/or applications, even when the device is offline. Accordingly, the P2P channel enables the management service to verify that the offline enrolled device is compliant and to also verify that the online enrolled device (second enrolled client device) is compliant to which the offline device is communicating over the P2P channel, where the online enrolled device can communicate to the management service via a communication network, such as the Internet.

In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same. Although the following discussion provides illustrative examples of the operation of various components of the present disclosure, the use of the following illustrative examples does not exclude other implementations that are consistent with the principals disclosed by the following illustrative examples.

With reference toFIG.1, shown is a network environment100according to various embodiments. The network environment100can include a computing environment103, one or more client devices106, and a network service109, which can be in data communication with each other via a network111. The network111can include wide area networks (WANs), local area networks (LANs), personal area networks (PANs), or a combination thereof. These networks can include wired or wireless components or a combination thereof. Wired networks can include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and integrated services digital network (ISDN) networks. Wireless networks can include cellular networks, satellite networks, Institute of Electrical and Electronic Engineers (IEEE) 802.11 wireless networks (e.g., WI-FI®), BLUETOOTH® networks, microwave transmission networks, as well as other networks relying on radio broadcasts. The network111can also include a combination of two or more networks111. Examples of networks111can include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks. A peer-to-peer communication channel can include direct client device106to client device106communications over a network111. The network111can include permanent and ad-hoc networks, networks generated by the client devices106themselves, and device-to-device communications over networks provided or facilitated using routers and other devices.

The computing environment103can include one or more computing devices that include a processor, a memory, and/or a network interface. For example, the computing devices can be configured to perform computations on behalf of other computing devices or applications. As another example, such computing devices can host and/or provide content to other computing devices in response to requests for content.

Moreover, the computing environment103can employ a plurality of computing devices that can be arranged in one or more server banks or computer banks or other arrangements. Such computing devices can be located in a single installation or can be distributed among many different geographical locations. For example, the computing environment103can include a plurality of computing devices that together can include a hosted computing resource, a grid computing resource or any other distributed computing arrangement. In some cases, the computing environment103can correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time.

Various applications or other functionality can be executed in the computing environment103according to various examples. The components executed in the computing environment103, for example, can include an identity manager114, one or more connectors116, an authentication service118, and a management service120. Correspondingly, computing devices hosting the respective services can be referred to as servers. For example, one or more computing devices hosting the management service120can be referred to as management server(s).

The identity manager114can authenticate users and manage user authorizations or permissions to access applications, data, or other computing resources. For example, the identity manager114can correspond to a single sign-on portal that verifies a user's authentication data133, which can include authentication credentials, an authentication token (e.g., single sign-on token) that identifies the user, and verifies whether the user has the appropriate access and permissions to access enterprise data and functionalities of the computing environment103and/or one or more network services109according to compliance policies126. The network services109which can include services that can provide user access to enterprise data. Examples of identity managers114include VMWARE's Identity Manager, Workspace ONE®, or MICROSOFT's Active Directory Federation Services.

A connector116can provide a standardized mechanism for the assistant connection service to communicate with a network service109. Each network service109may provide an application programming interface (API) for communicating, querying, or otherwise interacting with the network service109, which can include different methods or functions with different parameters compared to other network services109. This can allow for the assistant connection service to send a single, uniformly formatted query to one or more connectors116. Each connector116is then responsible for using the information provided in the query from the assistant connection service to invoke the appropriate functions provided by the API of the network service109. To add support for a new network service109, a new connector116can be created without needing to modify the assistant connection service itself. Likewise, if a change is made to the API of the network service109, the connector116between the assistant connection service and the federated service can be updated without having to modify the assistant connection service itself.

The authentication service118can retrieve and cache authentication data, such as authentication tokens and refresh tokens, provided by various network services109accessible over a network111. The cached authentication data can be used by an assistant connection service to query the network services109for information.

Various applications or other functionality can be executed in the computing environment103. Moreover, one or more of these applications could be executed on the same computing device within the computing environment103or on one or more separate computing devices within the computing environment103.

Also, various data is stored in a data store119that is accessible to the computing environment103. The data store119can be representative of a plurality of data stores119, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. Moreover, combinations of these databases, data storage applications, and/or data structures may be used together to provide a single, logical, data store. The data stored in the data store119is associated with the operation of the various applications or functional entities described below. This data can include one or more user accounts138, one or more device records123, one or more compliance policies126, one or more authentication data133, as well as potentially other data.

A device record123can be used to store any information related to a client device106enrolled with or managed by the management service120. This can include any information about the current or last known state of the client device106, such as applications installed on the client device or the last reported state of the client device106. This can also include information about the user who is currently using the client device106. Accordingly, the device record123can include information such as a device identifier128, and one or more configuration states136.

The device identifier128can include any identifier that uniquely identifies one client device106with respect to another client device106. Examples of device identifiers128include device names, globally unique identifiers (GUIDs), universally unique identifiers (UUIDs), network interface media access controller (MAC) addresses, international mobile equipment identity (IMEI) numbers, etc. Device identifier128can also include a public key such as a public key peer-to-peer verification certificate, a private key for one or more client devices106, and other information.

A configuration state136can represent any current or past configuration of the client device106. The configuration state136can include values to be used for operating system settings for the client device106or for settings for individual applications installed on the client device106. Text or markup language files (e.g., extensible markup language (XML) or yet another markup language (YAML) files) could be used to store a configuration state136.

A compliance policy126can represent one or more policies (of an enterprise) that must be satisfied by client device106when applied to the client device106. Compliance policies126can specify a range of configuration settings or options that the current configuration state136of the client device106must satisfy in order to be considered compliant. For example, a compliance policy126could specify that certain applications are required to be installed on the client device106or are prohibited from being installed on the client device106. As another example, a compliance policy126could specify a minimum version of an application installed on the client device106or minimum operating system version for the client device106. Similarly, a compliance policy126could specify prohibited versions of applications, such as versions that contain a known or unpatched security vulnerability. A compliance policy126could also specify permitted or prohibited network connections, domain name system (DNS) servers, virtual private network (VPN) configurations or settings, etc. A compliance policy could also specify that an enrolled client device106should be online in order to verify its compliance with enterprise policies and/or access enterprise resources, such as data content/files or applications. As another example, the one or more compliance rules representing the policy116can include general conditions with which the client device106must comply to be secure for enterprise use. The one or more compliance rules can specify, for instance, that certain applications executed by the client device106have not been offline from the management service120for greater than a specified amount of time. Although these examples are illustrative of the types of compliance policies126that could be deployed, other mandatory configuration settings could be specified by one or more compliance policies126.

The user account138represents information associated with a user. The information can include authentication data133. The authentication data133can include one or more authentication credentials, one or more single sign-on tokens, and/or one or more access permissions applied to the user account138, as well as cached authentication tokens and refresh tokens. The user account138can be associated with a compliance policy126, as well as one or more client devices106. In some examples, a compliance policy126can be applied to all client devices106associated with a particular user account138or a particular user group150. One or more compliance policies158can be applied to a single client device106. In some examples, a specific compliance policy126can be created for a particular client device106as well.

Authentication credentials represent the credentials that a user can present to the identity manager114to authenticate the user's identity. Authentication credentials can include a combination of a username and password, a cryptographic certificate, a one-time password, or a combination of several of the authentication credentials as part of a multi-factor authentication schema. Examples of one-time passwords can include a one-time password generated using a version of the time-based one-time password (TOTP) algorithm or a one-time password generated using the HMAC-based one-time password (HOTP) algorithm.

The access permissions represent computing resources that the user account is authorized to access. For example, the access permissions can indicate that a user account is permitted to access some network services109but is prohibited from accessing other network services109. As another example, the access permissions can indicate that the user account138can access certain features of a network service109but prohibited from accessing other features. For example, if one of the network services109that a user was permitted to access was a customer relationship management (CRM) service, the user might have permission to access his or her own contacts but be prohibited from accessing the sales contacts of other users. In some implementations, the access permissions can be defined at a user group level rather than at a user level in a directory service.

An authentication token is a token provided by the identity manager114or the network service109in response to a successful authentication of the user. The authentication token represents that a user account138is currently authenticated to access a network service109and authorized to access or otherwise interact with the network service109in some capacity. For security purposes, the authentication token often has a time-limit associated with it, (such as 5 minutes, 1 hour, 3 hours, 6 hours, 8 hours, or some other period of time). Once the time-limit has expired, the authentication token can no longer be used to prove current authentication status of the user account138with the network service109. The authentication token can be provided, for example, as part of an authentication exchange using a version of the OAUTH protocol. In some instances, such as those implementing a version of the KERBEROS protocol, a separate authentication token can be generated for each network service109that the client device106attempts to access on behalf of the user. In other instances, the authentication token can be generated and used to provide the client device106with access to several of the network services109. Although each of the network services109can have a different set of authentication credentials linked to the user account138, such as a different username and password combination, the authentication token allows the user to authenticate once with the identity manager114in order to use each of the network services109instead of having to authenticate with each of the network services109separately.

A refresh token is a token provided by one of the network services109in response to a successful authentication with the network service109. The refresh token can be used to acquire a new authentication token once a current or previous authentication token expires. The refresh token often has a much longer time-limit associated with it, such as 1 day, 1 week, 30 days, 3 months, or 1 year, which allows for the refresh token to be used to acquire a series of authentication tokens after an initial successful authentication. In the event that a user's access is revoked, the refresh token can be marked invalid, preventing the refresh token from being used to acquire new authentication tokens. The refresh token can be provided, for example, as part of an authentication exchange using a version of the OAUTH protocol.

The management service120can be executed to manage the configuration of registered or enrolled client devices106. This can include evaluating individual compliance policies126to determine an appropriate configuration state136for a client device106and distributing the configuration state136to client devices106. The management service120can also provide various facilities or mechanisms to determine or otherwise ensure that enrolled client devices106are compliant with the applicable compliance policies126.

The client device106is representative of a plurality of client devices that can be coupled to the network111. The client device106can include a processor-based system such as a computer system. Such a computer system can be embodied in the form of a personal computer (e.g., a desktop computer, a laptop computer, or similar device), a mobile computing device (e.g., personal digital assistants, cellular telephones, smartphones, web pads, tablet computer systems, music players, portable game consoles, electronic book readers, and similar devices), or other devices with like capability. The client device106can include one or more displays, such as liquid crystal displays (LCDs), gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (“E-ink”) displays, projectors, or other types of display devices. In some instances, the display can be a component of the client device106or can be connected to the client device106through a wired or wireless connection.

The client device106can be configured to execute various applications such as a management agent139and one or more client applications146. The management agent139can be configured to locally manage the client device106in order to enforce configuration settings specified by the management service120in the configuration state136. The management agent139can be installed with elevated privileges or be effectuated through operating system APIs to manage the client device106on behalf of the management service120. The management agent139can have the authority to manage data on the client device106, install, remove, or disable certain applications, or install configuration profiles, such as VPN certificates, Wi-Fi profiles, email profiles, etc. The management agent139can also have the authority to enable or disable certain hardware features of the client device106that as specified in the configuration state136for the client device106. The management agent139can also place the device into different hardware modes, such as airplane mode, silent mode, do-not-disturb mode, P2P mode, P2P offline access mode, or other modes supported by the client device106.

The network service109to which a client application146corresponds can require some form of user authentication before providing the client application146with user-specific data or information. For example, the network service109might be a salesforce tool that contains highly sensitive user and enterprise data. Accordingly, a client application146can include a management application that is communicatively linked to, and works in concert with, the management service120. The client application146can also authenticate a user's access to the network service109. In this way, once a user has associated the network service109and other services with his or her user account138by authenticating with the identity manager114, the identity manager114can also allow the user to access network services109that have federated their authentication to the identity manager114.

Next, a general description of the operation of the various components of the network environment100is provided. Although the following description provides an example of the operation of the network environment100, other interactions between the various components of the network environment100are also included within the scope of the various embodiments of the present disclosure. More detailed descriptions of the operations of specific components of the network environment100are provided in the discussion accompanyingFIGS.2-4.

To begin, the management service120can enroll one or more client devices106of a user for mobile device management or unified endpoint management (UEM) services. Accordingly, the management service120can identify and authenticate one of the client devices106and store data related to the client device106in a device record123for later reference. In some cases, the management service120can also be registered as a device administrator of the client device106, permitting the management service120to configure and manage certain operating aspects of the client device106.

The management service120can also determine which compliance policies126are applicable to the enrolled or registered client device106and create an appropriate configuration state136for the client device106. For example, the management service120could evaluate any groups or roles that the client device106has been assigned to, and then select any compliance policies126assigned to those groups or roles. Moreover, the management service120could evaluate any compliance policies126that were assigned to the client device106specifically. As a result of the evaluation, the management service120could generate a configuration state136for the client device106and save the configuration state136to the appropriate device record123.

The management service120can then distributed the configuration state136to the client device106. Meanwhile, the management agent139executing on the client device106can periodically evaluate the current state of the client device106to determine if is compliant with one or more compliance policies126or if its configuration state136is the current configuration state136published by the management service120. The management agent139could then apply the current configuration state136to the client device106.

Referring next toFIG.2, shown is a scenario that illustrates how interactions between the components of the networked environment100ofFIG.1can operate. Generally, this example shows how a plurality of client devices106A,106B of a user (the client devices106) can interact using peer-to-peer communications to enable an offline client device106B to access enterprise data content113(e.g., data or files stored in data store119), a network service109, or a specific client application146.

InFIG.2, client devices106A and106B can be in a same peer-to-peer zone or area. The peer-to-peer zone can refer to a zone or area associated with a network111accessible by multiple client devices106A and106B. This can include an area where a WiFi, Bluetooth, or another network is accessible by the client devices106A and106B. The network services109can be generated by one or more of the client devices106, by a gateway or router device, or by another device.

Accordingly, consider a scenario in which two client devices of the user, devices106A and106B, are enrolled with a management service120, in which client device106A is online and in communications with the management service120and client device106B is offline and not communicatively coupled with the management service120.

In step203, the client device106B intends to access enterprise data content113which has been secured with a read-only-when-online-mode level of protection, which requires that a requesting client device be communicatively coupled with the management service120and verify its compliance with enterprise policies126before access is granted to view or open the enterprise data content113. In the situation that the client device106B is not in compliance, the management agent139of the client device106B can be configured to install or uninstall client applications146specified by the configuration state136that should or should not be installed on the client device. Similarly, the management agent139could update application or operating system settings specified in the configuration state136to new values specified in configuration state136.

However, after the client device106B is verified to be in compliance and since the client device106B is detected to be offline (and not communicatively coupled with the management service), the management agent139of the client device106B initiates a P2P offline access mode, which can result in a peer-to-peer (P2P) channel208being launched with an available online client device106A, in step206.

In various embodiments, management agent139of client device106B can detect a presence of the client device106A. For example, the client device106A can execute the management agent139(for client device106A), and the client device106B can execute the management agent139(for client device106B). The management agents139, or other management instructions executed by the client devices106, can provide a peer-to-peer discovery API that pings for nearby client devices106using any one or more of the respective network devices156of the client devices106. Specifically, the client device106B can invoke the peer-to-peer discovery API, and the client device106A can respond and establish a direct peer-to-peer communication channel with the offline client device106B.

This device discovery ping can include a command, signal, or other predetermined discovery message that is unique to the management service120and/or a particular enterprise. The device discovery message is recognizable by the peer-to-peer discovery API or another management agent component. The peer-to-peer discovery API or another management agent component can respond using a predetermined response message that is unique to the management service120and/or a particular enterprise.

In step209, offline client device106B transmits or sends a request to online client device106A over the P2P channel to forward its P2P offline access mode request to open the enterprise data content113, where the request includes payload data comprising enterprise data content identification, heartbeat, and/or interrogation information (e.g., public key certificate and/or device identifier) showing the client device106B to be in compliance with enterprise compliance policies126. In various embodiments, the request is encrypted via a device certificate of the client device106B. Accordingly, the management agent139can include a private key (B) that was generated and provided by the management service120, for example, upon enrollment. The private key (B) can be specific to the client device106B. The management agent139can sign and/or symmetrically encrypt the verification data166using the private key (B). The offline client device106B can then transmit the signed or encrypted request data to the online client device106A over the P2P channel, where the data can be decrypted using a public key (B) of the client device106B, in various embodiments.

As such, the request can include verification data166such as a public key peer-to-peer verification certificate (the public key certificate (B)) that can identify the client device106B as owner of the public key and/or associated private key assigned to the client device106B during enrollment of the client device106B with the management service120. The public key certificate (B) can also identify the entity that issued the certificate such as a certificate authority, the management service120, or the client device106B. The public key certificate (B) can also specify a period of time that the public key certificate (B) is valid.

The verification data166can also include heartbeat data. The heartbeat data can include basic information about the client device106B, such as a device identifier, operating system, hardware information, device model or type, and so on. The verification data166can also include a unique time-based session token (B) generated by the management agent139at request generation time of the offline P2P offline access mode request. The verification data166can be specific to the client device106B.

In some cases, multiple client devices can be detected, and the management agent139can select the client device106A that shares a user group150or a compliance policy126with the client device106B and/or is identified as being associated with the same user in a device association(s) record152. In some examples, the management agent139can transmit a list of detected client devices to the management service120, and the management service120can select the client device106A for the P2P offline access mode request. The management service120can select the client device106A that shares a user group150or a compliance policy126with the client device106B and/or is identified as being associated with the same user in a device association(s) record152.

The online client device106A receives the P2P offline access mode request from offline client device106B (over the P2P channel). As discussed, the client device106A can decrypt the payload using the public key (B) and can then re-encrypt the payload using its private key (A) and forward the request to the management service120, such as by transmission over the Internet, in step211.

The management service120can decrypt the encrypted payload data of the request, which is encrypted using the private key (A) specific to client device106A. The management service120can have access to a symmetrical or asymmetrical key for decryption of data encrypted using the private key (A). For example, management service120can have access to the public key (A), since it was provided as part of an enrollment process with the management service120. If signed, the management service120can use an associated public key (A) to confirm the signature created using the private key (A).

In step213, the management service120processes the P2P offline access mode request and verifies if offline client device106B is compliant with enterprise policies126and/or if the requested enterprise data content is enabled for P2P offline access mode. The management service120can confirm an enrollment status of the client device106B. For example, the management service120can confirm that the public key certificate (B) and/or device identifier (B) matches data stored in association with the client device106B and a user account138. The management service120can confirm that the session token (B) matches an expected format, is generated using an expected token generation algorithm, and that the session token (B) is unexpired or is received within a predetermined time frame from a timestamp of the session token (B).

If the offline client device106B and the enterprise data content are compliant with enterprise policies, the management service120generates a special access token having a specified expiration period and transmits the special access token to online client device106A (over a client/server network, including the Internet) as an encrypted payload using public keys of the online client device106A.

Accordingly, the management service120can encrypt the special access token payload data using a public key (A) that was generated and provided by the management service120, for example, upon enrollment of client device106A. The public key (A) can be specific to the client device106A. The management service can sign and/or symmetrically encrypt the payload data using the public key (A). In step215, the management service120can then transmit the signed or encrypted special access token payload to the online client device106A (over a client/server network, including the Internet), where the client device106A can decrypt the payload using a private key (A) associated with the public key (A) in an asymmetric encryption scheme. Subsequently, client device106A can re-encrypt the payload using its private key (A) and forward the special access token payload to the client device106B over the P2P channel, in step217.

Client device106B decrypts the payload and the management agent139of client device106B uses the special access token and loads the expiration time/period into the management agent application and allows the client device106B to access the enterprise data content113. In various embodiments, whenever the content113is accessed, the special access token is used to communicate to the management service120via any nearby enrolled online device present in the P2P channel and once validated by the management service, the user is provided access, in step220. If the time period for the special access token expires, access to the content113will be restricted and a new peer-to-peer offline access mode request process will need to be repeated. Accordingly, in various embodiments, access to the enterprise data content may be facilitated by peer-to-peer communications using the P2P channel and an available peer device, such as client device106A of the same user, if the offline client device106B cannot access the enterprise data content on their own.

Next, consider a scenario in which two client devices of the user, devices106A and106C, are enrolled with a management service120, in which client device106A is online and in communications with the management service120and client device106C is offline and not communicatively coupled with the management service120. InFIG.3, the client devices106A and106C can be in a same peer-to-peer zone or area. The peer-to-peer zone can refer to a zone or area associated with a network111accessible by multiple client devices106A and106C. This can include an area where a WiFi, Bluetooth, or another network is accessible by the client devices106A and106C. The network services109can be generated by one or more of the client devices106, by a gateway or router device, or by another device.

In step303, the client device106C is offline and intends to access a local client application146of the client device106C which has been secured with a access-only-when-online-mode level of protection, which requires that a requesting client device be communicatively coupled with the management service120and verify its compliance with enterprise policies126before access is granted to view or open the client application146. In the situation that the client device106B is not in compliance, the management agent139of the client device106B can be configured to install or uninstall client applications146specified by the configuration state136that should or should not be installed on the client device. Similarly, the management agent139could update application or operating system settings specified in the configuration state136to new values specified in configuration state136. However, after the client device106B is verified to be in compliance and since the client device106B is detected to be offline (and not communicatively coupled with the management service), the management agent139of the client device106C initiates a P2P offline access mode, which can result in a peer-to-peer (P2P) channel308being launched with an available online client device106A, in step306.

In various embodiments, management agent139of client device106C can detect a presence of the client device106A. For example, the client device106A can execute the management agent139(for client device106A), and the client device106C can execute the management agent139(for client device106C). The management agents139, or other management instructions executed by the client devices106, can provide a peer-to-peer discovery API that pings for nearby client devices106using any one or more of the respective network devices156of the client devices106. Specifically, the client device106C can invoke the peer-to-peer discovery API, and the client device106A can respond and establish a direct peer-to-peer communication channel with the offline client device106C.

This device discovery ping can include a command, signal, or other predetermined discovery message that is unique to the management service120and/or a particular enterprise. The device discovery message is recognizable by the peer-to-peer discovery API or another management agent component. The peer-to-peer discovery API or another management agent component can respond using a predetermined response message that is unique to the management service120and/or a particular enterprise.

In step309, offline client device106C transmits or sends a request to online client device106A over the P2P channel to forward its P2P offline access mode request to open the local client application146, where the request includes payload data comprising client application identification, heartbeat, and/or interrogation information (e.g., public key certificate and/or device identifier) showing the client device106C to be in compliance with enterprise compliance policies126. In various embodiments, the request is encrypted via a device certificate of the client device106C. Accordingly, the management agent139can include a private key (C) that was generated and provided by the management service120, for example, upon enrollment. The private key (C) can be specific to the client device106C. The management agent139can sign and/or symmetrically encrypt the verification data166using the private key (C). The offline client device106C can then transmit the signed or encrypted request data to the online client device106A over the P2P channel, where the data can be decrypted using a public key (C) of the client device106C, in various embodiments.

As such, the request can include verification data166such as a public key peer-to-peer verification certificate (the public key certificate (C)) that can identify the client device106C as owner of the public key and/or associated private key assigned to the client device106C during enrollment of the client device106C with the management service120. The public key certificate (C) can also identify the entity that issued the certificate such as a certificate authority, the management service120, or the client device106C. The public key certificate (C) can also specify a period of time that the public key certificate (C) is valid.

The verification data166can also include heartbeat data. The heartbeat data can include basic information about the client device106C, such as a device identifier, operating system, hardware information, device model or type, and so on. The verification data166can also include a unique time-based session token (C) generated by the management agent139at request generation time of the offline P2P offline access mode request. The verification data166can be specific to the client device106C.

In some cases, multiple client devices can be detected, and the management agent139can select the client device106A that shares a user group150or a compliance policy126with the client device106C and/or is identified as being associated with the same user in a device association(s) record152. In some examples, the management agent139can transmit a list of detected client devices to the management service120, and the management service120can select the client device106A for the P2P offline access mode request. The management service120can select the client device106A that shares a user group150or a compliance policy126with the client device106C and/or is identified as being associated with the same user in a device association(s) record152.

The online client device106A receives the P2P offline access mode request from offline client device106C (over the P2P channel). As discussed, the client device106A can decrypt the payload using the public key (C) and can then re-encrypt the payload using its private key (A) and forward the request to the management service120, such as by transmission over the Internet, in step311.

The management service120can decrypt the encrypted payload data of the request, which is encrypted using the private key (A) specific to client device106A. The management service120can have access to a symmetrical or asymmetrical key for decryption of data encrypted using the private key (A). For example, management service120can have access to the public key (A), since it was provided as part of an enrollment process with the management service120. If signed, the management service120can use an associated public key (A) to confirm the signature created using the private key (A).

In step313, the management service120processes the P2P offline access mode request and verifies if offline client device106C is compliant with enterprise policies126and/or if the requested client application is enabled for P2P offline access mode. The management service120can confirm an enrollment status of the client device106C. For example, the management service120can confirm that the public key certificate (C) and/or device identifier (C) matches data stored in association with the client device106C and a user account138. The management service120can confirm that the session token (C) matches an expected format, is generated using an expected token generation algorithm, and that the session token (C) is unexpired or is received within a predetermined time frame from a timestamp of the session token (C).

If the offline client device106C and the local client application146are compliant with enterprise policies, the management service120generates a special access token having a specified expiration period and transmits the special access token to online client device106A (over a client/server network, including the Internet) as an encrypted payload using public keys of the online client device106A.

Accordingly, the management service120can encrypt the special access token payload data using a public key (A) that was generated and provided by the management service120, for example, upon enrollment of client device106A. The public key (A) can be specific to the client device106A. The management service can sign and/or symmetrically encrypt the payload data using the public key (A). In step315, the management service120can then transmit the signed or encrypted special access token payload to the online client device106A (over a client/server network, including the Internet), where the client device106A can decrypt the payload using a private key (A) associated with the public key (A) in an asymmetric encryption scheme. Subsequently, client device106A can re-encrypt the payload using its private key (A) and forward the special access token payload to the client device106C over the P2P channel, in step317.

Client device106C decrypts the payload and the management agent139of client device106C uses the special access token and loads the expiration time/period into the management agent application and allows the client device106C to access the local client application146. In various embodiments, whenever the application146is accessed, the special access token is used to communicate to the management service120via any nearby enrolled online device present in the P2P channel and once validated by the management service, the user is provided access to the local client application146by the local management agent139, in step320. If the time period for the special access token expires, access to the local client application146will be restricted and a new peer-to-peer offline access mode request process will need to be repeated.

Correspondingly, access to a remote client application may also be facilitated by peer-to-peer communications using the P2P channel and an available peer device, such as client device106A of the same user, if the remote client application utilizes network communications that are not available by a requesting client device106C and likewise are not currently available to a corresponding client application on the client device106C. Accordingly, consider a scenario in which two client devices of the user, devices106A and106C, are enrolled with a management service120, in which client device106A is online and in communications with the management service120and client device106C is offline and not communicatively coupled with the management service120. InFIG.4, the client devices106A and106C can be in a same peer-to-peer zone or area. The peer-to-peer zone can refer to a zone or area associated with a network111accessible by multiple client devices106A and106C. This can include an area where a WiFi, Bluetooth, or another network is accessible by the client devices106A and106C. The network services109can be generated by one or more of the client devices106, by a gateway or router device, or by another device.

In step403, the client device106C is offline and intends to access a client application146of another client device106A which has been secured with a access-only-when-online-mode level of protection, which requires that a requesting client device be communicatively coupled with the management service120and verify its compliance with enterprise policies126before access is granted to view or open the client application146. In the situation that the client device106B is not in compliance, the management agent139of the client device106B can be configured to install or uninstall client applications146specified by the configuration state136that should or should not be installed on the client device. Similarly, the management agent139could update application or operating system settings specified in the configuration state136to new values specified in configuration state136. However, after the client device106B is verified to be in compliance and since the client device106B is detected to be offline (and not communicatively coupled with the management service), the management agent139of the client device106C initiates a P2P offline access mode, which can result in a peer-to-peer (P2P) channel being launched308with an available online client device106A, in step406.

In various embodiments, management agent139of client device106C can detect a presence of the client device106A. For example, the client device106A can execute the management agent139(for client device106A), and the client device106C can execute the management agent139(for client device106C). The management agents139, or other management instructions executed by the client devices106, can provide a peer-to-peer discovery API that pings for nearby client devices106using any one or more of the respective network devices156of the client devices106. Specifically, the client device106C can invoke the peer-to-peer discovery API, and the client device106A can respond and establish a direct peer-to-peer communication channel with the offline client device106C.

This device discovery ping can include a command, signal, or other predetermined discovery message that is unique to the management service120and/or a particular enterprise. The device discovery message is recognizable by the peer-to-peer discovery API or another management agent component. The peer-to-peer discovery API or another management agent component can respond using a predetermined response message that is unique to the management service120and/or a particular enterprise.

In step409, offline client device106C sends a request to online client device106A over the P2P channel to forward its P2P offline access mode request to open a remote client application146on the client device106A, where the request includes payload data comprising client application identification, heartbeat, and/or interrogation information (e.g., public key certificate and/or device identifier) showing the client device106C to be in compliance with enterprise compliance policies126. In various embodiments, the request is encrypted via a device certificate of the client device106C. Accordingly, the management agent139can include a private key (C) that was generated and provided by the management service120, for example, upon enrollment. The private key (C) can be specific to the client device106C. The management agent139can sign and/or symmetrically encrypt the verification data166using the private key (C). The offline client device106C can then transmit the signed or encrypted request data to the online client device106A over the P2P channel, where the data can be decrypted using a public key (C) of the client device106C, in various embodiments.

As such, the request can include verification data166such as a public key peer-to-peer verification certificate (the public key certificate (C)) that can identify the client device106C as owner of the public key and/or associated private key assigned to the client device106C during enrollment of the client device106C with the management service120. The public key certificate (C) can also identify the entity that issued the certificate such as a certificate authority, the management service120, or the client device106C. The public key certificate (C) can also specify a period of time that the public key certificate (C) is valid.

The verification data166can also include heartbeat data. The heartbeat data can include basic information about the client device106C, such as a device identifier, operating system, hardware information, device model or type, and so on. The verification data166can also include a unique time-based session token (C) generated by the management agent139at request generation time of the offline P2P offline access mode request. The verification data166can be specific to the client device106C.

In some cases, multiple client devices can be detected, and the management agent139can select the client device106A that shares a user group150or a compliance policy126with the client device106C and/or is identified as being associated with the same user in a device association(s) record152. In some examples, the management agent139can transmit a list of detected client devices to the management service120, and the management service120can select the client device106A for the P2P offline access mode request. The management service120can select the client device106A that shares a user group150or a compliance policy126with the client device106C and/or is identified as being associated with the same user in a device association(s) record152.

The online client device106A receives the P2P offline access mode request from offline client device106C (over the P2P channel). As discussed, the client device106A can decrypt the payload using the public key (C) and can then re-encrypt the payload using its private key (A) and forward the request to the management service120, such as by transmission over the Internet, in step411.

The management service120can decrypt the encrypted payload data of the request, which is encrypted using the private key (A) specific to client device106A. The management service120can have access to a symmetrical or asymmetrical key for decryption of data encrypted using the private key (A). For example, management service120can have access to the public key (A), since it was provided as part of an enrollment process with the management service120. If signed, the management service120can use an associated public key (A) to confirm the signature created using the private key (A).

In step413, the management service120processes the P2P offline access mode request and verifies if offline client device106C is compliant with enterprise policies126and/or if the requested client application is enabled for P2P offline access mode. The management service120can confirm an enrollment status of the client device106C. For example, the management service120can confirm that the public key certificate (C) and/or device identifier (C) matches data stored in association with the client device106C and a user account138. The management service120can confirm that the session token (C) matches an expected format, is generated using an expected token generation algorithm, and that the session token (C) is unexpired or is received within a predetermined time frame from a timestamp of the session token (C).

If the offline client device106C and the remote client application146are compliant with enterprise policies, the management service120generates a special access token having a specified expiration period and transmits the special access token to online client device106A (over a client/server network, including the Internet) as an encrypted payload using public keys of the online client device106A.

Accordingly, the management service120can encrypt the special access token payload data using a public key (A) that was generated and provided by the management service120, for example, upon enrollment of client device106A. The public key (A) can be specific to the client device106A. The management service can sign and/or symmetrically encrypt the payload data using the public key (A). In step415, the management service120can then transmit the signed or encrypted special access token payload to the online client device106A (over a client/server network, including the Internet), where the client device106A can decrypt the payload using a private key (A) associated with the public key (A) in an asymmetric encryption scheme. Subsequently, client device106A can re-encrypt the payload using its private key (A) and forward the special access token payload to the client device106C over the P2P channel, in step417.

Client device106C decrypts the payload and the management agent139of client device106C uses the special access token and loads the expiration time/period into the management agent application and allows the client device106C to access the remote client application146. In various embodiments, whenever the application146is accessed, the special access token is used to communicate to the management service120via any nearby enrolled online device present in the P2P channel and once validated by the management service, the user is provided access to the remote client application146by the local management agent139(of client device106C) in concert with the remote management agent139of the online client device106A, in step420. If the time period for the special access token expires, access to the remote client application146will be restricted and a new peer-to-peer offline access mode request process will need to be repeated.

A number of software components previously discussed are stored in the memory of the respective computing devices and are executable by the processor of the respective computing devices. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory and run by the processor, source code that can be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory and executed by the processor, or source code that can be interpreted by another executable program to generate instructions in a random access portion of the memory to be executed by the processor. An executable program can be stored in any portion or component of the memory, including random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, Universal Serial Bus (USB) flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

The memory includes both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. Thus, the memory can include random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, or other memory components, or a combination of any two or more of these memory components. In addition, the RAM can include static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. The ROM can include a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device.

Although the applications and systems described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components, etc. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein.

The sequence diagrams show the functionality and operation of an implementation of portions of the various embodiments of the present disclosure. If embodied in software, each step or block can represent a module, segment, or portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that includes human-readable statements written in a programming language or machine code that includes numerical instructions recognizable by a suitable execution system such as a processor in a computer system. The machine code can be converted from the source code through various processes. For example, the machine code can be generated from the source code with a compiler prior to execution of the corresponding application. As another example, the machine code can be generated from the source code concurrently with execution with an interpreter. Other approaches can also be used. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function or functions.

Although the sequence diagrams show a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more steps or blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession can be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in the sequence diagrams can be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure.

Also, any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system. In this sense, the logic can include statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system. Moreover, a collection of distributed computer-readable media located across a plurality of computing devices (e.g., storage area networks or distributed or clustered filesystems or databases) may also be collectively considered as a single non-transitory computer-readable medium.

The computer-readable medium can include any one of many physical media such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium can be a random access memory (RAM) including static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.

Further, any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more applications described can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices in the same computing environment.

Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X; Y; Z; X or Y; X or Z; Y or Z; X, Y, or Z; etc.). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described embodiments without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.