Patent ID: 12218974

DESCRIPTION OF THE EXAMPLES

Reference will now be made in detail to the present examples, including examples illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Systems and methods are described for increasing web browser security on a user device managed by a device management system. In an example, the user device can use an unmanaged web browser to access secure enterprise content using a browser extension provided by the enterprise. When a user attempts to access secure content from an unmanaged browser, the device management system can communicate with the extension and a management application on the user device to authenticate the user and verify that the user device complies with certain policies. In one example, the device management system can include an extension recommendation engine that analyzes user browsing data and recommends browser extensions for the user. Based on policies, the device management system can recommend the extension to the user or force installation of the extension on the user device

FIG.1is an illustration of an example system for providing secure web browsing on a managed user device.FIGS.2and3are a flowchart and sequence diagram, respectively, of example methods for accessing secure content from an unmanaged web browser using a browser extension provided by a UEM system or other device management system.FIGS.4and5are a flowchart and sequence diagram, respectively, of example methods for recommending browser extensions for a user based on the user's browsing history, user device state, groups, and other factors.

FIG.1is an illustration of an example system for providing secure web browsing on a managed user device. The example system can include a user device110that belongs to or is assigned to a user. The user device110can be one or more processor-based devices, such as a personal computer, tablet, or cell phone. In an example, the user device110can be enrolled in a UEM system140, which can be any system for managing a group of user devices.

In an example, the UEM system140can manage the user device110through a management server142. The management server142can be a single server or a group of servers, including multiple servers implemented virtually across multiple computing platforms, including a cloud-based platform. In an example, the management server142can manage the user device110, and other enrolled user devices, by sending management instructions to a management application120installed on the user device110during or prior to enrolling. The management application120can be a stand-alone application, part of an enterprise application, or part of an operating system of the user device110. In one example, the management application120can communicate with the management server140using Application Programming Interface (“API”) calls.

In an example, the management application120can be responsible for ensuring that the user device110is up to date with compliance and security settings prior to secure content, which can include any type of data or services related to an enterprise or otherwise considered confidential in some respect. The management application120can communicate with the UEM server142(alternatively called management server142), allowing UEM management of the user device110based on compliance and security settings at the UEM server142. The management application120can enforce compliance at the user device110, such as by locking a device, notifying an admin, or wiping enterprise data when compliance standards are not met. Example compliance standards can include ensuring a device is not jailbroken, that particular encryption standards are used in enterprise data transmission, that the device does not have certain blacklisted applications installed or running, and that the device is located within a geofenced area when accessing certain secure content. In one example, the user device110can secure content through the UEM server142.

In an example, the user device110can include a browser130, which can be any kind of application that provides a user interface (“UI”) for accessing the Internet. Some examples can include GOOGLE CHROME, MICROSOFT EDGE, APPLE SAFARI, and MOZILLA FIREFOX, to name a few. In one example, the browser130can be a browser that is not managed by the UEM system140, which can mean that the UEM system140does not have control over access and functionality of the browser130.

In an example, the unmanaged browser130can include a UEM extension132that can help enforce secure browsing and allow the user device110to access secure content. The UEM extension132can be a software module, such as a plugin, provided by the UEM system140that enables custom functionality on a web browser. For example, the UEM extension132can modify the UI, manage cookies, execute custom scripting and styling, and perform other functions described later herein. In one example, the UEM extension132can help facilitate communications between the management application120and components of the UEM system140to authenticate the user and verify the state of the user device110when the user attempts to access secure content through the browser130. For example, the UEM extension132can receive and interpret HTTP communications from servers and services in the UEM system140and pass corresponding information to the management application120, such as instructions and security tokens received through the browser130.

In an example, the UEM system140can include one or more content servers146that host content for an enterprise. Each content server146can provide a particular resource or application associated with the enterprise. Although the UEM system140can include multiple content servers146, for simplicity these servers are referred to as the content server146. The content server146can single server or a group of servers, including multiple servers implemented virtually across multiple computing platforms, including a cloud-based platform. In an example, if the content server146hosts secure content from the browser130, the content server146can be configured to redirect the browser130to an identity manager144. The identity manager144can be a server, or service on a server, that authenticates identities of entities attempting to access secure content. The identity manager144can verify credentials, generate and verify security tokens, and instruct other servers and devices when an entity can or cannot access portions of the UEM system140.

In an example, the UEM system140can include an ERE148that can further increase browsing security of enrolled user devices. The ERE148can collect various data points related to the user's browsing habits and the user device110and provide suggestions for browser extensions for improving and securing the user's Internet browsing. Some examples can include browsing patterns, the location of the user device110, any groups the user belongs to, extensions used by other users in the same group as the user, a risk profile associated with the user, and more. In one example, the management application120can collect and send data related to the user device110to the ERE148, and the UEM extension132and a forward proxy134can collect and send data related to the user's Internet browsing to the ERE148. The forward proxy134can execute as a proxy server on the user device110.

