Logging a client device into a user-defined network with a federation-based network identity

Abstract

Aspects described herein include a method of automatically grouping client devices for a user-defined network (UDN). The method includes receiving, from a client device, an authentication request to join an access provider network. The authentication request includes a unique identifier of the client device that is targeted to a coalition-based network. The method also includes transmitting the unique identifier to a UDN cloud, transmitting the authentication request to an identity provider, and in response to authentication of the authentication request by the identity provider, receiving, from the UDN cloud, a list of one or more UDNs associated with the unique identifier. The method further includes joining the client device with one or more other client devices that are present on the access provider network of the same UDNs listed.

Description

Technical Field

[0001] The embodiments presented in this disclosure generally relate to wireless networking, and more specifically, to techniques for logging client devices into user-defined networks (UDNs) using identities for federation-based networks. Background Technology

[0002] Consumers increasingly expect their computing devices to remain connected to network-based services regardless of their location. However, cellular services such as 4G LTE and 5G may offer less than ideal connectivity in certain locations, such as indoors, far from cell towers, and / or otherwise obstructed. Open Roaming, as offered by the Wireless Broadband Alliance (WBA), is another option. TM Technologies like these use alliance-based frameworks to allow consumers to roam seamlessly onto Wi-Fi networks.

[0003] User-defined networks (UDNs) allow private networks to be established within shared or public networking infrastructure. Using a UDN, a private network can include a group of users and devices spanning multiple Virtual Local Area Networks (VLANs) and / or multiple wireless LANs. This private network can be configured manually or automatically, for example, based on location. Therefore, service discovery, link-local multicast (LLM), broadcast traffic, and optional unicast traffic can be included within the private network. Attached Figure Description

[0004] To enable a detailed understanding of the features described above, the present disclosure, which has been briefly summarized above, can be described in more detail by referring to embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the accompanying drawings illustrate typical embodiments and should not be considered limiting; other equivalent embodiments are contemplated.

[0005] Figure 1 This is an illustration showing a connection between a client device and an alliance-based network during roaming, according to one or more embodiments.

[0006] Figure 2 This is a diagram illustrating the sequence of connections from a client device to an alliance-based network according to one or more embodiments.

[0007] Figure 3 This is an illustration showing a client device logging into a user-defined network (UDN) according to one or more embodiments.

[0008] Figure 4 This is a method for creating a UDN using an authenticated client device, according to one or more embodiments.

[0009] Figure 5 This is a method for automatically grouping client devices of a UDN according to one or more embodiments.

[0010] Figure 6A and Figure 6B The sequence of connecting a client device to a UDN according to one or more embodiments is illustrated.

[0011] For ease of understanding, the same reference numerals are used wherever possible to denote the same common elements in the figures. It is foreseeable that elements disclosed in one embodiment may be advantageously used in other embodiments without specific description. Detailed Implementation

[0012] Overview

[0013] One embodiment presented in this disclosure is a method for automatically grouping client devices for a User Defined Network (UDN). The method includes receiving an authentication request from the client device to connect to an access provider network. The authentication request includes a unique identifier for the client device for a federation-based network. The method also includes transmitting the unique identifier to a UDN cloud and transmitting the authentication request to an identity provider. In response to the identity provider authenticating the authentication request, the method further includes receiving a list of one or more UDNs associated with the unique identifier from the UDN cloud. The method also includes connecting the client device to one or more other client devices present on access provider networks that list the same UDNs.

[0014] Another embodiment presented in this disclosure is a network device including one or more computer processors configured to perform the following operations: receiving from a client device an authentication request for connecting to an access provider network. The authentication request includes a unique identifier for the client device specific to a federated network. The operation further includes transmitting the unique identifier to a UDN cloud and transmitting the authentication request to an identity provider. The operation further includes receiving a list of one or more UDNs associated with the unique identifier from the UDN cloud in response to the identity provider authenticating the authentication request. The operation further includes connecting the client device to one or more other client devices present on an access provider network listing the same UDNs.

[0015] Another embodiment presented in this disclosure is a computer program product including a computer-readable storage medium having computer-readable program code therein. The computer-readable program code can be executed by one or more computer processors to perform the following operations: receiving an authentication request from a client device to connect to an access provider network. The authentication request includes a unique identifier for the client device for a federation-based network. The operation further includes transmitting the unique identifier to a UDN cloud and transmitting the authentication request to an identity provider. The operation further includes receiving a list of one or more UDNs associated with the unique identifier from the UDN cloud in response to the identity provider authenticating the authentication request. The operation further includes connecting the client device to one or more other client devices present on access provider networks listing the same UDNs.

