Cloud-controlled role management for Wi-Fi

Abstract

A system (300) comprising: a processor (402); and a memory (404) that is operationally connected to the processor (402), wherein the memory (404) contains instructions which, when executed, cause the processor (402) to: receive a request for a user role configuration for a user device (300Q, 300R, 300S, 300T) associated with the network device (302X, 302Y) from a network device (302X, 302Y), wherein the request is received after the network device (302X, 302Y) has authenticated the user device (300Q, 300R, 300S, 300T) and after the user device (300Q, 300R, 300S, 300T) has been placed in a locked state; authenticate the user role configuration request; after authentication, send the request to the network device (302X, 302Y) respond with the requested user role configuration;and to distribute the user role configuration to another network device (302X, 302Y) adjacent to the requesting network device (302X, 302Y), the other device being identified as a neighbor based on the ability of the network device (302X, 302Y) to decode transmissions destined for the other network device (302X, 302Y), and the user device (300Q, 300R, 300S, 300T) being placed in an unlocked state based on the response with the requested user role configuration.

Description

background

[0001] Wireless networks allow wireless devices, such as certain smartphones, laptops, tablets, or other compatible computing devices, to exchange data with other wired or wireless devices. In some wireless networks, a wireless device can access a wired portion of the network through one or more access points. These access points may be designed to communicate with wireless devices on one or more radio frequencies, depending on the capabilities of the network equipment or other factors. List of characters

[0002] The present revelation is described in detail in accordance with one or more different examples, with reference to the following figures. The figures serve only for illustration and represent only typical or exemplary examples. Fig. Figure 1 shows an example network in which examples of the technology disclosed here can be applied. Fig. Figure 2 shows an example of how to configure a user role. Fig. Figure 3 shows an example implementation of a cloud-based role service in accordance with some examples. Fig. 4A is a block diagram of example computer components or devices for cloud-controlled user role management according to some examples. Fig. 4B is a block diagram of example computer components or devices for cloud-controlled user role management according to some examples. Fig. 5 is an example of a computer component that can be used to implement various features of the examples described in the present disclosure.

[0003] The figures are not exhaustive and do not limit the present revelation to the exact form that is disclosed. Detailed description

[0004] A user role can refer to a policy container or a rule / set of rules that can be managed on a network device. A user role can be used to apply traffic policies to user traffic or communication passing through one or more network devices. Given the exponential increase in user devices and network connectivity, traditional user role configuration models cannot scale to handle this growth.

[0005] Traditional user role configuration models, such as the "static" user role configuration model, may be suitable for a limited number of user roles defined within a network, for example, up to 32 user role configurations. However, the static user role configuration model is incapable of managing more than this. Therefore, another user role configuration model, known as the "dynamic" user role configuration model, can be used to define a set of dynamic user roles in addition to the static user roles mentioned above. Dynamic user roles can be downloaded to a network device, such as an access point (AP), to be applied to a specific client as needed.

[0006] Despite the advantages of dynamic user roles, distributing them to other access points (APs), such as other APs in the same AP cluster or branch office, requires broadcasting these roles, which can be an unreliable method for distributing information. Furthermore, broadcasting mechanisms typically fail when attempting to distribute information across different virtual local area networks (VLANs) of the AP management system.

[0007] Accordingly, examples in this disclosure are aimed at configuring dynamic user roles that can be managed and distributed by a cloud-based user role service, enabling the distribution of dynamic user roles in a more scalable manner than previously possible. In particular, dynamic user roles can be configured using the aforementioned user role service. For example, the user roles and the policies applicable to each user role can be defined.

[0008] In some implementations of the disclosed technology, a user device may be authenticated and assigned a user role upon connecting to an access point (AP), even though the AP may not yet know the user role configuration. Therefore, the AP may request the user role configuration from the cloud-based user role service. During this period, the user device may be placed in a blocked state. If the AP sends a valid request, the requested user role configuration / details can be returned to the AP, the AP can unblock the user device, and the user role configuration can be applied to the device. If the request is invalid, for example, if the requested user role configuration is not applicable to the AP, the download request may be rejected by the cloud-based user role service.In some examples, a rejection reason code may be displayed in response to the request. If the user role configuration request has timed out or is rejected for any reason, the user device may remain blocked, and no further traffic / communication to / from the user device may be permitted.

[0009] The cloud-based user role service can also distribute the same user role configuration or user role details to all neighboring access points (APs). This allows a user device to move, roam, or otherwise connect to a different AP that, after distribution, already has the (dynamic) user role configuration that can be applied to the user device.

[0010] Before describing examples of the disclosed systems and methods in detail, it is useful to describe an example of a deployment network in which the disclosed systems and methods could be implemented in various applications. Fig. Figure 1 shows an example of a network 100 that includes a multi-AP micro-branch. In this example, the network 100 can include a data center 102 to which the multi-AP micro-branch 130 is operationally connected. Part of the network 100 can also be a deployment system, such as a cloud-based zero-touch deployment system / service 114.

[0011] Data center 102 can represent a corporate headquarters. Data center 102 can include a controller or core switch 104, to which a DHCP server 106 and a policy management platform 108 are operationally connected. Depending on how a connection between data center 102 and a remote branch office (in this example, the micro branch office 130) is implemented, the functionality of the controller or core switch 104 can vary. For example, network 100 can be a Layer 3 routed VLAN. In this case, a VPN concentrator can send traffic streams to a core switch, such as core switch 104, which can be a high-speed core switch. Core switch 104 can then forward the packets of the data streams to the required downstream hop.In another example, network 100 can be a Layer 2 connected VLAN, and the VPN concentrator can forward generic routing encapsulation packets (GRE) (see below) to a controller, e.g., controller or core switch 104, which can act as a controller in this case.