In some examples, the browser130can be a managed browser130. In other words, the managed browser can be provided by the UEM system140and allow an enterprise to control access and functionality of the browser130. If the browser is a managed browser130, then the browser130can be configured with the forward proxy134, and the forward proxy134can collect data on the user's browsing habits and send the data to the ERE148. On the other hand, if the browser130is unmanaged, then the browser130can include the UEM extension132, and the UEM extension132can collect the data and send it to the ERE148. The system illustrated inFIG.1shows a single browser130, as most users use a single browser on their user devices. References herein made to the unmanaged browser130or a browser130with the UEM extension132can be understood as referring to a web browser that is not managed by the UEM system140. Likewise, references herein made to the managed browser130or a browser with the forward proxy134can be understood as referring to a web browser that is managed by the UEM system140.

In an example, the ERE148can user various methods in identifying recommended browser extension. As some examples, the ERE148can recommend extensions based on policies, statistics, and the application of machine learning (“ML”) models. Some recommendations can be suggested to the user while other can be required. As an example, for a required extension, the management server142can instruct the managed browser130or UEM extension132to install the recommended extension. In one example, if the browser130does not have a certain recommended extension installed, the UEM extension132or managed browser130can deny the user access to any UEM related content. In one example, the ERE148can access an extension library150when identifying extensions to recommend. The extension library150can be an internal library within the UEM system140or from a third-party, depending on the example. Third-party extension libraries150can be associated with the browser being used on the user device110. For example, GOOGLE CHROME, MICROSOFT EDGE, APPLE SAFARI, and MOZILLA FIREFOX all have their own extension library for their corresponding browsers.

FIG.2is a flowchart of an example method for accessing secure content in the UEM system140from the unmanaged browser130. The unmanaged browser130in this example method can include the UEM extension132. At stage210, the user device110can send a request to the content server146. For example, the browser130can send an HTTP request to the content server146using a URL provided by the user. The content server146can be configured to respond to an HTTP request based on whether the browser130is managed or unmanaged. For example, if the content server146recognizes the browser130as a managed browser, then the content server146can allow the user to access the secure content. In one example where the browser130is a secure browser, the secure browser130can provide a security token and the content server146can verify with the identity manager144. In examples where the browser130is unmanaged, the content server146can be configured to redirect the browser130to the identity manager144for verification.

At stage220, the user device110can authenticate the user. For example, the content server146can respond to the browser130with a redirect URL that causes the browser130to send an HTTP request to the identity manager144. In an example, the identity manager144can respond by sending instructions to the browser130to prompt the user for authentication credentials. For example, the identity manager144can send an HTML file that causes the browser130to display a web page with a login prompt. The user can input his or her credentials, which the browser130can send to the identity manager144.

In an example, after authenticating the user, the identity manager144can retrieve policies from the management server142to determine whether the requested content requires additional verification. For example, the UEM system140can include multiple security levels for enterprise content. The UEM system140can allow access to some content based on the user providing accurate credentials. For more secure content, the UEM system140can require additional security measures, which is described in below.

In an example, the identity manager144can determine that access to the requested secure content require additional verification. In response, the identity manager144can generate a temporary security token (hereinafter referred to as a “temporary token”). The temporary token can be a time-based pseudorandom token that expires after a predetermined amount of time. For example, the temporary token can expire after 1 minute or 5 minutes so that the temporary token cannot be used on other attempts to access secure content. In one example, the identity manager can send the temporary token to the management server142. The management server142can use the temporary token to verify the user device110, which is described later herein.

In an example, the identity manager144can verify that the UEM extension132is installed on the browser130. If not, the identity manager144can deny the browser130access to the secure content. If the UEM extension132is present, the identity manager144can encrypt the temporary token and a UEM session token, and then transfer the two tokens to the UEM extension132. The UEM session token can be a security token generated in the UEM system140that the management application120can recognize and validate, thereby adding another layer of security. For example, the UEM session token can be created by the management server142and passed to the identity manager144. In one example, the management application130can be provided with a security key for decrypting the UEM session token during or after enrollment.

At stage230, the user device110can receive the UEM session token and temporary token from the identity manager144. In an example, the identity manager144can encrypt the tokens and send them to the browser130using an HTTP call. The tokens can be sent as one or more data files, such as an HTML or JavaScript Object Notation (“JSON”) file. In one example, the data file can include a flag value that causes the UEM extension132to handle the data file before any web page is rendered on the browser130. The UEM extension132can be configured with one or more security keys for decrypting the tokens. After receiving the response from the identity manager144, the UEM extension132can extract the tokens and decrypt them using the security keys. Alternatively, the UEM extension132can pass the encrypted tokens to the management application120, and the management application120can decrypt the tokens. In one example, the UEM extension132can also delete any HTML or JavaScript (“JS”) snippets in the response from the identity manager144that correspond to secure code.

At stage240, the user device110can validate the UEM session token. In an example, the UEM extension132can pass the tokens to the management application120for validation. In one example, the UEM extension143can pass the token to the management application120using deep linking, such as IOS UNIVERSAL LINKS or an intent URL on an ANDROID device. The management application120can then validate that the UEM session token came from a trusted source within the UEM system140.