[0016] Example Implementation

[0017] The target deployment of User-Defined Networks (UDNs) includes multiple locations where personalized private networks should be established within shared or public networked infrastructure. Some example locations include dormitories, universities, multi-family units, hospitals, hotels, and entertainment venues.

[0018] Users generally have access to all devices connected to the UDN and can extend their access to the UDN by sending invitations to other users. Logical groups of users and devices are created via the UDN, ensuring that only devices within the UDN can see each other (and advertise services to each other).

[0019] UDNs are typically qualified by grouping the Media Access Control (MAC) addresses of these devices into identifiers. In some cases, users of the UDN must manually search for the MAC addresses(s) of these devices(s) and must use a dedicated application to enter the MAC addresses(s). However, due to privacy concerns, devices may intermittently change their MAC addresses (e.g., using MAC randomization), which would disrupt device access to the UDN. For example, if a user registers a device with the UDN using a first Service Set Identifier (SSID) and later attempts to access the UDN using a different SSID, the user will not be able to access the UDN (if MAC randomization was performed on the device before the second SSID was attached).

[0020] Such as OpenRoaming TM Technologies like these allow client devices to roam to different network access providers without requiring repeated logins or authentication. In some cases, identity providers may seek to offer additional services beyond roaming, such as providing web-based (e.g., cloud-based) services to client devices.

[0021] The embodiments described herein disclose a method for automatically grouping client devices for a UDN. The authentication request includes a unique identifier of the client device known to the confederate-based network. The method also includes transmitting the unique identifier to a UDN cloud and transmitting the authentication request to an identity provider. The method further includes receiving a list of one or more UDNs associated with the unique identifier from the UDN cloud in response to the identity provider authenticating the authentication request. The method also includes connecting the client device to one or more other devices belonging to the same UDN(s) in response to determining that one or more other devices on the access provider network belong to the same UDN(s).

[0022] Advantageously, this method eliminates the need for manual UDN configuration and supports client devices using MAC randomization. Furthermore, it allows for the use of federation-based networks (e.g., OpenRoaming). TM The network serves as a source of UDN packet information and can manage and move UDNs across different networks.

[0023] Figure 1 This is a diagram 100 illustrating a connection between a client device 105 and an alliance-based network 115 during roaming, according to one or more embodiments. Diagram 100 represents an example sequence of client devices 105 used by a user. For example, this sequence could represent a user's work schedule.

[0024] Client device 105 can be implemented in any form suitable for wireless networking. In some embodiments, client device 105 is implemented as a mobile computing device, such as a laptop, tablet, smartphone, or smart wearable device. In other embodiments, client device 105 can be a computing device integrated into a vehicle.

[0025] At the start of this sequence, the user is at home 110-1, and client device 105 wirelessly connects to a home network (e.g., a Wi-Fi network), such as a local area network or local access network (LAN), general wide area network (WAN), and / or public network (e.g., the Internet), which provides access to external networks. When the user is driving a car 110-2, client device 105 wirelessly connects to a cellular network (e.g., a 4G LTE or 5G cellular network). When the user arrives at the company office 110-3, client device 105 roams from the cellular network to the Wi-Fi network operated by company office 110-3. The user returns to the car to make a customer call 110-4, and when out of range of the Wi-Fi network, client device 105 reconnects to the cellular network. When the user visits an office branch 110-5, a coffee shop 110-6, and a hotel 110-7, client device 105 later roams to different Wi-Fi networks.

[0026] When roaming to different Wi-Fi networks (e.g., at company office 110-3, branch office 110-5, coffee shop 110-6, and hotel 110-7), client device 105 uses alliance-based network 115 to access the external network. Alliance-based network 115 can be implemented using any standardized and / or proprietary technologies and protocols. For example, alliance-based network 115 can be compatible with OpenRoaming. TM .

[0027] The alliance-based network 115 includes multiple access providers 120 (also referred to as "access network providers") that provide wireless connectivity to client devices 105 using, for example, access points, wireless LAN controllers, etc. Some non-limiting examples of access providers 120 include enterprise access providers 122 (e.g., employers, manufacturing facilities), consumer access providers 124 (e.g., hotels, retail stores), public access providers 126 (e.g., airports, universities, stadiums), etc.