[0012] As experts know, a DHCP server (106) can refer to a network element that dynamically assigns an IP address and / or other network parameters to each device on the network. A policy management platform (108) can be implemented to securely and properly connect devices, such as client devices, to a network, for example, network 100. For instance, a policy management platform (108) can integrate new devices, grant different access levels to the network, maintain network security, and so on.

[0013] As in Fig. As further shown in Figure 1, data center 102 can be connected to microbranch 130 via an overlay tunnel 116. The overlay tunnel 116 can connect the root AP 132 of microbranch 130 to a headend gateway 110, which can act as a VPN concentrator and overlay terminator (e.g., using a GRE tunneling protocol) for terminating VPN tunnels (here, overlay tunnel 116), thus enabling routing from microbranch 130 to data center 102. The leaf APs 134A-134C can be operationally connected to the root AP 132, through which the connection to data center 102 can be established. The microbranch 130 can contain one or more client devices, e.g., For example, client devices 138A-C, each of which can be directly connected to the root AP 132 or one of the APs 134A-134C. In this example, the microbranch 130 can also include an unmanaged switch 136 to which additional client devices, e.g.,The client devices can be connected to the 138D-E. Client devices can include computer devices such as laptops, PCs, tablet computers, smartphones, and the like, as well as sensors or other IoT devices.

[0014] As previously mentioned, user roles can refer to policy containers / rule sets that are used to apply traffic policies to user traffic on a network device, such as an access point (AP). Multiple rule entries can be defined within a user role. In some examples, each rule or rule entry specifies a particular traffic policy. An example rule might be: "Allow" a specific data flow, "Deny" a specific data flow, or "Prioritize" a specific data flow. User role configuration can be complex depending on a customer's requirements.

[0015] In Fig. Figure 2 shows an example of a User Role Configuration 200. As can be seen, User Role Configuration 200 comprises a variety of rules to be applied to traffic to / from a user device to which User Role Configuration 200 is applied. User roles can be applied to individual users or groups of users. In some implementations, a JavaScript Object Notation (JSON) / ProtoBuf / Extensible Markup Language (XML) block can contain a set of firewall rules. Once an access point (AP) receives the block, it can decode its contents to identify the firewall rules. For example, the rule "rule any any match udp 67 68 permit" might allow a user / client device to obtain IP addresses from a DHCP server.The rule "rule any any match udp 53 53 src-nat vlan 901", for example, allows access to a DNS (Domain Name System) server, but specifies that DNS queries should be translated via NAT (Source Network Address Translation) into the IP address of the access point on VLAN 901. This means that the translated source IP address of a packet is used to allow hosts with private IP addresses to access a public network. Other rules, such as "rule rule any any match webcategory * deny", are used to block access to websites with inappropriate content. It should be understood that... Fig. 2 merely represents an example of a user role configuration with sample rules / settings / parameters and that other rules / user rule configurations are possible and are considered within the scope of this disclosure.

[0016] As previously mentioned, the traditional static user role configuration model or scheme can be used when customers have a limited number of user roles on the network. For example, an access point, such as an Instant AP (IAP), can support up to 32 user role configurations. However, the variety and number of end-user devices continues to increase, as devices such as IoT devices connect over a Wi-Fi edge network, and hotspots / operators can offload related functions to a Wi-Fi edge network. As mentioned, traditional, static user role configuration models / schemes can no longer be used when the number of user roles exceeds the maximum allowed number. The examples listed can enable users to securely connect their devices via access points.

[0017] Dynamic user roles can be used when the need for user roles exceeds the limitations of traditional static user role configuration models. When dynamic user roles are used, and an access point comes online, the access point can still obtain static user roles from one or more configuration management servers. If a client / user device connects to the AP at a later time, that client / user device can obtain a user role that is not included in the static configuration. The access point can then dynamically download the contents of this dynamic user role and apply it to the client / user device. The access point can subsequently distribute the contents of the dynamic user role to other access points in the same AP cluster.When a user device moves to a new access point, the new access point can apply the appropriate user role without needing to contact the configuration management server(s) mentioned above again. Specifically, dynamic user role content (user role configuration) can be transferred to an AP controller, such as a virtual AP controller. The virtual AP controller can then redistribute the role content to the other AP cluster members (e.g., APs within the same AP management VLAN). The AP can also distribute the dynamic user role configuration to other APs. Therefore, a centralized virtual control instance may be required (which can hinder upward scaling).Here too, there are only two methods for distributing user role configurations: sending them to other APs in the same VLAN and using a virtual controller that must maintain an AP "database" of the APs in the cluster (which, as described here, complicates scaling). Furthermore, in some examples, dynamic user role configurations cannot be distributed to APs belonging to a different AP cluster / management VLAN. Accordingly, distributing dynamic role configurations via an AP sending the dynamic user role configurations may limit distribution to network devices within the same VLAN. Alternatively, dynamic user roles can be sent to a virtual AP controller, and the virtual AP controller can then distribute the dynamic user role configuration to other APs, but scaling with such a mechanism may be limited.

[0018] Disclosed examples include a cloud-based user role service that addresses the scalability-related shortcomings of traditional / conventional user role configuration models. This means the examples no longer require the use of a central or primary access point (AP). Instead, all APs can be treated logically equally through the cloud-based user role service, which facilitates the management and distribution of dynamic user roles.

[0019] Fig. Figure 3 shows a schematic diagram of a System 300 in accordance with one or more examples. As in Fig. As shown in Figure 3, the System 300 can include the following: user devices, for example, User Device 300Q, User Device 300R, User Device 300S, User Device 300T; network devices, for example, Network Device 302X, Network Device 302Y; a Network 304; a Policy Manager 306; and a Data Store 308. Each of these components is explained below with the help of one or more examples.