In an example, the management application120prompt the user to enter a secure passcode on the user device110, such as an SSO, PIN, or PBE. If the user provides the correct passcode, the management application120can verify the security posture of the user device110. For example, the management application130can verify that the user device110complies with all the UEM policies required to access the secure content. In one example, the response from the identity manager144can include policies that the user device110must comply with, and the management application120can compare the security posture of the user device110to those policies. This can be a requirement from the UEM system140for accessing certain levels of secure content.

At stage250, the user device110can send the UEM session token, the temporary token, and a user session token to the management server142. In an example, the user session token can refer to a token provided by the management application120that is verifiable by the UEM system130. For example, the user session token can be provided to the management application120during or after enrollment from the management server142. In one example, the management application120can encrypt the tokens using a public key provided by the management server142. The management server142can decrypt the tokens using a corresponding private key. The management server142can verify that the UEM session token is the same token previously given to the identity manager144, that the user session token originated from a trusted user device, and that the temporary token received from the user device110matches the temporary token received from the identity manager144. In one example, the management server142can also verify that the temporary token has not expired.

In an example, the management application120can send information related to the device state of the user device110to the management server142. As an example, the device state information can include information about the user device's110compliance with UEM policies, the security status of the user device's110network connection, and so on. The management application120can verify that the user device110is compliant with access policies associated with the secure content. In one example, the management application120can also send information related to the browser130. For example, the UEM system140can restrict access to the secure content to web browsers that meet minimum qualifications. For example, the management server142can whitelist certain web browsers, blacklist certain web browsers, or block unknown browsers. In one example, the management server142can verify that the browser130meets certain version requirements. For example, for each known web browser, the UEM system140can designate a version or range of versions that can access the secure content. In on example, this information can be provided by an administrator (“admin”) using an admin console.

At stage260, the user device110can receive a redirect to the secure content from the identity manager144. For example, after verifying the state of the user device110and validating the tokens, the management server142can notify the identity manager144that the tokens were validated and that the user device110is compliant. In response, the identity manager144can authorize the user device110to access the secure content. The identity manager144can then send a redirect URL to the browser130that the browser130can use to access the secure content. In examples where the management server142cannot verify the tokens or the user device110is not compliant, the identity manager144can instead notify the user device110that access to the secure content has been denied. As an example, the identity manager144can send an HTML data file to the browser130that causes the browser130to display a web page informing the user that access has been denied.

FIG.3is a sequence diagram of an example method for accessing secure content from an unmanaged web browser130. The unmanaged browser130in this example method can include the UEM extension132. At stage302, the browser130can send a request for secure content to the content server146. For example, the browser130can send an HTTP request to the content server146using a URL provided by the user.

At stage304, the content server146can redirect the browser130to the identify manager144. In an example, the content server146can be configured to redirect HTTP requests from unmanaged browsers. In one example, the HTTP request can include information identifying the browser used to make the request. Alternatively, the content server146can respond to the browser130by requesting information about the browser130. In one example, the response can include a flag value that the UEM extension132can recognize. In response to the flag value, the UEM extension132can be configured to cause the browser130to send certain information about the browser130, such as the browser's name and version. In an example, in response to determining that the browser130is not managed by the UEM system140, the content server146can send a redirect URL that causes the browser130to send an HTTP request to the identity manager144.

At stage306, the identity manager144can instruct the browser130to prompt the user for credentials. For example, the identity manager144can send a HTML file that causes the browser130to display a web page with a login prompt. At stage308, the user can input credentials into the browser130, which the browser130can send to the identity manager144at stage310. In one example, the communications between the browser130and the identity manager144can be protected with end-to-end encryption.

At stage312, the identity manager144can authenticate the credentials. For example, the identity manager144can decrypt the credentials and compare them to a credentials database in the UEM system140that the identity manager144can access. If the credentials match, at stage314, the identity manager144can retrieve access policies associated with the secure content from the management server142. For example, the UEM system140can include multiple security levels for enterprise content. The UEM system140can allow access to some content based on the user providing accurate credentials. For more secure content, the UEM system140can require additional security measures, such as ensuring that the device posture of the requesting user device is compliant, allowing only certain versions of browsers, and utilizing the UEM extension132for token verification. In one example, the access policies can be specific to the user. For example, the access policies can indicate whether the user can access the secure content or whether the user can use the unsecured browser130to access the secure content. At stage316, the identity manager144can determine that access to the secure content requires additional verification. This can be based on the access policies, for example.

At stage318, the identity manager144can generate a temporary token. The temporary token can be a time-based pseudorandom token that expires after a predetermined amount of time so that the temporary token cannot be used on other attempts to access secure content. At stage320, the identity manager144can send the temporary token to the management server142.

At stage322, the management server142can send a UEM session token to the identity manager144. The UEM session token can be a security token generated in the management server142that the management application120can recognize and validate, thereby adding another layer of security. In one example, the management application130can be provided with a security key for decrypting the UEM session token during or after enrollment. As an example, each enrolled user device in the UEM system140can be configured with an encrypted key pair. Each enrolled user device can possess a private key and the UEM system140can store a copy of each corresponding public key. The UEM system can encrypt communications with each user device using their corresponding public key. In an example, the management server142can encrypt the UEM session key using the public key that corresponds to the user device110so that only the management application120on the user device110can decrypt the UEM session key.

