USRE49585E1 - Certificate based profile confirmation - Google Patents

Abstract

Disclosed are various embodiments for controlling access to resources in a network environment. Methods may include installing a profile on the device and installing a certificate included in or otherwise associated with the profile on the device. A request to execute an application, and/or access a resource using a particular application, is received and determination is made as to whether the certificate is installed on the device based on an identification of the certificate by the application. If the certificate is installed on the device, then execution of the application and/or access to the resource is allowed. If the certificate is not installed on the device, then the request for execution and/or access is refused.

Description

This application claims priority as a continuation of is a reissue of U.S. patent application Ser. No. 15/800,224 and is an application for reissue of U.S. Pat. No. 10,560,453, claiming priority to U.S. patent application Ser. No. 13/835,542, filed Mar. 15, 2013, and entitled “CERTIFICATE BASED PROFILE CONFIRMATION,” all of which is are expressly incorporated by reference herein.

BACKGROUND

Controlling access to enterprise resources by network-connected devices is critical to ensure that only authenticated and authorized users and devices gain access to sensitive information or services. To date, this has typically been accomplished by utilizing network firewalls, reverse proxy servers with authentication, and encrypted VPN tunnels. Today, however, enterprise resources are being moved out of enterprise managed data centers and into the “Cloud.”

The inventors have explored various ways of protecting enterprise-managed data centers at a device level. These solutions have addressed challenges related to, for example, the fact that cloud-based data services often do not provide the necessary features to allow enterprises to control access to the service at a device level, but rather permit access, without restriction as to any device, with proper user level access controls.

Controlling access to and distribution of enterprise resources, such as documents, databases, and executable applications, in a networked environment is critical to ensure that only authorized users and network-connected devices may gain access to sensitive information. Depending on the sensitivity of a given resource, an array of authorization rules may be necessary to ensure that the resource is adequately protected. Some resources may only require ensuring that the proper user is requesting the resource. Other resources may require compliance with more stringent authorization rules, such as determining whether an appropriate transport protocol is used (i.e., http and/or https) by the requesting device, determining whether access to the resource is permitted for a specified duration or at a given time, determining whether the resource is accessed from a secured device, etc.

However, in many such systems, it is necessary for the managing system to have significant control over the managed device in order to implement the desired protocols. This may present its own challenges in situations where, for example, all device users are not willing to surrender the necessary level of device control, and/or where enterprise managers may desire to allow users of non-managed devices certain limited access to resources on the managed network, such as data, etc. Accordingly, the inventors have proposed the following systems and methods to provide, at least in some aspects, methods of enforcing protocols on devices that are not otherwise under management of a Mobile Device Management (MDM) service.

SUMMARY OF THE INVENTION

The following systems and methods provide solutions for controlling the use and distribution of resources in a networked environment, including limiting application execution and/or distribution of resources to devices that are not fully managed by an MDM service. Among other objects, the present subject matter may provide the ability to uniquely associate a required profile with a certificate, and to check that the certificate is installed on the mobile device to thereby ensure the required profile is also still in place.

In cases where a mobile device is not fully managed by an MDM service, the MDM, or other service, may instead provide the user of the device with a required profile for use with an enterprise application or an application that is configured to access enterprise resources including remotely stored data. The required profile may specify certain mandated settings, or parameters, for the device, and include a certificate that is uniquely associated with the required profile. The term “required” is used herein to signify that the profile is defined by or for the operator of the MDM service and must be installed on a device and validated before the device will be permitted to execute a certain application or access certain enterprise resources and/or access the managed network. When the device requests to execute the associated application or to access certain data or other resources from the managed network, the presence of the required profile on the device may be confirmed, as well as the compliance of the device with one or more setting or parameters specified in the required profile, by confirming that the certificate is installed on the device and/or that the stored certificate is valid.

According to certain embodiments, methods of managing access to resources by a device may include one or more steps of installing a plurality of profiles on the device; installing a plurality of certificates associated with the profiles; receiving a plurality of requests to access a plurality of resources; and/or determining whether the certificates are accessible to the device.

In some embodiments, determining whether the certificates are accessible to the device may include determining whether the certificates are stored and/or installed on the device. In some embodiments, determining whether the certificates are installed on the device may be based on an identification of the certificates by the applications.

In some embodiments, if it is determined that certain of the certificates are accessible to the device, and/or are installed on the device, then resources associated with the certain certificates may be accessed. Whereas, if it is determined that certain certificates are not accessible to the device, and/or are not installed on the device, then the requests to access the resources associated with the certain certificates may be refused.

In some embodiments, a request to access a resource may include one or more of a request to execute an application on the device, a request to access or render data stored on the device, a request to execute an enterprise application residing at least partially on a network, and/or a request to access or render data that is stored at least partially on a network. In embodiments where the request to access the resource includes a request to execute an application, the application may be referred to as the “called application.”

It should be noted that, as used herein, certain portions of a resource may be executed and/or accessed, in a limited manner, in order to perform the certificate validation without fully executing or accessing the resource as requested by the user. For example, in the context of requesting an application to execute, certain portions of the application may execute for the purpose of identifying and/or validating the required profile or corresponding certificate, but the application may not fully “open” for the user until the certificate validation is successfully completed. Likewise, in the context of requesting access to certain local or network data, portions of the requested data, or other associated data, may be accessed for purposes of identifying and/or validating the required profile or corresponding certificate, but the requested data may not be fully “accessed” by the user until the certificate validation is successfully completed.