[0020] In some examples, a user device, such as User Device 300Q, User Device 300R, User Device 300S, or User Device 300T, can be a hardware component that receives communication from another user device in the system and / or sends communication to another user device in the system. The communication can be sent or received in one or more messages. When the user device receives a message, it can be referred to as the message destination. When a user device sends a message, it can be referred to as the message source. The communication might, for example, be a request for or response to one or more services from another user device.

[0021] In one or more examples, a user device, such as User Device 300Q, User Device 300R, User Device 300S, User Device 300T, can be one or more mobile user devices (e.g., laptop computer, smartphone, personal digital assistant, tablet computer, or other mobile user device), a game console, a desktop computer, a server, blades in a server chassis, or any other type of electronic user device or devices that contain at least the minimum processing power, memory, and input / output device(s) to run one or more examples, such as sensors, IoT devices, and the like. The user device can, for example, include one or more hardware processors, associated memory (e.g., RAM, cache memory, flash memory, etc.), one or more storage user devices (e.g., a hard drive, an optical drive such as a CD drive or DVD drive, a flash memory stick, etc.).) and numerous other elements and functionalities. The hardware processor(s) can be an integrated circuit for processing instructions. The hardware processor(s) can be, for example, one or more cores or microcores of a processor. The user device can also include one or more input devices, such as a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, or any other type of input device. Furthermore, the user device can include one or more output devices, such as a screen (e.g., a liquid crystal display (LCD), plasma display, touchscreen, cathode ray tube monitor, projector, or other display device), a printer, external storage, or other output device. One or more of the output devices can be the same as or different from the input device(s).The input and output device(s) can be connected locally or remotely (e.g., via a network) to the hardware processor(s), memory, and memory user device(s). There are many different types of user devices, and the input and output device(s) mentioned above can also take other forms.

[0022] The user device can be connected to a network 304 via a network interface connection (not shown) and a network device, such as network device 302X or network device 302Y. Network 304 can be a local area network (LAN), a wide area network (WAN) such as the internet, a cellular network, or another type of network, or a combination of networks. Furthermore, the different user devices can be in the same Internet Protocol (IP) subnet or in different IP subnets. For example, two or more user devices can be in the same virtual local area network (VLAN).

[0023] A network device, such as network device 302X or network device 302Y, can be a digital hardware user device that can communicate with network 304. For example, a user device can communicate directly, either wired or wirelessly, with a single access point (AP), which can communicate directly with a single controller, which in turn can be connected to the network (e.g., network 304). In this example, the network device can be the AP, the controller, an AP with controller functionality, a switch (e.g., a mobility access switch), or another such user device. Furthermore, one network device can be a controller, while another network device can be an AP. The network device that is the AP in this example may or may not be connected to the network via the network device that is a controller.

[0024] An access point (AP) can be a separate hardware unit from a user device that is directly connected to the user device, for example, via a wired or wireless connection, and is located in a communication path from the user device to the network. In other words, the AP can be directly connected to a network interface card on the user device (e.g., user device 300Q, user device 300R, user device 300S, user device 300T) via a wired / wireless connection. Furthermore, APs can be directly connected to the 304 network or connected to the 304 network via a controller. The AP can, for example, be a wireless access point (WAP) that communicates wirelessly with user devices using Wi-Fi, Bluetooth, or related standards and is connected to a wired network.

[0025] Each network device can be connected to any number of user devices at any given time. Specifically, each network device can be connected to no user devices, a single user device, or multiple user devices at any given time. Furthermore, the number of user devices connected to a network device can vary among network devices; that is, network devices can be connected to different numbers of user devices.

[0026] In one or more examples, a network device can be configured to decide whether a user device is allowed to communicate with another user device in the system. The network device making the decision can be the network device associated with the source of the message and / or the network device associated with the destination of the message.

[0027] Continuing from Fig. 3. Network devices, such as network device 302X and network device 302Y, can be connected continuously or intermittently, directly or over the network, to a policy manager 306. The policy manager 306 can correspond to or run on a computer system and can cause the computer system to manage user device records, such as user device record 310Q (corresponding to user device 300Q) and user device record 310T (corresponding to user device 300T), and user role records, such as user role record 312M and user role record 312N. Specifically, the policy manager 306 can include a user interface that allows an administrator to create, configure, modify, and delete user device records and user role records. The policy manager 306 can also include functions for updating the user device records and user role records accordingly.

[0028] The computer system of Policy Manager 306 can be one or more mobile user devices (e.g., laptops, smartphones, personal digital assistants, tablet computers, or other mobile user devices), desktop computers, servers, blades in a server chassis, or any other type of computer user device or devices that have at least a minimum of processing power, memory, and input / output device(s) to perform one or more examples. There are many different types of computer systems, and the input / output device(s) mentioned above can take different forms. Furthermore, one or more elements of the computer system can be located remotely and connected to the other elements via a network.

[0029] As mentioned above, examples of the disclosed technologies may include a cloud-based user role service through which user role configurations can be maintained and retrieved. Accordingly, the 306 policy manager may be embodied in / as part of a cloud-based 330 user role service, which may be operationally connected to the 304 network. In some examples, the 306 policy manager may be implemented as a standalone / separate component that a remotely deployed cloud-based 330 user role service can access. As in Fig. As shown in Figure 3, the policy manager 306 can be part of the user role service 330 or implemented separately. In either case, the cloud-based user role service can provide improved scalability (with a larger number of user devices) and the ability to access and deploy dynamic user role configurations for network devices. This contrasts with broadcasting, for example, where in a large VLAN, broadcast messages would need to be sent to all VLAN members for every user role update / download. When using a virtual controller, the cost of maintaining AP membership can increase with the number of APs, and currently, for example, an Instant AP cluster can only support 128 APs per cluster, limiting scalability.This means that access to cloud-based user roles is not limited by the maximum number of supported APs and / or restrictions on updating / downloading user roles.