At stage324, the identity manager144can send the UEM session token and the temporary token to the UEM extension132. In one example, the identity manager144can send the tokens to the browser130in an encrypted data file, such as an HTML or JSON file, that the browser130cannot decrypt. However, the UEM extension132can have the necessary key for decrypting the data file. In one example, the data file can include a flag value that can indicate to the UEM extension132that it should handle the data file.

At stage326, the UEM extension132can extract the tokens. For example, the UEM extension can extract the UEM session token and temporary token from the data file and delete any HTML or JS snippets in the data file that correspond to secure code. At stage328, the UEM extension132can decrypt the tokens, and, at stage330, the UEM extension132can send the decrypted tokens to the management application120.

At stage332, the management application120can validate the UEM session token. In one example, the UEM extension143can pass the token to the management application120using deep linking, such as IOS UNIVERSAL LINKS or an intent URL on an ANDROID device. The management application120can then validate that the UEM session token came from a trusted source within the UEM system140.

At stage334, the management application120can authenticate the user. For example, the management application120prompt the user to enter a secure passcode on the user device110, such as a SSO, PIN, or PINBE. In an example, if the user provides the correct passcode, then the management application120can verify the security posture of the user device110. For example, the management application130can verify that the user device110complies with all the UEM policies required to access the secure content. Such policies can be based on the user device's110compliance with UEM policies, and the security status of the user device's110network connection, for example. The UEM system140can also restrict access based on the unmanaged browser used and whether the unmanaged browser is an allowed version. For example, for each known unmanaged web browser, the UEM system140can designate a version or range of versions that can access the secure content. In one example, the data file from the identity manager144can include the policies that the user device110must comply with, and the management application120can compare the security posture of the user device110to those policies.

At stage336, the management application120can send the UEM session token, temporary token, and a user session token to the management server142. In an example, the user session token can refer to a token provided by the management application120that is verifiable by the UEM system130. For example, the user session token can be provided to the management application120during or after enrollment from the management server142. In one example, the management application120can encrypt the tokens using a public key provided by the management server142. The management server142can decrypt the tokens using a corresponding private key.

At stage338, the management server142can validate the tokens. For example, the management server142can verify that the UEM session token is the same token previously given to the identity manager144, that the user session token matches a user session token associated with the user device110, and that the temporary token received from the user device110matches the temporary token received from the identity manager144. In one example, the management server142can also verify that the temporary token has not expired.

At stage340, the management server142can verify the state of the user device110. In one example, the management application120can notify the management server142whether the device posture of the user device110is compliant with the access policies. This can be based on the analysis of the user device110state, for example. In an alternative example, the management application120can send information about the user device110posture and the management server142can make the determination of whether the user device110is compliant.

At stage342, the management server142can notify the identity manager144that the tokens and state of the user device110are verified. In response, at stage344, the identity manager144can authorize the browser130to access the secure content. Then, at stage346, the identity manager144can redirect the browser130to the secure content. For example, the identity manager144can send a redirect URL to the browser130that the browser130can use to access the secure content at stage348. In another example, the identity manager144can notify the content server146that the browser130is authorized to access the secure content. In one example, the identity manager144can send the temporary token to the content server146, and the browser130can access the secure content by sending the temporary token to the content server146.

FIG.4is a flowchart of an example method for installing a recommended browser extension. At stage410, the ERE148can receive browsing data related to the user and their browsing habits. In one example, the browsing data can include the types of websites the user tends to visit, particularly websites not associated with the enterprise. Some examples can include shopping sites, sports sites, social media sites, and any unsecure websites. In another example, the browsing data can include how many tabs the user tends to have open, which can waste a large portion of memory, such as RAM, on the user device110. In another example, the browsing data can include information related to the user's location and the types of networks the user device110connects to. This can include, for example, how often the user connects to internal networks of the UEM system140versus external networks and the security protocols used by the external networks. In another example, the browsing data can include information related to any groups in the enterprise that the user belongs to. For example, the ERE148can recommend browser extensions for certain groups. In another example, the browsing data can include a risk profile created for the user. In another example, the browsing data can identify UEM-managed applications that the user frequently uses.

The ERE148can receive the user browsing data from one or more sources associated with the UEM system140. For example, if the user uses a managed browser130, then the managed browser130can collect the data and send it to the ERE148. In another example where the user uses a managed browser130, then the forward proxy134configured on the managed browser130can collect the data. In an example where the user uses an unmanaged browser130, then the UEM extension132can gather the data. Some data associated with the user, such as designated groups and risk profiles, can be collected from a database or server in the UEM system140. In one example, data related to the user device's110location and network connections can be collected by the management application120.