In some embodiments, the profiles or certificates may be uniquely associated with the called application, the profiles or certificates may be associated with particular data, and/or certain certificates may be uniquely associated with certain profiles.

In some embodiments, various functions of the device may be enabled and/or disabled to bring the device into compliance with one or more settings and/or parameters specified in the required profile. For example, a parameter may specify that the data not be transferred outside of the device. In such a case, a camera, screen capture function, transmission capability, or other function of the device that would facilitate the transfer of data outside of the device, may be disabled via appropriate settings included in the profile.

In some embodiments, a request to access a resource on a remote server may be sent by the application if a required certificate is determined to be installed on the device.

In some embodiments, a failure notification may be sent to a remote server if a required certificate is determined not to be installed on the device.

In some embodiments, the determination as to whether a required certificate is installed on the device may be performed in response to a request to access the resource, prior to receiving the request to access the resource, at scheduled or random times (regardless the request to access the resource), and/or based on detection of a non-complying setting or parameter.

An alert may be sent from the device to a managing server if either the profile or certificate is not present on the device, or if the device is not in compliance with the at least one setting or parameter of the required profile. In response to such an alert, the server may initiate a remedial action, such as, enabling or disabling hardware and/or software functionality, increasing a password complexity, sending a message to an account and/or service administrator, sending a message to a user, locking the device, an enterprise wipe of certain resources, a full or partial wipe of the device, removing profiles, disabling access to enterprise server resources such as email, application data, content servers such as SharePoint, Box, etc., disabling and/or removing applications, etc. In some embodiments, the enabled or disabled functionality may include at least one of a camera, a screen capture, an artificial intelligence and/or assistance program (e.g. Apple Siri, Google Now, and the like), a GPS, Wifi communication, cellular communication, a microphone, speakers, a touchscreen, network support and/or services (e.g. Apple iCloud, Microsoft SkyDrive and the like), etc. In some embodiments, a sever may independently enforce various of the foregoing functions, and/or may “push” necessary enforcement commands, code, and the like, to devices, or other service providers. In some embodiments, the device may include local rules that allow enforcement of the remedial action, such as in the case of functionality built into an OS, e.g. password enforcement, etc., and/or when the device includes certain enterprise applications, such as a Secure Content Locker described further herein.

In some embodiments, the profiles may be, for example, one of a plurality of iOS profiles, a plurality of Android OS profiles, a plurality of Windows Mobile profiles, a plurality of Windows Phone profiles, a plurality of Windows 8 (etc.) profiles, a plurality of Mac OS X (etc.) profiles, a plurality of Symbian OS profiles, or other operating system profiles. In some embodiments, the certificates may be one of a plurality of root certificates and/or a plurality of intermediate certificates, and may be stored, if at all, in a “trust store” or “certificate store” of the device or in some other suitable memory space of the device.

In some embodiments, required certificates may be securely associated with certain devices and stored remotely from the devices. In such embodiments, device profile compliance may be determined, for example, by checking those certificates in addition to, or instead of, checking locally stored certificates.

According to certain further embodiments, a method of managing an application on a device, based on the presence of a plurality of profiles on the device, may include one or more steps of receiving a plurality of requests to execute a plurality of applications on the device; identifying a plurality of certificates associated with the profiles and the applications; and/or determining whether the certificates are installed on the device. In some embodiments, if certain of the certificates are installed on the device, then applications associated with the certain certificates may be executed, whereas if certain certificates are not installed on the device, then requests to execute applications associated with the certain certificates may be refused.

According to certain further embodiments, an apparatus including a computing device, a display and a processor may be configured to perform the various method steps and functions described herein.

According to certain further embodiments, the various method steps and apparatus functions described herein may be embodied on non-transitory electronic storage medium in the form of computer-readable instructions that, when executed by a microprocessor, cause a computer system perform the described functions and steps.

Additional features, advantages, and embodiments may be set forth or apparent from consideration of the following detailed description, drawings, and claims. Moreover, it is to be understood that both the foregoing summary and the following detailed description are provided by way of example only and intended to provide further explanation without limiting the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood with reference to the following diagrams. The drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating certain features of the disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG.1 is a block diagram of a networked environment according to certain exemplary embodiments of the present invention.

FIG.2 is a flowchart illustrating an exemplary application access control process using profile and certificate confirmation in the networked environment ofFIG.1 according to certain embodiments of the present invention.

FIG.3 is a flowchart illustrating an exemplary data access control process using profile and certificate confirmation executed in the networked environment ofFIG.1 according to certain embodiments of the present invention.

DETAILED DESCRIPTION

It is to be understood that the invention is not limited to the particular methodology, protocols, etc. described herein, as the skilled artisan will recognize that these may vary in different embodiments the invention. It is also to be understood different embodiments the invention. It is also to be understood that the terminology used herein is used for the purpose of describing particular embodiments only, and is not intended to limit the scope of the invention. It also is to be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include the plural reference unless the context clearly dictates otherwise. Thus, for example, a reference to “a server” is a reference to one or more servers and equivalents thereof known to those skilled in the art.

