Abstract:
A method and proxy device for securing an access to a cloud-based application are presented. The method includes receiving an authentication token, wherein the authentication token includes an identity of a user of a client device requesting an access to the cloud-based application; receiving, from an agent executed in the client device, a client certificate; retrieving, from a compliance server, a device posture of the client device, wherein the device posture is retrieved respective of the received client certificate; identifying an access policy for the client device to access the cloud-based application, wherein the access policy is identified based at least on the retrieved device posture; and determining whether to grant an access to the cloud-based application based in part on the compliance of the client device with the identified access policy.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. Provisional Application No. 62/163,623 filed on May 19, 2015, the contents of which are hereby incorporated by reference. 
     
    
     BACKGROUND 
       [0002]    In recent years more and more providers offer the ability to create computing environments in the cloud. For example, Amazon Web Services™ (also known as AWS) launched in 2006 a service that provides users with the ability to configure an entire environment tailored to an application executed over a cloud-computing platform. In general, such services allow for developing scalable applications in which computing resources are utilized to support efficient execution of the application. 
         [0003]    Organizations and businesses that develop, provide, or otherwise maintain cloud-based applications have become accustomed to relying on these services and implementing various types of environments, from complex websites to applications and services provided as software-as-a-service (SaaS) delivery model. Such services and applications are collectively referred to as “cloud-based applications.” 
         [0004]    Cloud-based applications are typically accessed by users using a client device via a web browser. Cloud-based applications include, among others, e-commerce applications, social media applications, enterprise applications, gaming applications, media sharing applications, storage applications, software development applications, and so on. Many individual users, businesses, and enterprises turn to cloud-based applications in lieu of “traditional” software applications that are locally installed and managed. For example, an enterprise can use Office® 365 online services for email accounts, rather than having an Exchange® Server maintained by the enterprise. 
         [0005]    As greater reliance is made on cloud-based applications, the access to such applications from a web browser must be completely secured. For example, for an e-commerce application executed in a cloud-based platform, any unauthorized access and/or data breach must be prevented. 
         [0006]    Providers of cloud computing platforms offer various security capabilities primary designed to protect their infrastructure against cyber-attacks (e.g., DoS, DDoS, etc.). However, cloud computing platforms are not designed to detect any unauthorized and/or unsecured access to cloud-based applications hosted therein. 
         [0007]    Most, if not all, cloud-based applications implement a native access control often limited to a username and password (also known as login information). More advanced solutions would require another layer of authentication using, for example, a software certificate and/or two-step authentication. However, the authentication solutions currently available are agnostic to the user&#39;s device. 
         [0008]    That is, a user can authenticate from any client device using the same credentials and have the same trust level and permission to a cloud-based application&#39;s functions regardless of whether the client device is being utilized to access the application. For example, a user can access the Office® 365 email account from his/her work computer and from his/her home computer using the same login information. 
         [0009]    As not all client devices are configured with the same security level, the existing solutions for gaining access to cloud-based applications impose significant vulnerabilities. Referring to the above example, the work computer may be fully secured, while the home computer may not have been installed with anti-malware software. As such, any access from the home computer to sensitive documents (e.g., emails) can be downloaded and distributed by malicious code that may exist in the home computer. 
         [0010]    In sum, conventional authentication solutions do not provide any application access control based on the security measures of client devices. Specifically, conventional authentication solutions do not distinguish between managed and unmanaged client devices attempting to access a cloud-based application. A managed device is typically secured by an IT personnel of an organization, while an unmanaged client device is not. Referring to the above example, the work computer is a managed device while the home computer is an unmanaged device. 
         [0011]    It would therefore be advantageous to provide a solution that overcomes the deficiencies noted above by providing secured access control to cloud-based applications. 
       SUMMARY 
       [0012]    This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed embodiments, nor is it intended to be used to limit the scope of the various claimed embodiments. Moreover, the sole purpose of this Summary is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later. For convenience, the term “some embodiments” or “various embodiments” may be used herein to refer to a single embodiment or multiple embodiments of the disclosure. 
         [0013]    Some embodiments disclosed herein include a method for securing an access to a cloud-based application. The method comprises receiving an authentication token, wherein the authentication token includes an identity of a user of a client device requesting an access to the cloud-based application; receiving, from an agent executed in the client device, a client certificate; retrieving, from a compliance server, a device posture of the client device, wherein the device posture is retrieved respective of the received client certificate; identifying an access policy for the client device to access the cloud-based application, wherein the access policy is identified based at least on the retrieved device posture; and determining whether to grant an access to the cloud-based application based in part on the compliance of the client device with the identified access policy. 
         [0014]    Some embodiments disclosed herein also include a proxy device for securing an access to a cloud-based application. The system comprises a processing system; and a memory, the memory containing instructions that, when executed by the processing system, configure the proxy device to: receive an authentication token, wherein the authentication token includes an identity of a user of a client device requesting an access to the cloud-based application; receive, from an agent executed in the client device, a client certificate; retrieve, from a compliance server, a device posture of the client device, wherein the device posture is retrieved respective of the received client certificate; identify an access policy for the client device to access the cloud-based application, wherein the access policy is identified based at least on the retrieved posture; and determine whether to grant an access to the cloud-based application based in part on the compliance of the client device with the identified access policy. 
         [0015]    Some embodiments disclosed herein also include a cloud computing platform comprising: at least one server configured to host at least one cloud-based application; a compliance server; a proxy device communicatively connected to the at least one server, wherein the proxy device includes a processing system and a memory; the memory containing instructions that, when executed by the processing system, configure the proxy device to: receive an authentication token, wherein the authentication token includes an identity of a user of a client device requesting an access to the cloud-based application; receive, from an agent executed in the client device, a client certificate; retrieve, from the compliance server, a device posture of the client device, wherein the device posture is retrieved respective of the received client certificate; identify an access policy for the client device to access the cloud-based application, wherein the access policy is identified based at least on the retrieved posture; and determine whether to grant an access to the cloud-based application based in part on the compliance of the client device with the identified access policy. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    The subject matter disclosed herein is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features and advantages of the disclosed embodiments will be apparent from the following detailed description taken in conjunction with the accompanying drawings. 
           [0017]      FIG. 1  is a network diagram utilized to describe the disclosed embodiments. 
           [0018]      FIG. 2  is a flowchart illustrating the operation of an authentication proxy according to one embodiment. 
           [0019]      FIG. 3  is a block diagram of the authentication proxy constructed according to one embodiment. 
           [0020]      FIG. 4  is a screenshot showing an access denied message generated according to an embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0021]    It is important to note that the embodiments disclosed herein are only examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claims. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views. 
         [0022]      FIG. 1  is an example network diagram of a communication system  100  utilized to describe the various disclosed embodiments. The system  100  includes a cloud computing platform  110  which may be a private cloud, a public cloud, or a hybrid cloud providing computing resources to applications or services executed therein. In the exemplary  FIG. 1 , a cloud-based application  115  is executed in the cloud computing platform  110 . As noted above, the cloud-based application  115  may include, among others, an e-commerce application, a collaboration application, an office and messaging application, a social media application, an enterprise application, a gaming application, a media sharing application, and the like. 
         [0023]    The communication system  100  further includes an authentication (auth.) proxy  120 , client devices  130 - 1  and  130 - 2 , a central authentication system  140 , and a compliance server  150  that are communicatively connected to a network  160 . The network  160  may be, for example, a wide area network (WAN), a local area network (LAN), the Internet, and the like. Each of the client devices  130 - 1  and  130 - 2  may include, for example, a personal computer, a laptop, a tablet computer, a smartphone, a wearable computing device, or any other computing device. In exemplary and non-limiting embodiment, the client device  130 - 1  is a managed device and the client device  130 - 2  is an unmanaged device. Both devices  130 - 1  and  130 - 2  belong to the same user. 
         [0024]    It should be noted that, although one cloud-based application  115  two client devices  130  are depicted in  FIG. 1  merely for the sake of simplicity, the embodiments disclosed herein can be applied to a plurality of client devices and cloud-based applications. 
         [0025]    In an embodiment, the central authentication system  140  may be realized as a federated identity management (FIdM) system, a single-sign-on (SSO) server, or the like. A FIdM system provides means for linking a person&#39;s electronic identity and attributes, stored across multiple distinct identity management systems. A SSO server typically ensures that when a user logs in to one application, the user will be signed in to every other application controlled by the SSO server, regardless of the platform, technology and domain. The central authentication system  140  can utilize a lightweight directory access protocol (LDAP) service, persistent cookies, and/or IdP provisioning. 
         [0026]    In an embodiment, a request to access the cloud-based application  115  is sent from any of the client devices  130  to the central authentication system  140  and authenticated by the authentication proxy  120 , as will be described in detail below. 
         [0027]    The compliance server  150  is configured to gather and maintain for each client device  130  a device posture. In an embodiment, the device posture characterizes at least the security capabilities that a client device  130  is configured with. The security capabilities can be related to hardware resources, software resources, and/or network resources of a client device  130 . In addition, the security capabilities may be related to a user and/or IT policies of the client device  130 . In one embodiment, the device posture includes a unique device certificate associated with the respective client device and a set of compliance parameters. The compliance parameters of each client device  130  are associated with a unique client certificate and can be stored locally in the compliance server  150  or in a database (not shown) connected to the server  150 . The gathering of compliance parameters is facilitated using an agent  131 . 
         [0028]    In an embodiment, the authentication proxy  120  can cause the compliance server  150  to install and execute the agent  131  over a client device  130 . The agent  131  is a piece of executable code downloaded from the compliance server  150  (or any other repository connected to the network  160 ). The agent  131  may be temporarily executed on a client device  130 , i.e., without any installation. Alternatively, installation and execution of the agent  131  in the background allows continuous monitoring of a respective client device  130 . That is, the agent  131  can operate and be implemented as a stand-alone program or, alternatively, can communicate and be integrated with other programs or applications executed in the client device  130 . Alternatively, the agent  131  can be implemented as a script executed over the client device  130 . 
         [0029]    The agent  131  is configured to scan the respective client device  130  and gather identifiers and security capabilities of the client device  130 . The client device&#39;s  130  identifiers include, for example, a type, a make, a model, an operating system, and so on. The security capabilities include, for example, whether the likes of any or all of hard-disk encryption, third-party security patches, anti-virus, malware protection, a network access control (NAC), a mobile device management (MDM), password protection, and firewall, are installed and operative in the client device  130 . The agent  131  can also determine if the client device  130  is a managed or unmanaged device. 
         [0030]    The compliance server  150  is configured to receive the information sent from each agent  131  and to generate the device posture respective thereof. That is, a device posture of a client device  130 - 1  characterizes the security capabilities that the client device  130 - 1  is configured with. As noted above, the device posture of a client device  130 - 1  may include a unique device certificate associated with the client device  130 - 1  and one or more compliance parameters gathered by the respective agent  131 . 
         [0031]    As a non-limiting example, the device posture of a client device  130 - 1  may be different from the device posture of the device  130 - 2  due to the fact that the former is a managed device and the latter is an unmanaged device. A managed device is typically secured by an IT personnel of an organization, while an unmanaged client device is not. Referring to the above example, the work computer is a managed device while the home computer is an unmanaged device. 
         [0032]    In certain exemplary embodiments, in addition to the information gathered by the agent  131  or in lieu of the agents, the device posture can be defined using parameters provided from, for example and without limitation, an end-point Data Loss Prevention (DLP) service, a network access control (NAC) device or service, a mobile device management (MDM) device or service, the central authentication system  140 , directory services, and so on. 
         [0033]    In an embodiment, a device posture includes at least one compliance parameter indicating a general compliance status of device and a set of compliance parameters indicating a compliance status of each security capability. The general compliance status may be set to “non-compliant” if one or more of the other security capabilities are determined to be “non-compliant” as well. Each compliance parameter may be categorized as critical or not critical. The device posture can further define, for each compliance parameter, the reason for non-compliance. 
         [0034]    The compliance parameters indicating a compliance status of each security capability may include, for example, a status of anti-virus software installed in the device (or the existence or lack thereof); a status of malware software installed in the device (or the existence or lack thereof); a status of encryption software installed in the device (or the existence or lack thereof); a status of a public file sharing configuration; a status of encryption anti-phishing software installed in the device (or the existence or lack thereof); a status of the most recent operating system update; a status of a firewall installed in the device (or the existence or lack thereof); a status of each IM application installed in the device (or the existence or lack thereof); a status of backup software installed in the device (or the existence thereof); a status of each remote access application installed in the device (or existence thereof); and so on. 
         [0035]    Each compliance parameter may be categorized as critical or not critical. The device posture can further define for each compliance parameter the reason for not being compliant, the vendor to the resource, and the name and version of the resource. For example, the antivirus compliance parameter may include the following information: 
         [0036]    Compliance Parameter: “Antivirus”;
       Critical: yes   vendor: “Microsoft Corporation”;   name: “Windows Defender”:   version: “6.1.7600.16385”;   status: Not an approved antivirus product   compliant: No       
 
         [0043]    The device posture may include a number of “critical issues” identified in the device. The device posture may also include a general information about the device, such a MAC address, IP address(es), OS version, a type of the device (desktop, laptop, managed, unmanaged), an available password protection means; a current geographic location, and so on. 
         [0044]    In order to retrieve the device posture, the authentication server  120  is configured to query the compliance server  150  using a predefined application programming interface (API). In one example, the compliance server  150  is queries through an API, with the client certificate in order to return the posture of the respective device. In another example, the compliance server  150  is queries through an API, with the client certificate and authentication server in order to return the posture of the respective device. 
         [0045]    According to the disclosed embodiments, access to the cloud-based application  115  or any of its components is controlled and enforced by the authentication proxy  120 . The authentication proxy  120  is configured to support any token-based authentication protocol. Such protocols include, but are not limited to, WS-Federation®, security assertion markup language (SAML), WS-TRUST, and the like. 
         [0046]    In an embodiment, the authentication proxy  120  is configured to determine whether or not to allow a client device  130 - 1  or  130 - 2  access to the cloud-based application  115 . Such determination is based, in part, on a compliance with a predefined access policy. In one embodiment, the access decision is based at least on device attributes included in the access policy and a definition of a security compliance with the client device  130 . Other attributes, discussed below, are also considered by the authentication proxy  120 . 
         [0047]    The authentication proxy  120  is further configured to determine a trust level of the client device  130  as well as functions and/or components of the cloud-based application  115  that the client device  130  can perform or access. In another embodiment, the authentication proxy  120  is further configured to provide a user of the client device  130  with actions that should be taken (e.g., install anti-virus software) in order to gain access to the cloud-based application  115 . 
         [0048]    An access policy can be defined for a specific user, a group of users, a specific role (e.g., administrator), a device type (e.g., managed/unmanaged), a schedule (e.g., weekends), a cloud-based application  115 , any combination thereof, and so on. For example, different access policies may be defined for users of a finance department and users of a HR department of an enterprise. 
         [0049]    In an embodiment, an access policy defines a plurality of attributes and policy actions. The policy actions are, for example, allow full access, block access, and allow limited access. Limited access functionality includes, for example, block native client devices, restrict access to certain components of the cloud-based application  115 , and allow the restricted functionality of the cloud-based application  115  (e.g., view only mode, disable download of documents, etc.). In one configuration, the limited access can be contingent upon actions taken by the user, for example, a self-registration, a two-step authentication, running a software update, installing a security patch, and so on. In an embodiment, the limited access actions are controlled by the authentication proxy  120 . This is achieved, for example, by redirecting an active session between the cloud-based application and client device, through the proxy  120 . 
         [0050]    The access policy attributes are categorized by one or more of the following groups: a user, a client device, and a location. The user attributes include a user identify (e.g., a username), a user group (e.g., HR department), and a user account history. The user account history is defined respective of past user activities (typically, suspicious and/or malicious activities) associated with the user account. The client device attributes include a client certificate and compliance parameters, such as those gathered by the compliance server  150 . 
         [0051]    The client device attributes may also include a device history and a device posture. The device history is defined respective of past user activities performed from a client device  130 . In an embodiment, the access policies can be defined by IT personnel of the enterprise, for example, through a web-portal provided by the authentication proxy  120 . The location attributes include risky, known, and/or reliable locations of the client devices  130  determined by their IP addresses. 
         [0052]    In an embodiment, the decision to allow access to the cloud-based application  115  and/or any of its components may be based on any of the attributes defined in the access policy. In a preferred embodiment, at least one of the device attributes as defined in the access policy should be met in order to permit access. 
         [0053]    As an example, if the access policy defines as a part of the device attributes that only managed devices can access the cloud-based application  115  and only the client device  130 - 1  is a managed device, then an access is granted to only the client device  130 - 1 . The information of whether a device is managed or unmanaged is retrieved from the compliance server  150 . 
         [0054]    According to the disclosed embodiments, in order to access the cloud-based application  115 , a client device, e.g., the device  130 - 1 , by means of its web browser, receives a login webpage of the cloud-based application  115 . Then, the client device  130 - 1  is directed to the central authentication system  140 . 
         [0055]    When the user successfully authenticates to the central authentication system  140 , an authentication token is transferred from the central authentication system  140  to the authentication proxy  120 . In one implementation, the central authentication system  140  is configured to cause redirection of the client device&#39;s  130 - 1  browser to the authentication proxy  120 . 
         [0056]    Upon receiving the authentication token, the authentication proxy  120  is configured to check if the agent  131  is installed in the client device  130 - 1 . In an embodiment, the authentication proxy  120  is further configured to check if a valid client certificate resides in the client device  130 - 1 . As noted above, the client certificate is a unique identifier of each client device. 
         [0057]    In an embodiment, if the client device  130 - 1  does not include an installed agent  131 , the authentication proxy  120  is configured to cause the execution of an agent on the device  130 - 1 . According to some embodiments, the authentication proxy  120  is configured to direct the client device&#39;s  130 - 1  browser (not shown) to the compliance server  150  that would provide the various options for installing and/or running the agent  131  on the client device  130 - 1 . If the user opted not to run the agent  131 , access to the cloud-based application  115  can be determined based on other attributes defined the access profile (e.g., location, device history, etc.). 
         [0058]    As discussed above, the agent  131 , once executed, is configured to scan the client device  130 - 1  and to provide a set of compliance parameters to the server  150 . In an embodiment, once the scanning of the agent  131  is completed, the client device&#39;s  130 - 1  browser is directed again to the authentication proxy  120 , this time with the client certificate saved in the client device  130 - 1  during the execution of the agent  131 . The authentication proxy  120  is further configured to query the compliance server  150  using the client certificate to retrieve at least the device posture. 
         [0059]    Then, an access policy utilized for the client device  130 - 1  is identified. The authentication proxy  120  is configured with a plurality of access policies (per users, group of users, schedule, etc.). The access policy to be evaluated and analyzed is identified based on, for example, a username (or any other user identifier, such as an email, a telephone number, etc.), user&#39;s group or department, time, application being accessed, and so on. Such information can be obtained from, for example, the central authentication system  140 , directory services (e.g., LDAP), and so on. 
         [0060]    Upon identification of the access policy utilized for the client device  130 - 1 , the authentication proxy  120  is configured to check for satisfaction of any attribute (or condition) defined in the identified access policy. Respective of the checks and the policy actions, the authentication proxy  120  is configured to determine whether to allow a full access, a limited access, or block any access to the cloud-based application  115 . The limited access actions are controlled by the proxy  120 . This is achieved, for example, by redirecting an active session between the cloud-based application and client device, through the proxy  120 . 
         [0061]    In an embodiment, the satisfaction checks are performed using information generated by the authentication proxy  120  or received from other systems, such as the central authentication system  140  and the compliance server  150 , external reputation services, LDAP services, and so on. 
         [0062]    Following are non-limiting examples demonstrating the satisfaction checks, in which the user identity is checked against information included in the authentication token. The user group attribute may be evaluated based on group information received from an LDAP directory, active directory, and user groups and roles defined in the cloud-based application  115 . 
         [0063]    The device attributes are evaluated based on the device posture retrieved from the compliance server  150 , while the device identity and user history are evaluated by the authentication proxy  120 . For example, the authentication proxy  120  can track past user activities performed from the client device  130 - 1  and compare those past user activities to conditions defined in the access policy. Such conditions include, for example, a number of past security incidents, access from suspicious locations, and so on. 
         [0064]    To determine satisfaction of the location attributes, the authentication proxy  120  is configured to track risky IP addresses, known IP addresses, known office locations, VPN IP addresses, ISPs, and so on. In an embodiment, the authentication proxy  120  is also configured to learn the user past activities to determine known locations of the user (e.g., a home location, a bus terminal from which the user commutes, etc.). In an embodiment, the authentication proxy  120  may consult reputation services to determine if a location is a “risky location”. 
         [0065]    The determined locations are matched against the location attributes defined in the policy. Such attributes can be simply defined as “user accessing from a location never visited by anyone in the company”, “user accessing from an unrevealed location”, “user accessing from home”, a specific IP address or addresses, specific countries, and so on. 
         [0066]    It should be noted that not all attributes need to be evaluated and only a sub-set of attributes or conditions can be evaluated prior to deciding on the policy action to be taken. For example, upon determination that the client device  130 - 2  is unmanaged, access to the application can be blocked. It should be further noted that the policy action can be determined based on satisfaction of any combination of attributes. As an example, if the client device  130 - 1 , which is a managed device, will comply with the user and device attributes. However, if the client device  130 - 1  accesses the cloud-based application  115  from an unknown location, the policy action may be a two-step authentication (in which a passcode is sent to the user through a secondary channel). In an embodiment, any access policy includes at least the device attributes. 
         [0067]    The above embodiments are described with reference to the client device  130 - 1  merely for the sake of simplicity. The same authentication process may be performed for each client device regardless of whether the device is managed or unmanaged. For unmanaged devices, the access to the cloud-based application  115  may be restricted. 
         [0068]    As an example, if the device posture of the client device  130 - 2  would indicate that the operating system is not installed with the latest security update, then an access to the cloud-based application  115  may be permitted only if a software update takes place. As another example, if the device posture of the client device  130 - 2  would indicate that the hard disk is not encrypted, then an access to the cloud-based application  115  would be limited to viewing, but not downloading, documents. As yet another example, if the device posture of the client device  130 - 2  would indicate that the client device  130 - 2  is not password protected, then an access to the cloud-based application  115  would be blocked. 
         [0069]    In an embodiment, if the access to the cloud-based application  115  is denied, a message is generated by the proxy  120  and displayed over the client device  130 . The message may identify the reason for denying the access and remedial actions to be taken by the user (e.g. an administrator) of the client device. The message may be generated in part based on information contained in the client device  130 . 
         [0070]      FIG. 4  shows an example screenshot  400  of an “access denied message” displayed over the client device  130 . As demonstrated in  FIG. 4 , access was denied because the antivirus software is out of date and the disk is not encrypted. The remedial actions (in blocks  410 ) suggest updating the antivirus file and encrypting the disk. 
         [0071]    It should be understood that the embodiments disclosed herein are not limited to the specific architecture illustrated in  FIG. 1  and other architectures may be equally used without departing from the scope of the disclosed embodiments. Specifically, the authentication proxy  120  may reside in the cloud computing platform  110 , a different cloud computing platform, or a connectable datacenter. Moreover, in an embodiment, there may be a plurality of authentication proxies  120  operating as described hereinabove and configured to either have one as a standby proxy to take control in a case of failure, to share the load between them, or to split the functions between them. Furthermore, without departing from the scope of the disclosed embodiments, various functions of the compliance server  150  may be implemented by the authentication proxy  120 . 
         [0072]      FIG. 2  depicts an example flowchart  200  illustrating the operation of the authentication proxy  120  for controlling and enforcing access to a cloud-based application according to one embodiment. 
         [0073]    At S 210 , an authentication token is received. In an embodiment, the authentication token includes the identity of a user of a client device accessing the cloud-based application. The authentication token may be provided by a central authentication system (e.g. the system  140 ,  FIG. 1 ). 
         [0074]    At S 220 , it is checked whether an agent is installed in the client device and, if so, execution continues with S 240 ; otherwise, execution continues with S 230 . In an example embodiment, the check whether the agent is installed is performed respective of an existence of a valid client certificate. Prior to execution of the agent, it is checked whether the client device includes a valid state cookie (or any other type of data structure). The state cookie maintains compliance parameters recently gathered by an agent. The state cookie is valid for a predefined time interval (e.g., 3 days). 
         [0075]    At S 230 , execution of the agent in the client device is enabled. In an embodiment, S 230  may include causing installation of the agent in the client device. 
         [0076]    At S 240 , a client certificate associated with the client device is received. Such a certificate was either previously created by an agent already installed in the device or by agent that was executed on the client device in response to S 230 . 
         [0077]    At S 250 , at least the device posture is retrieved. In an embodiment, the device posture is retrieved from a compliance server using the received client certificate and/or authentication token. In an optional embodiment, if the valid state cookie exists in the client device, information is retrieved directly from the client device. Thus, the compliance server may not be required and, accordingly, may not be queried. Various examples for the contents of a device posture are provided above. 
         [0078]    At S 260 , an access policy for controlling an access of the client device to the cloud-based application is identified. The access policy is identified based on, for example, a user unique identifier, user&#39;s group or department, time, application being accessed, and so on. 
         [0079]    At S 270 , the attributes and/or conditions defined in the identified access policy are evaluated to determine if one or more of the attributes (or conditions) are satisfied. The satisfaction checks are performed using information generated by the authentication proxy  120  or received from other systems, such as the central authentication system  140  and the compliance server  150 , external reputation services, LDAP services, and so on. 
         [0080]    At S 280 , respective of the met or unmet attributes (or conditions) the policy action defined in the identified access policy is performed. Various embodiments and examples for performing S 260 , S 270  and S 280  are discussed in greater detail above. 
         [0081]    The operation of the authentication proxy  120  has been described herein with a reference to a specific embodiment, where an identity of a client device is validated based on a client certificate. It should be noted that the other device validation mechanisms can be utilized as well without compromising the operation of the proxy  120 . For example, a persistent cookie can be utilized instead of the client certificate. 
         [0082]    In an embodiment, an advanced validation mechanism based on registering web-based protocol handlers is disclosed. In this embodiment, a browser of a client device  130  initiates a protocol handler call with a unique session identifier (ID). The protocol handler sends the authentication proxy  120  a coupling between the device ID and the session ID. Such coupling allows the web browser to uniquely identify the client device  130 . 
         [0083]    In another embodiment, detection techniques to prevent reuse of device IDs are disclosed. In this embodiment, a state with a counter value is stored on the client device  130 . At every login to the cloud-based application  115 , the counter value is increased. When two or more client devices  130  with the same device ID attempt to access the cloud-based application  115 , the state will be out of synchronization and the breach will be immediately detected. 
         [0084]      FIG. 3  shows an example block diagram of the authentication proxy  120  constructed according to one embodiment. The authentication proxy  120  may be deployed in cloud-computing platforms, data centers, or as a stand-alone network device. The authentication proxy  120  is configured to at least control and enforce access to cloud-based applications based on access policies described in greater detail above. The authentication proxy  120  includes a processing system  310  coupled to a memory  315 , an application-level access controller  320 , a storage  330 , and a network interface  340 . 
         [0085]    The processing system  310  may be realized by one or more hardware logic components and circuits. For example, and without limitation, illustrative types of hardware logic components that can be used include Field Programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components that can perform calculations or other manipulations of information. The memory  315  may be volatile (e.g., RAM, etc.), non-volatile (e.g., ROM, flash memory, etc.), or a combination thereof. 
         [0086]    The storage  330  may be magnetic storage, optical storage, and the like and may be realized, for example, as flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information. 
         [0087]    In one configuration, computer readable instructions to implement one or more embodiments disclosed herein may be stored in the storage  330 . The storage  330  may also store other computer readable instructions to implement an operating system, an application program, and the like. Computer readable instructions may be loaded in the memory  315  for execution by the processing system  310 . The storage  330  is configured to store, for example, access policies, client certificates, authentication tokens, device postures of client devices, device history, user account history, and other information that can be for authentication. 
         [0088]    In another embodiment, the storage  330  and/or memory  315  are configured to store software. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the one or more processors, cause the processing system  310  to perform the various functions described herein. 
         [0089]    The network interface  340  allows the authentication proxy  120  to communicate with other external devices. For example, the interface  340  is configured to allow the proxy  120  to communicate with the central authentication system, the cloud computing platform, the compliance server, and/or client devices over a network. In an embodiment, the network interface  340  allows remote access to the authentication proxy  120  for the purpose of, for example, configuration, reporting, etc. Such a connection, in an embodiment, can be realized through a web portal. The network interface  340  may include a wired connection or a wireless connection. The network interface  340  may transmit and/or receive communication media. For example, the network interface  340  may include a modem, a network interface card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, and the like. 
         [0090]    The application-level access controller  320  is configured to retrieve information required to determine if the attributes and conditions defined in the access policies are met. Such information can be retrieved from the network interface  340  via the central authentication system, the compliance server, and/or other external systems. 
         [0091]    The controller  320  is further configured, upon receiving a request to access a cloud-based application, to identify at least one access policy. The request may comprise an authentication token. The access control module  320  is further configured to execute a policy action respective of the identified access policy analysis. The operation of the access control module  320  is discussed in greater detail above with reference to  FIG. 2 . 
         [0092]    In an embodiment, the application-level access controller  320  can be realized by one or more hardware logic components and circuits. For example, and without limitation, illustrative types of hardware logic components that can be used include FPGAs, ASICs, ASSPs, SOCs, CPLDs, general-purpose microprocessors, DSPs, and the like, or any other hardware logic components that can perform calculations or other manipulations of information. 
         [0093]    The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal. 
         [0094]    All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the disclosed embodiments and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.