At stage420, the ERE148can compare the browsing data to one or more policies. The policies can include a set of parameters for determining whether a browser extension should be recommended. Some examples of parameters can include a maximum number of tabs open on a browser, a maximum rate of visits to websites with trackers, and minimum security requirements for connections to public networks. The ERE148can compare the browsing data and policies in different ways, depending on the data. For example, some policies can require that a certain extension be installed for certain users, and the ERE148can simply compare the user to the policy and determine whether the required extension is installed. In another example, the ERE148can perform a statistical analysis on the browsing data. For example, the ERE148can determine how frequently a user visits a particular website or type of website, how many tabs the user typically has open in the browser130when the browser130is open, and a maximum the user connects using an unsecure network, and how much time the user spends using a particular web application. This statistical data can then be compared to the policies.

In an example, if the user browsing data satisfies the parameters of a policy, the ERE148can recommend a browser extension corresponding to the policy at stage430. Some policies can be based on the user's browsing history. In one example policy, if a user averages more than 3 tabs open in a web browser over a predetermined amount of time (e.g., a week or a month), then the ERE148can recommend a browser extension that reduces RAM utilization by unused tabs (e.g., TAB SUSPENDER). In another example policy, if the user regularly visits websites that are known for tracking users, such as shopping websites, then the ERE148can recommend an extension that prevents tracking (e.g., PRIVACY BADGER). In another example policy, if the user regularly visits websites known to have large amounts of advertisements, such as shopping sites, sports sites, and blogs, then the ERE148can recommend an extension that minimizes ads, thereby reducing bandwidth usage (e.g., ADBLOCK).

Some policies can be based on the user's location or the network that the user device110connects to. For example, the ERE148can create a risk profile from the browsing data based on factors like the physical location, the type of network the user device110connect to (e.g., open versus secure WI-FI and the type of security is used if connected to a secure network) and a risk level associated with the Internet Protocol (“IP”) address. The risk profile can be based on the user, the user device110, or both. In one example, the ERE148can retrieve a risk profile created by the UEM system140or provided by a third-party, such as CARBON BLACK. If the risk profile designates an elevated security risk based on the policy, then the ERE148can recommend an extension that can increase the security posture of the browser130(e.g., PRIVACY BADGER and HTTPS EVERYWHERE).

Some policies can be based on one or more groups in the enterprise that the user belongs to. In one example, groups can have their own policies related to browser extensions. As an example, users in a financial department can be required to extensions that add additional security to browsing and password protection (e.g., HTTPS EVERYWHERE and LASTPASS), and a sales department can require or recommend extensions for optimizing performance (e.g., TAB SUSPENDER). Some group-based recommendations can be based on extensions prominently used by other users belonging to a group. For example, the ERE148can identify any extensions used by a large portion of users in a group and recommend the extension to other members of that group.

Some policies can be based on frequently used web applications. For example, if a user frequently uses a particular web application, and that web application has a browser extension, then the ERE148can recommend that extension to the user. For example, ASANA is a project management web-based application that offers a browser extension called ASANA2GO. For a user that frequently uses ASANA, the ERE148can identify ASANA2GO as the corresponding extension and recommend it to the user.

In one example, the ERE148can recommend an extension based on other extensions used by the user. For example, if a user uses a particular set of extensions, the ERE148can compare that set to extensions used by other users. The ERE148can identify other extensions used by others that also use the set of the first user. If a threshold amount or percentage of the other users also use another extension, then the ERE148can recommend that extension to the user. As an example, the user can use the LASTPASS and HTTPS EVERYWHERE extensions. The ERE148can identify other users in the organization that also use LASTPASS and HTTPS EVERYWHERE and identify other extensions those users also use. In doing so, the ERE148can determine that most of those users also use the ADBLOCK extension, and so the ERE148can recommend the ADBLOCK extension to the user.

The ERE148can recommend internal extensions provided by the UEM system140, third-party extensions, or both, depending on the example. In one example, an admin can select which extensions that the ERE148can recommend. In another example, the ERE148can apply an ML model to identify extensions. For example, the ML model can be trained to analyze third-party extension libraries150and identify extensions that may be useful to users based on browsing data. The ML model can do this by analyzing descriptions of the extensions provided in the extension library150using natural language processing (“NLP”) techniques and mapping the descriptions to the user browsing data. In one example, if the ERE148identifies a new extension, the ERE148can notify an admin so that the admin can review the new extension and decided whether to approve it.

At stage440, the ERE148can cause the browser130to install the browser extension. In an example, this can depend on the policy. For example, a policy can designate a browser extension as optional or mandatory. For example, if a policy dictates that the extension is mandatory, then the UEM system140can push an install to the browser130. For example, if the browser130is a managed browser, then the managed browser130can be configured to allow for push installs of extensions. The UEM system140can send an install file of the corresponding extension to the managed browser130with instructions to install it. The UEM system140can also send instructions to prohibit use of the managed browser130if the extension is not installed. In one example, the management application120can receive the extension install file from the management server140, and the management application120can instruct the managed browser130to install the extension. In an example where the browser130is not managed, the UEM extension132can be responsible for installing a required extension and enforcing noncompliance.