[0028] The alliance-based network 115 includes multiple identity providers 130 that operate to create, maintain, and / or manage user identity information and provide authentication services within the alliance-based network 115. Some non-limiting examples of identity providers 130 include cloud providers 132 (e.g., providers of scalable computing resources), service providers 134 (e.g., telecommunications companies, utility organizations), and equipment manufacturers 136. By authenticating users using identity providers 130, client devices 105 can roam to different access providers 120 without requiring repeated logins or authentication from the user.

[0029] Figure 2 This is a diagram 200 illustrating the sequence of connections from client device 105 to an alliance-based network according to one or more embodiments. The features shown in diagram 200 may be combined with other embodiments (e.g., showing client device 105 and...). Figure 1 Access provider 120 can be used at any of the following locations shown: company office 110-3, office branch 110-5, coffee shop 110-6, or hotel 110-7.

[0030] In Figure 200, access provider 205 ( Figure 1(An example of an access provider 120) transmits a beacon 220 that announces one or more requests for connecting a client device 105 to the access provider 205. The beacon 220 can be implemented in any suitable form, such as an IEEE 802.11u beacon. In some embodiments, the beacon 220 instructs the client device 105 to provide a private identifier for the user. In other embodiments, the beacon 220 instructs the client device 105 to provide only a public identifier.

[0031] In response to beacon 220, client device 105 attaches 225 to access provider 205 (i.e., client device 105 establishes a connection with access provider 205), and access provider 205 initiates authentication of the user, for example via an Extensible Authentication Protocol (EAP) process, by transmitting one or more acceptable authentication types 230 to client device 105. Client device 105 may search a list of profiles stored thereon and may automatically select an identity 235 that corresponds to an acceptable credential type 230 (e.g., token, certificate, username / password, SIM, etc.) and best matches one or more requirements specified by access provider 205 (e.g., via beacon 220). In some embodiments, identity 235 includes elements of a Uniform Resource Locator (URL), such as a domain name. Client device 105 may use any suitable technology to select the best match.

[0032] Client device 105 provides the selected identity 235 to access provider 205, and access provider 205 uses identity 235 to contact Domain Name Service (DNS) server 210. As shown in Figure 200, the identity 235 selected by client device 105 is "bob@newco.com", which can be a public or private identity in response to beacon 220 transmitted by access provider 205. Access provider 205 uses DNS server 210 to look up 240 "newco.com". Using the result from DNS server 210, access provider 205 establishes a connection with identity provider 215 (…). Figure 1An encrypted and authenticated Transport Layer Security (TLS) tunnel 245 (an example of an identity provider 130) is used, with identity provider 215 corresponding to the selected identity 235. Identity provider 215 provides EAP authorization 250 to access provider 205 using the Remote Authentication Dial In User Service (RADIUS) attribute, and access provider 205 provides EAP authorization 255 to client device 105 using EAP over LAN (EAPoL).

[0033] Figure 3 Figure 300 illustrates client devices 305-1 and 305-2 logging into a user-defined network (UDN) 325 according to one or more embodiments. The features shown in Figure 300 can be used in conjunction with other embodiments. For example, Figure 3 Client device 305-1, client device 305-2, access provider 335, and identity provider 350 can be Figure 1 Examples of client device 105, access provider 120, and identity provider 130.

[0034] In Figure 300, client devices 305-1, 305-2, and identity provider 350 are connected to access provider 335 via corresponding communication links 375-1, 375-2, and 375-3. Each of client devices 305-1, 305-2, access provider 335, and identity provider 350 can be implemented as one or more computing devices in any suitable form(s). For example, client devices 305-1 and 305-2 can be implemented as mobile computing devices for one or more users, while each of access provider 335 and identity provider 350 can be implemented as one or more server computers. In some embodiments, access provider 335 represents a network of multiple computing devices. For example, the UDN management module 370 of access provider 335 can be implemented in a manager computing device, which is separate from the other (one or more) computing devices of access provider 335.

[0035] Each of client device 305-1, client device 305-2, access provider 335, and identity provider 350 includes one or more corresponding computer processors 310, 340, 355, and corresponding memories 315, 345, and 360. The one or more computer processors 310, 340, and 355 can be implemented in any suitable form, such as a general-purpose microprocessor, controller, application-specific integrated circuit (ASIC), etc. Memories 315, 345, and 360 can include various computer-readable media selected for their size, relative performance, or other capabilities (volatile and / or non-volatile media, removable and / or non-removable media, etc.).

[0036] Commonly, access provider 335 and identity provider 350 can represent Figure 1 This is an example of a federation-based network 115, and can be implemented using one or more networks of any suitable type, such as a public network (e.g., the Internet), a local area network (LAN), a wide area network (WAN), and / or a wireless network. Communication links 375-1, 375-2, and 375-3 can have any suitable implementation, such as one or more copper transmission cables, one or more optical fiber transmissions, wireless transmissions, one or more routers, one or more firewalls, one or more switches, one or more gateway computers, and / or one or more edge servers. In some embodiments, communication links 375-1 and 375-2 are dedicated wireless communication links.

[0037] Access provider 335 typically includes networking hardware located near client devices 305-1 and 305-2 and providing wireless connectivity (e.g., via WiFi) to client devices 305-1 and 305-2. Access provider 335 can represent one or more types of devices, such as access points (APs), switches, routers, wireless LAN controllers (WLCs), policy engines, software-defined networking (SDN) controllers, etc.

[0038] In some embodiments, access provider 335 advertises its support for automatic packetization for client devices 305-1 and 305-2 to UDN 325. For example, access provider 335 may advertise this support in response to a query received from client devices 305-1 and 305-2. In some embodiments, the query conforms to the Access Network Query Protocol (ANQP). In some embodiments, access provider 335 uses new ANQP elements to advertise support for confederation-based networks and support for automatic packetization.

[0039] Advantageously, client devices 305-1 and 305-2 can preferentially select access provider 335 that advertises support for automatic grouping of client devices 305-1 and 305-2. For example, client devices 305-1 and 305-2 can scan available networks and give higher priority to access provider 335 due to the advertised support.

[0040] Identity Provider 350 typically provides authentication for client devices 305-1 and 305-2 used to log in to UDN 325. As mentioned above, some examples of Identity Provider 350 include cloud providers, service providers, and device manufacturers. Identity Provider 350 can use any appropriate authentication protocol, such as OAuth, Remote Authentication Dial-In User Service (RADIUS), Security Assertion Markup Language (SAML), etc.

[0041] Memory 315, memory 345, and memory 360 may include one or more modules for performing the various functions described herein. In one embodiment, each module includes program code executable by one or more corresponding computer processors 310, 340, and 355. In another embodiment, each module is partially or wholly implemented in the hardware (i.e., circuitry) or firmware of client device 305-1, client device 305-2, access provider 335, and / or identity provider 350 (e.g., as circuitry within one or more computer processors 310, 340, and 355). However, other embodiments of Figure 300 may include modules partially or wholly implemented in other hardware or firmware, such as hardware or firmware included in one or more other computing devices connected to access provider 335. In other words, the overall functionality of one or more modules may be distributed across other devices of Figure 300.

[0042] As shown in the figure, the memory 315 of each of the client devices 305-1 and 305-2 includes a message passing module 316 and a MAC random number generator module 318, the memory 360 of the identity provider 350 includes an identity service module 365, and the access provider 335 includes a UDN management module 370.

[0043] The identity service module 365 typically operates to create, maintain, and / or manage identity information for users and / or associated client devices 305-1 and 305-2. The identity service module 365 may also use an access provider 335 to provide authentication services. In some embodiments, the identity service module 365 provides credentials for authenticating users to access network-based services. These credentials can be implemented in any suitable form, such as a security token unique to a specific session with the user. In some embodiments, the security token includes a value provided by the identity provider 350, an identifier of the identity provider 350, and / or a value provided by a provider of network-based service security.

[0044] Client devices 305-1 and 305-2 each include a profile 320 associated with a user of client devices 305-1 and 305-2, respectively. Each profile 320 includes one or more optional identities for connecting to a federation-based network. For example, a user may have an employer-provided identity and one or more personal identities. Each profile 320 may allow one or more services, policies, capabilities, features, etc. to be applied when it is selected. For example, one or more additional security services may be applied to the employer-provided identity instead of the personal identity. One or more services, policies, capabilities, features, etc., may be directly selected and / or purchased by the user, or may be directly provided to the user by the access provider 335.

[0045] Each profile 320 may include any other appropriate information, such as a username and / or personal information. In some embodiments, the profile 320 includes a user-friendly device name, a unique identifier 322 for each device associated with (and managed by) the user, and / or a list of one or more UDNs associated with the device (e.g., associated with the unique identifier 322). In some embodiments, the unique identifier 322 includes a serial number assigned to client device 305-1, client device 305-2.

[0046] In some embodiments, the identity service module 365 may store a list of client devices 305-1 and 305-2 associated with a user. Using the list of client devices 305-1 and 305-2, a user can create different UDN groups (e.g., commercial UDNs and personal UDNs) and access each of these UDNs using the same profile 320. Furthermore, for example, when client devices 305-1 and 305-2 are found to be unauthorized, lost, or stolen, the list of client devices 305-1 and 305-2 can be updated to restrict access to certain client devices 305-1 and 305-2.

[0047] UDN management module 370 performs monitoring and / or maintenance functions for UDN 325. In some embodiments, identity provider 350 creates UDN 325 in response to receiving requests from client devices 305-1 and 305-2, and adds requesting client devices 305-1 and 305-2 to UDN 325. Identity provider 350 propagates information about the created UDN 325 to UDN management module 370, where this information is appropriately stored and updated.

[0048] In some embodiments, the UDN management module 370 maintains a list of one or more UDNs associated with each identity. For example, when the UDN management module 370 is implemented in a separate computing device, the list of one or more UDNs may also be stored separately by the identity provider 350 and the UDN management module 370. After the client device 305-1 is authenticated, the UDN management module 370 queries the list of one or more UDNs(s) associated with the client device 305-1. The UDN management module 370 communicates with the UDN cloud (e.g., Figure 6A The UDN cloud 630 shown receives a list of one or more UDNs from the identity provider 350. The list of one or more UDNs is stored by the UDN management module 370.

[0049] For client device 305-2, a similar process can be performed. After successfully authenticating client device 305-2, access provider 335 (e.g., UDN management module 370) queries a list of one or more UDNs associated with client device 305-2, receives the list of one or more UDNs from identity provider 350, and stores the list of one or more UDNs in UDN management module 370.

[0050] When the UDN management module 370 finds a matching UDN qualification in the list received for client devices 305-1 and 305-2, the UDN management module will automatically form UDN 325 (for example, create a local instance of UDN 325 using the MAC address and identifier 322 of client devices 305-1 and 305-2) and place client devices 305-1 and 305-2 inside UDN 325.

[0051] Advantageously, although access provider 335 receives the MAC addresses of client devices 305-1 and 305-2, in some embodiments, when client devices 305-1 and 305-2 are connected to UDN 325, these MAC addresses are not transmitted to the federation-based network or identity provider 350. This allows users to have improved privacy because various network devices cannot use a user's (one or more) MAC addresses to track location, duration of use, etc.

[0052] Furthermore, as described above, some implementations of client devices 305-1 and 305-2 can intermittently change the MAC address presented to the access provider 335. For example, client devices 305-1 and 305-2 each include a MAC randomization generator module 318, which randomizes the MAC address of the respective client device 305-1 or client device 305-2 according to any suitable technique. In other embodiments, the MAC addresses of client devices 305-1 and client devices 305-2 can be changed intermittently without randomization.

[0053] Normally, changing the MAC addresses of client devices 305-1 and 305-2 will interrupt access to UDN 325 and may require manual reconfiguration. However, by using the identifier 322 associated with the confederation-based network, access provider 335 can ensure that client devices 305-1 and 305-2 continue to access UDN 325 regardless of any changes to their MAC addresses.

[0054] In some embodiments, the system shown in Figure 300 can also support ad hoc connections between client devices 305-1, 305-2, and UDN 325. For example, two colleagues in a meeting might want to establish a UDN for directed P2P messaging, file sharing, etc., with each other. In one example sequence, client devices 305-1 and 305-2 are authenticated using a corresponding identifier 322 (e.g., via access provider 335 at the meeting site). The user of client device 305-1 can use the techniques described above to create UDN 325. The user of client device 305-1 can then use messaging module 316 to send an invitation to the user of client device 305-2.

[0055] The messaging module 316 can be implemented in any suitable form for transmitting invitations to UDN 325. Some non-limiting examples of the messaging module 316 include email clients, dedicated messaging clients, and social networking clients. Furthermore, the invitation can be provided to client device 305-2 in any suitable format (e.g., a hyperlink). Advantageously, the messaging module 316 can be implemented using one or more applications already in use by the user on client device 305-1 or client device 305-2 (e.g., without needing to use a dedicated application).

[0056] When a user of client device 305-2 accepts an invitation, client device 305-2 transmits an authentication request (with identifier 322), which is then transmitted to UDN management module 370. UDN management module 370 can transmit a list of one or more UDNs associated with the identifier to access provider 335, and access provider 335 can connect client device 305-2 to UDN 325. Because UDN 325 is defined by identifier 322 of client devices 305-1 and 305-2, client devices 305-1 and 305-2 can migrate to different access providers 335 (e.g., at a different location than the meeting site) while providing the same experience.

[0057] Figure 4 This is a method 400 for creating a UDN using an authenticated client device, according to one or more embodiments. Method 400 can be used in conjunction with other embodiments, for example, using... Figure 3 The combination of access provider 335 and identity provider 350 is used to perform this.

[0058] Method 400 begins at box 405, where a federation-based network is used to authenticate the client device. In some embodiments, the access provider contacts the identity provider to authenticate the client device. At box 415, a request to create a UDN is received, and at box 425, the client device is added to the UDN. In some embodiments, the identity provider receives the request, creates the UDN, and adds the client device to the UDN.

[0059] At box 435, the list of one or more UDNs associated with the client device's identifier is updated. In some embodiments, the identity provider updates this list and forwards it to the access provider. At box 445, the access provider creates a local instance of the UDN using the client device's MAC address and the client device's unique identifier.

[0060] At box 455, the user of the client device sends an invitation to the second client device for the UDN. At box 465, the second client device is authenticated to the UDN using an identity provider (or another identity provider). The identity provider can update the list of UDNs associated with the second client device. At box 475, the access provider receives the updated list of UDNs associated with the second client device. At box 485, the access provider determines whether two or more client devices (here referring to the first client device and the second client device) are included in the same UDN. At box 495, when two or more client devices are included in the UDN, the access provider creates a local instance of the UDN. Method 400 ends after completing box 495.

[0061] Figure 5 This is a method 500 for automatically grouping client devices for a UDN according to one or more embodiments. The method 500 can be used in conjunction with other embodiments, for example, using... Figure 3 Access provider 335 is used to execute.

[0062] Method 500 begins at box 505, where the access provider announces support for federation-based networks. At box 515, the access provider announces support for automatic grouping of client devices as UDNs. In some embodiments, the announcements at boxes 505 and 515 are in response to queries from client devices, such as ANQP queries.

[0063] At box 525, the access provider requests a list of one or more UDNs associated with the client device. In some embodiments, the access provider requests this list in response to the client device being authenticated by an identity provider. In some embodiments, the access provider transmits a unique identifier of the client device to the UDN network (UDN cloud).

[0064] At box 535, the access provider uses a list of one or more UDNs to determine if any other client devices currently on the access provider network belong to the same UDN. At box 545, in response to determining that two or more client devices list the same UDN, the access provider creates a local instance of the UDN. At box 555, the access provider connects two or more client devices to the UDN. Method 500 ends after completing box 555.

[0065] Figure 6A and Figure 6B The sequence of connecting a client device to a UDN according to one or more embodiments is illustrated. The features shown in Figures 600 and 645 can be used in conjunction with other embodiments. For example, Figures 600 and 645 may represent... Figure 4 Method 400 includes one or more boxes.

[0066] As described above, access provider 335 refers to networked hardware located near client device 305 and providing wireless connectivity to client device 305. In some embodiments, the networked hardware of access provider 335 is owned or operated by a location. Figures 600 and 645 also include cloud-based infrastructure 605 representing the networked hardware, which may be located remotely from client device 305 and / or access provider 335.

[0067] Access provider 335 includes access point (AP) 610, wireless LAN controller (WLC) 615, policy engine 620, and software-defined networking (SDN) controller 625. In some embodiments, AP 610 provides access to client device 305, WLC 615 connects to client device 305 and orchestrates authentication, policy engine 620 provides dynamic users (or client device 305) to group mappings and policy restrictions, and SDN controller 625 provides centralized management and control, automation, and policy enforcement across physical and virtual network environments.

[0068] The cloud-based infrastructure 605 includes a user-defined network (UDN) cloud 630, a federation-based network 635, and an identity provider 350. Typically, the UDN cloud 630 represents a cloud-based device that manages the propagation of information from the identity provider 350 (e.g., a maintained list of UDNs to which client devices are included) to the access provider 335 (e.g., the access provider 335 groups client devices into one or more local instances of the UDN(s) based on the received list).

[0069] In one exemplary sequence, client device 305 detects an announcement from access provider 335 indicating support for automatically packetizing the client device to a UDN. Client device 305 transmits an authentication request including the client device's unique identifier. In Figure 600, the unique identifier is transmitted to the UDN cloud 630 via AP 610, WLC 615, policy engine 620, and SDN controller 625. In this way, access provider 335 can map the client device's current MAC address to a UDN packet without transmitting the MAC address to the federation-based network or identity provider 350.

[0070] In Figure 645, the authentication request from client device 305 is transmitted to identity provider 350 via AP 610, WLC 615, SDN controller 625, and federation-based network 635. When identity provider 350 confirms the authentication request, the user is authenticated without the need to create a UDN.

[0071] UDN cloud 630 can send a list of UDNs associated with unique identifiers to access provider 335. If the list indicates that client device 305 belongs to a UDN listed by another device (also associated on the network), WLC 615, policy engine 620, and SDN controller 625 can connect client device 305 to a local instance of the UDN.

[0072] In an alternative implementation, access provider 335 can create a UDN for each device, even if other devices from the same UDN are not present. Advantageously, creating a UDN allows unwanted traffic (e.g., P2P traffic) to be blocked, while any desired traffic (e.g., mDNS or broadcast traffic) is added as a shared resource by access provider 335. In this way, creating a UDN provides granularity for attachment policies. For example, these policies can be applied per user rather than per device, which tends to simplify the workflow.

[0073] Various embodiments have been referenced in this disclosure. However, the scope of this disclosure is not limited to the specific embodiments described. Rather, any combination of the described features and elements is considered for implementing and practicing the considered embodiments, regardless of whether different embodiments are involved. Furthermore, when elements of an embodiment are described in the form of "at least one of A and B," it should be understood that embodiments including only element A, only element B, and including both elements A and B are all considered. Moreover, while the embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the scope of this disclosure. Therefore, the aspects, features, embodiments, and advantages disclosed herein are merely illustrative and should not be considered elements or limitations of the appended claims unless expressly recited in the claims. Similarly, references to "the invention" should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered elements or limitations of the appended claims unless expressly recited in the claims.

[0074] As will be apparent to those skilled in the art, the embodiments disclosed herein can be embodied as systems, methods, or computer program products. Therefore, the embodiments may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which are generally referred to herein as “circuit,” “module,” or “system.” Furthermore, the embodiments may take the form of computer program products embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0075] Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, or any suitable combination of the foregoing.

[0076] Computer program code used to perform the operations of the various embodiments of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​(e.g., Java, Smalltalk, C++, etc.) and conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). This program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or the connection can be made to an external computer (e.g., via the Internet provided by an Internet service provider).