The embodiments of the invention and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments and examples that are described and/or illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and computing techniques may be omitted so as to not unnecessarily obscure the embodiments of the invention. The examples used herein are intended merely to facilitate an understanding of ways in which the invention may be practiced and to further enable those of skill in the art to practice the embodiments of the invention. Accordingly, the examples and embodiments herein should not be construed as limiting the scope of the invention, which is defined solely by the appended claims and applicable law.

As used herein, a “profile” should be understood as referring to a file that is recognizable by the operating system (OS) of a user device, and that defines one or more settings. As used herein, such settings may also include more general “parameters” that may relate to, for example, the presence or absence of certain applications on a device, a required version of an application, configuration states that may rely on various settings, etc. The specific settings included in a profile may typically be set by a service manager such as an MDM, and may include an embedded certificate that the OS will recognize and install for the device, such as in a “trust store” or “certificate store” or other suitable memory space (any of which may be generically herein as a “trust store” for ease of reference) of the device. Typically, the profile is formatted in a manner such that the particular OS is able to recognize and implement the settings defined therein when installed by a user. For example, a profile may be an XML file that contains settings (which may define or otherwise indicate desired parameters) to deploy to the OS of a client device. The profile may therefore set and/or control a variety of device settings, functions and the like, e.g. passcode policies, email account configurations, calendar, contact accounts, VPN settings, WiFi settings, restrictions on how and what features and components of the device can and cannot be used, etc. If the profile is uninstalled, disabled, becomes corrupted or is otherwise inactive, the OS will typically remove the corresponding certificate from its trust store.

Disclosed are various embodiments for a system and associated devices and methods for controlling access to resources such as computer applications and electronic data. In one embodiment, a client device executes an application on a user device based on a confirmation that a required profile is present on the user device. As described further herein, the profile may typically include parameters that relate to disabling one or more functions of the client device, such that client device's ability to further distribute the data accessed by the application is inhibited. The confirmation may be based on the presence of a unique certificate associated with the required profile, and typically present on the client device. However, it should also be understood that, as “cloud-based” applications continue to develop, aspects of the invention may find applicability in profile and certificate management environments that securely associate particular client devices with profiles and certificates, without necessarily storing the profiles or corresponding certificates locally on the client device itself.

FIG.1 illustrates anetworked environment100 according to various embodiments. Thenetworked environment100 includes anetwork110, aclient device120, and adistribution server150. Thenetwork110 may be or include, for example, any type of wireless network such as a wireless local area network (WLAN), a wireless wide area network (WWAN), or any other type of wireless network now known or later developed. Additionally, thenetwork110 may be or include the Internet, intranets, extranets, microwave networks, satellite communications, cellular systems, PCS, infrared communications, global area networks, or other suitable networks, etc., or any combination of two or more such networks. In one embodiment, thenetwork110 facilitates transmission ofresources165 between one ormore client devices120 and adistribution server150.

Theclient device120 may be a desktop computer, a laptop computer, a personal digital assistant, a cellular telephone, a set-top box, a music player, a web pad, a tablet computer system, a game console, and/or another device with like capability. Theclient device120 may include a wired network connectivity component (not shown inFIG.1), for example, an Ethernet network adapter, a modem, and/or the like. Theclient device120 may further include a wireless network connectivity interface (not shown inFIG.1), for example, a PCI (Peripheral Component Interconnect) card, USB (Universal Serial Bus) interface, PCMCIA (Personal Computer Memory Card International Association) card, SDIO (Secure Digital Input-Output) card, NewCard, Cardbus, a modem, a wireless radio transceiver, and/or the like. Theclient device120 may thus be operable to communicate via wired connection with thedistribution server150 with the aid of the wired network connectivity component. Theclient device120 may be further operable to communicate wirelessly with thedistribution server150 with the aid of the wireless network connectivity component. Additionally, theclient device120 may further comprise a memory for storing data and applications, a processor for executing applications stored in memory, and a local interface such as a bus.

Additionally, theclient device120 may store in a data store122 aprofile123, user credentials132, acertificate135, and other data. In one embodiment,profile123, may indicate one or more required configuration parameters related to capabilities, functions, and/or applications of theclient device120 that must either be present or not present, or enabled or disabled, on theclient device120 in order to open anapplication126 stored on theclient device120 or use thatapplication126 to access certain data stored on theclient device120, and/or to accesscertain resources165 available on thedistribution server150.

For example, the requiredprofile123 may indicate that a camera, screen capture function, or other function (including applications or functions performed by applications) that would facilitate the transfer of data outside of theclient device120 must be not present, or disabled. These parameters may be determined by a service provider that supportsapplication126 and/or that managesdistribution service174. Therefore, parameters included in theprofile123 may be advantageously used to limit the ability of theclient device120 to transfer certain data outside of theclient device120. Additional details regarding the installation and function of theprofile123 are described further below.

The user credentials132 may uniquely identify the user of theclient device120. For example, the user credentials132 may include a username, a password, and/or biometric data related to facial recognition, retina recognition, fingerprint recognition, and the like.

