POLICY MANAGEMENT SYSTEM FOR PROVIDING AUTHORISATION INFORMATION VIA A DISTRIBUTED DATA STORE

Abstract

Procedure comprising: Receiving, by a Policy Management (PM) cluster (115), an access request message associated with a client device (105) and a user of the client device (105), wherein the access request message comprises a request to access a network infrastructure (700) partially managed by the PM cluster (115), wherein the PM cluster (115) comprises a plurality of PM nodes (210); in response to the access request message, determining, by the PM cluster (115), a role of the user, the role being associated with a scope of permitted access of the user to the network infrastructure (700); Extending a data set in a distributed data store (220) accessible by each PM node (210) of the plurality of PM nodes (210) to provide each PM node (210) of the plurality of PM nodes (210) with information about the role; Receiving, by the PM cluster (115), a first account request message associated with the client device (105) and the user, the first account request message comprising a request to access a specific service or resource of the network infrastructure (700); In response to the first account request message, accessing, by the PM cluster (115), the record to extend the first account request message by the role and provide a second account request message; and Providing the second account request message to a computing device (500, 600, 800) that is not part of the PM cluster (115) and that is associated with the specific service or resource.

Description

STATE OF THE ART

[0001] Authentication, authorization, and accounting (AAA) are functions provided by network security protocols to restrict, enable, and monitor access to services and resources in a network cluster or distributed network of services. Authentication is the function security providers use to ensure that the identity of users or devices attempting to access network resources has been recognized and verified as genuine. This assurance can be provided through the presentation of identification credentials and via Extensible Authentication Protocol (EAP) over LAN (EAPoL). EAPoL is a network port authentication protocol used in the Institute of Electrical and Electronics Engineers Port-Based Network Access Control standard (e.g., IEEE 802.1X standards).Authorization function generally used to determine the scope or role of permissible access of a user with an authenticated identity to a specific network resource (e.g., authentication to a network via a network authentication server (NAS)). After an entity has been authenticated and authorized to specific resource(s), a session can be established for that user and device. Accounting functions provide a means to track user activity within established sessions. Established sessions can further enable the collection of statistical data for various purposes (e.g., network monitoring, usage tracking, analytics, and other reasons). RADIUS (Remote Authentication Dial-In User Service) is a network protocol that provides all three AAA functions through a standard interface.RADIUS is supported by many different hardware and software vendors and is controlled based on IETF (Internet Engineering Task Force) standards. US 2018 / 0 288 048 A1 describes techniques for supporting the mass transmission of authorization change data in authentication, authorization, and accounting (AAA) protocols, wherein the transmission is performed as an authorization change after a subscriber has successfully authenticated and initially authorized. It is an object of the invention to propose a method, a network infrastructure device, and a non-transitory, computer-readable medium for providing authorization information via a distributed data store. This object is achieved by an inventive method according to claim 1, an inventive network infrastructure device according to claim 11, and an inventive, non-transitory, computer-readable medium according to claim 16. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The present disclosure can be better understood from the following detailed description when read in conjunction with the accompanying figures. It should be noted that, in accordance with industry practice, various features are not drawn to scale. Indeed, the dimensions or positions of functional attributes may be shifted or combined based on design, security, performance, or other factors known in the field of computer systems. Furthermore, the order of processing for some functions may be changed, both internally and with respect to each other. This means that some functions may not be implemented using serial processing and may therefore be executed in a different order than shown or may be executed in parallel. For a detailed description of various examples, reference is now made to the accompanying drawings, in which: Fig. 1 shows a functional timeline diagram with example components (and actions of those components) for a system constructed using the RADIUS network protocol and other protocols to share information from a policy manager (PM) with other devices on a network according to one or more disclosed implementations; Fig. 2 is a block diagram illustrating a possible relationship between multiple interacting resources within a cluster that provide AAA functions for distributed instances of an example PM implementation according to one or more disclosed implementations; Fig. 3 is a flowchart illustrating a possible process flow for a handshake procedure of an access request function and including updating the results of a corresponding access acceptance response according to one or more disclosed implementations; Fig. 4 is a flowchart illustrating a possible process flow for a second handshake method representing an accounting request function and including updating the results of a corresponding accounting response back to the requesting network device, according to one or more disclosed implementations; Fig. 5 shows an example processor and a computer-readable medium for implementing the example method of FIG. 3, according to one or more disclosed implementations; Fig. 6 shows an example processor and a computer-readable medium for implementing the example method of Fig. 4, according to one or more disclosed implementations; Fig. 7 shows an exemplary computer network infrastructure that may be used to implement all or part of the disclosed techniques for updating AAA information via RADIUS to an external server from a PM according to one or more disclosed embodiments; and Fig. 8 shows a computer processing device that can be used to implement the functions, modules, processing platforms, execution platforms, communication devices, and other methods and processes of this disclosure. DETAILED DESCRIPTION

[0003] Illustrative examples of the subject matter claimed below are now disclosed. For clarity, this specification does not describe all features of an actual implementation for each example implementation. It is understood that in developing such an actual example, numerous implementation-specific decisions may be made to achieve the developer's specific goals, such as adhering to system-related and business-related constraints that vary from implementation to implementation. Furthermore, it is understood that such a development effort, even if complex and time-consuming, would be a routine undertaking for one of ordinary skill in the art who would benefit from this disclosure.

[0004] Systems designed to handle AAA for users, such as those implementing the RADIUS protocol, can use reliable storage mechanisms to manage and exchange information about known users (e.g., authenticated users) and their assigned roles. One such system that handles AAA is a Lightweight Directory Access Protocol (LDAP) server. AAA systems generally store information about user sessions and recognized user roles at runtime. AAA systems can also enable user session accounting (e.g., using an authentication database). In some implementations, proxy servers can act as a bridge between isolated network components (e.g.,different subnets of a larger corporate network) to support centralized management and information sharing among other instances of the devices that understand the same network protocol, such as RADIUS. The use of a standard protocol such as RADIUS further enables a heterogeneous network of devices provided by multiple vendors simultaneously. For example, forwarding or rewriting packets of the standard protocol using the same well-defined interfaces described in that protocol can allow different vendors to work together.

