Description:
DESCRIPTION
Technical Field
[001] This disclosure relates generally to wireless network management, and more particularly to method, device, and system for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network.
Background
[002] An enhanced Pre-Shared Key (ePSK) allows multiple user devices to connect to a wireless network using the same PSK. Thus, use of ePSKs may be implemented in wireless networks in building complexes (e.g., Multi-Dwelling Units (MDUs), business complexes, enterprise buildings, enterprises implementing a bring your own device (BYOD) policy, co-working spaces, or the like) to provide a streamlined internet access to various user groups. Generally, building complexes include a plurality of units (e.g., apartments, stores, office spaces, etc.) having different set of occupants (i.e., tenant, dwellers, users, etc.). The ePSK provides each set of occupants in the building complex with their own private PSK and Virtual Local Area Network (VLAN), creating micro-segmented personal area networks with ubiquitous roaming across the building complex using a single Service Set Identifier (SSID) or a personalized SSID.
[003] In the present state of art, to reduce management overhead for Managed Service Providers (MSPs) and property managers, many wireless network deployments provide occupants of the units of the building complex a self-service portal where various network management operations (such as looking up the PSK, resetting the PSK, looking at list of user devices, adding or removing devices, viewing data usage, managing security settings, managing parental controls, raising a support ticket, etc.) can be performed. Typically, this requires a separate user account to be added and managed per unit. Thus, the user may be required to provide login credentials to access the self-service portal. This makes accessing the self-service portal a two-step process (connecting to the wireless network and then logging into the self-service portal). Moreover, the user may then be required to remember two login credentials, which may neither be optimal nor user-friendly.
[004] The present invention is directed to overcome one or more limitations associated with the known arts stated above.
SUMMARY
[005] In one embodiment, a method for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network is disclosed. In one example, the method may include receiving, by an access point (AP) and from a user device, an access request to the user portal hosted on a remote server. The AP may be one of a plurality of APs in a wireless network. The user device may be communicatively connected to the AP using a unique ePSK of a user. The method may further include generating, by the AP, a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user. The method may further include transmitting, by the AP, the pre-authenticated access request to the remote server for validation. The method may further include establishing, by the AP, a communication between the user device and the remote server for rendering of the user portal based on the validation.
[006] In one embodiment, a system for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network is disclosed. In one example, the system may include a remote server and a plurality of access points (APs). Each of the plurality of APs is communicatively coupled to the remote server. Each AP of the plurality of APs is configured to receive, from a user device, an access request to the user portal hosted on the remote server. The user device is communicatively connected to the AP using a unique ePSK of a user. Each AP of the plurality of APs is further configured to generate a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user. Each AP of the plurality of APs is further configured to transmit the pre-authenticated access request to the remote server for validation. Each AP of the plurality of APs is further configured to establish a communication between the user device and the remote server for rendering of the user portal based on the validation.
[007] In one embodiment, an Access Point (AP) for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network is disclosed. In one example, the AP may include a processor and a memory communicatively coupled to the processor. The memory may store processor instructions, which when executed by the processor, may cause the processor to receive, from a user device, an access request to the user portal hosted on a remote server. The AP is one of a plurality of APs in a wireless network. The user device is communicatively connected to the AP using a unique ePSK of a user. The processor instructions, on execution, may further cause the processor to generate a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user. The processor instructions, on execution, may further cause the processor to transmit the pre-authenticated access request to the remote server for validation. The processor instructions, on execution, may further cause the processor to establish a communication between the user device and the remote server for rendering of the user portal based on the validation.
[008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[010] FIG. 1 illustrates an exemplary network where various embodiments may be deployed.
[011] FIG. 2 illustrates a functional block diagram of an exemplary system for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network, in accordance with some embodiments.
[012] FIG. 3 illustrates a flow diagram of an exemplary process for managing access to a user portal using an ePSK in a wireless network, in accordance with some embodiments.
[013] FIG. 4 illustrates a schematic diagram of a detailed exemplary process for managing access to a user portal using an ePSK in a wireless network, in accordance with some embodiments.
[014] FIG. 5 illustrates a schematic diagram of a detailed exemplary process for managing access to a user portal hosted on a trusted third-party server using an ePSK in a wireless network, in accordance with some embodiments.
DETAILED DESCRIPTION
[015] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[016] Referring now to FIG. 1, an exemplary network 100 where various embodiments may be deployed is illustrated, in accordance with some embodiments of the present disclosure. The network 100 may be a wireless network (i.e., a Wireless Local Area Network (WLAN)), based on a wireless networking technology (for example, a Wireless Fidelity (Wi-Fi), Light Fidelity (Li-Fi), or the like). The network 100 may be implemented in a building complex 101. By way of an example, the building complex 101 may be a Multi-Dwelling Unit (MDU) (such as a residential society, an apartment building, a condominium, a boarding house, a hostel, a hotel, etc.), a school, a hospital, a park, an airport, a railway station, a mall, a government office, a business complex (such as a business park, an enterprise complex, an enterprise office space, a coworking space, a factory, a warehouse complex, etc.), or the like. The building complex 101 may include a plurality of units (such as a unit 102 and a unit 103), and one or more common spaces (for example, a pool area 104, a community center gym 105, or the like). By way of an example, each of the plurality of units may correspond to a housing unit, a commercial unit, or a pre-defined area within the building complex 101. Some other examples of common spaces may include, but may not be limited to, a lounge area, a reception area, a common room, a waiting room, a guest room, a meeting room, a cafeteria, a food court, or the like.
[017] A unit may be vacant or may be occupied by a user. The term “occupied” may imply that the user is an owner of the unit (e.g., landlord, shopkeeper, etc.), a caretaker of the unit, a tenant in the unit (e.g., a hosteler, a guest, etc.), or a frequent visitor at the unit (e.g., an employee, a proprietor, etc.). For example, the unit 102 may be occupied by a first user and the unit 103 may be occupied by a second user. The term “user” may generally refer to an individual occupant or multiple occupants (such as a group of tenants, a resident family, employees, etc.) associated with the same unit. For ease of explanation, the first user and the second user correspond to individual users.
[018] The user may access internet based services, including Information Technology (IT) services and non-IT services, over the network 100 through a user device. The user device may be, for example, a smartphone, a tablet, a laptop, a desktop, a smartwatch, an Internet of Things (IoT) device, or the like. For example, the first user may possess two user devices, i.e., a user device 106A and a user device 106B. The second user may possess two user devices, i.e., a user device 107A and a user device 107B. The IT-based services or non-IT services may be provided by a managed service provider (MSP) over the network 100. Each of the first user and the second user may be registered to avail the IT-based services from the MSP.
[019] The network 100 may include a plurality of access points (APs) (such as an AP 108, an AP 109, an AP 110, an AP 111, an AP 112, and an AP 113). A user may access the IT-based services by connecting an associated user device to an AP through a unique ePSK. An AP may be located inside a unit of the building complex 101 or may be located at the common spaces. For example, the AP 108 may be located in the unit 102, the AP 109 may be located in the unit 103, the AP 112 may be located in the community center gym 105, and the AP 113 may be located in the pool area 104.
[020] Further, the network 100 may include a remote server 114, a gateway 115 communicatively connected to the remote server 114, and one or more switches (such as a switch 116 and a switch 117) communicatively connected to the gateway 115. The plurality of APs may be communicatively connected to the one or more switches. For example, the AP 109, the AP 110, and the AP 113 may be communicatively connected to the switch 116, and the AP 108, the AP 111, and the AP 112 may be communicatively connected to the switch 117.
[021] In an embodiment, the remote server 114 may be a remote network management server (e.g., cnMaestro™) of the MSP of the network 100. The remote server 114 may deploy, monitor, and manage the network 100 through cloud. In other words, the remote server 114 may manage internet access to user devices in the building complex 101. It should be noted that for efficient network management, the user devices may be logically divided into a plurality of Virtual Local Area Networks (VLANs). Each of the plurality of VLANs may include a VLAN ID. The gateway 115 may route data traffic (or internet traffic) between the internet (not shown in figure) and various network devices (i.e., the one or more switches and the plurality of APs) in the building complex 101 through the one or more switches. The one or more switches may route the internet traffic to devices of appropriate VLANs.
[022] To elaborate, each user device within a VLAN may be assigned the VLAN ID corresponding to that VLAN. User devices associated with occupants of a unit of the building complex 101 may be grouped into a single VLAN. There may be one or more dedicated VLANs for guests/visitors in the building complex. By way of an example, the user device 106A and the user device 106B, associated with the first user (occupant of the unit 102), may be assigned VLAN 100 as the VLAN ID. Similarly, the user device 107A and the user device 107B, associated with the second user (occupant of the unit 103), may be assigned VLAN 200 as the VLAN ID.
[023] The association of a user device with a VLAN may be determined through ePSKs. An ePSK is a cryptographic key generated based on an SSID of the network 100 and a password entered by the user. A unique ePSK may be mapped with each VLAN (i.e., each user or unit) in a pre-stored database. When a user device connects with the network 100 through an ePSK, the received ePSK may be identified in the pre-stored database. The VLAN corresponding to the received ePSK may be determined. The user device may then be associated with the corresponding VLAN. For example, the user device 106A may be operated by the first user (occupant of unit 102, assigned VLAN ID VLAN 100). However, when the first user connects the user device 106A to the network 100 using an ePSK of the unit 103, the user device 106A may then be associated with VLAN 200. Thus, each of the plurality of occupants of the building complex 101 can be assigned unique ePSKs to securely access the same network 100.
[024] Thus, the plurality of APs may bridge the data traffic from the connected user devices to the VLANs corresponding to the respective ePSKs. Further, since the plurality of VLANs is dynamically created based on the ePSK received from the connecting user devices rather than based on ports of the one or more switches, the user device may remain in the assigned VLAN even when that user device is located outside the associated unit of the user device. In some scenarios, the user may take the user device to another unit of the building complex 101 (i.e., when visiting or meeting another user in the another unit), or the user may take the user device to the common spaces in the building complex 101. In such scenarios, the user device may remain associated with the assigned VLAN. By way of an example, when the user device 107A is in the pool area 104, the VLAN associated with the user device 107A may still be VLAN 200 when the user device 107A is connected to the network 100 through the unique ePSK of the unit 103.
[025] In an embodiment, the user device 106A (operated by the first user) and the user device 107A (operated by the second user) both may connect to the same SSID (for example, SSID “A”) of the network 100, through their respective ePSKs. The connected SSID (i.e., SSID “A”) may remain unchanged when the user device 106A and the user device 107A are in the unit 102 and the unit 103, respectively, or in the common spaces. The unique ePSK corresponding to the first user may be ePSK “1” and the corresponding VLAN may be VLAN 100. The unique ePSK corresponding to the second user may be ePSK “2” and the corresponding VLAN may be VLAN 200. The user device 106A and the user device 107A may connect to the VLAN 100 and the VLAN 200, respectively, based on the unique ePSKs provided by the first user and the second user, respectively. Thus, irrespective of which AP the user device may connect to (i.e., the AP 108, the AP 109, the AP 110, the AP 111, the AP 112, or the AP 113), the user device operated by the user may remain a part of the same VLAN (or virtual micro-segmented network) and connected to the same SSID (i.e., SSID “A”).
[026] In an alternate embodiment, the ePSK may be extended to create a personal wireless network. In such an embodiment, the unit 102 corresponding the first user may be assigned a first personalized SSID, (for example, SSID “U1”) of the network 100 and the unit 103 corresponding the second user may be assigned a second personalized SSID (for example, SSID “U2”) of the network 100. Further, when the user device 106A operated by the first user and the user device 107A operated by the second user are in the common spaces, these user devices may connect to a common SSID (for example, SSID “PROPERTY”) of the network 100. However, the user device 106A may continue to use the ePSK “1” with the corresponding VLAN 100, and the user device 107A may continue to use the ePSK “2” with VLAN 200, respectively, regardless of the connected SSID. In other words, the user device may remain connected to the network 100 on both the corresponding unit SSID as well as the common SSID (i.e., SSID “PROPERTY”). Thus, by providing such personal wireless networks, the user experience in the unit is enhanced and the roaming experience is maintained as before. Further, in such an embodiment, the home unit APs (i.e., the AP 108, the AP 109, the AP 110, and the AP 111) may also publish the common SSID (i.e., SSID “PROPERTY”) for any visiting community users to provide a ubiquitous coverage across the whole property.
[027] To reduce network management overhead for the MSPs and property managers, many deployments of the network 100 may provide a user portal (such as a self-service portal) to the occupants where for performing operations such as looking up the corresponding unique ePSK, resetting the ePSK, looking at a list of associated user devices, adding or removing user devices, viewing data usage, managing security settings, managing parental controls, raising a support ticket, and the like. Typically, a separate user account for the user portal may be required to be added and managed for each of the plurality of units. In some embodiments, the gateway 115 may also terminate tunnels from each of the plurality of APs in some deployments, where the VLAN tagged traffic is transported over the top of the switches.
[028] Referring now to FIG. 2, a functional block diagram of an exemplary system 200 for managing communication between a plurality of network nodes of a distributed network is illustrated, in accordance with some embodiments. The system 200 may be deployed to overcome the problem of adding and managing of separate user accounts for the user portal, as described in detail in conjunction with FIG.1. In an embodiment, the system 200 may be implemented in the network 100. The system 200 may include the remote server 114 and the AP 109 communicatively connected to the remote server 114 via a switch and a gateway (not shown in figure). Additionally, the user device 107A and the user device 107B are communicatively connected to the AP 109 using a unique ePSK of the second user. For ease of explanation, a part of the network 100 is shown to describe the functioning of the system 200. The system 200 may, thus, include additional APs (for example, the AP 108, the AP 110, the AP 111, the AP 112, and the AP 113) and user devices (for example, the user device 106A and the user device 106B), each analogous to the AP 109 and the user devices 107A and 107B, respectively, as described in conjunction with FIG. 1.
[029] The remote server 114 may include a processor 201 and a memory 202. Further, the memory 202 may include a validation module 203 and a user portal module 204. The AP 109 may include a processor 205 and a memory 206. The memory 206 may include an authentication module 207, a communication establishment module 208, and a database 209. Each of the user device 107A and the user device 107B may also include a processor and a memory (not shown in the figure).
[030] The AP 109 may receive, from a user device (for example, the user device 107A operated by the second user), an access request to the user portal hosted on the remote server 114. The user portal may include a self-service portal hosted on the remote server 114 of a wireless network provider (i.e., the MSP for the network 100). In an embodiment, the self-service portal may be a self-service ePSK management portal. Alternatively, the user portal may include an external portal hosted on a trusted third-party server. In such an embodiment, the trusted third-party server and the remote server 114 of the network provider have an established trust with each other. Further, the trusted third-party server may be integrated with the remote server 114 through an Application Programming Interface (API). This is further explained in detail in conjunction with FIG. 5.
[031] In an embodiment, the access request to the user portal may be sent by scanning a machine-readable code (for example, a Quick Response (QR) code, a Datamatrix code, High Capacity Color Barcode (HCCB), an Aztec code, a Shotcode, a MaxiCode, or any other type of 2D barcode, a linear barcode, or the like). The machine-readable code may be generated by an MSP administrator. Multiple copies of the machine-readable code may be located in various areas of the building complex 101. The second user may scan one of the multiple copies through a camera of the user device 107A to send, to the AP 109, the access request to the user portal.
[032] Alternatively, the access request may be sent through a vanity Uniform Resource Locator (URL) (i.e., a custom short URL). By way of an example, the vanity URL may be “wifi.local”, “my.wifi”, “wifi..com”, “wifi..com”, and the like. The vanity URL may be easy to remember or branded by the MSP or the building complex 101. In such an embodiment, the second user may enter the vanity URL in a browser application on the user device 107A. In some embodiments, if the vanity URL is based on a Multicast Domain Name System (mDNS) domain, the AP 109 may resolve the vanity URL to an appropriate URL of the user portal, using mDNS protocol.
[033] The authentication module 207 may generate a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user. The pre-stored additional information may be pre-stored in the database 209. More specifically, the database 209 may include the unique ePSK of each of the plurality of users (i.e., occupants and guests) in the network 100. The unique ePSK of each user may be mapped with the corresponding pre-stored additional information in the database 209. The authentication module 207 may extract the pre-stored additional information corresponding to the unique ePSK. Further, the authentication module 207 may append the pre-stored additional information to the access request. The pre-stored additional information may include user device information (e.g., Media Access Control (MAC) address of the user device 107A), AP information (e.g., MAC address of the AP 109), wireless network information (e.g., SSID of the network 100), and AP authentication information (e.g., signature corresponding to the authorization of the AP 109 by the remote server 114).
[034] In an embodiment, the pre-stored additional information corresponding to an ePSK may be “apmac=ABC&climac=XYZ&ssid=PQR&sign=jsdkjk3j4k2jewj3j”. In such an embodiment, parameter ‘apmac’ in the pre-stored additional information may correspond to a MAC address of the AP 109. The value corresponding to the parameter ‘apmac’ is ‘ABC’. Parameter ‘climac’ may correspond to a MAC address of the user device 107A. The value corresponding to the parameter ‘climac’ is ‘XYZ’. Parameter ‘ssid’ may correspond to SSID of the network 100. The value corresponding to the parameter ‘ssid’ is ‘PQR’. Parameter ‘sign’ may correspond to signature (or authentication information) indicating that the AP 109 is trusted by the remote server 114. The value corresponding to the parameter ‘sign’ is ‘jsdkjk3j4k2jewj3j’.
[035] It should be noted that, in some embodiments, the pre-stored additional information corresponding to the unique ePSK may not be found in the database 209 (for example, when the unique ePSK corresponds to a guest ePSK). In such embodiments, the authentication module 207 may not generate the pre-authenticated access request. Further, in such embodiments, a login screen of the user portal may be rendered on the user device 107A, thereby prompting the user to enter login credentials corresponding to a separate user account registered with the user portal. Upon successful validation of the login credentials, the validation module 203 may may trigger the user portal module 204 to initiate data exchange corresponding to the user portal to the user device 107A, via the communication establishment module 208 of the AP 109. The user portal module 204 may then render the user portal on the user device 107A.
[036] In embodiments, where the pre-authenticated request is generated, the authentication module 207 may then transmit the pre-authenticated access request to the remote server 114 for validation. The validation module 203 of the remote server 114 may receive and validate the pre-authenticated access request. The validation of the pre-authenticated access request may be based on the user device information, the AP information, the wireless network information, and the AP authentication information. In an embodiment, the validation module 203 may validate the AP authentication information using a signature verification method. Upon successful validation, the validation module 203 may trigger the user portal module 204 to initiate data exchange corresponding to the user portal to the user device 107A, via the communication establishment module 208 of the AP 109. The user portal module 204 may then render the user portal on the user device 107A without further authentication. That is to say, a Single Sign On (SSO) feature may be implemented for the user portal for user devices connected to the network 100 through ePSK. In other words, logging into a separate user account for the user portal may not be required as the authentication is performed based on the unique ePSK through which the user device 107A is connected to the AP 109.
[037] The communication establishment module 208 may enable a communication between the user device 107A and the remote server 114 for rendering of the user portal upon on the successful validation of the pre-authenticated access request or based on the successful validation of the login credentials.
[038] As an added security measure for certain features of SSO (for example, to prevent unauthorized changing/resetting of the PSK), an email verification can be used. This may prevent one of the family members (e.g., kids) or guests from changing any such setting without the permission of the unit owner (in this case, the second user). Further, MAC filters may be used to assign roles and rights to certain user devices to prevent operations, including editing and viewing. To this end, the pre-stored additional information may include role-based access control information (i.e., user role and/or permissions corresponding to the user). This may be based on the MAC address of the user device. This may allow the unit owner to restrict access or provide limited access to certain user devices (for example, user devices operated by kids or guests) to the user portal. Thus, a user device may be presented on the user portal with information that is allowed by the owner, based on the user role associated with the user device. This way role-based-access-control (RBAC) can also be supported in addition to SSO. In an embodiment, a feature may be provided to the unit owner (in this case, the second user – owner of the unit 103) to define a separate password for guests. In such an embodiment, the guests may be allowed to connect to the VLAN 200 (the VLAN designated for the second user) with a separate ePSK (i.e., guest ePSK) whereas the second user and other residents of the unit 103 may connect to the VLAN 200 with a unit ePSK. Both the unit ePSK and the guest ePSK may be mapped to the VLAN 200. However, the guest ePSK may not be authorized for SSO and may be prompted to provide user credentials for the user portal account to login to the user portal.
[039] Also, upon unsuccessful validation, the validation module 203 may trigger the user portal module 204 to render a login screen of the user portal on the user device 107A, requiring further authentication. Alternatively, the validation module 203 may block access of the user device 107A to the user portal displaying a message citing denial of the access due to unsafe connection. In such an embodiment, a recommendation may be displayed asking the user to reconnect to the network 100.
[040] It should be noted that all such aforementioned modules 203-204, and 207-209 may be represented as a single module or a combination of different modules. Further, as will be appreciated by those skilled in the art, each of the modules 203-204, and 207-209 may reside, in whole or in parts, on one device or multiple devices in communication with each other. In some embodiments, each of the modules 203-204, and 207-209 may be implemented as dedicated hardware circuit comprising custom application-specific integrated circuit (ASIC) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Each of the modules 203-204, and 207-209 may also be implemented in a programmable hardware device such as a field programmable gate array (FPGA), programmable array logic, programmable logic device, and so forth. Alternatively, each of the modules 203-204, and 207-209 may be implemented in software for execution by various types of processors (e.g., the processor 201 or the processor 205). An identified module of executable code may, for instance, include one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, function, or other construct. Nevertheless, the executables of an identified module or component need not be physically located together, but may include disparate instructions stored in different locations which, when joined logically together, include the module and achieve the stated purpose of the module. Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[041] As will be appreciated by one skilled in the art, a variety of processes may be employed for managing access to a user portal using an ePSK in a wireless network. For example, the exemplary system 200 may manage access to a user portal using an ePSK in a wireless network by the processes discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 200 either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by the one or more processors on the system 200 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some, or all of the processes described herein may be included in the one or more processors on the system 200.
[042] Referring now to FIG. 3, an exemplary process 300 for managing access to user portal using ePSK in wireless network (such as the network 100) is depicted via a flowchart, in accordance with some embodiments. The process 300 may be implemented by the system 200. The process 300 may include receiving, by an AP (for example, the AP 109) and from a user device (for example, the user device 107A), an access request to the user portal hosted on a remote server, at step 301. The AP may be one of a plurality of APs (for example, the AP 108, the AP 109, the AP 110, the AP 111, the AP 112, and the AP 113) in the wireless network. The user device may be communicatively connected to the AP using a unique ePSK of a user. The access request may be provided from the user device by scanning a machine-readable code (such as a QR code) or by entering a vanity URL. In some embodiments, the user portal may include a self-service portal hosted on the remote server of the wireless network provider. Alternatively, the user portal may include an external portal hosted on a trusted third-party server. The trusted third-party server may be trusted (or authorized) by the wireless network provider through a validation mechanism (for example, using a digital root certificate). Similarly, the wireless network provider may be trusted (or authorized) by the trusted third-party server. In other words, both the trusted third-party server and the remote server of the wireless network provider have an established trust between them.
[043] Further, the process 300 may include generating, by the AP, a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user, at step 302. The AP may search for the pre-stored additional information corresponding to the unique ePSK in a database. The step 302 of the process 300 may include appending the pre-stored additional information to the access request, at step 303. The pre-stored additional information may include user device information, AP information, wireless network information, and AP authentication information. In some embodiments, where the access request is made by the user device using the vanity URL, the AP may resolve the vanity URL to an appropriate URL of the user portal using mDNS protocol.
[044] By way of an example, the AP 109 may be connected with the user device 107A through a unique ePSK ‘secretpassword123’ associated with the second user in the building complex 101. When an access request for the user portal is received from the user device 107A, the authentication module 207 may check the database 209 for pre-stored additional information corresponding to ‘secretpassword123’. The pre-stored additional information corresponding to ‘secretpassword123’ may be ‘apmac=ABC&climac=XYZ&ssid=PQR&sign=jsdkjk3j4k2jewj3j’. It should be noted that ‘apmac’, ‘climac’, ‘ssid’, and ‘sign’ may correspond to user device information, AP information, wireless network information, and AP authentication information, respectively. Further, the authentication module 207 may append the pre-stored additional information to the access request to obtain a pre-authenticated access request.
[045] Further, the process 300 may include transmitting, by the AP, the pre-authenticated access request to the remote server for validation, at step 304. It should be noted that, in some embodiments, the pre-authenticated access request may be referred to as a signed access request. The validation of the pre-authenticated access request may be based on the pre-stored additional information (i.e., the user device information, the AP information, the wireless network information, and the AP authentication information). The validation may be performed to check the authenticity of the AP (i.e., whether the AP is a valid AP or a rogue AP), the user device, and the wireless network.
[046] Further, the process 300 may include establishing, by the AP, a communication between the user device and the remote server for rendering of the user portal based on the validation, at step 305. It should be noted that the rendering of the user portal on the user device at step 305 is without any further authentication. In continuation of the example above, the authentication module 207 may transmit the pre-authenticated request to the remote server 114. The validation module 203 of the remote server 114 may validate the pre-stored additional information in the pre-authenticated access request. In some embodiments, upon successful validation, the user portal module 204 may render the user portal to the user device 107A via the communication establishment module 208, without requiring any additional access credentials. As will be appreciated, the authentication module 207 and/or communication establishment module 208 may be a simple proxy to establish a communication between the user device 107A and the remote server 114. For example, the authentication module 207 in conjunction with the communication establishment module 208 may modify an incoming http request (i.e., access request) from the user device 107A by appending keys and signature to the http request. Further, the user portal module 204 of the remote server 114 may render the user portal to the user device 107A without requiring any additional access credentials.
[047] Referring now to FIG. 4, a detailed exemplary process 400 for managing access to user portal using ePSK in wireless network (such as the network 100) is schematically depicted via a flowchart, in accordance with an embodiment. The process 400 may be implemented by the system 200 over the network 100. For sake of simplicity, the process 400 is explained through some components (i.e., the remote server 114, the gateway 115, the switch 116, the AP 109, and the user device 107A) of the network 100. However, it should be noted that the aforementioned components are representatives for other analogous components in the network 100. At step 1 of the process 400, an MSP administrator 401 may create and/or set up user access to a self-service portal 402 for the network 100 corresponding to the building complex 101. The self-service portal 402 may be hosted on the remote server 114.
[048] At step 2 of the process 400, the remote server 114 may configure the AP 109 with details of the self-service portal 402. It should be noted that each of the plurality of APs in the network 100 may be configured with the details of the self-service portal 402. However, for ease of explanation, the AP 109 is used as an exemplary representative of each of the plurality of APs, and any of the steps described as being performed by the AP 109 in the foregoing description in conjunction with the FIG. 4 may also be performed through any of the plurality of APs.
[049] At step 3 of the process 400, the MSP administrator 401 may print and deploy a machine-readable code 403 (such as a QR code) in each unit of the building complex 101 for easy access to the occupants. In an embodiment, when creating the portal, the admin can choose to use mDNS domain. In this case, the machine-readable code 403 may direct to a URL, such as http://my.wi-fi.local or http://wi-fi.lakeview.local (where ‘lakeview’ is the name of the building complex 101) or http://wi-fi.acme-msp.local. The URL may be a vanity URL which is easy to remember. Therefore, a user may access the user portal by scanning the machine-readable code 403 or by directly entering the vanity URL (which the machine-readable code 403 directs to) in a browser application of the user device.
[050] The self-service portal 402 may be hosted on the remote server 114 on a unique URL (such as epsk-portals.cloud.cambiumnetworks.com). For each network (such as the network 100) in the building complex 101, the self-service portal 402 may be linked to a unique WLAN URL. For example, the unique WLAN URL may be http://epsk-portals.cloud.cambiumnetworks.com/resident/123r-aseae-43dfea4-as4e/. It may be noted that usage of HyperText Transfer Protocol (HTTP) in vanity URLs, unique URLs, and unique WLAN URLs may allow the AP to intercept the access request. The remote server 114 may push a configuration to the plurality of APs. The configuration may include the unique WLAN URL of the portal for the community network including the plurality of APs as well as mDNS host name. A signature verification method may be pre-established between the remote server 114 and the AP 109 by way of secure onboarding and existing management relationship. Thus, if the AP 109 may sign some data (i.e., add a signature to the data), the remote server 114 may independently verify whether the data was signed by the AP 109 or some rogue AP disguising as the AP 109.
[051] It should be noted that the steps 1-3 of the process 400 may constitute a sub-process corresponding to creating and configuring the self-service portal 402.
[052] In an exemplary scenario, at step 4 of the process 400, the user device 107A may connect to the network 100 using a unique ePSK. The second user may provide the unique ePSK (e.g., ‘secretpassword123’) associated with the VLAN of the unit 103 (i.e., ‘VLAN 200’) from the user device 107A. Further, the user device 107A may send a connection request to the AP 109. The connection request may include the unique ePSK. Further, the AP 109 may validate the connection request. Upon successful validation, the user device 107A may connect with the network 100. In other words, the user device 107A may receive internet access from the network 100. It should be noted that for ease of explanation, the user device 107A is used as an exemplary representative of each of the plurality of user devices connected to the network 100, and any of the steps described as being performed by the user device 107A in the foregoing description in conjunction with the FIG. 4 may also be performed through any user device that is connected to the network 100 through one of the plurality of APs.
[053] At step 5 of the process 400, to access the self-service portal 402, the second user may scan the machine-readable code 403 using a camera of the user device 107A or may enter the vanity URL in a browser application of the user device 107A.
[054] At step 6 of the process 400, the browser application of the user device 107A may be redirected to the unique WLAN URL. The user device 107A may thus send an access request for the self-service portal 402 to the AP 109.
[055] At step 7 of the process 400, the AP 109 may handle DNS resolution (or mDNS resolution based on the protocol used) and may resolve a hostname of the self-service portal 402 to an IP address of the AP 109. If mDNS is configured, the AP 109 may resolve an mDNS hostname of the self-service portal 402 to the IP address of the AP 109. If mDNS is not configured, the AP 109 may resolve the unique URL, i.e., ‘epsk-portals.cloud.cambiumnetworks.com’, (used as an example previously) only for user devices connected over the ePSK WLAN (i.e., the network 100).
[056] At step 8 of the process 400, portal traffic (i.e., data packets for the self-service portal 402) transmitted by the user device 107A may be filtered and captured by an AP web server running on the AP 109. The AP web server may add pre-stored additional information to the access request and may sign the access request to obtain a pre-authenticated access request. Further, the AP web server may redirect the user device 107A to the self-service portal 402 via the pre-authenticated access request.
[057] Use of HTTP URLs ensures that the AP 109 can handle the URLs locally without having a public Hypertext Transfer Protocol Secure (HTTPS) server certificate. This simplifies the approach to intercept connections of the user device 107A to the self-service portal 402 via the network 100. In both mDNS enabled or mDNS disabled cases, the access request to the self-service portal 402 from the user device 107A connected to the network 100 using the unique ePSK may be received by a tiny HTTP web server (i.e., the AP web server) running on the AP 109. The AP web server may add some query parameters (i.e., the pre-stored additional information) to the HTTP request (i.e., the access request) to generate the pre-authenticated access request. Further, the AP may then redirect the browser application of the user device 107A to a redirected URL corresponding to the self-service portal 402 through the pre-authenticated access request. For example, the redirected URL may be ‘https://epsk-portals.cloud.cambiumnetworks.com/resident/123r-aseae-43dfea4-as4e?apmac=ABC&climac=XYZ&ssid=PQR&sign=jsdkjk3j4k2jewj3j’. It should be noted that the redirected URL includes HTTPS, and that the AP 109 adds a signature of the added query parameters to the access request, in a required format of the self-service portal 402. It should also be noted that the browser application of the user device 107A may send a full URL (for example, ‘http://epsk-portals.cloud.cambiumnetworks.com/resident/123r-aseae-43dfea4-as4e/’) if the mDNS is disabled, whereas the browser application may only use a fancy host name (i.e., the vanity URL) and the AP 109 may generate the full URL based on the configuration received from the remote server 114 if the mDNS is enabled.
[058] At step 9 of the process 400, the browser application of the user device 107A may connect to the self-service portal 402 through the pre-authenticated request received from the AP 109.
[059] At step 10 of the process 400, the self-service portal 402 may validate the pre-authenticated access request received from the AP 109 for the user device 107A. Further, the self-service portal 402 may trigger an SSO for the second user, presenting the self-service portal 402 on the user device 107A without requiring any login credentials from the second user. When the self-service portal 402 receives the pre-stored additional information via the redirected URL from the AP 109, the self-service portal 402 may verify the AP signature in the pre-authenticated access request with a predefined signing key of the AP 109. It should be noted that the predefined signing key of the AP 109 may be pre-stored in a database accessible to the remote server 114. If the AP signature matches with the predefined signing key, the SSO may be initiated with no additional login steps.
[060] It should be noted that the steps 4-10 of the process 400 may constitute a sub-process corresponding to accessing the self-service portal 402 via SSO upon successful validation of the ePSK.
[061] In another exemplary scenario, the user device 107B may not be connected to the network 100 (i.e., the user device 107B is accessing internet services through a different network (e.g., a public internet network)), may be connected to the network 100 via an ePSK corresponding to guests and visiting members, or may be connected to the network 100 via a predefined ePSK for which the SSO feature may be unavailable. At step 11 of the process 400, to access the self-service portal 402, the second user may scan the machine-readable code 403 using the camera of the user device 107B or may enter the vanity URL in the browser application of the user device 107B.
[062] At step 12 of the process 400, when the user device 107B is connected to a different network (other than the network 100), the browser application of the user device 107B may be redirected directly to the self-service portal 402. In other words, the user device 107B may not be directed to the self-service portal 402 via the AP web server of the AP 109. When the user device 107B is connected to the network 100 through the AP 109 using a guest ePSK or any other restricted-access ePSK, the AP web server may also direct the browser application to the self-service portal 402 without generating the pre-authenticated request.
[063] At step 13 of the process 400, the self-service portal 402 may receive the access request from the user device 107B without a signature from any of the plurality of APs in the network 100. Thus, the SSO may be disabled and a login screen may be rendered on the user device 107B. When connecting via the public internet, the self-service portal 402 may redirect the HTTP request to HTTPS before acting on it. As will be appreciated, this is a standard practice for web servers.
[064] It should be noted that the steps 11-13 of the process 400 may constitute a sub-process corresponding to denying an access to the self-service portal 402 via SSO upon failed validation of the ePSK.
[065] Referring now to FIG. 5, a detailed exemplary process 500 for managing access to user portal hosted on a third-party server using ePSK in wireless network (such as the network 100) is schematically depicted via a flowchart, in accordance with an embodiment. The process 500 may be implemented by the system 200 over the network 100. For sake of simplicity, the process 500 is explained through some components (i.e., the remote server 114, the gateway 115, the switch 116, the AP 109, and the user device 107A) of the network 100. However, it should be noted that the aforementioned components are representatives for other analogous components in the network 100. At step 1 of the process 500, the MSP administrator 401 may create an API key for an external portal 501 hosted on the third-party server 502 so as to provide seamless access to the external portal 501 to users of the network 100 through the remote server 114.
[066] At step 2 of the process 500, the MSP administrator 401 may create the external portal 501 hosted on the third-party server 502 using the API. The API may enable data exchange between the remote server 114 and the third-party server 502. The MSP administrator 401 may also use a management console of the third-party server 502 to configure an API key for the remote server 114. The external portal 501 may be analogous to the self-service portal 402. The external portal 501 may be hosted on the third-party server 502 of the network 100.
[067] At step 3 of the process 500, the third-party server 502 may use the API key (provided in step 2) to configure the external portal 501 in the plurality of APs through the third-party server 502. Additionally, at the step 3, the third-party server 502 may receive a trusted signing issuer certificate (a root certificate) from the remote server 114 upon authentication of the API key. It should be noted that the step 3 may also be performed manually, being a one-time process. In other words, the third-party server 502 may verify messages signed by AP certificates issued by the remote server 114.
[068] At step 4 of the process 500, the remote server 114 may configure the AP 109 with details of the external portal 501. It should be noted that each of the plurality of APs in the network 100 may be configured with the details of the external portal 501. However, for ease of explanation, the AP 109 is used as an exemplary representative of each of the plurality of APs, and any of the steps described as being performed by the AP 109 in the foregoing description in conjunction with the FIG. 5 may also be performed through any of the plurality of APs.
[069] At step 5 of the process 500, the AP 109 may create a digital certificate and may send a certificate signing request for the digital certificate to the remote server 114. A Certificate Authority (CA) of the remote server 114 may sign the digital certificate.
[070] At step 6 of the process 500, the MSP administrator 401 may print and deploy the machine-readable code 403 in each unit of the building complex 101 for easy access to the occupants. This has been already discussed in detail in conjunction with FIG. 4.
[071] It should be noted that the steps 1-6 of the process 500 may constitute a sub-process corresponding to creating and configuring the external portal 501.
[072] In an exemplary scenario, at step 7 of the process 500, the user device 107A may connect to the network 100 using a unique ePSK. This has already been discussed in detail in conjunction with FIG. 4.
[073] At step 8 of the process 500, to access the external portal 501, the second user may scan the machine-readable code 403 using a camera of the user device 107A or may enter the vanity URL in a browser application of the user device 107A.
[074] At step 9 of the process 500, the browser application of the user device 107A may be redirected to the unique WLAN URL. The user device 107A may thus send an access request for the external portal 501 to the AP 109.
[075] At step 10 of the process 500, the AP 109 may handle DNS resolution (or mDNS resolution based on the protocol used) and may resolve a hostname of the external portal 501 to an IP address of the AP 109. This has already been discussed in detail in conjunction with FIG. 4.
[076] At step 11 of the process 500, portal traffic (i.e., data packets for the external portal 501) transmitted by the user device 107A may be filtered and captured by an AP web server running on the AP 109. The AP web server may add pre-stored additional information to the access request and may sign the access request with the digital certificate created at step 5 to obtain a pre-authenticated access request. Further, the AP web server may redirect the user device 107A to the external portal 501 via the pre-authenticated access request.
[077] At step 12 of the process 500, the browser application of the user device 107A may connect to the external portal 501 through the pre-authenticated request received from the AP 109.
[078] At step 13 of the process 500, the external portal 501 may validate the pre-authenticated access request received from the AP 109 for the user device 107A. Further, the external portal 501 may trigger an SSO for the second user, presenting the external portal 501 on the user device 107A without requiring any login credentials from the second user. When the external portal 501 receives the pre-stored additional information via the redirected URL from the AP 109, the external portal 501 may verify the AP signature in the pre-authenticated access request with a predefined signing key of the AP 109. It should be noted that the predefined signing key of the AP 109 may be verified against the root certificate provided by the third-party server 502 in step 3. If the AP signature matches with the predefined signing key, the SSO may be initiated with no additional login steps.
[079] It should be noted that the steps 7-13 of the process 500 may constitute a sub-process corresponding to accessing the external portal 501 via SSO upon successful validation of the ePSK.
[080] In another exemplary scenario, the user device 107B may not be connected to the network 100 (i.e., the user device 107B is accessing internet services through a different network (e.g., a public internet network)), may be connected to the network 100 via an ePSK corresponding to guests and visiting members, or may be connected to the network 100 via a predefined ePSK for which the SSO feature may be unavailable. At step 14 of the process 500, to access the external portal 501, the second user may scan the machine-readable code 403 using the camera of the user device 107B or may enter the vanity URL in the browser application of the user device 107B.
[081] At step 15 of the process 500, when the user device 107B is connected to a different network (other than the network 100), the browser application of the user device 107B may be redirected directly to the external portal 501. In other words, the user device 107B may not be directed to the external portal 501 via the AP web server of the AP 109. When the user device 107B is connected to the network 100 through the AP 109 using a guest ePSK or any other restricted-access ePSK, the AP web server may also direct the browser application to the external portal 501 without generating the pre-authenticated request.
[082] At step 16 of the process 500, the external portal 501 may receive the access request from the user device 107B without a signature from any of the plurality of APs in the network 100. Thus, the SSO may be disabled and a login screen may be rendered on the user device 107B.
[083] It should be noted that the steps 11-16 of the process 500 may constitute a sub-process corresponding to denying an access to the external portal 501 via SSO upon failed validation of the ePSK.
[084] It should be noted that a major difference between the process 400 and the process 500 is that an implicit trust between the user device 107A and the third-party server 502 is absent in the process 500, when compared to that between the user device 107A and the remote server 114. Thus, in the process 500, the trust should be explicitly established between the user device 107A and the third-party server 502. The establishing of the trust may be done using a standard practice of using digital certificates, especially when the process 500 is to be implemented at scale.
[085] Differences between the process 400 and the process 500 lie in setting up the system 200. In process 500, the MSP administrator 401 may create an API key so that the third-party server 502 can exchange data with the remote server 114, at step 1. The third-party server 502 may then use the API key (or API token) to call the API of the remote server 114 to create the third-party external portal 501, at step 3. This may cause the remote server 114 to generate a new root certificate that can be used by each of the plurality of APs in the trusted group (defined by a site, network, etc.) to generate a per-AP child signing certificate (i.e., the digital certificate). The root certificate and the child certificates (i.e., the digital certificate) may include specific details about the network 100 and the certificate-issuing AP (e.g., network name, AP serial number, etc.). At the step 13 of the process 500, this may allow the external portal 501 on the third-party server 502 to verify the AP signature inserted by the AP using the root certificate provided by the remote server 114 at step 3 of the process 500.
[086] As will be also appreciated, the above described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[087] Thus, the disclosed method and system try to overcome the technical problem of managing access to a user portal using an ePSK in a wireless network. The method and system receive, by an AP and from a user device, an access request to the user portal hosted on a remote server. The AP is one of a plurality of APs in a wireless network. The user device is communicatively connected to the AP using a unique ePSK of a user. Further, the method and system generate, by the AP, a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user. Further, the method and system transmit, by the AP, the pre-authenticated access request to the remote server for validation. Further, the method and system establish, by the AP, a communication between the user device and the remote server for rendering of the user portal based on the validation.
[088] As will be appreciated by those skilled in the art, the techniques described in the various embodiments discussed above are not routine, or conventional, or well understood in the art. The techniques discussed above provide for managing access to a user portal using an ePSK in a wireless network. The techniques provide a Single Sign On (SSO) access to the user portal to users of the wireless network. The users already connected to the wireless network may not be required to provide login credentials of a separate portal user account, making the user portal more accessible and user-friendly to operate. Access to portal may be simplified further by generating machine-readable codes (e.g., QR codes) that may direct the user to the user portal. The techniques facilitate a truly self-service portal, with minimal intervention from MSP administrators. The techniques allow the users to assign user roles and rights to prevent unauthorized change of security settings (e.g., change of password or PSK) through MAC filters.
[089] In light of the above-mentioned advantages and the technical advancements provided by the disclosed method and system, the claimed steps as discussed above are not routine, conventional, or well understood in the art, as the claimed steps enable the following solutions to the existing problems in conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the device itself as the claimed steps provide a technical solution to a technical problem.
[090] The specification has described method and system for managing access to a user portal using an ePSK in a wireless network. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[091] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[092] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims. , Claims:CLAIMS
I/We claim:
1. A method (300) for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network, the method (300) comprising:
receiving (301), by an access point (AP) (109) and from a user device (107A), an access request to the user portal hosted on a remote server (114), wherein the AP (109) is one of a plurality of APs in a wireless network, and wherein the user device (107A) is communicatively connected to the AP (109) using a unique ePSK of a user;
generating (302), by the AP (109), a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user;
transmitting (304), by the AP (109), the pre-authenticated access request to the remote server (114) for validation; and
establishing (305), by the AP (109), a communication between the user device (107A) and the remote server (114) for rendering of the user portal based on the validation.

2. The method (300) as claimed in claim 1, wherein the user portal comprises a self-service portal hosted on the remote server (114) of the wireless network provider.

3. The method (300) as claimed in claim 1, wherein the user portal comprises an external portal hosted on a trusted third-party server, and wherein the trusted third-party server and the remote server (114) of the wireless network provider have an established trust with each other.

4. The method (300) as claimed in claim 1, wherein generating (302) the pre-authenticated access request comprises appending (303) the pre-stored additional information to the access request, and wherein the pre-stored additional information comprises at least one of user device information, AP information, wireless network information, AP authentication information, or role-based access control information.

5. The method (300) as claimed in claim 4, wherein the validation of the pre-authenticated access request is based on the user device information, the AP information, the wireless network information, and the AP authentication information.

6. The method (300) as claimed in claim 1, wherein rendering comprises rendering the user portal on the user device (107A) without further authentication.

7. The method (300) as claimed in claim 1, wherein generating the pre-authenticated access request comprises:
resolving, by the AP (109), a vanity URL or a machine-readable code to an appropriate URL of the user portal, when the access request is made by the user device (107A) using the vanity URL or the machine-readable code.

8. A system (200) for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network, the system (200) comprising:
a remote server (114); and
a plurality of access points (APs), each communicatively coupled to the remote server (114), wherein each AP of the plurality of APs is configured to:
receive (301), from a user device (107A), an access request to the user portal hosted on the remote server (114), wherein the user device (107A) is communicatively connected to the AP (109) using a unique ePSK of a user;
generate (302) a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user;
transmit (304) the pre-authenticated access request to the remote server (114) for validation; and
establish (305) a communication between the user device (107A) and the remote server (114) for rendering of the user portal based on the validation.

9. The system (200) as claimed in claim 8, wherein the user portal comprises a self-service portal hosted on the remote server (114) of the wireless network provider.

10. The system (200) as claimed in claim 8, wherein the user portal comprises an external portal hosted on a trusted third-party server, and wherein the trusted third-party server and the remote server (114) of the wireless network provider have an established trust with each other.

11. The system (200) as claimed in claim 8, wherein to generate (302) the pre-authenticated access request, the AP (109) is configured to append (303) the pre-stored additional information to the access request, and wherein the pre-stored additional information comprises at least one of user device information, AP information, wireless network information, AP authentication information, or role-based access control information.

12. The system (200) as claimed in claim 11, wherein the validation of the pre-authenticated access request is based on the user device information, the AP information, the wireless network information, and the AP authentication information.

13. The system (200) as claimed in claim 8, wherein rendering of the user portal on the user device (107A) is without further authentication.

14. The system (200) as claimed in claim 8, wherein to generate the pre-authenticated access request, the AP (109) is configured to:
resolve a vanity URL or a machine-readable code to an appropriate URL of the user portal, when the access request is made by the user device (107A) using the vanity URL or the machine-readable code.

15. An access point (AP) (109) for managing access to a user portal using an enhanced Pre-Shared Key (ePSK) in a wireless network, the AP (109) comprising:
a processor (205); and
a memory (206) communicatively coupled to the processor (205), wherein the memory (206) stores processor instructions, which when executed by the processor (205), cause the processor (205) to:
receive (301), from a user device (107A), an access request to the user portal hosted on a remote server (114), wherein the AP (109) is one of a plurality of APs in a wireless network, and wherein the user device (107A) is communicatively connected to the AP (109) using a unique ePSK of a user;
generate (302) a pre-authenticated access request corresponding to the access request based on the unique ePSK and pre-stored additional information related to the user;
transmit (304) the pre-authenticated access request to the remote server (114) for validation; and
establish (305) a communication between the user device (107A) and the remote server (114) for rendering of the user portal based on the validation.

16. The AP (109) as claimed in claim 15, wherein the user portal comprises a self-service portal hosted on the remote server (114) of the wireless network provider.

17. The AP (109) as claimed in claim 15, wherein the user portal comprises an external portal hosted on a trusted third-party server, and wherein the trusted third-party server and the remote server (114) of the wireless network provider have an established trust with each other.

18. The AP (109) as claimed in claim 15, wherein to generate (302) the pre-authenticated access request, the processor instructions, on execution, cause the processor (205) to append (303) the pre-stored additional information to the access request, and wherein the pre-stored additional information comprises at least one of user device information, AP information, wireless network information, AP authentication information, or role-based access control information.

19. The AP (109) as claimed in claim 18, wherein the validation of the pre-authenticated access request is based on the user device information, the AP information, the wireless network information, and the AP authentication information.

20. The AP (109) as claimed in claim 15, wherein rendering of the user portal on the user device (107A) is without further authentication.

21. The AP (109) as claimed in claim 15, wherein to generate the pre-authenticated access request, the processor instructions, on execution, cause the processor (205) to:
resolve a vanity URL or a machine-readable code to an appropriate URL of the user portal, when the access request is made by the user device (107A) using the vanity URL or the machine-readable code.