Thecertificate135 may represent either, or both, of an algorithm for generating a unique certificate and/or the generated certificate itself. In some embodiments, thecertificate135 is introduced to theclient device120 via theprofile123. For example, in certain operating systems, the system may recognize that aprofile123 includes a root or intermediate certificate, and automatically store the certificate in a trust store, or certificate store. Thecertificate135 may be unique and associated with theclient device120,application126, and/or theprofile123. For example, thecertificate135 may be based on one or more of a unique hardware identifier such as a GUID (Globally Unique Identifier), UUID (Universally Unique Identifier), UDID (Unique Device Identifier), serial number, IMEI (Internationally Mobile Equipment Identity), Wi-Fi MAC (Media Access Control) address, Bluetooth MAC address, a CPU ID, and/or the like, or any combination of two or more such hardware identifiers. Additionally or alternatively, thecertificate135 may be securely tied to theprofile123 such that, if theprofile123 is disabled on theclient device120, then thecertificate135 is removed or uninstalled from the client device's trust store.

Thecertificate135 may be generated and/or updated by theclient device120, or may be provided by a third party. For example, an application running on theclient device120 can generate acertificate135 in coordination with a third party server, and can thereafter use the certificate for validation on theclient device120.

Theclient device120 may further be configured to execute various applications. For example, theclient device120 may be configured to execute applications such as web browsing applications, email applications, instant messaging applications, and/or other applications capable of receiving and/orrendering resources165 on adisplay136 associated with theclient device120. Any applications capable of receiving and/or rendering resources on adisplay136 is generally referred to herein as a “client side application”126, even though some, or all, of the application program itself may reside on non-transitory storage medium of any device or server networked to theclient device120. According to certain aspects of the invention, aclient side application126 may further include instructions that identify a requiredcertificate135 associated with the requiredprofile123.

For example, a set of instructions may be included in theclient side application126 that are executed when the application is called. This set of instructions may include a certificate identifier(s) associated with one or more required profiles for the application, and code for querying the OS if the identified certificate(s) are installed. The required profile, and more specifically the device parameters that must be implemented to execute the application, may be set by a service provider that provides the application, provides additional code for the application to perform the certificate validation, and/or provides the profile to the user. Thus, the set of instructions included in theclient side application126 may cause the application to communicate with the OS, using the certificate identifier to determine if the required certificate is installed on theclient device120.

FIG.2 is a flowchart illustrating an exemplary application access control process using profile and certificate confirmation in the networked environment ofFIG.1 according to certain embodiments of the present invention. As shown inFIG.2, the method may begin withstep200, in which a profile is installed on a client device such asclient device120 fromFIG.1. The profile may typically be installed, for example, by opening the profile file embedded in or attached to an e-mail, connecting a smartphone or other mobile client device to a PC (e.g., via USB or another suitable connector, or via Bluetooth, WiFi, infrared or other suitable wireless connection) and loading the profile to the mobile client device. It should be understood that the need to “manually” install such profiles onto the client device is driven by the fact that the client device is not managed, or at least not fully managed, by an MDM and therefore the profile and other MDM settings cannot be “pushed” to the client device by the MDM. Exemplary profiles may include, for example, an iOS profile, an Android OS profile, a Windows Mobile profile, a Windows Phone profile, a Windows 8 (etc.) profile, a Mac OS X (etc.) profile, a Symbian OS profile, or similar profiles recognized by other OS's. In some embodiments, the profile may be associated with (and perhaps specially configured for) a certain user and/or client device or a class or users or client devices. As such, thedistribution server150, or other profile provider, can associate a unique profile with a unique device or set of devices, and ensure that the profile is not migrated to any other device(s). By way of example, a profile with more restrictive device configuration requirement may be provided for devices used by users with lower security clearance or lesser administrative privileges, etc. and a profile with less restrictive device configuration requirements may be provided for devices used by users with higher security clearance or greater administrative privileges, etc.

As part of the profile installation, and as shown instep205, the client device may automatically implement one or more parameters included in the profile. As discussed above, such parameters may advantageously include inhibiting certain hardware and/or software functions of the client device such as a camera, a screen capture, an artificial intelligence and/or assistance program (e.g. Apple Siri, Google Now, and the like), a GPS, Wifi communication, cellular communication, a microphone, speakers, a touchscreen, network support and/or services (e.g. Apple iCloud, Microsoft SkyDrive and the like), etc. In certain embodiments consistent with current OS standards, one ore more of the foregoing parameters may be applied globally (i.e. system wide and applying to all applications). However, the invention may also find applicability in systems that allow for discreet application of such parameters, e.g. limiting camera operation or other functions of the client device only when certain applications are executed, or certain data is rendered on the display screen, etc.

In certain embodiments, such parameters may be applied in a hierarchical manner whereby the most restrictive parameters from a plurality of installed profiles are implemented, which ensures that the client device continues to comply with all required parameters. For example, if a first profile is installed that prohibits all screen capture, the later installation of a profile that only limits screen capture while certain applications are running will not override the more restrictive first profile, at least with respect to the global prohibition of screen capture. Therefore, in some embodiments, multiple profiles may be provided to and simultaneously installed on a particular client device, or the client device or user of the client device may be permitted to choose among the different profiles to be installed in different circumstances.