[0005] AAA systems such as RADIUS can also be made highly available (e.g., configured for redundancy) to ensure reliable access to the services and resources they provide in the event of a single device failure. High availability (HA) is a feature that, in a composite view, attempts to ensure that a system, service, or resource remains functional and accessible, with maximum uptime and a reduced likelihood of downtime at any single point of failure of the individual components of the system. Another aspect that can be provided along with HA is a distributed resource feature that allows the system, service, or resource to be universally accessible within a given enterprise.These goals of HA and distributed access can be achieved by distributing acting components and / or distributing state information for both access and change. Distributing state for both access and change allows for timely reflection of current information across the distributed system (e.g., cluster information exchange, distributed database, etc.). The decisions made regarding the supporting infrastructure of a network security protocol that provides AAA capabilities such as RADIUS can be adapted for different implementations and are based on components from multiple vendors.

[0006] Implementations of network security protocols such as RADIUS typically provide their authentication, authorization, and accounting (AAA) functions through standard interfaces defined by the protocol. RADIUS and other network protocols may provide defined interfaces to enable handshaking between external actors (e.g., other systems on an enterprise network) and the systems providing AAA functionality. In addition to predefined interfaces (e.g., device consumer handshakes) for the system providing AAA functionality, this disclosure provides a means for retrieving and modifying the resulting state information.Thus, an improvement over traditional computer networks can be provided to interface between networked systems intended for consumption and peripheral systems that can further process this shared information within the larger enterprise. In particular, example implementations can enable the exchange of information from a PM system and other systems (e.g., firewalls) that can benefit from additional information related to corporate network policies (e.g., policies provided by the PM system).

[0007] Disclosed implementations for retrieving changes to information managed by AAA functions executed by a PM server include the use of a shared memory cache, referred to herein as a "multi-master cache" (MMC). The MMC can be deployed to various computing devices to collectively provide comprehensive policy management for an organization. As mentioned above, the policy management functions include controlling access features (e.g., security) for network services within the enterprise's corporate network.

[0008] In general, there may be devices on the corporate network that consume devices (e.g., user devices or subscribing devices). User devices can be laptops, tablets, desktops, etc. Subscribing devices can be application servers or computing resources that provide common functions (e.g., computer applications) to support corporate operations through the devices communicatively connected to the corporate network. Each of these consuming devices can interact with each other and with providing devices (e.g., subscribers providing PM functionality) using a network protocol such as RADIUS. Each subscriber providing PM functionality can exchange information using RADIUS (or another network protocol) and using the MMC.By using a distributed MMC, the distribution of PM functionality across a cluster can be made highly available to the corporate network. Implementations are not limited to a cluster for HA; a cluster is simply one way to provide redundancy.

[0009] In the example implementations of this disclosure, a cluster is used; however, other techniques for HA are possible and will be understood by those of ordinary skill in the art given the benefit of this disclosure. In particular, a conventional primary and backup role for two servers with PM functionality is another example of implementing HA. In any case, multiple servers working together to deploy an HA solution can do so by using the disclosed MMC to share information and allow multiple devices to access an up-to-date set of information (e.g., changes to dynamic information are automatically propagated) to perform their intended function.

[0010] In a cluster implementation, the MMC can act as a repository for nodes of a PM cluster to store dynamic information, which can then be automatically propagated (based on changes) across each of the cluster's nodes, allowing each node to maintain power and redundancy of data access to ensure high availability. Furthermore, each of the devices sharing current information (e.g., via the MMC) can allow access to information by consumer devices using backend channels that are not necessarily defined by a specific protocol standard (e.g., RADIUS). In short, extensions to the standard can be provided that allow the expansion of available data without "breaking" standards-compliant interfaces.

[0011] In disclosed implementations, the ability to provide PM functionality may use established network security protocols such as RADIUS to establish and share AAA information. A method for establishing and sharing AAA information may include the handshake interfaces discussed in this disclosure. Sharing may occur between the providing devices (e.g., using RADIUS or MMC access) and may also be provided to resources (e.g., consuming devices) that use the AAA information. Examples of consuming devices include, but are not limited to, application services, computing resources, and firewalls. Consuming devices may not have direct access to MMC, but may be able to access current data indirectly through the MMC. That is, they may (e.g.,via handshake or another interface) with a distributed component providing the PM functionality, which has direct access to the MMC. An advantage of this type of implementation is to provide loose coupling with any protocol and further to allow proprietary access (e.g., access not based on an industry standard) to this information without being limited to or compromising functionality based on an industry standard. Accordingly, access to AAA information can be optimized, enhanced, and made available using techniques that would otherwise be unavailable (e.g., not provided by any standard).

[0012] Using an MMC can enable AAA information updates in at least two ways. For example, AAA information can be managed in an MMC, and updates can be delivered to non-MMC devices (e.g., firewalls) using a protocol such as RADIUS. Additionally, AAA information updates can be delivered to MMC devices through a distributed shared data store. Of course, it may also be possible to update MMC devices through means other than using the MMC function. Generally, shared data store (MMC) updates can be made as a built-in function of the successful acknowledgment of an attempted handshake interface. In one example, MMC updates can occur before handshake success / failure is reported back to an initiator of that attempted handshake.After updating a local data store associated with the component device performing the handshake, changes to data can be automatically propagated (e.g., shared or distributed) to the other component devices that did not directly participate in that handshake instance. This allows the data store on the remaining nodes of the cluster, which represents their local version of the MMC, to be maintained with up-to-date information.

[0013] In general, information passing can apply to any handshake operation that has resulted in the addition, modification, or deletion of the resulting state information related to PM functionality. In this context, state information refers to the authentication status related to users or end-user devices based on interactions with an enterprise infrastructure network. Interactions can include requests to authenticate to the enterprise network or to access application services provided as part of the overall secure enterprise infrastructure. In an example implementation using RADIUS, identity and role information of a particular user and the assigned session resulting from a successful access request invocation can be updated to the MMC before responding with an access response.Furthermore, accounting stop responses may not be sent until the associated AAA status information has been cleared. Accordingly, changes can be propagated independently through the MMC to be available to members of a cluster or other compute resources that implement PM functions using the MMC (e.g., the shared and propagated data store).