[0030] In some examples, dynamic user roles can be configured using Policy Manager 306 versus the cloud-based User Role Service 330. For example, a network administrator or similar entity can define the dynamic user roles, the policies according to which the dynamic user roles should be applied, and the actual dynamic user role configurations (which are explained in more detail below). Once a user device, such as User Device 300Q, connects to an access point, such as a Network Device 302X, the User Device 300Q can be authenticated. User device authentication can be based on credentials such as a username and password, a device certificate, or a device MAC address, etc. The Network Device 302X, which may be an access point, can securely forward the credentials to a backend authentication server, such as a web server.A RADIUS server (Remote Authentication Dial-in User Service) is used to authenticate the user's device. Other authentication methods or means can also be used, such as multi-factor authentication.

[0031] If user device 300Q is authenticated, network device 302X can assign a user role to user device 300Q. It should be understood that assigning a user role to user device 300Q does not yet involve parsing and applying the actual user role configuration to user device 300Q's communication. Rather, network device 302X can request the actual user role configuration, embodied as a user role record, from user role service 330 to policy manager 306.

[0032] User Role Service 330 can determine whether a user role configuration request is valid. Determining the validity of a user role configuration request can involve identifying the source of the request and whether that source is authorized to receive the requested user role configuration. For example, User Role Service 300 can determine whether the user role configuration request originates from a valid network device or a valid WLAN Service Set Identifier (SSID). This means that a particular dynamic user role can be selectively enabled only for specific access points or SSIDs. If the request is valid, the network device 302 can submit the requested user role configuration in the form of a user role record (for example, as a file or a datastore record from datastore 308, as explained below).If the request is not valid, the user role service 330 may reject it, and in some cases, a rejection reason code or similar notification may be sent to the requesting network device, user device, user, etc. For example, if an access point has requested a role that is not yet known / configured in the cloud-based user role service, a rejection reason code such as "unknown role" may be sent.

[0033] User role service 330 can also transmit or distribute the user role configuration / user role record to neighboring APs or, in some examples, to all neighboring APs of the requesting AP. In this example, network device 302Y can be a neighboring AP to network device 302X. While network device 302X waits to receive the user role configuration from user role service 330, it can place user device 300Q into a temporary lock state. Once network device 302X receives the requested user role configuration, it can unlock user device 300Q and apply the user role configuration to user device 300Q.It should be understood that once the user role configuration is applied, all traffic to / from user device 302X is regulated / controlled / restricted in accordance with the user role configuration, for example, in accordance with the defined user role relationships specified in the user role configuration / data record. In some examples where the request is rejected, user device 300Q may remain in its blocked state in addition to rejecting the request (and in some examples, sending a rejection reason code or similar notification to user device 300Q). This can prevent further traffic from being sent to / received from user device 300Q. It should be clear that in some examples, the rejection reason code / notification may be sent by user role service 330.