The method may continue withstep210, in which the system identifies any certificate associated with the profile, and stores the certificate. In some embodiments, the certificate is included in the profile and extracted therefrom by the OS. In other embodiments, the certificate may be provided separately from the profile. Typically the storage is implemented in a trust store that resides on the client device to ensure uninterrupted access to the trust store. However, it may also be possible to store the certificate on another networked device or server that is securely associated with the client device for future reference. The certificate may be, for example, a root or intermediate certificate.

The method may continue withstep215, in which an application, or other resource, is called. This may include, for example, a user request to execute an application or access a file, an application calling another application or resource, etc. In certain embodiments, the request may initiate a limited execution or access to the requested resource in order to execute instructions that attempt to identify a required profile or certificate and/or complete a required certificate validation.

The method may continue withstep220, in which the system checks to see if the required certificate is installed on the device. It should be understood that, as used herein, checks to see if the required certificate is “installed” on the device may include one or more of checking to see if the certificate is stored on the device, checking to see if the certificate is stored in a particular location on the device, e.g. in a trust store, and/or checking to see if a certificate stored on the device is valid. This may be done, for example, by the called application including instructions that request the OS to confirm whether a required certificate is “trusted” by the device. In some embodiments, certificates stored remotely, and associated with the device, may be subject to similar checks, and in some instances may be used instep220 instead of checking for certificates stored on the device itself. In such embodiments, the remotely stored certificates may be updated, at various times, to ensure that the device includes the required profile as needed. For example, an application on the client device may send an alert to delete the remote certificate if the profile is removed, a remote server may ping the client device to check profile compliance, and take appropriate remedial action, such as deleting the remote certificate, if non-compliance is determined, etc.

In some embodiments, an identifier, or other sufficient indicia, of the required certificate may be encoded in the called application. In such embodiments, the application may be updated, as needed, to identify the appropriate certificate, e.g. based on profile updates, software version changes, etc. In some embodiments, the called application may be configured to fetch a required certificate, certificate identifier, or the like, from a remote resource or service provider, such asdistribution service174. For example, the called application may include instructions with an address, or other pointer, to a location at which required certificate, certificate identifier, or the like, are stored. A service provider, or other entity, may then update certificates, certificate identifiers, or the like, in a hardcoded location where various devices can fetch the new certificate, even if it changes.

In some embodiments, the called application may be configured to query the OS to determine whether the certificate is valid by presenting the certificate, or other sufficient indicia, to the OS and asking it to return a binary response of whether the certificate is trusted. The OS may, for example, refer to the trust store, or other certificate directory, to determine whether the certificate is present and/or has been signed by a certificate authority. Typically, current OS's are configured such that a particular application does not have direct access to the trust store in order to make such a determination on its own.

In response to the request from the application, the OS may look for the required certificate in the trust store and/or validate the certificate. In some embodiments, if the required certificate is found, the certification is determined to be trusted by the device and the method may proceed withstep230 where the application is allowed to complete the process of opening. In some embodiments, the certificate may be validated by other means as well, such as checking a certificate authority signature, before proceeding withstep230.

However, if the user has disabled or uninstalled the required profile, or the required profile has become corrupted, etc., then the corresponding certificate may have been removed from the trust store by the OS. Therefore, when the OS looks for the required certificate in the trust store, it will not be found, and the application will not be opened, i.e., the application will not execute its routines for opening or will otherwise be shut down. As mentioned above, certificates may also be determined to be invalid, for example, by not including a required signature, etc. In the event that the certificate is not “trusted” by the device, or is otherwise invalid, the method may continue withstep225.

Instep225, a number of options are possible. Generally speaking,step225 may ensure that the request for access is denied, at least temporarily, until the problem with the certificate is resolved. This may involve, for example, theclient device120 suspending communication with thedistribution server150, the client device displaying an alert to the user with, or without, instructions for correcting the problem, the client device sending an alert to the distribution server, the distribution server suspending communication with the client device, the distribution server sending an alert to the client device, with, or without, instructions for correcting the problem, etc.

In some embodiments, theclient device120 and/ordistribution server150 may initiate corrective and/or remedial measures as part ofstep225, such as on theclient device120. For example, the user ofclient device120 may agree to certain restrictions or remedial measures when theprofile123 is installed, that go into effect if a certificate validation check fails. Such measures may include deleting any local resources that were originally accessed using thecertificate135, disablingenterprise resources165 such as certain enterprise applications associated with theprofile123, etc. In certain embodiments,step225 may be used to pursue an alternate access validation in the event that there is a connection between the user device and thedistribution service174 and the profile-based validation fails. For example, thedistribution service174 may initially attempt to validate the access request using the profile validation, which may require little to no user involvement, and, if that is not successful, thedistribution service174 may initiate a user credential/device identifier (or other) access validation.

Instep225 an alert may be sent to the user and/or service manager. The alert may include one or more of an identification of the application that did not open or the resource to which access was denied, the certificate that was not found, the profile parameters for the profile corresponding to the missing certificate, user identification, device identification, or other information.

It should be noted that, although only a singlecertificate validation step220 is depicted in the embodiment ofFIG.2, as sequentially happening in a certain order, the invention is not limited to such sequential operation. For example, the certificate validation can be performed in response to an attempt to open an application, an attempt to access data, at random times, according to a schedule, and/or based on detection of a non-complying parameter. Depending on the service provider's preferences, this may allow the application to execute based on previous certificate validations, e.g. within a predetermined time frame, or may require updated certificate checks, even while the application is running.