[0014] In general, disclosed implementations may use several different functional flows (e.g., handshakes) to exchange information. An initial information flow may occur between two PM nodes of a distributed PM implementation. In this initial flow, a first PM node (after authentication at a possibly different node) may derive (e.g., retrieve or query via a rule query) authorization attributes (e.g., for the newly authenticated user) from a database of rules (e.g., policies). Then, the first PM node may update / insert (e.g., into the MMC) a record reflecting the derived authorization attributes. In a specific example, upon authenticating user BOB, the database may identify BOB as a "student." Then, a mapping of BOB to the student role may be inserted into the MMC.

[0015] A second information flow may occur between a NAS and a PM node and reflect an accounting request. In this second flow, an accounting request may be made by the NAS to obtain a station identification and frame IP address for a device associated with user BOB. A third functional flow may be between nodes of a distributed PM implementation (e.g., like the first functional flow discussed above). This third functional flow may potentially occur after the accounting request of the second flow and represent a node executing a query to the MMC for user BOB. Then, an update to the account information for user BOB may be made based on the information obtained in the second flow. The updated account information may then be shared across all nodes of the distributed PM using an update to the MMC.Finally, a fourth example flow can exist between a node of a distributed PM implementation and a firewall. In this flow, a node of the distributed PM can use a RADIUS-based message to provide information (e.g., information obtained from the MMC) to the firewall. Other flows are possible. The purpose of these examples is to explain that information can be exchanged between distributed nodes of a PM implementation via the MMC. Using the sharing feature, different nodes can interact with other network devices (e.g., firewall, PM database instance) to perform functions that may have been limited to a single device (e.g., in a non-distributed PM implementation). Thus, further distribution of PM functionality (i.e., load balancing) and HA (e.g.,distributed redundancy) may be provided by disclosed implementations using a distributed MMC as disclosed herein.

[0016] With an understanding of the above overview, this disclosure now explains a possible non-limiting example implementation (possible optional variants may also be included where appropriate). This example implementation is explained with reference to the figures and represents only one possibility based on disclosed techniques. In Fig. Figure 1 shows a functional block diagram of relevant operating components of a system built on the RADIUS network protocol, operating within the parameters of the standard protocol while further incorporating a distributed in-memory caching technique to extend functionality without violating the standard. Fig. Figure 2 then shows a functional block diagram to illustrate possible relationships between connecting devices that can be managed by a PM system (e.g., a ClearPass Policy Manager, such as that available from Hewlett Packard Enterprises). In one example, a PM can share extended information about RADIUS interactions and maintain concurrency in an enterprise network (e.g., a clustered implementation of a PM) using a distributed multi-master cache (MMC). Thus, multiple network components can simultaneously know the relationship of other network components by receiving their status information from the MMC. Fig. Figure 3 then shows a flowchart for an example method of a handshake (e.g., controlled device interaction such as challenge-response) for an access request function. The access request function may represent an interaction between a network device (e.g., a client device) or a cluster component based on the RADIUS network protocol. Any other device participating in this handshake may have concurrency and availability of data required to implement the PM's policies via the distributed MMC. Fig. Figure 4 then shows a flowchart for an exemplary second handshake procedure (which may follow the first handshake) for providing an accounting request function between a network device (e.g., the client device) or a cluster component based on the RADIUS network protocol. Again, each different device participating in this handshake may exhibit concurrency and availability of data required to implement PM policies via the distributed MMC. Fig. 5-6 illustrate non-transitory computer-readable media and a corresponding computing resource for implementing disclosed methods. Finally, Fig. Figures 7-8 illustrate a possible enterprise network infrastructure and a processing device for enterprise network infrastructure components, respectively. Fig. 7-8 illustrate an environment in which aspects of the current disclosure may be implemented to provide improvement in the management, maintenance, security, availability, and overall performance / reliability of policy management for networked devices.

[0017] With reference to Fig. 1, a functional timeline 100 is shown. The timeline 100 includes exemplary components (e.g., client device 105, network authentication server (NAS) 110, PM 115, firewall 1 (120), and firewall 2 (125)). Together, these functional components may represent an example of a system constructed using the RADIUS network protocol and other protocols to implement PM functionality for providing authorization and accounting information to an external server in accordance with one or more disclosed implementations. Although PM 115 in Fig. 1 is represented as a single box. In 1, a distributed implementation can provide the functionality of PM 115. Events of timeline 100 are represented from top to bottom, and interactions are represented as arrows from left to right and right to left.