[0077] Aspects of this disclosure have been described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in the blocks of the flowchart illustrations and / or block diagrams.

[0078] These computer program instructions may also be stored in a computer-readable medium that can direct a computer, other programmable data processing apparatus or other device to operate in a particular manner such that the instructions stored in the computer-readable medium produce an article of manufacture, including instructions that implement the functions / actions specified in the boxes of flowcharts and / or block diagrams.

[0079] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus or other equipment to cause a series of operational steps to be performed on the computer, other programmable apparatus or other equipment to produce a computer-implemented process. Thus, the instructions that execute on the computer, other programmable data processing apparatus or other equipment provide a process for implementing the function / action specified in the boxes of the flowchart and / or block diagram.

[0080] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each box in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing one or more specific logical functions. It should also be noted that in some alternative implementations, the functions mentioned in the boxes may appear in a different order than that shown in the drawings. For example, depending on the functions involved, two boxes shown consecutively may actually be executed substantially simultaneously, or the boxes may sometimes be executed in reverse order. It should also be noted that each box in the block diagrams and / or flowcharts, and combinations of boxes in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs a specific function or action, or by a combination of dedicated hardware and computer instructions.

[0081] In view of the foregoing, the scope of this disclosure is defined by the appended claims.

Claims

1. A method for automatically grouping client devices in a user-defined network (UDN), the method comprising: The first client device receives an authentication request for connecting to the provider network, wherein the authentication request includes a unique identifier of the first client device for the alliance-based network; Transmit the unique identifier to the UDN cloud; The authentication request is transmitted to the identity provider; In response to the identity provider authenticating the authentication request, a list of one or more UDNs associated with the unique identifier is received from the UDN cloud; and Connect the first client device to one or more other client devices that are present on the access provider network and list the same UDN.