FIG.3 is a flowchart illustrating an exemplary data access control process using profile and certificate confirmation executed in the networked environment ofFIG.1 according to certain embodiments of the present invention. The steps shownFIG.3 may be performed after, or independent of, the steps shown inFIG.2. Instep300, a client side application, such asapplication126 shown inFIG.1, requests access to resources which may be stored locally on the device, or remotely on a server, such asdistribution server150 shown inFIG.1. For example, with respect to a request for remotely stored resources, aclient side application126 may be executed to transmit requests to accessresources165 to thedistribution server150 and render a user interface137 on thedisplay136 that provides access to theresources165. In particular, theresources165 may be presented in a user interface137 by decompressing compressed files and presenting the uncompressed files, mounting disk image files and presenting the mounted image files, running executable files and presenting the executed files, by enabling a data search of theresources165 and presenting the featured output in a user interface, by calling on another application on theclient device120 to respond to data links contained within theresources165, and/or by transmitting a part or the whole of theresources165 to another application on theclient device120.

Instep305, a determination is made as to whether the requesting application complies with the necessary criteria to access the requested resource. Step305 may include, for example, checks to ensure that an application has been updated to a current version, that the request includes valid user credentials, that the request is not coming from a blacklisted address, etc. In some embodiments, a certificate check, as described above, may be all that is implemented in order to grant the application general access to a group of local or remote resources. However, the invention may also be applied in environments that require various other access controls in addition to, or as alternatives to, the certificate validation, as discussed further below.

If the requesting application is found not to comply with any of the requirements to access the requested resource, the method may continue withstep310. Instep310, a number of options are possible. Generally speaking,step310 may ensure that the request for access is denied, at least temporarily, until the problem with the requesting application is resolved. In situations where the client device is attempting to access resources on the distribution server, this may involve, for example, the distribution server suspending communication with the client device, the distribution server sending an alert to the client device, with, or without, instructions for correcting the problem, etc.

In some embodiments, theclient device120 and/ordistribution server150 may initiate corrective and/or remedial measures as part ofstep310, such as those described above with respect to step225.

If the requesting application is found to comply with the requirements to access the requested resource, the method may continue withstep315. Instep315, the resources that correspond to the request, and to which access is authorized, are determined. In some embodiments, parts, or all, ofstep315 may optionally be performed prior to step305.

Various ways of identifying resources that are subject to a particular request, and that may be implemented in conjunction with the concepts provided herein. For example, further details regarding methods of determining the accessible resources, in the context of the present invention, are discussed with reference back toFIG.1. As shown inFIG.1, in one embodiment, theresource qualifier172 may be or include metadata that describes and/or regulates the use of therespective resource165. For example, a resource qualifier may include categories/sub-categories to which theresource165 belongs, an indication that theresource165 is considered a favorite, an indication of whether theresource165 is privately owned, publicly owned, and/or enterprise-owned, an indication of whether theresource165 is confidential, an indication of whether theresource165 is password protected, an indication of the historical version of theresource165, a description of theresource165, one or more comments regarding theresource165, an indication of the size and format of theresource165, an indication of the download priority associated with theresource165, an indication of the expiration date associated with theresource165, an indication of the effective date associated with theresource165, an indication of the ownership of theresource165, an indication of the managing party of theresource165, and/or the like, or any combination of resource qualifiers.

Thedistribution server150 may comprise, for example, a server computer or any other system providing distribution capability. For purposes of convenience, thedistribution server150 is referred to herein in the singular. Even though thedistribution server150 is referred to in the singular, it is understood that a plurality ofdistribution servers150 may be employed in the arrangements as descried herein.

Certain applications and/or other functionality may be executed in thedistribution server150 according to certain embodiments. Also, certain data is stored in adata store153 that is accessible to thedistribution server150. The data stored in thedata store153, for example, is associated with the operation of the applications and/or functional entities described herein.

Thedata store153 may includeresource grouping identifiers154,resources165, and/or other data. In one embodiment, theresources165 referenced herein may include any electronic data, such as databases, applications, text files, word processor files, spreadsheet files, presentation files, graphic files, audio files, photographic files, video files, applications and application files, and/or the like. More specifically,resources165 may include: data files, audio files, video files, three-dimensional image files, raster image files, vector image files, page layout files, spreadsheet files, database files, executable files, CAD files, web files, plug-in files, font files, system files, settings files, encoded files, compressed files, disk image files, developer files, backup files, and/or any other files.

Theresource grouping identifiers154 may represent unique identifiers for previously determined resource groupings and are used to determine whichresources165 are served up to the user of theclient device120. For example, a resource grouping may relate to approved profile andcertificates159, organizational groups, organizational roles, geographic locations, and/or any other type of grouping that require access to a type of resource. In some embodiments,distribution rules171 may specify, or be otherwise associated with, required profiles125 orcertificates135 that must be confirmed in order to transfer resources to a requestingclient device120.

Eachresource grouping identifier154 may be associated with a pairing of at least one of a plurality of approved user credentials and device identifiers156 and/or a pairing of at least one of a plurality of approved profiles andcertificates159. Generally speaking, pairings of approved user credentials and device identifiers156 may be used to manage the distribution ofresources165 to managedclient devices120, whereas pairings of approved profiles andcertificates159 can be used to manage distribution ofresources165 tounmanaged client devices120.

