BACKGROUND

[0001] Managing user devices on a network often requires implementation of authentication mechanisms to authenticate users. Among other things, successful authentication may be used to trigger implementation of management policies that control how and whether a given user can access protected resources. In recent years, it has become more and more popular to have authentication and other management functions for end-user devices be facilitated via cloud-hosted platforms.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] FIG. 1 depicts an example computer system for managing user access to network resources.

[0003] FIG. 2 depicts an example of Remote Authentication Dial In User Service (RADIUS) payloads being selectively encapsulated within different types of messages/packets.

[0004] FIG. 3 depicts an example method of managing user access to network resources.

[0005] FIG. 4 depicts an example computer system that can be used to implement and/or carry out the user access management systems and methods described herein.

DETAILED DESCRIPTION

[0006] The present disclosure is directed to improved mechanisms for providing authentication for end-user computing devices that wish to access protected network resources. It is becoming more and more popular to manage such network devices from one or more servers hosted in a public cloud. One consideration when dealing with public cloud management is that it is often desirable to establish a lightweight, bi-directional, secure communication protocol that can traverse explicit and transparent proxies and go through firewalls with minimal or no changes to the local network on which the end-user devices reside. Furthermore, it can be a challenge to provide a secure user authentication method for network users, as in many cases the users of public cloud-managed devices are often lacking the experience and knowledge needed to set up the complex systems that are often necessary to provide secure user authentication and user account management. In particular, despite the move toward cloud management, many authentication solutions are implemented at least in part locally, i.e., on the local network on which the managed devices reside. One widely used and effective authentication system is Remote Authentication Dial In User Service (RADIUS). However, installing and configuring a RADIUS server typically requires detailed knowledge of RADIUS, which can make its implementation difficult and/or expensive for users of the local network, who typically have little or no RADIUS expertise.

[0007] Referring now to FIG. 1 , the figure shows an example computer system 100 and data flows for managing user access to network resources. System 100 includes a local network 102 having end-user devices (e.g., device 104) that go through an authentication process in order to access protected resources, which may be on local network 102 or externally located. In the depicted example, authentication is facilitated by an access point 106 on the local network and a cloud-hosted authentication system 108 that is external to the local network. In some examples, access point 106 may be a wireless access point (e.g., a router, gateway, etc. in a home or business) by which end- user devices access the Internet and other resources, though wired configurations are also possible.

[0008] Access point 106 may include an authenticator 1 10 and a local cloud agent 1 12. Authenticator 1 10 (alone or as part of access point 106), acts as a gatekeeper for user device 104, controlling its ability to access protected resources. In some examples, the depicted system is configured to provide authentication, accounting and other management via Extensible Authentication Protocol over LAN (EAPoL); Remote Authentication Dial In User Service (RADIUS); and WebSocket protocols. To that end, the various depicted components may include modules that interact using these protocols. For example, user device 104 may include an EAPoL client 1 14 that interacts via EAP frames with an EAPoL server 1 16 of authenticator 1 10; Authenticator 1 10 may include a RADIUS client 1 18 that interacts via RADIUS messages with a client-side authentication module 120 of local cloud agent 1 12; local cloud agent 1 12 may include a cloud-side authentication module 122 that interacts with components external to local network 102 by exchanging RADIUS payloads that are encapsulated within WebSocket packets.

[0009] Cloud-hosted authentication system 108 may include a remote cloud agent 124 and a RADIUS server 126. Remote cloud agent 124 may include a WebSocket module 128 that interacts via WebSocket messages with cloud-side authentication module 122 of local cloud agent 1 12. Remote cloud agent 124 may also include a RADIUS module 130 that interacts via RADIUS messaging with RADIUS server 126.

[0010] As used herein, "RADIUS messages" or "messaging" will frequently refer to requests, responses and/or other communications in which RADIUS payloads are encapsulated within EAPoL packets. Specifically, in some examples, EAPoL client 1 14 and EAPoL server 1 16 exchange RADIUS messages via sending and receiving EAPoL packets containing RADIUS payloads. EAPoL packets encapsulating RADIUS payloads may also be exchanged between RADIUS client 1 18 and client-side authentication module 120, and between RADIUS module 130 and RADIUS server 126. On the other hand, "WebSocket" messaging will often refer to communications in which RADIUS payloads are encapsulated within WebSocket packets. Local cloud agent 1 12 and remote cloud agent 124 may engage in such communications; specifically these components may exchange RADIUS payloads which are encapsulated within WebSocket packets.