2. The method according to claim 1, further comprising: The announcement supports the aforementioned alliance-based network; as well as The announcement provides support for automatic grouping of client devices via UDN.

3. The method according to claim 2, wherein, The announcement of support for the alliance-based network and the announcement of support for automatic grouping of client devices are made in response to receiving a query from the first client device.

4. The method according to claim 3, wherein, The query from the first client conforms to the Access Network Query Protocol (ANQP).

5. The method according to claim 1, wherein, The Media Access Control (MAC) address of the first client device was not transmitted to the alliance-based network or the identity provider.

6. The method according to claim 1, further comprising: Using a unique identifier for the second client device specific to the alliance-based network, a request to connect to the access provider network is received from the second client device; as well as A local instance of the UDN is created using the Media Access Control (MAC) address of the second client device and the unique identifier of the second client device.

7. The method according to claim 1, wherein, The unique identifier is stored by the first client device in a profile for the alliance-based network.

8. A network device, comprising: One or more computer processors are configured to perform operations, said operations including: The first client device receives an authentication request for connecting to the provider network, wherein the authentication request includes a unique identifier of the first client device for the alliance-based network; Transmit the unique identifier to the UDN cloud; The authentication request is transmitted to the identity provider; In response to the identity provider authenticating the authentication request, a list of one or more UDNs associated with the unique identifier is received from the UDN cloud; and Connect the first client device to one or more other client devices that are present on the access provider network and list the same UDN.