The components executed on thedistribution server150, for example, include thedistribution service174 and other applications, services, processes, systems, engines, or functionality not disclosed in detail herein. Thedistribution service174 may be executed to provideresources165 stored in thedata store153 to a requestingclient device120 based on, for example,resource grouping identifiers154 anddistribution rules171, as will be described.Distribution service174 may also generate and distribute requiredprofiles123 includingcertificates135 to client devices. It should be understood that, in some circumstances it may be advantageous to push the distribution rules171 to managed client devices that do not use a profile and certificate validation as described herein. However, if a client device is using a profile and certificate validation, the distribution rules171 may simply be used as a tool to associate approved profiles and certificates with appropriate resources, without pushing the distribution rules171 to the client device(s).

A user operating aclient device120 may wish to accessresources165 stored on thedistribution server150. In one embodiment, the user may interact with an input device to manipulate a user interface137 rendered by theclient side application126, to thereby cause theclient device120 to transmit arequest177 for accessing one ormore resources165 on thedistribution server150. For unmanaged devices, theclient device120 and/or thedistribution server150 may be required to confirm the installation of thecertificate135 on thedevice120 before access will be granted. For example, therequest177 may include confirmation that theclient device120 has avalid certificate135, or it may include such information as may be necessary fordistribution server150 to confirm these facts.

Upon determining that therequest177 from theclient device120 is valid, such as instep305 ofFIG.3, thedistribution server150 may further determine which of theresources165 to provide to theclient device120, as instep315 ofFIG.3. In one embodiment, thedistribution service174 determines whichresources165 to provide based on theresource grouping identifiers154 associated with eachresource165. For instance, in the case of a managedclient device120, thedistribution service174 may first determine whichresource grouping identifiers154 are associated with user credentials132 included in therequest177. In the case of an unmanaged client device, thedistribution service174 may first determine whichresource grouping identifiers154 are associated with the profile/certificate information received from theclient device120.

Next, thedistribution service174 may identify aresource165 to provide to theclient device120 based on the determinedresource grouping identifiers154. In one embodiment, thedistribution service174 identifies one ormore resources165 associated with each one of the determinedresource grouping identifiers154. In another embodiment, thedistribution service174 identifies theresource165 if theresource165 is associated with all of the determinedresource grouping identifiers154. Additionally, in another embodiment, thedistribution service174 identifies theresource165 if it is associated with a threshold number of theresource grouping identifiers154. Thedistribution service174 may then provide the identifiedresources165 to theclient device120 or otherwise allow the client device to accesssuch resources165.

Instep315, information related to the access request may also be logged and stored, for example, by theclient device120 and/ordistribution server150. These records may be used to maintain access for predetermined periods of time and other housekeeping matters, such as refusing further access requests after a certain number of failed attempts.

Instep320, thedistribution service174 facilitates accessing theresources165 for theclient device120. In one embodiment, the requested resource(s) may be provided toclient side application126 based on the request and validation without further input from the user, e.g. thedistribution service174 automatically transmits the identifiedresources165 that theclient device120 is authorized to receive. In other embodiments, thedistribution service174 may provide an operable hyperlink, or the like, to theclient device120, that is tied to a specific client side application. For instance, theclient device120 may receive an indication that theresource165 is available for download and may transmit a request to thedistribution service174 for downloading theapplicable resource165. Upon receiving the request, thedistribution service165 may transmit theresource165 to theclient device120. Aclient side application126 on theclient device120 may periodically determine whether theclient device120 remains compliant to access the receivedresources165, e.g. based on periodic certificate validation, as described above.

Other access facilitating methods may include, for example, granting folder access, application downloads and/or access, etc. For example, thedistribution service174 may provide an appropriate user interface to theclient device120. Thedistribution service174 may determine theresource grouping identifiers154 of theresources165 accessible using theprofile123 from theclient device120. In one embodiment, thedistribution service174 determines theresource grouping identifiers154 based on the required certificate. For instance, eachresource grouping identifier154 may be associated with a profile/certificate. Thedistribution service174 may determine one or moreresource grouping identifiers154 associated with the profile/certificate, as described above.

Aspects of the above described steps may also be performed with respect to accessing resources stored locally on the client device. For example, an application that uses a certificate validation may be allowed to store certain data locally. If a user attempts to reopen the locally stored data, the application may go through certificate validation steps before granting access to the locally stored data. Likewise, thedata store122 may include any of theresource grouping identifiers154, and the like, as used on thedistribution server150, to facilitate identification of accessible resources that may be stored on theclient device120.

Although thedistribution service174,client side application126, and other various systems described herein may be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same may 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 may 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 having appropriate logic gates, 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 flowcharts ofFIGS.2 and3 may show certain functionality and operations described as performed by thedistribution service174 andclient side application126, respectively. If embodied in software, each box may represent a module, segment, or portion of code that comprises program instructions to implement the specified logical function(s). The program instructions may be embodied in the form of source code that comprises human-readable statements written in a programming language or machine code that comprises numerical instructions recognizable by a suitable execution system such as a processor in a computer system or other system. The machine code may be converted from the source code, etc. If embodied in hardware, each block may represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