[001 1] As described in more detail below, outbound authentication- related communication data flow may progress successively from EAPoL client 1 14 to the RADIUS server 126 through the EAPoL server 1 16, RADIUS client 1 18, local cloud agent 1 12 and remote cloud agent 124. This communication is conducted in such a manner that the local cloud agent 1 12 appears, from the perspective of the RADIUS client 1 18, as a RADIUS server. Inbound authentication-related data flow may in turn progress successively from RADIUS server 126 to the EAPoL client 1 14 through the remote cloud agent 124, local cloud agent 1 12, RADIUS client 1 18 and EAPoL server 1 16. This inbound communication may be conducted so that the remote cloud agent 124 appears, from the perspective of the RADIUS server 126, to be a RADIUS client. In other words, the local and remote cloud agents may operate more or less transparently from the perspective of the RADIUS client 1 18 and RADIUS server 126.

[0012] Specific data flow among the various components of system 100 will now be described. Authentication-related communication may commence first with a RADIUS messaging interaction between EAPoL client 1 14 and EAPoL server 1 16 of authenticator 1 10. The EAPoL client sends an EAPoL start message 140 to the EAPoL server, which responds with an identity request 142. The EAPoL client then sends identity information via response 144. This causes generation of a RADIUS access request, which is passed via various components and protocols, so that it eventually reaches RADIUS server 126. In particular, RADIUS access request 146 is passed from RADIUS client 1 18 to client-side authentication module 120 via RADIUS messaging; RADIUS access request 148 is passed from cloud-side authentication module 122 to WebSocket module 128 via RADIUS payload encapsulation within a WebSocket message; and RADIUS access request 150 is passed from RADIUS module 130 to RADIUS server 126 via RADIUS messaging.

[0013] RADIUS server 126 then consults a user database to identify the user and then issue a challenge to the user, e.g., a request for a username, password, credential, etc. Resultant challenge messages flow back to the user device 104 through the various depicted components and using different protocols. Specifically, RADIUS access challenge 152 is passed from RADIUS server 126 via RADIUS messaging to RADIUS module 130 of remote cloud agent 124; RADIUS access challenge 154 is passed from WebSocket module 128 to cloud-side authentication module 122 via encapsulating RADIUS payloads within WebSocket packets; RADIUS access challenge 156 is passed from client-side authentication module 120 to RADIUS client 1 18 via RADIUS messaging; and an EAP request 158 then reaches EAPoL client 1 14. The RADIUS challenge received by the user device 104 and EAPoL client 1 14 may be a request for additional information from the user, such as a secondary password, PIN, token, certificate, etc. The response is shown at 160, and the response is passed in the form of RADIUS messaging and WebSocket messaging that flows back to RADIUS server 126 (i.e., communications 162, 164 and 166, which are handled similarly to messages 146, 148 and 150). In some examples and as depicted, request 158 and response 160 may entail a one-time password (OTP) request and response.

[0014] RADIUS server 126 then analyzes the response to determine proper authentication. In the depicted example, authentication is successful, and a RADIUS access accept message is passed back to the EAPoL client on user device 104 (i.e., RADIUS access accept 168 using RADIUS messaging; RADIUS access accept 170 using RADIUS payloads encapsulated within WebSocket; RADIUS access accept 172 using RADIUS messaging; and finally an EAP success message 174). The user device is then able to access protected resources dependent upon the specific authorization policies associated with the user. In the event of a rejection, data flows and payload encapsulation would be similar to the messaging shown at 168, 170, 172 and 174.

[0015] From the above, it will be appreciated that instead of having a local, on-premises RADIUS server, authentication can be achieved by using local cloud agent 1 12 to delegate authentication for access requests to a cloud- hosted authentication system (e.g., system 108). The client-side authentication module 120 of local cloud agent 1 12 receives access requests (e.g., requests 146 and 162) initiated by a user device (e.g., device 104). The cloud-side authentication module 122 encapsulates the payload of the received access requests into an outbound WebSocket message (e.g., messages 148 and 164) to delegate authentication to cloud-hosted authentication system 108 by sending the outbound WebSocket message to the cloud-hosted authentication system 108. At the cloud-hosted authentication system, the remote cloud agent 124 receives the outbound WebSocket message, extracts the payload, and then passes the payload along to the RADIUS server in the form of RADIUS message (e.g., within an EAPoL packet).