9. The network device according to claim 8, further comprising: The announcement supports the aforementioned alliance-based network; as well as The announcement provides support for automatic grouping of client devices via UDN.

10. The network device according to claim 9, wherein, The announcement of support for the alliance-based network and the announcement of support for automatic grouping of client devices are made in response to receiving a query from the first client device.

11. The network device according to claim 10, wherein, The query from the first client device conforms to the Access Network Query Protocol (ANQP).

12. The network device according to claim 8, wherein, The Media Access Control (MAC) address of the first client device was not transmitted to the alliance-based network or the identity provider.

13. The network device according to claim 8, wherein the operation further comprises: Using a unique identifier for the second client device specific to the alliance-based network, a request to connect to the access provider network is received from the second client device; as well as A local instance of the UDN is created using the Media Access Control (MAC) address of the second client device and the unique identifier of the second client device.

14. The network device according to claim 8, wherein, The unique identifier is stored by the first client device in a profile for the alliance-based network.

15. A computer program product comprising: A computer-readable storage medium containing computer-readable program code, said computer-readable program code being executable by one or more computer processors to perform operations, said operations including: The first client device receives an authentication request for connecting to the provider network, wherein the authentication request includes a unique identifier of the first client device for the alliance-based network; Transmit the unique identifier to the UDN cloud; The authentication request is transmitted to the identity provider; In response to the identity provider authenticating the authentication request, a list of one or more UDNs associated with the unique identifier is received from the UDN cloud; and Connect the first client device to one or more other client devices that are present on the access provider network and list the same UDN.

16. The computer program product according to claim 15, wherein the operation further comprises: The announcement supports the aforementioned alliance-based network; as well as The announcement provides support for automatic grouping of client devices via UDN.

17. The computer program product according to claim 16, wherein, The announcement of support for the alliance-based network and the announcement of support for automatic grouping of client devices are made in response to receiving a query from the first client device.

18. The computer program product according to claim 17, wherein, The query from the first client device conforms to the Access Network Query Protocol (ANQP).

19. The computer program product according to claim 15, wherein, The Media Access Control (MAC) address of the first client device was not transmitted to the alliance-based network or the identity provider.

20. The computer program product according to claim 15, wherein the operation further comprises: Using a unique identifier for the second client device specific to the alliance-based network, a request to connect to the access provider network is received from the second client device; A local instance of the UDN is created using the Media Access Control (MAC) address of the second client device and the unique identifier of the second client device.

Images