Although the flowcharts ofFIGS.2 and3 show a specific order of execution, it is understood that the order of execution may differ from that which is depicted. For example, the order of execution of two or more steps may be scrambled relative to the order shown. Also, two or more blocks shown in succession inFIGS.2 and3 may be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the steps shown inFIGS.2 and3 may 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.

Any logic or application described herein, including thedistribution service174 and theclient side application126, or other processes and modules running ondistribution server150 orclient device120, that comprises 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, for example, a processor in a computer system or other system. In this sense, the logic may comprise, for example, 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. The computer-readable medium can comprise any one of many physical media such as, for example, 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 may be a random access memory (RAM) including, for example, static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium may 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.

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 may be made to the above-described embodiment(s) 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.

Claims (17)

The invention claimed is:

1. A method for managing a device, comprising:

sending, to the device from a remote server, a profile specifying that an application installed on the device is authorized to execute on the device and authorized to access a resource, wherein the profile comprises a certificate that uniquely identifies the profile from another profile;

receiving, at the remote server, a request from the application installed on the device to access the resource, the request including the certificate;

verifying that the certificate is valid;

identifying the resource based on a resource grouping identifier that is associated with a pairing of the profile and the certificate; and

if the certificate is valid, providing the application with access to the resource; and, wherein providing the application with access to the resource further comprises providing the application with access to a plurality of additional resources authorized by the certificate.

2. The method ofclaim 1, further comprising: if the certificate is not valid, determining, in a subsequent verification, that the certificate is no longer valid, and denying access to the resource.

3. The method ofclaim 1, further comprising: if the certificate is not valid, determining, in a subsequent verification, that the certificate is no longer valid, and initiating a remedial measure defined by the profile.

4. The method ofclaim 3, wherein the remedial measure is one of at least:

causing the device to delete any resources originally accessed using the certificate;

disabling an enterprise application;

sending an alert to the device alerting a user of the device that access was denied;

sending an alert to an administrator; and

pursuing an alternate validation method.

5. The method ofclaim 1, wherein the profile is uniquely associated with the application.

6. The method ofclaim 1, wherein providing the application with access to the resource further comprises locating the resource and transmitting the resource to the device.

7. A non-transitory, computer-readable medium comprising instructions that, when executed by a processor of a remote server, performs stages for managing a device, the stages comprising:

sending, to the device from the remote server, a profile specifying that an application installed on the device is authorized to execute on the device and authorized to access a resource, wherein the profile comprises a certificate that uniquely identifies the profile from another profile;

receiving, at the remote server, a request from the application installed on the device to access the resource, the request including the certificate;

verifying that the certificate is valid;

identifying the resource based on a resource grouping identifier that is associated with a pairing of a user credential and a device identifier of the device; and

if the certificate is valid, providing the application with access to the resource; and, wherein providing the application with access to the resource further comprises providing the application with access to a plurality of additional resources authorized by the certificate.

8. The non-transitory, computer-readable medium ofclaim 7, the stages further comprising: if the certificate is not valid, determining, in a subsequent verification, that the certificate is no longer valid, and denying access to the resource.

9. The non-transitory, computer-readable medium ofclaim 7, the stages further comprising: if the certificate is not valid, determining, in a subsequent verification, that the certificate is no longer valid, and initiating a remedial measure defined by the profile.

10. The non-transitory, computer-readable medium ofclaim 9, wherein the remedial measure is one of at least:

causing the device to delete any resources originally accessed using the certificate;

disabling an enterprise application;

sending an alert to the device alerting a user of the device that access was denied;

sending an alert to an administrator; and

pursuing an alternate validation method.

11. The non-transitory, computer-readable medium ofclaim 7, wherein the profile is uniquely associated with the application.

12. The non-transitory, computer-readable medium ofclaim 7, wherein providing the application with access to the resource further comprises locating the resource and transmitting the resource to the device.

13. A server, comprising:

a memory storage storing program code; and

a processor coupled to the memory storage, wherein, upon execution, the program code causes the processor to:

send, to a device from the server, a profile specifying that an application installed on the device is authorized to execute on the device and authorized to access a resource, wherein the profile comprises a certificate that uniquely identifies the profile from another profile;

receive a request, from the application installed on the device, to access the resource, the request including the certificate;

verify that the certificate is valid;

identify the resource based on a resource grouping identifier that is associated with a pairing of the profile and the certificate; and

if the certificate is valid, provide the application with access to the resource; and, wherein providing the application with access to the resource further comprises providing the application with access to a plurality of additional resources authorized by the certificate.

14. The server ofclaim 13, wherein the program code causes the processor to, if the certificate is not valid, determine, in a subsequent verification, that the certificate is no longer valid, and deny access to the resource.

15. The server ofclaim 13, wherein the program code causes the processor to, if the certificate is not valid, determine, in a subsequent verification, that the certificate is no longer valid, and initiate a remedial measure defined by the profile.

16. The server ofclaim 15, wherein the remedial measure is one of at least:

causing the device to delete any resources originally accessed using the certificate;

disabling an enterprise application;

sending an alert to the device alerting a user of the device that access was denied;

sending an alert to an administrator; and

pursuing an alternate validation method.

17. The server ofclaim 13, wherein the profile is uniquely associated with the application.

Images