[0016] FIG. 2 depicts an example of how cloud-side authentication module 122 may encapsulate payloads into WebSocket messages. FIG. 2 shows an example EAPoL packet 200. Packet 200 may correspond, for example, to the outbound RADIUS messaging shown at 144 and 146 in FIG. 1 , or 160 and 162 (e.g., outbound EAPoL packets). Cloud-side authentication module 122 of local cloud agent 1 12 may remove one or more headers from EAPoL packet 200 to strip them off of payload 202, which may be a RADIUS payload. Depicted example headers that may be removed are MAC header 204, IP header 206, and UDP header 208. Cloud-side authentication module 122 then encapsulates payload 202 into an outbound WebSocket message 210 with WebSocket header 212. The outbound WebSocket message 210 may correspond, for example to outbound WebSocket messages 148 and 164 of FIG. 1 .

[0017] The local cloud agent 1 12 can also perform the reverse process, i.e., receive a RADIUS payload encapsulated in WebSocket and then extract the payload and provide it to another component as a RADIUS message, for example in an EAPoL packet such as shown at 200. Specifically, as shown at 148 and 154 in FIG. 1 , the cloud-side authentication module 122 receives an inbound WebSocket message 154 in response to outbound WebSocket message 148, and constructs a RADIUS access response (i.e., a RADIUS challenge 156) based on the inbound WebSocket message. This response is then provided to RADIUS client 1 18. In this example, the local cloud agent is performing the opposite conversion, i.e., the RADIUS payload 202 is extracted from a WebSocket message and placed back into an EAPoL packet, such as packet 200.

[0018] Remote cloud agent 124 is similarly capable of performing conversions between RADIUS messaging and WebSocket messaging. In other words, the remote cloud agent can take a RADIUS payload encapsulated within an EAPoL packet and encapsulate it into a WebSocket packet, and vice versa. WebSocket module 128 handles receiving and transmitting WebSocket messaging, while RADIUS module 130 handles the EAPoL messaging. As a specific example from FIG. 1 , remote cloud agent 124 receives outbound WebSocket message 148, extracts the RADIUS payload from the message, and then provides the RADIUS payload to RADIUS server 126 in a RADIUS message 150 (i.e., EAPoL packet). The response 152 may be in the form of an EAPoL packet having a RADIUS payload. RADIUS module 130 and WebSocket module 128 then operate to extract the RADIUS payload and encapsulate it into a WebSocket packet (RADIUS access challenge 154).

[0019] It will thus be appreciated in the depicted example that the local cloud agent 1 12 and remote cloud agent 124 mirror one another, and the WebSocket channel enables them to communicate efficiently via a bidirectional, persistent and secure connection. In some settings, use of WebSocket messaging may advantageously facilitate traversal of various infrastructure 132 which may be internal or external to local network 102. Such infrastructure may include switches, routers, explicit and transparent proxies, firewalls and the like. In many cases, such components are implemented to allow passage of WebSocket traffic, for example because it may use standardized Internet Protocol ports such as port 80. These components therefore typically see WebSocket traffic as normal network traffic, so use of WebSocket allows the authentication methods discussed herein too often be deployed with little or no modification to infrastructure 132.

[0020] Local cloud agent 1 12 often will be deployed to listen on predefined RADIUS ports, such that for a given inbound communication originating from a user device, it implicitly knows the destination port. However the source port can vary from communication to communication. For example, though FIG. 1 shows only one user device, local network 102 includes many more user devices that may interact with access point 106 to become authenticated and access various network resources. Accordingly, local cloud agent 1 12 may include stored identifiers 134 associated with the authentication traffic it handles in order to match responses so that they are returned to the device making the request. For example, in connection with the WebSocket encapsulation of RADIUS access request 148, the local cloud agent 1 12 may store the source port so as to identify user device 104 as the source of the request. When the response is received (RADIUS access challenge 154) over the same WebSocket channel, the stored identifier is then used to match the challenge response with the access request, so that the challenge response gets routed back to user device 104, instead of to another device that may be interacting with access point 106. Stored identifiers 134 may be constructed as a lookup table or in any other appropriate structure. Still further, when the local cloud agent 1 12 receives a RADIUS payload from cloud-hosted authentication system 108, it can inspect the payload to assess the type of RADIUS message. For example in some cases, the payload relates to authentication, while in other cases the payload may relate to accounting. This type identification may also be used to route RADIUS payloads back to the appropriate source ports on processes running at authenticator 1 10 and/or user device 104.

[0021] The described system can provide a number of advantages. One benefit is that delegating RADIUS authentication to the cloud removes the need for a user to install, configure and maintain a RADIUS server on local network 102, which can be time-consuming and expensive, and require specialized information and expertise. Instead, the user could, for example, simply configure EAPoL clients 1 14 and/or authenticator 1 10 to use cloud-hosted authentication by checking a box or otherwise simply selecting an option for such authentication at a user interface. WebSocket encapsulation provides a lightweight, bi-directional channel that allows RADIUS payloads to be passed securely (e.g., using transport layer security (TLS) connections) to the cloud. In particular, the payloads are passed securely via the WebSocket channel to a cloud-hosted counterpart (remote cloud agent 124), which encapsulates the payloads back into EAPoL packets which are handled by the cloud-hosted RADIUS server.