In an example where the extension is designated as optional, the ERE148can merely recommend the extension to the user. For example, the ERE148can cause a notification, message, or email to be sent to the user device110that identifies the recommended extension and provides a brief explanation of why the extension is recommended. As an example, if the user frequently has a large number of tabs open on the browser130, then user can receive a message or notification that recommends the TAB SUSPENDER extension and explains that the extension will reduce memory usage and therefore increase the speed of the user device110.

FIG.5is a sequence diagram of an example method for installing a recommended browser extension based on user behavior. At stage502, the management application120can collect data related to the user device110. In an example, the data related to the user device110can include data related to device posture, network connections, and location. In one example, the network information can include information related to the user's location and the types of networks the user device110connects to. For example, the network information can include how often the user connects to internal networks of the UEM system140versus external networks and the security protocols used by the external networks.

In an example, the management application120can send the data to the management server142. For example, the management application120can compile the data as one or more data files, such as a JSON, Extensible Markup Language (“XML”), HTML, text, or other file type. The management application120can send the data file using a communication protocol like an HTTP or API call. Jumping ahead to stage508, the management server142can send the ERE148or grant the ERE148access to the data. In an alternative example, the management application120can send the data directly to the ERE148, thus negating the need for stage508.

At stage504, the UEM extension132can collect browsing data related to the user, and at stage506, the forward proxy134can collect browsing data related to the user. In an example, only one of stages504and506occurs. For example, for an unmanaged browser130, the UEM extension132can be installed thereon and collect the browsing data. Alternatively, for a managed browser130, the forward proxy134can collect the browsing data. Stages504and506can both occur in examples where the user uses both a managed and unmanaged browser130. For example, the user can use a managed browser130on one device and an unmanaged browser130on another.

Regardless of the browser configuration, the UEM extension132and forward proxy134can collect the same types of data and send the data to the management application120. Examples of data collected by the UEM extension132and forward proxy134can relate to the user's browsing habits, such as the types of websites the user tends to visit, how many tabs the user tends to have open, and so on.

In an example, the UEM extension132and forward proxy134can send the data to the management server142. For example, the UEM extension132and forward proxy134can compile the data as one or more data files, such as a JSON, Extensible Markup Language (“XML”), HTML, text, or other file type. The UEM extension132and forward proxy134can send the data file using a communication protocol like an HTTP or API call. At stage508, the management server142can send the ERE148or grant the ERE148access to the data. In an alternative example, the UEM extension132and forward proxy134can send the data directly to the ERE148, thus negating the need for stage508.

At stage510, the ERE148can compare the browsing data to extension policies. The way the ERE148compares the data can depend on the policy. For example, some policies can require that a certain extension be installed for certain users, and the ERE148can simply compare the user to the policy and determine whether the required extension is installed. For example, the ERE148can determine how frequently a user visits a particular website or type of website, how many tabs the user typically has open in the browser130when the browser130is open, how frequently the user connects using an unsecure network, and how much time the user spends using a particular web application. This statistical data can then be compared to the policies.

At stage512, the ERE148can identify an extension based on the policy parameters. For example, if the browsing data falls within the parameters of a policy, then the ERE148can identify the corresponding extension for recommendation. Some policies can be based on the user's browsing history. For example, a policy can include a parameter for a maximum number of tabs open in the browser130. For users that exceed the maximum number, the policy can designate a browser extension that limits the RAM utilized by unused tabs (e.g., TAB SUSPENDER). In another example, a policy can include a parameter for a maximum rate (i.e., number of visits to such websites over a period of time) at which a user visits websites that are known for tracking users, such as shopping websites. For users that exceed the maximum rate, the policy can designate an extension that prevents tracking (e.g., PRIVACY BADGER). In another example, a policy can include a parameter for a maximum rate at which a user visits websites known to have large amounts of advertisements, such as shopping sites, sports sites, and blogs. For users that exceed the maximum rate, the policy can designate an extension that minimizes ads, thereby reducing bandwidth usage (e.g., ADBLOCK).

Some policies can be based on the user's location or the network that the user device110connects to. For example, the ERE148can create a risk profile from the browsing data based on factors like the physical location, the type of network the user device110connect to (e.g., open versus secure WI-FI and the type of security is used if connected to a secure network) and a risk level associated with the Internet Protocol (“IP”) address. The risk profile can be based on the user, the user device110, or both. In one example, the ERE148can retrieve a risk profile created by the UEM system140or provided by a third-party, such as CARBON BLACK. If the risk profile designates an elevated security risk based on the policy, then the ERE148can recommend an extension that can increase the security posture of the browser130(e.g., PRIVACY BADGER and HTTPS EVERYWHERE).

Some policies can be based on one or more groups in the enterprise that the user belongs to. In one example, groups can have their own policies related to browser extensions. As an example, users in a financial department can be required to extensions that add additional security to browsing and password protection (e.g., HTTPS EVERYWHERE and LASTPASS), and a sales department can require or recommend extensions for optimizing performance (e.g., TAB SUSPENDER). Some group-based recommendations can be based on extensions prominently used by other users belonging to a group. For example, the ERE148can identify any extensions used by a large portion of users in a group and recommend the extension to other members of that group.