[0018] Timeline 100 begins at the top left, where client device 105 first connects to NAS 110 using Extensible Authentication Protocol over LAN (EAPoL), as indicated by bidirectional arrow 130. As mentioned above, EAPoL is defined in the IEEE (Institute for Electrical and Electronics Engineers) standard for Port-Based Network Access Control (PNAC) and is commonly referred to in the industry by the acronym and enumeration IEEE 802.1X. NAS 110 can determine a proper response to the EAPoL request via arrow 130 by first (or concurrently) sending an access request, as indicated by arrow 135, to PM 115. In this example, the access request associated with arrow 135 represents an authentication request. If PM 115 is able to verify the identity of client device 105, an update (as indicated by loop 140) may be made to the MMC (e.g.,The node serving the access request associated with arrow 135 may update a local instance of the MMC with appropriate values ​​for authorizing access. The appropriate values ​​may include a role of a user currently associated with the client device 105 or other credentials that may be verified / identified via an authentication / authorization process as per NAS 110 and PM 115. In this example, attributes may be added to the account request in the MMC (indicated by annotation 145). An example attribute (as indicated in annotation 150) is the role of a "STUDENT." In some implementations, the update indicated by loop 140 may be with respect to attributes added to an MMC before any responses are provided to the client device 105.In response to a successful update of the MMC by PM 115, an access response indicated by arrow 155 may be returned to NAS 110. NAS 110 may then return the response (not shown for simplicity) to client device 105. The response to the client may include information regarding the session assigned to the now authenticated client device 105 and an associated user.

[0019] At this stage of timeline 100, in one example, client device 105 is now authenticated, and client device 105 may perform functions on an enterprise network based on instantiated session information. Additionally, NAS 110 may submit an accounting request, as indicated by arrow 160, to PM 115. Accounting requests may be associated with tracking or permitting user interactions (e.g., authentication or access requests) of a client device (e.g., client device 105) and an associated user. Initially, an accounting request may be associated with EAPoL 130 as part of (or in response to) an initial network authentication activity. After authentication, accounting requests may be associated with an attempt by client device 105 to access a particular service or resource on the enterprise network.

[0020] In this example, the corporate network is secured and managed by PM 115. In response to an access request, PM 115 may initiate query 165 to obtain information from the MMC (e.g., a query based on a MAC address of client device 105, a query based on user identification, a query based on user / device role, or a query based on a combination thereof). Query 165 may be used to determine whether client device 105 (and possibly an associated user) has access to the target service or resource. PM 115 may then forward an accounting request, as indicated by arrow 175, to another computing device.It is important to note that in a distributed PM implementation of PM 115, a first node may functionally work with the billing request associated with arrow 160, while a second different node may initiate the billing requests associated with arrows 175 (Note 1 to Firewall 1 (120) and another to Firewall 2 (125)). Furthermore, different nodes of a single distributed PM 115 may interact with Firewall 1 (120) and Firewall 2 (125) simultaneously. Thus, at least three nodes of a distributed PM 115 implementation may use a sharded MMC to jointly execute the activities depicted in timeline 100. Of course, fewer than three nodes are also possible, and all activities of timeline 100 may be executed by a single node or any number of nodes.Each of the participating nodes can have access to the shared MMC to maintain a consistent distributed copy of the PM information.

[0021] Continuing with timeline 100, accounting responses, as indicated by arrows 185, may be sent from Firewall 1 (120) and Firewall 2 (125) to PM 115. As indicated in note 170, PM 115 may not wait for a response from each of the one or more firewalls. Instead, PM 115 may initiate a transmission (e.g., sending) of an accounting response message, as indicated by arrow 180. Note that the accounting response message indicated by arrow 180 may be derived using information previously received by PM 115 from the MMC (e.g., query response) (e.g., as indicated by loop 165). The billing response message indicated by arrow 180 may be sent from PM 115 back to NAS 110, which may then (not shown in timeline 100) return the response (or information about the response) to client device 105.In this way, processing can be parallelized by using information available in the MMC.

[0022] Concluding the discussion of timeline 100, an HTTP GET request (as indicated by arrow 190) for a particular website Universal Resource Locator (URL) may be made from client device 105. The result is a rejection in this example because Firewall 2 (125) does not grant access to this URL. The rejection may be caused by a lack of proper authentication or because the role assigned to the user and / or client device 105 (as known by Firewall 2 (125)) is not authorized to interact with this URL. In either case, the rejection results in an HTTP: Error Forbidden response message, as indicated by arrow 195, being sent back to client device 105.

[0023] With reference to Fig. 2, an example networked system 200 is described by showing selected relationships between components of an example implementation of a PM system and other computer systems typically found in an enterprise network infrastructure according to one or more disclosed implementations. In particular, the networked system 200 describes a PM system (e.g., PM nodes 1-5 (210-1 to 210-5)) implemented as a cluster, with each PM node (210-1 to 210-5) of the distributed PM system having access to a distributed data store 220 (e.g., an MMC as described above). In this example, each PM node (210-1 to 210-5) of the distributed PM system can interact with other network devices (e.g., firewall 230 and application cluster 235) using a RADIUS protocol interface to provide information from the distributed data store 220.

[0024] As illustrated in network system 200, multiple client devices 205 are shown interfacing with selected instances of PM nodes (210-1 through 210-5). Note that, for clarity, the previously described NAS instances are not fully illustrated in network system 200. An example NAS 206 is shown for PM node 3 (210-3), and other instances of PM nodes may be similarly configured. As explained above, NAS 206 may act as an intermediary network device between client devices 205-3 and PM node 3 (210-3), and similar intermediary devices may be present to support other PM nodes as desired. In the networked system 200, client devices 205-1 may interface with the PM node 1 (210-1) and the PM node 1 (210-1) may interface with the distributed data store 220 via a bidirectional connection 215-1.Similarly, client devices 205-2 may interface with PM Node 2 (210-2) and PM Node 2 (210-2) via a bidirectional connection 215-2 to distributed data store 220. Each of client devices 205-4 and client devices 205-4 is connected to PM Node 4 (210-4) and PM Node 5 (210-5), respectively, which in turn use bidirectional connections 215-4 and 215-5 (again) to access distributed data store 220. As explained herein, it is possible for a given client device to interact with multiple different instances of a PM Node at different times for a single authenticated session. That is, an instance of a client device may perform a first handshake interaction with a first instance of a PM node and (within the same authenticated session) perform a second handshake interaction with a second, different instance of a PM node.Thus, load balancing can be achieved for PM functions supporting multiple client devices within an enterprise infrastructure network. Furthermore, distributed data store 220 enhances the ability to balance PM functionality, in part because each instance of a PM node (210-1 through 210-5) maintains a consistent copy of information within distributed data store 220 (e.g., by using an implementation of an MMC as described herein).

[0025] Fig. Figure 2 also shows a relationship between each instance of a PM node (210-1 through 210-5) and the distributed data store 220, which is accessible by each of the PM nodes 210-1 through 210-5. Note also that the dashed box of PM node N 226 appears twice in the network system 200 and is used to illustrate an indirect relationship (e.g., links 225-1 and 225-2) to data from the distributed data store 220 from the application cluster 235 and the firewall 230, respectively. This indirect relationship was described above and represents that although the application cluster 235 and the firewall 230 do not have direct access to the distributed data store 220, information from the distributed data store 220 can be provided via RADIUS protocol messages from an appropriate PM node to another node of the networked system 200.In particular, records within distributed data store 220 can be supplemented with information managed by a PM system and provided to other nodes of network system 200 that are equipped to understand RADIUS protocol messages. In this way, information from a distributed PM system, as depicted in networked system 200, can be shared with nodes that do not have direct access to distributed data store 220 (e.g., an MMC as described above).

[0026] In general, instances of each PM node 210-1 through 210-5 may treat the distributed data store 220 as their backend data store and use an internal integration layer to propagate information throughout the cluster. Furthermore, each instance of a PM node 210-1 through 210-5 may use a RADIUS protocol to provide proxy propagation to all other nodes of the network system 200. Each instance of a PM node 210-1 through 210-5 may receive updates from other RADIUS implementations through a proxy and propagate its own updates to other computer systems using RADIUS implementations through a proxy. However, if one instance of a PM node (e.g., PM node 2 (210-2)) wishes to provide an update to another instance of a PM node (e.g., PM node 4 (210-4)), this update may be provided by passing data within the distributed data store 220 (e.g.,B. an MMC), which may provide a more efficient mechanism for sharing data than using RADIUS messages. It should also be noted that although the distributed data store 220 is implemented as a centralized, standalone unit in . Fig. 1 is shown. In Fig. 2, this is for illustrative purposes only (i.e., it is a logical representation). In an actual implementation of the network system 200, there may be no central repository, as each instance of a PM node 210-1 through 210-5 may maintain a locally synchronized copy of data in internal (or locally accessible) storage for performance or other reasons.

[0027] With reference to Fig. 3, a flowchart is presented to outline an example method 300 that enables a client device to make an authentication request (e.g., perform a handshake interaction as discussed herein), according to one or more disclosed implementations. Actions of the example method 300 may be performed in a different order than those described in Fig. 1. 3, and some actions may be performed in parallel. The example method 300 may utilize an implementation of RADIUS that cooperates with distributed PM functionality to extend the capabilities typically available in a standard implementation using the RADIUS protocol. The example method 300 begins at block 305, where a client device (e.g., client device 105 of FIG. 1) may send an EAPoL request to a NAS (e.g., NAS 110 of FIG. 1) for authentication. Block 310 indicates that the NAS may further initiate a RADIUS or other network protocol-defined access request call to an instance of the example distributed PM implementation (e.g., shown as PM 115 of FIG. 1) operating within a cluster or other computing devices of an enterprise network.The distributed PM implementation provides security and monitors the activities of devices and users on an enterprise network (or other network types). Decision 315 indicates that a response to the access request can be analyzed to determine various possible flow paths, for example, method 300.

[0028] If decision 315 determines that the PM node's response is an Access Challenge type, flow continues to block 320. Block 320 indicates that the Access Challenge response may be returned to the NAS and then sent back to the corresponding client device, which returns to block 305. Upon returning from block 320, a client device may process the response to complete the authentication request based on the challenge. For example, a client device may change information based on the challenge and attempt a different request.

[0029] Alternatively, if decision 315 determines the PM node's response is an Access-Reject type, flow continues to block 325. At block 325, the Access-Reject response may be returned to the NAS and ultimately provided to the client device. In a typical implementation, an Access-Reject response returns an error condition to the client device and terminates an iteration of example method 300 in an error state.

[0030] As a third possible determination from decision 315, if the PM node's response represents an Access-Accept response, flow continues to block 330. As indicated in block 330, user and session information, such as role and other attributes, used for authorization may be updated in the shared distribution repository (e.g., the MMC). The flow from block 330 has two possible paths, which may be executed either serially or in parallel, depending on a PM node's implementation type. Block 335 indicates that the user and session information may then be propagated to other PM nodes of the cluster via data propagation techniques that involve synchronizing the clustered in-memory cache. Serially or concurrently with the processing of block 335, block 340 indicates that the Access-Accept response may be returned to the NAS and ultimately to the client device.The NAS can simply forward an Access-Accept response, or it can process the Access-Accept response and send information indicating that the authentication request has been granted. Receiving a condition for granting access can allow the client device to proceed with a requested operation (e.g., access to a service). It can grant access to a URL and return information for that URL.

[0031] With reference to Fig. 4, a flowchart is presented to explain an example method 400 in which an authenticated client device may be associated with one or more accounting requests that are processed by the example implementation of a distributed PM system. These one or more accounting requests may be processed at least in part using a RADIUS protocol to enable a PM system to interact with other computing devices available on an enterprise network. Actions of the example method 400 may be performed in a different order than those in Fig. 1. 4 and some actions can be performed in parallel.

[0032] In the example method 400, a PM system may be implemented to utilize information disseminated through the distributed PM system (e.g., available in a CCM) to further interact with other computer systems (e.g., firewalls) via functions defined via the RADIUS protocol. The example method 400 begins at block 405, where a NAS may periodically (or as needed) provide information to a distributed PM system (e.g., on behalf of an associated client device already authenticated to a network). These updates may continue until a client disconnects from the NAS. Generally, after authentication, a client device may perform actions resulting in an accounting request, possibly conforming to a standard RADIUS protocol. Periodically (or as needed), a NAS may send accounting updates to a PM node of a distributed PM system.Flow continues with block 410, which indicates that a PM node (e.g., of a distributed PM system) may query a local instance of a distributed data store, which may be an implementation of a multi-master cache such as the MMC described above. The query may retrieve session information of a user who has authenticated to a network via the NAS on a particular end-user device. Block 415 indicates that the type of accounting request may be either to update information about a user session or to terminate a user session.

[0033] If the request is determined to be an update in decision 415, flow continues to block 420, where a PM node (which may be a different node than the one that previously interacted with this client for this particular user authentication session) may add authorization values ​​(e.g., AAA information as described above) for the user. The authorization values ​​may be added to a configured Radius attribute stored in an MMC. At block 420, there are two possible exit paths, which may be performed in parallel or serially. Block 430 indicates that updates to an MMC may be propagated across all instances of an MMC (or other distributed data store) within the cluster or distributed PM implementation. Block 435 indicates that a PM node may send the same updates (or part of them in the same or a different format) over a network communication protocol (e.g.,RADIUS) to other connected devices and forward one or more authorization requests via proxy. This allows information to be passed to external servers that do not necessarily have access to an MMC. Block 445 indicates that the PM node does not need to wait for responses to these proxy requests, as they may be processed asynchronously to other actions. Of course, in some implementations, the PM node may wait for an acknowledgment. Flow then leaves block 445 to proceed to block 450, where the PM node (or another node in the PM cluster) can return information about the accounting response to the initially requesting client device. This return of information to the client device can optionally be sent directly to the client or, in some cases, via the NAS.

[0034] Returning to decision 415, if it is determined that the request sent to the PM node is a stop instruction (e.g., termination of the activity or session), flow continues to block 425. Block 425 has two different possible exit paths (similar to block 420, as discussed above), which can be executed in parallel or sequentially. As mentioned above, block 430 indicates that updates to an MMC can be propagated across all instances of an MMC (or other distributed data store) within the cluster or distributed PM implementation. Block 440 indicates that a PM node can also propagate the same session shutdown updates (or part of them in the same or a different format) to other connected devices via a network communication protocol (e.g., RADIUS).Shutdown updates may indicate the deletion of information about a terminated activity or session. Additionally, an instruction to delete session information may also be passed through a proxy. This allows information to be passed to external servers that may not necessarily have access to an MMC. Blocks 445 and 450 complete the session update process in a similar manner to that described above.

[0035] Fig. 5 is an example computing device 500 having a hardware processor 501 and accessible machine-readable instructions stored on a machine-readable medium 502 for implementing management of a distributed PM system according to one or more disclosed example implementations. Fig. 5 shows, as an example, the computing device 500 configured to perform the flow of the method 300. However, the computing device 500 may also be configured to perform the flow of other methods, techniques, functions, or processes described in this disclosure. In this example of Fig. 3, the machine-readable storage medium 502 includes instructions to cause the hardware processor 501 to execute the steps described above with reference to Fig. 3 blocks 305-340 discussed above.

[0036] Fig. 6 is an example computing device 600 having a hardware processor 601 and accessible machine-readable instructions stored on a machine-readable medium 602 for implementing alternative techniques and methods associated with the distributed PM system described above, according to one or more disclosed example implementations. Fig. 6 shows, as an example, the computing device 600 configured to perform the flow of the method 400. However, the computing device 600 may also be configured to perform the flow of other methods, techniques, functions, or processes described in this disclosure. In this example of Fig. 4, the machine-readable storage medium 602 includes instructions to cause the hardware processor 601 to execute the steps described above with reference to Fig. 4 blocks 405-450 discussed above.

[0037] A machine-readable storage medium, such as 502 in Figure 602, may include both volatile and non-volatile, removable and non-removable media, and may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions, data structures, program modules, or other data accessible by a processor, such as firmware, erasable programmable read-only memory (EPROM), random access memory (RAM), non-volatile random access memory (NVRAM), optical disk, solid-state drive (SSD), flash memory chips, and the like. The machine-readable storage medium may be a non-volatile storage medium, where the term "non-volatile" does not include volatile propagation signals.

[0038] Fig. 7 illustrates a computer network infrastructure 700 that can be used to implement, in whole or in part, the disclosed technique for distributing user session information provided by AAA functions (e.g., a distributed PM system, as discussed above) defined in a network security protocol such as RADIUS over a highly distributed distributed in-memory cache (e.g., a CCM), or providing information flow between a system executing the disclosed techniques and other computer networks according to one or more disclosed implementations. The network infrastructure 700 includes a number of networks in which embodiments of the present disclosure can operate. The network infrastructure 700 includes a customer network 702, network 708, cellular network 703, and a cloud service provider network 710.In one embodiment, the customer network 702 may be a local private network, such as a local area network (LAN), which includes various network devices such as, but is not limited to, switches, servers, and routers.

[0039] Each of these networks may include wired or wireless programmable devices and may operate with any number of network protocols (e.g., TCP / IP) and connection technologies (e.g., WiFi® networks or Bluetooth®). In another embodiment, customer network 702 represents an enterprise network that may include or be communicatively coupled to one or more local area networks (LANs), virtual networks, data centers, and / or other remote networks (e.g., 708, 710). In the context of the present disclosure, customer network 702 may include a network device supporting a distributed CCM data store such as that described above.

[0040] As in Fig. 7, the customer network 702 may connect to one or more client devices 704A-E and enable the client devices 704A-E to communicate with each other and / or with the cloud service provider's network 710 via the network 708 (e.g., Internet). The client devices 704A-E may be computer systems such as desktop computer 704B, tablet computer 704C, mobile phone 704D, laptop computer (shown as wireless) 704E, and / or other types of computer systems generically represented as client device 704A. Client devices 704A-E may have one or more associated users (not shown) that can be authenticated to a network and access services managed by a PM system such as the one described above.

[0041] The network infrastructure 700 may also include other types of devices commonly referred to as the Internet of Things (IoT) (e.g., edge IoT device 705) that may be configured to send and receive information over a network, to access cloud computing services, or to interact with a remote web browser application (e.g., to receive configuration information).

[0042] Fig. 7 also shows that the customer network 702 includes local computing resources 706A-C, which may include a server, access point, router, or other device configured to provide local computing resources and / or facilitate communication between networks and devices. For example, the local computing resources 706A-C may be one or more physical local hardware devices, such as the HA switches described above. Local computing resources 706A-C may also facilitate communication between other external applications, data sources (e.g., 707A and 707B), and services, and the customer network 702. The computing resources 706A-C may be configured as a set of cluster nodes to collectively perform an application function.

[0043] The network infrastructure 700 also includes the cellular network 703 for use with mobile communication devices. Cellular networks support mobile phones and many other types of mobile devices, such as laptops, etc. Mobile devices in the network infrastructure 700 are represented as mobile phones 704D, laptops 704E, and tablet computers 704C. A mobile device, such as mobile phones 704D, can interact with one or more wireless carrier networks as the mobile device moves. Typically, it interacts with a plurality of cellular network towers 720, 730, and 740 to connect to the cellular network 703.

[0044] Fig. 7 shows that the customer network 702 is coupled to a network 708. The network 708 may include one or more currently available computer networks, such as other LANs, wide area networks (WANs), the Internet, and / or other remote networks, to transfer data between the client devices 704A-D and the cloud service provider's network 710. Each of the computer networks in the network 708 may include wired and / or wireless programmable devices operating in the electrical and / or optical domains.

[0045] In Fig. 7, the cloud service provider network 710 is depicted as a remote network (e.g., a cloud network) capable of communicating with the client devices 704A-E via the customer network 702 and the network 708. The cloud service provider network 710 acts as a platform that provides additional computing resources to the client devices 704A-E and / or the customer network 702. In one embodiment, the cloud service provider network 710 includes one or more data centers 712 with one or more server instances 714. The cloud service provider network 710 may also include one or more frames or clusters (and cluster groups) that represent a scalable computing resource that can benefit from the techniques of this disclosure.

[0046] Fig. Figure 8 shows a computing device 800 that may be used to implement or in conjunction with the functions, modules, processing platforms, execution platforms, communication devices, and other methods and processes of this disclosure. For example, the Fig. 8 may represent a client device or a physical server device and may include either hardware or virtual processor(s) depending on the level of abstraction of the computing device. In some cases (without abstraction), the computing device 800 and its elements, as in Fig. 8, each on physical hardware. Alternatively, in some cases, one, several, or all elements could be implemented using emulators or virtual machines as abstraction levels. Regardless of how many abstraction levels are removed from the physical hardware, in any case, the computing device 800 may be implemented at its lowest level on physical hardware.

[0047] As in Fig. As shown in Figure 8, computing device 800 may include one or more input devices 830, such as a keyboard, mouse, touchpad, or sensor display (e.g., a biometric scanner), and one or more output devices 815, such as displays, speakers for audio, or printers. Some devices may also be configured as input / output devices (e.g., a network interface or a touchscreen display).

[0048] Computing device 800 may also include communication interfaces 825, such as a network communication unit, which may include a wired communication component and / or a wireless communication component communicatively coupled to processor 805. The network communication unit may use various proprietary or standardized network protocols, such as Ethernet, TCP / IP, to name a few of many protocols, for communication between devices. Network communication units may also include one or more transceivers using Ethernet, Power Line Communication (PLC), Wi-Fi, cellular, and / or other communication methods.

[0049] As in Fig. 8, computing device 800 includes a processing element such as processor 805, which includes one or more hardware processors, where each hardware processor may have a single or multiple processor cores. In one embodiment, processor 805 may include at least one shared cache that stores data (e.g., computational instructions) used by one or more other components of processor 805. For example, the shared cache may be a locally cached data store stored in memory for faster access by components of the processing elements that make up processor 805. In one or more embodiments, the shared cache may include one or more mid-level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other cache levels, a last-level cache (LLC), or combinations thereof.Examples of processors include a central processing unit (CPU) and a microprocessor. Although in . Fig. Not shown, the processing elements comprising processor 805 may also include one or more other types of hardware processing components, such as graphics processing units (GPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or digital signal processors (DSPs).

[0050] Fig. 8 shows that memory 810 may be operatively and communicatively coupled to processor 805. Memory 810 may be a non-volatile medium configured to store various types of data. For example, memory 810 may include one or more storage devices 820, which may include a non-volatile storage device and / or volatile memory. Volatile memory, such as random access memory (RAM), may be any suitable non-permanent storage device. Non-volatile storage devices 820 may include one or more disk drives, optical drives, solid-state drives (SSDs), tap drives, flash memory, read-only memory (ROM), and / or any other type of memory configured to retain data for a specified period of time after a power failure or shutdown.In certain cases, the non-volatile storage devices 820 may be used to store overflow data when the allocated RAM memory is not large enough to accommodate all working data. The non-volatile storage devices 820 may also be used to store programs that are loaded into the RAM memory when such programs are selected for execution.

[0051] Those skilled in the art will appreciate that software programs may be developed, coded, and compiled in various computer languages ​​for various software platforms and / or operating systems, and then loaded and executed by processor 805. In one embodiment, the software program compilation process may convert program code written in one programming language into another computer language so that processor 805 is capable of executing the program code. For example, the software program compilation process may generate an executable program that provides coded instructions (e.g., machine code instructions) to processor 805 to perform specific, non-generic, particular computational functions.

[0052] Following the compilation process, the encoded instructions may then be loaded into processor 805 as computer-executable instructions or process steps from storage device 820, memory 810, and / or embedded within processor 805 (e.g., via a cache or on-board ROM). Processor 805 may be configured to execute the stored instructions or process steps to perform instructions or process steps that transform the computing device into a non-generic, particularly specially programmed, machine or apparatus. Stored data, e.g., data stored on storage device 820, may be accessed by processor 805 during the execution of computer-executable instructions or process steps to instruct one or more components within computing device 800.

[0053] A user interface (e.g., output devices 815 and input devices 830) may include a display, a positional input device (such as a mouse, a touchpad, a touchscreen, or the like), a keyboard, or other forms of user input and output devices. The user interface components may be communicatively coupled to the processor 805. If the output device is or includes a display, the display may be implemented in various ways, including a liquid crystal display (LCD) or a cathode ray tube (CRT), or a light-emitting diode (LED) display, such as an organic light-emitting diode (OLED) display. Those skilled in the art will appreciate that the computing device 800 may also include other components known in the art, such as sensors, power sources, and / or analog-to-digital converters not explicitly described in Fig. 8 are shown.

[0054] Throughout this description, certain terms have been used to refer to specific system components. As one of ordinary skill in the art will appreciate, different parties may refer to a component by different names. This document does not distinguish between components that differ in name but do not function. Throughout this disclosure and the claims, the terms "including" and "comprising" are used in an unlimited manner and should therefore be construed to mean "including, but not limited to..." Also, the term "pair" or "pairs" is intended to mean either an indirect or direct wired or wireless connection. Thus, when a first device pairs with a second device, this connection may be through a direct connection or through an indirect connection via other devices and connections.The phrase "based on" means "at least partially based on." Therefore, if X is based on Y, X can be a function of Y and any number of other factors.

[0055] The above discussion is intended to illustrate the principles and various implementations of the present disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.

Claims

[1] Procedure comprising: Receiving, by a Policy Management (PM) cluster (115), an access request message associated with a client device (105) and a user of the client device (105), wherein the access request message comprises a request to access a network infrastructure (700) partially managed by the PM cluster (115), wherein the PM cluster (115) comprises a plurality of PM nodes (210); in response to the access request message, determining, by the PM cluster (115), a role of the user, the role being associated with a scope of permitted access of the user to the network infrastructure (700); Extending a data set in a distributed data store (220) accessible by each PM node (210) of the plurality of PM nodes (210) to provide each PM node (210) of the plurality of PM nodes (210) with information about the role; Receiving, by the PM cluster (115), a first account request message associated with the client device (105) and the user, the first account request message comprising a request to access a specific service or resource of the network infrastructure (700); In response to the first account request message, accessing, by the PM cluster (115), the record to extend the first account request message by the role and provide a second account request message; and Providing the second account request message to a computing device (500, 600, 800) that is not part of the PM cluster (115) and that is associated with the specific service or resource. [2] The method of claim 1, wherein the distributed data store represents a multi-master cache (MMC) having a locally accessible data store for each PM node (210) of the plurality of PM nodes (210) to maintain common information about states of a plurality of client devices (105) and a plurality of roles for the plurality of client devices (105). [3] The method of claim 1 or 2, wherein extending the data set comprises a first PM node (210-1) of the plurality of PM nodes (210) updating the data set in response to the access request message, and wherein accessing the data set to extend the first account request message with the role comprises a second PM node (210-2) different from the first PM node (210-1) accessing the distributed data store (220). [4] The method of any one of claims 1 to 3, wherein receiving the first account request message comprises receiving a Remote Authentication Dial-In User Service (RADIUS) protocol message. [5] The method of claim 4, wherein extending the data set comprises embedding information in a segment of the RADIUS protocol message in accordance with an industry standard for a RADIUS protocol. [6] The method of any of claims 4 or 5, further comprising providing, by the PM cluster (115), a response to the first account request message before the computing device (500, 600, 800) responds to the second account request message. [7] The method of any one of claims 1 to 6, wherein the access request message is received at a first PM node (210-1) of the plurality of PM nodes (210), and the method further comprises: Receiving the first account request message at the first PM node (210-1); Updating the record in the distributed data store (220) to reflect the first account request message and create an updated record in the distributed data store (220); and Passing the updated data set to the plurality of PM nodes (210). [8] The method of claim 7, further comprising: Sharing at least a portion of the information from the updated data set with an infrastructure device of the network infrastructure (700) via a Remote Authentication Dial-In User Service (RADIUS) protocol message. [9] The method of claim 8, wherein the computing device (500, 600, 800) comprises a firewall (120, 125) or a network authentication server (NAS). [10] The method of any one of claims 1 to 9, wherein the PM cluster (115) comprises a high availability (HA) PM system. [11] A network infrastructure device comprising: a network interface communicatively connected to a first network; a processing device (501, 601) communicatively connected to the network interface; and a non-transitory storage medium (502, 602) that can be read by the processing device (501, 601) and stores instructions that, when executed by the processing device (501, 601), cause the network infrastructure device to provide the functionality of a first policy management (PM) node (210) of a plurality of PM nodes (210) of a PM cluster (115), and that is intended to: Receiving an access request message associated with a client device (105) and a user of the client device (105), the access request message comprising a request to access a network infrastructure (700) partially managed by the PM cluster (115); in response to the access request message, determining a role of the user, the role being associated with a scope of permitted access of the user to the network infrastructure (700); Extending a data set in a distributed data store (220) accessible by each PM node (210) of the plurality of PM nodes (210) to provide each PM node (210) of the plurality of PM nodes (210) with information about the role; Receiving a first account request message associated with the client device (105) and the user, the first account request message comprising a request to access a specific service or resource of the network infrastructure (700); In response to the first account request message, accessing the record to extend the first account request message with the role and to provide a second account request message; and Providing the second account request message to a computing device (500, 600, 800) that is not part of the PM cluster (115) and that is associated with the specific service or resource. [12] The network infrastructure device of claim 11, wherein the distributed data store represents a multi-master cache (MMC) having a locally accessible data store for each PM node (210) of the plurality of PM nodes (210) to manage shared information about states of a plurality of client devices (105) and a plurality of roles for the plurality of client devices (105). [13] The network infrastructure device of claim 11 or 12, wherein the instructions further comprise instructions to cause the network infrastructure device to receive a Remote Authentication Dial-In User Service (RADIUS) protocol message. [14] The network infrastructure device of any one of claims 11 to 13, wherein the instructions further comprise instructions to cause the network infrastructure device to: receiving the first account request message by a first PM node (210) of the plurality of PM nodes (210); updates the record in the distributed data store (220) to reflect the first account request message and create an updated record in the distributed data store (220); and passes the updated data set to the plurality of PM nodes (210). [15] The network infrastructure device of claim 14, wherein the instructions further comprise instructions to cause the network infrastructure device to: to share at least part of the information from the updated data set with another infrastructure device of the network infrastructure (700) via a RADIUS (Remote Authentication Dial-In User Service) protocol message. [16] A non-transitory, computer-readable medium (502, 602) having instructions stored thereon that, when executed by a processor (501, 601) of a first network infrastructure device, cause the first network infrastructure device to perform the following: Receiving an access request message associated with a client device (105) and a user of the client device (105), the access request message comprising a request to access a network infrastructure (700) partially managed by a policy management (PM) cluster (115), the PM cluster (115) comprising a plurality of PM nodes (210); in response to the access request message, determining a role of the user, the role being associated with a scope of permitted access of the user to the network infrastructure (700); Extending a data set in a distributed data store (220) accessible by each PM node (210) of the plurality of PM nodes (210) to provide each PM node (210) of the plurality of PM nodes (210) with information about the role; Receiving a first accounting request message associated with the client device (105) and the user, the first accounting request message comprising a request to access a specific service or resource of the network infrastructure (700); In response to the first account request message, accessing the record to extend the first account request message with the role and to provide a second account request message; and Providing the second account request message to a computing device (500, 600, 800) that is not part of the PM cluster (115) and that is associated with the specific service or resource. [17] The non-transitory computer-readable medium (502, 602) of claim 16, wherein the access request message is received at a first PM node (210) of the plurality of PM nodes (210) and further comprises instructions to cause the network infrastructure device to perform the following: Receiving the second account request message at a second PM node (210) of the plurality of PM nodes (210); and Updating the record in the distributed data store (220) to reflect the second account request message and creating an updated record in the distributed data store (220); and Passing on the updated data set to the plurality of PM nodes (210) of the PM system.

Images