[0022] Using the technology as described in the above examples may free the user from the need to consider firewalls, proxy servers or other restrictions that may be imposed on them by ISPs or network administrators. WebSocket packets are based on HTTP/HTTPS and use standard Web protocol ports (e.g., ports 80 and 443). Because of that, creating the WebSocket channel through which the RADIUS payloads are sent to the cloud is transparent to the users.

[0023] Turning now to FIG. 3, an example method 300 is depicted for managing user access to network resources. Method 300 may be implemented using one or more of the components shown in FIG. 1 , or may be implemented using other hardware and software configurations. Though there may be a practical ordering of certain steps in FIG. 3, the figure and its description does not require that the described steps be performed in a particular sequence. Different sequences may be employed for certain steps, and in some cases two or more steps may be performed simultaneously in parallel. Still further, other example implementations may include additional steps other than those that are described and depicted, and/or may omit one or more of the depicted/described steps.

[0024] Continuing with FIG. 3, at 302, method 300 includes deploying a local cloud agent on a local network to intercept Remote Authentication Dial In User Service (RADIUS) access requests initiated by user devices on the local network. At 304, the method includes receiving a RADIUS access request at the local cloud agent. In some implementations, the RADIUS access request may be received from a RADIUS client that is included in an authenticator on the local network, for example as shown at 1 10 in FIG. 1 . When so implemented, the authenticator may include an EAPoL server in communication with an EAPoL client running on the user device, where the RADIUS access request of step 304 is initiated in response to interaction between the EAPoL client and EAPoL server. Continuing with FIG. 3, at 306, the method 300 includes encapsulating a RADIUS payload of the RADIUS access request within an outbound WebSocket message. At 308, the method includes delegating authentication for the RADIUS access request to a cloud-hosted authentication system by sending the outbound WebSocket message to the cloud-hosted authentication system.

[0025] At 310, method 300 includes receiving the outbound WebSocket message at a remote cloud agent of the cloud-hosted authentication system. At 312, the method includes extracting the RADIUS payload from the outbound WebSocket message with the remote cloud agent. At 314, the method includes providing the RADIUS payload from the remote cloud agent to a RADIUS server of the cloud-hosted authentication system, where the remote cloud agent appears, from the perspective of the RADIUS server, as a RADIUS client.

[0026] Method 300 may further include (1 ) storing a source identifier associated with the RADIUS access request of 304; (2) receiving an inbound WebSocket message from the cloud-hosted authentication system in response to the outbound WebSocket message; (3) constructing a RADIUS access response based on the inbound WebSocket message; and (4) retrieving and using the source identifier to match the RADIUS access response with the RADIUS access request. This may be performed similarly as described with reference to stored identifiers 134 of FIG. 1 .

[0027] In some embodiments, the methods and processes described herein may be tied to a computing system of one or more computing devices. In particular, such methods and processes may be implemented as a computer- application program or service, an application-programming interface (API), a library, and/or other computer-program product.

[0028] FIG. 4 schematically shows a non-limiting embodiment of a computing system 400 that can enact one or more of the methods and processes described above. Computing system 400 is shown in simplified form. Computing system 400 may take the form of one or more personal computers, server computers, tablet computers, home-entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phone), and/or other computing devices. Referring back to FIG. 1 , the computing system 400 here described may correspond to and/or be used to implement aspects of user device 104, access point 106, authenticator 1 10, local cloud agent 1 12, remote cloud agent 124, and RADIUS server 126.

[0029] Computing system 400 includes a logic machine 402 and a storage machine 404. Computing system 400 may optionally include a display subsystem 406, input subsystem 408, communication subsystem 410, and/or other components not shown in FIG. 4. [0030] Logic machine 402 includes one or more physical devices configured to execute instructions. For example, the logic machine may be configured to execute instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement a data type, transform the state of one or more components, achieve a technical effect, or otherwise arrive at a desired result.

[0031] The logic machine may include one or more processors configured to execute software instructions. Additionally or alternatively, the logic machine may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. Processors of the logic machine may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel, and/or distributed processing. Individual components of the logic machine optionally may be distributed among two or more separate devices, which may be remotely located and/or configured for coordinated processing. Aspects of the logic machine may be virtualized and executed by remotely accessible, networked computing devices configured in a cloud-computing configuration.