Some policies can be based on frequently used web applications. For example, if a user frequently uses a particular web application, and that web application has a browser extension, then the ERE148can recommend that extension to the user. For example, ASANA is a project management web-based application that offers a browser extension called ASANA2GO. For a user that frequently uses ASANA, the ERE148can identify ASANA2GO as the corresponding extension and recommend it to the user.

The ERE148can recommend internal extensions provided by the UEM system140, third-party extensions, or both, depending on the example. In one example, an admin can select which extensions that the ERE148can recommend. In another example, the ERE148can apply a ML model to identify extensions. For example, the ML model can be trained to analyze third-party extension libraries150and identify extensions that may be useful to users based on browsing data. The ML model can do this by analyzing descriptions of the extensions provided in the extension library150using NLP techniques and mapping the descriptions to the user browsing data. In one example, if the ERE148identifies a new extension, the ERE148can notify an admin so that the admin can review the new extension and decided whether to approve it.

At stage514, the ERE148can inform the management server142of an extension that should be installed on the browser130based on the comparison. In an example, the ERE148can also notify the management server142whether installation of the extension is required or optional. For example, if installation is optional, then the management server142can notify the user. For example, the management server142can send a notification, message, or email to the user device110that identifies the recommended extension and provides a brief explanation of why.

The remaining stages illustrate an example of when installation of the extension is required. At stage516, the management server142can send instructions to the UEM extension132for installing the extension. This stage can occur when the user device110includes an unmanaged browser130that has the UEM extension132installed. Alternatively, the management server142can send the instructions to the management application120, and the management application120can communicate with the UEM extension132to facilitate the installation of the extension. In examples where the browser130is managed, the management server142can send the instructions to the management application120, and the management application120can communicate with the managed browser130to facilitate installation of the extension.

In an example, the instructions can include an install for file for the extension and instructions to install it. Alternatively, the instructions can include a URL for the extension that the browser130can use to retrieve the install file. In one example, based on the corresponding policy, the management server142can also send instructions to prohibit use of the browser130if the extension is not installed.

At stage518, the UEM extension132or managed browser130, depending on the example, can request the extension from the extension library150. The extension library150can be internal to the UEM system140or a third-party, depending on the example. For example, GOOGLE CHROME, MICROSOFT EDGE, APPLE SAFARI, and MOZILLA FIREFOX all have their own extension library for their corresponding browsers. At stage520, the extension library150can send an installation file for the extension to the user device110.

At stage522, the user device110can install the extension. In examples where the browser130is unmanaged, the UEM extension can instruct the unmanaged browser130to install the extension. In examples where the browser130is managed, the managed browser130can install the extension based on the received instructions.

FIG.6is a sequence diagram of an example method for resource-specific policy enforcement using a managed extension with an unmanaged web browser. In addition to ensuring that particular extensions are installed on an unmanaged browser130, a managed extension can provide enhanced policy enforcement when a user attempts to access secure content with the browser130. For example, the management server142can enforce data loss prevention (“DLP”) policies by sending profiles and policies to a UEM extension132that includes capabilities for enforcing the policies on content accessed by the browser130. Such policy enforcement has previously required a managed browser or management application. But in situations where users wish to use the browser130and device of their choice to access secure enterprise content, the UEM extension132can allow for this needed policy enforcement.

While accessing secure resources, the UEM extension132can act as a gatekeeper. Users can first be required to install the UEM extension132, such as using the methods ofFIGS.4and5. The UEM extension132can then download user-specific and resource-specific profiles and compliance settings that get enforced at the browser during runtime. For example, an administrator can enable a copy and paste restriction for a particular webpage or enable a watermark for viewing the webpage. When the user attempts to access the webpage, the UEM extension132can intercept the content being loaded and apply these sorts of policies.

A detailed example is provided inFIG.6. At stage602, the browser130can request secure content from a content server146. The secure content can be an enterprise resource. The content server146can redirect the request for authentication purposes at stage604. For example, the content server146can begin a secure assertion markup language (“SAML”) assertion and forward the request to an identity manager144, like in stage304ofFIG.3. The identity manager144can then authenticate the user at stage612, such as by following stages306through312ofFIG.3. This can include asking for user authentication information, which the user or UEM extension132can provide, and verifying those credentials.

When the user is authenticated, the identity manager144can send the user's credentials to the management server142at stage616. At stage617, the management server142can then determine whether resource-specific policies exist for the secure content and whether user-specific policies exist for that user. Resource-specific policies can include specific restrictions for the secure content or types of secure content. These can include functional restrictions that disable regular features of the browser or user device, such as printing, copying, screen capturing, or using other types of applications such as email while the secure content is displayed. User-specific policies similarly can enable and disable particular features and applications based on the user or a group to which the user belongs. As an example, a CEO may have the ability to copy text from the secure resource whereas a mail clerk does not. Similarly, compliance policies, such as whether the device can be jailbroken, can be user-specific. The management server can store profiles specific to users, user groups, secure content, and content groups. The secure content or respective group can be identified by either a document identifier or a URL, in an example.