[0034] Considering that network device 302X distributes a requested user role configuration to neighboring network devices, such as network device 302Y, network device 302Y can apply the user role configuration to user device 300Q if user device 300Q were to connect / roam to network device 302Y. For example, network device 302Y does not need to contact or access user role service 330 or any other network device. It is understood that an access point, such as network device 302Y, can maintain a list of user device records containing corresponding user IDs (e.g., MAC addresses) and user role IDs, as described here. The dynamic user role configuration can also be maintained as a set of user role records (e.g., user role record 312N), each containing a user role identifier (e.g.,The user role ID (322) and rules associated with that user role (e.g., defined user role relationships 324) are stored in the user role cache table. The access point (AP) can first determine if the rooted user device's entry exists in the user device record cache table and, if so, assign the user role ID to the user. It's important to understand that the user device record cache table can contain a list of user device entries related to user devices currently connected to an AP. Each user device entry contains at least some Layer 2 / Layer 3 attributes, such as the device's Media Access Control (MAC) address, Internet Protocol (IP) address, Virtual Local Area Network (VLAN) ID, access control list (ACL) role, and so on. The access control service can then look up the user role cache table for that role ID and retrieve the user role configuration.

[0035] The policy manager 306 can be associated with a data store 308. In one or more examples, the data store 308 is any type of storage unit and / or user device (for example, a file system, a database, a collection of tables, or some other storage mechanism) used to store data. Furthermore, the data store 308 can include multiple different storage units and / or user devices. These multiple storage units and / or user devices can be of the same type or located in the same physical location. Additionally, the data store can be located on or running on the same computer system as the policy manager 306. Alternatively, or in addition, the data store 308 can be located on a separate computer system.

[0036] The data store 308 can be configured to store user device records, e.g., user device record 310Q, user device record 310T, for each user device connected to a network device, e.g., network device 302X, network device 302Y. A user device record, e.g., user device record 310Q, user device record 310T, can contain information about a user device. Any mechanism can be used to store a user device record without this exceeding the scope of the claims. In particular, a user device record can be a file, a database record, an entry or row in a table, or another data structure.

[0037] Fig. Figure 3 shows an example of a user device record, user device record 310Q. As in Fig. As shown in Figure 3, the user device record 310Q can, for example, contain a user device address 314 and a user identifier 315, according to one or more examples. A user device address 314 can be a unique identifier for a user device. The user device address can be, for example, a MAC (Media Access Control) address, a serial number of the user device, or another unique identifier of the user device.

[0038] A user ID 315 can be a unique identifier of a user who owns or otherwise controls the user device. The user ID can be a single identifier (e.g., tax ID number, login name, email address, a system-assigned unique identifier) ​​or a combination of identifiers (e.g., a combination of postal address and name, a combination of name and date of birth, or another combination).

[0039] In one or more examples, the data store also includes functions for storing user records, e.g., user record 311W, user record 311V. Each user record can contain a user profile. In one or more examples, the user profile corresponds to information about a user of one or more user devices. Fig. Figure 3 shows an example of a user record, for example, user record 311W. As shown in the example, user record 311W can contain a user identifier 318 and a user role identifier 320. The user identifier 318 can be a cross-reference to the user identifier 315 in the device record. Therefore, the user identifier can be the same as, or similar to, the user identifier described above.

[0040] In one or more examples, a user role identifier, such as user role identifier 320, can be an identifier of the user's role. A user role can be a logical classification of a user that defines the role the user plays within a group or a specific activity. For example, the user role can be the user's job title, the department the user works in, a project the user works on, an organization the user belongs to, or any other classification of the user. The term "user role," as used in this application, excludes media access control addresses and Internet Protocol addresses of user devices.

[0041] Although Fig. While section 3 shows a user record containing only one user role identifier, the user record can contain multiple user role identifiers if a user has multiple user roles. Data repository 308 can also store information that defines a hierarchy of user roles. The hierarchy can establish a ranking of user roles with respect to whether communication is permitted. User roles can thus be accessed according to the hierarchy to determine whether a specific communication is allowed. If the user role does not allow communication, the next user role is accessed according to one or more examples.

[0042] Data repository 308 can also include functions for storing user role records (e.g., user role record 312M, user role record 312N) for each defined user role in the system. As described in Fig. As shown in Figure 3, the user role record 312N contains a user role identifier 322 and a set of defined user role relationships 324. The user role identifier 322 can be a cross-reference to the user role identifier 320, which is part of a user device record.

[0043] The set of defined user role relationships (324), which are associated with a specific user role, can determine whether communication between user devices of users with that specific user role is permitted. In some examples, the defined user role relationships can be defined before the message to be allowed or denied is sent. In some examples, the defined user role relationships for a specific user role can be maintained as a group of user roles with which the specific user role is allowed to communicate, as a group of user roles with which the specific user role is not allowed to communicate, or as a combination of both. Additionally, one or more default user role relationships can be defined that specify a default action if a user role relationship is not defined in the set of user role relationships (not shown).

[0044] In one or more examples, the set of user role relationships can include separate user role relationships for different stages of communication. A stage of communication can refer to the temporal position of a communication within the overall communication session. For example, a user role relationship can exist when a first specific user role initiates communication with a second specific user role. Another user role relationship can exist when the first specific user role responds to communication from the second specific user role. A third user role relationship can exist when the first specific user role has already established communication with the second specific user role.A communication session can refer to a data record whose key consists of five attributes: source IP, destination IP, protocol (TCP / UDP), source port and destination port, and whose value is the "action" performed by an access control system, e.g., allow / deny / translate source IP / destination IP, etc.

[0045] In one or more examples, the set of user role relationships can contain separate user role relationships for different types of communication. A communication type can refer to the type of data transmitted in the communication. For example, there can be separate user role relationships for voice data, video data, background data, and best-effort data.

[0046] In one or more examples, individual user role relationships can be defined for a collection of user roles. For instance, one user role relationship can be defined if the user(s) corresponding to the source and / or destination of a communication have a first collection of user roles, while another user role relationship can be defined if the user(s) corresponding to the source and / or destination have a second collection of user roles. In this example, the first and second collections of user roles may or may not overlap.

[0047] Several techniques can be used to store user role relationships. For example, user role relationships can be stored as access control lists, in a set of one or more tables, or using another storage mechanism for permissions. Furthermore, it shows Fig. 3. This is only one possible storage structure for storing data records in the data storage. Other storage structures can also be used without this deviating from the scope of the claims.

[0048] Fig. Figure 3 shows one configuration of components, but other configurations can also be used without deviating from the scope of the claims. For example, different components can be combined into a single component. Another example is that the functionality performed by a single component can be performed by two or more components.

[0049] Fig. 4A is a block diagram of an example computer component or device 400 for performing cloud-orchestrated user role management according to an example. The computer component 400 could be, for example, a controller, a processor, or another similar computer component capable of processing data, such as an access point or access point controller. In the example implementation of Fig. 4A comprises the computer component 400, a hardware processor 402, and a machine-readable storage medium 404.

[0050] The Hardware Processor 402 can be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices capable of retrieving and executing instructions stored in the machine-readable memory medium 404. The Hardware Processor 402 can retrieve, decode, and execute instructions, such as instructions 406-412, to control processes or operations for distributing user role configurations. Alternatively or in addition to retrieving and executing instructions, the Hardware Processor 402 can include one or more electronic circuits comprising electronic components for performing the functionality of one or more instructions, such as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other electronic circuits.

[0051] A machine-readable storage medium, such as the 404 machine-readable storage medium, can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. The 404 machine-readable storage medium can be, for example, random-access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable solid-state memory (EEPROM), a storage device, an optical disk, or the like. In some examples, the 404 machine-readable storage medium can be a non-transient storage medium, the term "non-transient" excluding the transitive transmission signals. As detailed below, the 404 machine-readable storage medium can be encoded with executable instructions, such as instructions 406-412.

[0052] The 402 hardware processor can execute the 406 instruction to receive a user role configuration request from an access point (AP) to a cloud-based role management service (also known as the user role service mentioned above). As described above, a user device can connect to a network device, such as an AP, for example, one of the 302X or 302Y network devices ( Fig. 3) Connect / Associate. It should be clear that such a cloud-based role management service can be implemented in network devices other than just access points (APs). For example, a cloud-based role management service can be implemented in any network device capable of enforcing user data policies based on a user role, such as a wired switch, a controller, etc. When connecting / associating with an AP, the AP can authenticate the user device. As mentioned earlier, user device authentication can be based on information identifying the user device (and / or the SSID to which the user device belongs), which can be sent to an authentication server / service. If the user device passes the authentication process, the AP can assign a user role to the authenticated user device. As above (in conjunction with Fig. 3) As described, the user device can be identified by a user device address, e.g. a MAC address, and can also be linked to some kind of user identification / identifier that indicates a user who is connected to or uses the user device.

[0053] The user device record 310Q ( Fig. 3) contains, for example, both the user device address 314 and the user ID 315. In some examples, the user ID 315 corresponds to a user ID 318, which is included as part of a user record, e.g., user record 311W, which may also contain a user role ID 320. This user role ID 320, in turn, corresponds to a user role ID 322, which is contained in a user role record 312N, which in turn contains defined user role relationships 324. In this way, the appropriate user role can be determined based on the user / user device.

[0054] In some examples, the AP performs a check to determine if it has the appropriate user role configuration to apply to the user device. If not, the AP can request the user role configuration file / record from the cloud-based user role management service.

[0055] The hardware processor 402 can execute the 408 instruction to authenticate the user role configuration request (received by the access point to which the user device is connected) through the cloud-based role management service. In some examples, authentication / verification that the user role configuration request is legitimate may involve determining the source of the request and whether that source is authorized to receive the requested user role configuration. Again, user roles can be selectively assigned according to the needs / requests of the network's control instance(s), in accordance with the network topology, configuration, and other factors.

[0056] Hardware processor 402 can execute instruction 410 to respond to the requesting AP with the requested user role configuration after authentication by the cloud-based role management system. This means the cloud-based role management system can, via Policy Manager 306 ( Fig. 3) Retrieve the relevant user role configuration / record, which the cloud-based role management system can then forward to the requesting AP so that the requesting AP can download the user role configuration / record. The requesting AP can then apply the downloaded user role configuration / record to the connected user device.

[0057] As previously mentioned, the connected user device is placed in a locked state and remains there until the user role configuration / record is received and applied, preventing it from sending or receiving any communication / data. Once the user role configuration / record request has been authenticated, received, and applied, the access point can release the user device from the locked state to an unlocked state. As previously mentioned, the user device will remain locked if the user role configuration / record request is invalid or otherwise unacceptable, preventing any further data transmission / receipt.

[0058] Hardware processor 402 can execute instruction 412 to distribute the user role configuration to an access point (AP) that is adjacent to the requesting AP. In the context of user role distribution, an AP neighborhood relationship can be defined based on successful radio frequency (RF) communication between two APs. If one AP can "listen" to the RF transmissions of another AP, the two APs can be considered neighbors. More specifically, if an access point can successfully decode an 802.11-compliant frame from another access point received at one of its radio interfaces, they are neighbors. As described above, upon receiving the requested user role configuration, the cloud-based role management service can forward or distribute the user role configuration to other adjacent access points of the requesting access point.To achieve this, the cloud-based role management service can leverage a service / mechanism capable of analyzing network RF data to derive / optimize the network configuration. In some examples, the network analysis mechanism can be cloud-based. For instance, each AP in a network can periodically perform a scan by sending 802.11 Probe Request Frames on RF channels where APs are permitted to operate. Neighbor APs respond to these requests with 802.11 Probe Response Frames. The AP performing the scan collects these probe responses in an RF neighborhood report and can send it to the cloud-based network analysis service. The cloud-based network analysis service can then analyze the RF neighborhood report from each AP and create an RF neighborhood graph of the APs. Using this graph, the cloud-based network analysis service can identify RF neighbors for each individual AP.The cloud-based role management service can use this information about the identified neighbors of the requesting AP and forward / distribute the requested user role configuration to one or more of the neighboring APs. In some examples, this distribution can also be a selective process, where some APs, but not all neighboring APs, receive the user role configuration. For example, a group of APs can be defined or grouped to receive distributed user role configurations. Alternatively, another commonality can be the basis for distributing / broadcasting a user role configuration, such as all APs with the same site label. A site can refer to a physical location where a set of devices is installed, such as a campus, branch office, or event venue. In some implementations, sites can be used as the primary navigation element.For example, if several devices are installed on a campus, a location named CampusA can be created. The devices within CampusA can also be labeled. If the campus defined as CampusA consists of multiple buildings, the devices deployed on that campus can be named Building1 or Lobby. If the devices at a specific location, or within an area of ​​a specific location, need to have a similar configuration, the devices can be grouped together.

[0059] It is important to note that neighboring APs need not be limited to APs belonging to the same AP cluster or managed by the same management VLAN (unlike the conventional / traditional user role configuration models / mechanisms described above). Furthermore, the examples avoid the traditional limitations of user role configuration distribution and are able to implement a more efficient method or model. This is because the distribution of a requested user role configuration / record is limited to neighboring APs, rather than all APs in a given AP cluster. As a result, distributing a user role configuration / record can take less time and require fewer resources.As previously mentioned, an access point does not need to interact with another network device (such as the cloud-based role management service) to obtain a user role configuration to be applied to a connected user device. After distribution by the requesting access point, neighboring access points may already possess the user role configuration / record if the user device subsequently roams or establishes other connections to one or more of these neighboring access points.

[0060] Fig. Figure 4B is a block diagram of an example computer component or device 450 for implementing cloud-based user role management according to another example. The computer component 450 could be, for example, a controller, a processor, or another similar computer component capable of processing data, such as a user device processor. In the example implementation of Fig. 4B comprises the computer component 450, a hardware processor 452, and a machine-readable storage medium 454.

[0061] The hardware processor 452 can be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices capable of retrieving and executing instructions stored in the machine-readable memory medium 454. The hardware processor 452 can retrieve, decode, and execute instructions, such as instructions 456-460, to control processes or operations for establishing links, synchronizing, and publishing routes / states. Alternatively or in addition to retrieving and executing instructions, the hardware processor 452 can include one or more electronic circuits comprising electronic components for performing the functionality of one or more instructions, such as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other electronic circuits.

[0062] A machine-readable storage medium, such as machine-readable storage medium 454, can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. For example, machine-readable storage medium 454 could be random-access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable solid-state memory (EEPROM), a storage device, an optical disk, or the like. In some examples, machine-readable storage medium 454 could be non-transient, the term "non-transient" excluding transitive transmission signals. As detailed below, machine-readable storage medium 454 could be encoded with executable instructions, for example, instructions 456-460.

[0063] Hardware processor 452, which may be a hardware processor of the user device, can execute instruction 456 to receive an instruction from an access point (AP) to which the user device is connected, enter a blocked state while waiting for a cloud-based user role management service to authenticate a user role configuration request from the AP. As described above, a user device may be prevented from sending / receiving messages / communications while in a blocked state. This buys time for the user role configuration request to be authenticated.

[0064] Hardware processor 452 can execute instruction 458 to receive, after authentication of the user role configuration request from the access point (AP), the instruction to enter an unlocked state. Accordingly, the user device can enter the unlocked state when the requested user role configuration is applied to it. That is, once the AP is able to control traffic to / from the user device based on the requested user role configuration, the AP instructs the user device to transition from its locked state to an unlocked state. In the unlocked state, the user device can receive / send traffic.

[0065] As previously mentioned, these implementations improve upon the traditional management and distribution of user role configurations by enabling the distribution of user role configurations to desired network devices, such as access points (APs). Because this distribution is handled by a cloud-based role management service, it is not subject to the limitations associated with traditional systems and mechanisms, such as those using a virtual controller or broadcasting. Instead, an initial access point can pass a user role configuration to another access point, allowing the user role to be applied when a user device subsequently connects to that other access point. As mentioned earlier, the distribution is not limited to APs located in the same cluster or branch office. For example, neighboring APs can receive the requested user role configuration.As previously mentioned, in some contexts, neighboring APs may be based on one AP listening to the radio traffic of another. In some scenarios, neighboring APs are APs that a user device can connect to / associate with from another AP, regardless of whether the APs belong to the same cluster / branch. Therefore, the limitations of typical user role management models may not apply to the disclosed implementations.

[0066] Fig.Figure 5 shows a block diagram of an example Computer System 500, in which various examples described here can be implemented. The Computer System 500 can include a Bus 502 or other communication mechanism for transmitting information, and one or more Hardware Processors 504 coupled to the Bus 502 for processing information. The Hardware Processor(s) 504 can be, for example, one or more general-purpose microprocessors. The aforementioned components / units, such as the User Role Service 330, the Policy Manager 306, the Network Device 302X, etc., can be implementations or examples of the Computer System 500.

[0067] The Computer System 500 can include memory units, such as a main memory 506, including random-access memory (RAM), a cache, and / or other dynamic memory devices connected to the bus 502, to store information and instructions to be executed by the processor 504. The main memory 506 can also be used to store temporary variables or other intermediate information during the execution of instructions to be carried out by the processor 504. When such instructions are stored in memory media accessible to the processor 504, the Computer System 500 becomes a specialized machine adapted to perform the operations specified in the instructions.

[0068] The Computer System 500 may also include a read-only memory (ROM) 508 or other static storage device connected to the bus 502 to store static information and instructions for the processor 504. A storage device 510, such as a magnetic disk, an optical disk, or a USB flash drive, etc., may be provided and connected to the bus 502 to store information and instructions.

[0069] In general, the terms "engine," "component," "system," "database," and the like, as used here, can refer to logic embodied in hardware or firmware, or to a collection of software instructions that may have entry and exit points and are written in a programming language such as Java, C, or C++. A software component may be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as BASIC, Perl, or Python. It is understood that software components may be called by other components or by themselves, and / or may be invoked in response to detected events or interruptions. Software components configured to run on computer devices may be stored on a computer-readable medium, such as...Software code can be provided on a compact disc, digital video disc, flash drive, magnetic disk, or other tangible medium, or as a digital download (and may initially be stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such software code may be stored partially or entirely in the memory of the executing computer device so that it can be executed by the computer device. Software instructions may be embedded in firmware, such as an EPROM. Furthermore, the hardware components may consist of interconnected logic units such as gates and flip-flops, and / or programmable units such as programmable gate arrays or processors.

[0070] The Computer System 500 can implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with the Computer System, make the Computer System 500 a specialized machine or program it. According to one example, the techniques described herein are executed by the Computer System 500 in response to the Processor(s) 504 executing one or more sequences of instructions stored in the main memory 506. Such instructions may be read into the main memory 506 from another storage medium, such as a storage device 510. The execution of the instruction sequences stored in the main memory 506 causes the Processor(s) 504 to perform the process steps described herein.In alternative examples, hardwired circuits can be used instead of, or in combination with, software instructions.

[0071] The term "non-volatile media" and similar terms as used here refer to all media that store data and / or instructions that cause a machine to operate in a particular way. Such non-volatile media can include both non-volatile and volatile media. Non-volatile media include, for example, optical or magnetic disks, such as the Storage Device 510. Volatile media include dynamic storage devices, such as the Main Memory 506. Common forms of non-volatile media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or other magnetic data storage media, CD-ROMs, other optical data storage media, physical media with hole patterns, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, other memory chips or cartridges, and their networked versions.

[0072] Non-transitory media differ from transmission media but can be used in conjunction with them. Transmission media are involved in the transfer of information between non-transitory media. Examples of transmission media include coaxial cable, copper and fiber optic cables, including the wires that make up the 502 bus. Transmission media can also take the form of sound or light waves, such as those generated in radio and infrared data communication.

[0073] The Computer System 500 also includes a Communications / Network Interface 518, which is connected to the Bus 502. The Communications Interface 518 provides a two-way data communication connection to one or more network connections that are connected to one or more local area networks (LANs). For example, the Communications Interface 518 could be an ISDN (Integrated Services Digital Network) card, a cable modem, a satellite modem, or a modem to establish a data communication connection to a corresponding type of telephone line. Alternatively, the Communications Interface 518 could be a LAN card to establish a data communication connection to a compatible LAN (or a WAN component to communicate with a WAN). Wireless connections can also be implemented.In each of these implementations, the 518 communication interface sends and receives electrical, electromagnetic, or optical signals that transmit digital data streams representing various types of information.

[0074] A network connection typically enables data communication over one or more networks to other data devices. For example, a network connection might establish a connection over a local area network to a host computer or to data devices operated by an Internet service provider (ISP). The ISP, in turn, provides data communication services over the worldwide packet data communication network, commonly known today as the "Internet." Both the local area network and the Internet use electrical, electromagnetic, or optical signals to transmit digital data streams. The signals across the various networks, the signals on the network connection, and the communication interface 518, which transmit digital data to and from the computer system 500, are examples of transmission media.

[0075] The Computer System 500 can send messages and receive data, including program code, via the network(s), network connection, and communication interface 518. In the Internet example, a server could transmit requested code for an application program via the Internet, the ISP, the local network, and communication interface 518.

[0076] As used herein, the term "or" can be understood in both an inclusive and an exclusive sense. Furthermore, the description of resources, processes, or structures in the singular is not to be understood as excluding the plural. Conditional expressions, such as "may," "could," "might," or "may," are, unless expressly stated otherwise or understood differently in the context, generally to mean that certain examples include certain features, elements, and / or steps, while other examples do not. The terms and expressions used in this document, and their variations, are, unless expressly stated otherwise, to be understood as open rather than restrictive. As examples of the foregoing, the term "inclusive" is to be understood as "including, without limitation," or the like.The term "example" is used to provide illustrative examples of the subject of discussion, not to create an exhaustive or limiting list. The terms "a" or "an" are to be understood as meaning "at least one," "one or more," or similar. The presence of expansive words and phrases such as "one or more," "at least," "but not limited to," or similar expressions in some cases is not to be understood as implying that the narrower case is intended or required when such expansive phrases are absent.

Claims

[1] A system that includes the following: a processor; and a memory that is operationally connected to the processor, wherein the memory contains instructions which, when executed, cause the processor to: a request for user role configuration was received from a network device; Authenticate the request for user role configuration; After authentication, respond to the requesting network device with the requested user role configuration; and to distribute the user role configuration to another network device adjacent to the requesting network device. [2] The system according to claim 1, wherein the instructions effect a cloud-based role management service. [3] The system according to claim 1, wherein the network device comprises a device capable of enforcing the user role configuration. [4] The system according to claim 1, wherein the network device comprises an access point. [5] The system according to claim 1, wherein the instructions which, when executed, further cause the processor to determine that a source of the request is authorized to receive the requested user role configuration, the source of the request comprising the network device. [6] The system according to claim 1, wherein the memory contains further instructions which, when executed, authenticate a user device when the user device connects to the network device. [7] The system according to claim 6, wherein the authentication of the user device is based on at least one of the credentials that identify the user device or a group of network devices to which the user device belongs. [8] The system according to claim 6, wherein the memory contains further instructions which, when executed, cause the processor to apply the requested user role configuration to the user device. [9] The system according to claim 8, wherein the memory contains further instructions which, when executed, cause the processor to place the user device in a blocked state before the user device is authenticated and before the requested user role configuration is applied to the user device. [10] The system according to claim 9, wherein the memory contains further instructions which, when executed, cause the processor to place the user device into an unlocked state when the requested user role configuration is applied to the user device. [11] The system according to claim 1, wherein the memory contains further instructions which, when executed, cause the processor to select the other adjacent network device based on a radio frequency analysis of network devices. [12] A procedure comprising the following: Receiving a request from an access point for a user role configuration that specifies policies to apply to user traffic passing through the access point; authentication of the request for user role configuration; After authentication, respond to the requesting access point with the requested user role configuration; and Distribution of the user role configuration to another access point near the requesting access point. [13] The method according to claim 12, wherein the other adjacent access point is part of the same virtual local access network to which the requesting access point belongs. [14] The method according to claim 12, wherein the other adjacent access point is part of a different virtual local access network than the one to which the requesting access point belongs. [15] The method according to claim 12, further comprising placing a user device connected to the requesting access point into a blocked state while the user role configuration request is authenticated. [16] The method according to claim 15, further comprising placing the user device in an unlocked state when the requested user role configuration is applied to the user device after the user role configuration request has been authenticated. [17] A user device comprising the following: a processor; and a memory that is operationally connected to the processor, wherein the memory contains instructions which, when executed, cause the processor to: enters a blocked state while waiting for a cloud-based user role management service to authenticate a user role configuration request from a first network device to which the user device is associated; after authentication of the user role configuration request, enter an unlocked state resulting from the application of the requested user role configuration to the user device by the first network device; When connecting to a second network device, communication is carried out in accordance with the requested user role configuration, wherein the requested user role configuration is applied to the user device by the second network device, and wherein the second network device received the requested user role configuration via distribution by the cloud-based user role management service prior to connecting the user device to the second network device. [18] The user device according to claim 17, wherein all communications to and from the user device are prohibited while it is in the blocked state. [19] The user device according to claim 17, wherein the authentication of the user role configuration request is based on identification information that links a user device record with a user record and a user role record. [20] The user device according to claim 17, wherein the user device is assigned a user role corresponding to the requested user role configuration before the user role configuration is applied to the user device by the first network device.

Images