[0032] Storage machine 404 includes one or more physical devices configured to hold instructions executable by the logic machine to implement the methods and processes described herein. When such methods and processes are implemented, the state of storage machine 404 may be transformed— e.g., to hold different data.

[0033] Storage machine 404 may include removable and/or built-in devices. Storage machine 404 may include optical memory (e.g., CD, DVD, HD- DVD, Blu-Ray Disc, etc.), semiconductor memory (e.g., RAM, EPROM, EEPROM, etc.), and/or magnetic memory (e.g., hard-disk drive, floppy-disk drive, tape drive, MRAM, etc.), among others. Storage machine 404 may include volatile, nonvolatile, dynamic, static, read/write, read-only, random- access, sequential-access, location-addressable, file-addressable, and/or content-addressable devices. [0034] It will be appreciated that storage machine 404 includes one or more physical devices. However, aspects of the instructions described herein alternatively may be propagated by a communication medium (e.g., an electromagnetic signal, an optical signal, etc.) that is not held by a physical device for a finite duration.

[0035] Aspects of logic machine 402 and storage machine 404 may be integrated together into one or more hardware-logic components. Such hardware-logic components may include field-programmable gate arrays (FPGAs), program- and application-specific integrated circuits (PASIC / ASICs), program- and application-specific standard products (PSSP / ASSPs), system- on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.

[0036] The terms "module," "program," and "engine" may be used to describe an aspect of computing system 400 implemented to perform a particular function. In some cases, a module, program, or engine may be instantiated via logic machine 402 executing instructions held by storage machine 404. It will be understood that different modules, programs, and/or engines may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same module, program, and/or engine may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms "module," "program," and "engine" may encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc.

[0037] It will be appreciated that a "service", as used herein, is an application program executable across multiple user sessions. A service may be available to one or more system components, programs, and/or other services. In some implementations, a service may run on one or more server- computing devices.

[0038] Referring again to FIG. 1 , logic and storage machines as described with reference to FIG. 4 may be implemented in connection with the components and functionality described with reference to FIG. 1 . Referring to local cloud agent 1 12, in one example, a processor executes instructions contained in a storage machine to handle conversions between RADIUS messages and WebSocket messages. Storage may be provided on the local cloud agent 1 12, or elsewhere on access point 106. In addition to or instead of software instructions executed by a processor, the local cloud agent may be implemented with hardware and/or firmware logic machines that carry out the functionality via hardware/firmware instructions. Remote cloud agent 124 may similarly be implemented via software instructions contained on a storage machine and executed by a logic machine (e.g., a processor), and/or by firmware/hardware logic. The functionality of the other components of FIG. 1 may similarly be implemented via executable software instructions, firmware logic machine instructions, and/or hardware logic machine instructions.

[0039] When included, display subsystem 406 may be used to present a visual representation of data held by storage machine 404. This visual representation may take the form of a graphical user interface (GUI). As the herein described methods and processes change the data held by the storage machine, and thus transform the state of the storage machine, the state of display subsystem 406 may likewise be transformed to visually represent changes in the underlying data. Display subsystem 406 may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with logic machine 402 and/or storage machine 404 in a shared enclosure, or such display devices may be peripheral display devices.

[0040] When included, input subsystem 408 may comprise or interface with one or more user-input devices such as a keyboard, mouse, touch screen, or game controller. In some embodiments, the input subsystem may comprise or interface with selected natural user input (NUI) componentry. Such componentry may be integrated or peripheral, and the transduction and/or processing of input actions may be handled on- or off-board. Example NUI componentry may include a microphone for speech and/or voice recognition; an infrared, color, stereoscopic, and/or depth camera for machine vision and/or gesture recognition; a head tracker, eye tracker, accelerometer, and/or gyroscope for motion detection and/or intent recognition; as well as electric-field sensing componentry for assessing brain activity.

[0041] When included, communication subsystem 410 may be configured to communicatively couple computing system 400 with one or more other computing devices. Communication subsystems may, for example, be used to enable communication between the devices of FIG. 1 , and may participate in the various described encapsulations of RADIUS payloads, such as within EAPoL packets and WebSocket packets. Communication subsystem 410 may include wired and/or wireless communication devices compatible with one or more different communication protocols. As non-limiting examples, the communication subsystem may be configured for communication via a wireless telephone network, or a wired or wireless local- or wide-area network. In some embodiments, the communication subsystem may allow computing system 410 to send and/or receive messages to and/or from other devices via a network such as the Internet.

[0042] It will be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated and/or described may be performed in the sequence illustrated and/or described, in other sequences, in parallel, or omitted. Likewise, the order of the above-described processes may be changed.

[0043] The subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.