When any such policy exists, the management server142can generate and send an access token to the identity manager144at stage618or directly to the UEM extension132. The access token can allow the UEM extension132to communicate with the management server144for purposes of receiving the resource-specific and user-specific policies.

Stage618can include informing the identity manager144that user-specific or resource-specific profiles are found. In addition to the access token, the management server144can send a redirection URL for communicating with the UEM extension132. This can allow the UEM extension132to intercept communications to the browser and obtain the access token.

At stage619, the identity manager144can contact the browser130, with the UEM extension132intercepting the communication. The interception can occur before the secure content is loaded on the page. The UEM extension132can decrypt a portion of the response from the identity manager144and understand next actions to take. For example, an encrypted payload can identify that the management server142has policies for use by the UEM extension132. The UEM extension132can include certain certificates to decrypt the payload.

The UEM extension132can receive the redirect URL and the access token issued by the management server142. In one example, the redirect URL is used by the UEM extension to know where to contact the management server142at stage620. The UEM extension132can send the access token at stage621when contacting the management server142. The management server142can then validate the access token at stage622. For example, it can be compared against a paired version of the token that it kept, or information from the token can be used to look up the user profile.

At stage623, the management server142can provide one or more profiles to the UEM extension132. These profiles can include user-specific and resource-specific policies that exist for the user or secure content. The user-specific profile can have policies relating to the user, such as requiring that the user is enrolled in the UEM system in order to view content or geofencing properties that allow the user to access secure content from certain areas. The content-specific policies can be additional policies that relate to the particular content or type of content. The UEM extension132can then enforce the policies at the browser130at stage624. In one example, this can include enabling or disabling particular functionality or restricting particular application usage prior to receiving the secure content. In general, the UEM extension132can enforce the policies and ensure that the user device110and browser130are compliant with the policies as a condition to accessing the secure content.

After determining that the browser130and device110are compliant, at stage625the UEM extension can call back to the identify manager144or content server146. The URL extension can do this by utilizing a callback URL received from the identity manager144at stage619, in an example. Alternatively, the callback URL can be received from the management server142as part of the profile download. Calling back can cause the identity manager144to complete the SAML assertion with the content server146at stage626, authenticating the user with the content server146. At stage627, the content server146can then send the secure content to the UEM extension132or browser130. With the resource-specific and/or user-specific policies being enforced, the browser130can load the secure content.

FIG.7is a flowchart of an example method for resource-specific policy enforcement using a managed extension with an unmanaged web browser. Although a UEM extension132and UEM system140is discussed, the examples can apply to any type of managed extension and managed backend system. At stage710, the UEM system140can receive a request for secure content from a browser130on a user device110. The request can be sent to a content server146in one example. But the UEM system140can authenticate the user device110and ensure that the UEM extension132is enabled with the browser130making the request. For example, the UEM system140can follow the stages ofFIG.5starting at stage512to ensure that the UEM extension144gets installed. The request for secure content can be redirected for purposes of user authentication at the management server142.

At stage720, the UEM system140can identify a resource-specific policy for the secure content. This can occur at the management server142, such as after the request is redirected to the identity manager144or management server142. The resource-specific policy can include functional enhancements or limitations to be enforced at the user device110while the secure content is loaded. This can include disabling certain features for security reasons, such as email, copy functions, or screen captures. The policies can also add functional enhancements, such as checking for the user's facial identification in periodic intervals to ensure the user is still controlling the device110that is displaying secure content.

At stage730, the UEM system140can send a redirect URL and an access token to the UEM extension132. The redirect URL can allow the UEM extension to contact the management server144for purposes of retrieving the resource-specific policy, in an example. Alternatively, or in addition, the redirect URL can allow the UEM extension to call back to the identity manager144once the resource-specific and user-specific policies are being enforced at the browser130.

At stage740, the UEM system140can provide the resource-specific policy to the UEM extension132. This can be in response to receiving an access token that allows the management server142to validate the identity of the user or user device110and the validity of the UEM extension132. A user-specific policy can also be provided to the UEM extension132. One or more profiles with the policies can be provided as files or scripts that are executed by the UEM extension132to enforce the policies at the browser130.

With at least a portion of the policies enforced, at stage750the UEM system140can receive a call back from the UEM extension132at the redirect URL. In response, at stage760the UEM system140can send the secure content to the browser130for display in accordance with the enforced resource-specific policy. For example, the content server146can send the secure content to the UEM extension132. The UEM extension132can apply a policy by blocking display of portions of the secure content or by disabling particular functionality. Any such modifications are possible, depending on the policies, and can be applied prior to displaying the secure content on the browser130.

Other examples of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the examples disclosed herein. Though some of the described methods have been presented as a series of steps, it should be appreciated that one or more steps can occur simultaneously, in an overlapping fashion, or in a different order. The order of steps presented are only illustrative of the possibilities and those steps can be executed or performed in any suitable fashion. Moreover, the various features of the examples described here are not mutually exclusive. Rather any feature of any example described here can be incorporated into any other suitable example. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.