Patent Application
20160277262
The present disclosure relates generally to communication networks, and more particularly, to policy servers.
Policy servers may be used, for example, to create and enforce network access policies for clients, connection request authentication, and connection request authorization. A policy management server may use multiple factors such as identity, location, profile, and posture to determine the access policies applied to any individual session. Manual inspection of session attributes and rules applied may be needed to determine why a particular access rule and result has been applied to a session in conventional systems.
Corresponding reference characters indicate corresponding parts throughout the several views of the drawings.
In one embodiment, a method generally comprises receiving at a policy server, a request to trace a session at the policy server, tracing the session at the policy server, wherein tracing comprises running the session and identifying access results from the trace, and transmitting the access results from the policy server to a network device requesting the trace.
In another embodiment, an apparatus generally comprises a processor for processing a request to trace a session at a policy server, tracing the session at the policy server, and transmitting access results from the policy server to a network device requesting the trace. The apparatus further comprises a policy engine for running the session through policies and memory for storing the policies and access results identified from the trace.
The following description is presented to enable one of ordinary skill in the art to make and use the embodiments. Descriptions of specific embodiments and applications are provided only as examples, and various modifications will be readily apparent to those skilled in the art. The general principles described herein may be applied to other applications without departing from the scope of the embodiments. Thus, the embodiments are not to be limited to those shown, but are to be accorded the widest scope consistent with the principles and features described herein. For purpose of clarity, details relating to technical material that is known in the technical fields related to the embodiments have not been described in detail.
The embodiments described herein may be used to identify a policy applied to a session at a policy server and test, modify, and verify changes to access policies applied to the session. As described in detail below, one or more embodiments reduce time and effort needed to write, test, and modify access policies on a policy server by providing a policy tracer and editor. The policy tracer allows a previous session from a history or a created session to be used to simulate the policy flow and result of the flow. The policy editor allows the conditions and result of the trace to be modified to view the effect of the changes. The embodiments may be used to match access results for a session back to the configuration and attributes and thereby provide a quick way to identify access results and reasons for the results, for any authentication or authorization request. The embodiments eliminate the need to manually go through large amounts of data to determine why a particular access rule and result has been applied to a session.
Referring now to the drawings, and first to
The network shown in the example of
In one example, network device (admin workstation, management device) 10 is a node operated by a network administrator, network integrator, or other network user. The node 10 may be used, for example, to simulate sessions between client 12 and the policy server 14. The network device 10 may also be used to modify sessions at the policy server 14 and view the impact of changes to the session. As shown in
The client (endpoint, station) 12 may be, for example, a desktop computer, laptop computer, IP (Internet Protocol) phone, server, appliance, game console, printer, camera, sensor, mobile phone, tablet, personal digital assistant, or any other device configured for communication with the policy server 14. The client 12 may be a managed or unmanaged device. For example, a user may attempt to access a network from a corporate-managed personal computer, personal network-accessible device, or public terminal. The client 12 may be a wired device or wireless device, or configured for both wired communication (e.g., connected to a docking station) and wireless communication.
The policy server 14 may be any network device operable to provide network access to one or more networks. For example, the policy server 14 may be an identity and access control policy platform that enables enterprises to enforce compliance and enhance infrastructure security (e.g., Identity Services Engine (ISE)). The policy server 14 may include, for example, one or more access directory, access control server, AAA (authentication, authorization and accounting) server/proxy, application server, controller, security manager, client profile manager, or any other node, combination of nodes, or source (e.g., network administrator) that provides authentication or policy information for the clients 12. The authentication server may use, for example IEEE 802. lx (Port Based Network Access Control), EAP (Extensible Authentication Protocol), EAPoUDP (EAP over User Datagram Protocol), Web Portal authentication, RADIUS (Remote Authentication Dial in User Service), Diameter, or any other authentication scheme. The policy server 14 may also provide support for discovery, profiling, and accessing device posture for endpoint devices, for example. The policy server 14 may be a computer, processor, network appliance, or other suitable device, component, element, or object capable of performing operations described herein. The policy tracer/editor 18, policy engine 19, and session database may all be located at the same node or one or more the components may be located at a separate node. For example, the session database may be stored on a separate monitoring node and the policy tracer 18 may search or fetch results from the database. Thus, the term “policy server” as used herein may refer to one or more network devices or a distributed platform.
The policy server 14 includes a policy engine 19 for running a policy session at the policy server. As described in detail below, the policy server 14 further comprises a policy tracer/editor 18 operable to simulate a policy flow at the policy server, provide results of the flow, and allow the result to be modified and the effect of the changes to the policy flow to be viewed.
In one embodiment, a sample session (access session) may be injected, either from a history or by entering key characteristics of the session. The policy server 14 applies authentication and authorization policies and the policy tracer 18 outputs the resultant policy and permissions and the reasons why those policies and permissions were used (access results). The policy server 14 may also use profiling and posture information learned from the sample session along with the authentication and authorization policies to determine the output.
As described further below, the policy editor 18 allows for modification to characteristics of the sample session to allow visualization of changes in the output. The policy editor may also allow the user to define the intended output to identify changes needed to policies to achieve a given result.
It is to be understood that the network shown in
Memory 24 may be a volatile memory or non-volatile storage, which stores various applications, operating systems, modules, and data for execution and use by the processor 22. Memory 24 may include, for example, one or more session database 28, access database or list, policy table, or any other data structure configured for storing policy, session history, access information, or user information. One or more components of the policy tracer/editor 18 (e.g., code, logic, software, firmware, etc.) may also be stored in memory 24. The network device 20 may include any number of memory components.
Logic may be encoded in one or more tangible media for execution by the processor 22. For example, the processor 22 may execute codes stored in a computer-readable medium such as memory 24. The computer-readable medium may be, for example, electronic (e.g., RAM (random access memory), ROM (read-only memory), EPROM (erasable programmable read-only memory)), magnetic, optical (e.g., CD, DVD), electromagnetic, semiconductor technology, or any other suitable medium. In one example, the computer-readable medium comprises a non-transitory computer-readable medium. The network device 20 may include any number of processors 22.
The network interface 26 may comprise any number of interfaces (linecards, ports) for receiving data or transmitting data to other devices. The network interface 26 may include, for example, an Ethernet interface for connection to a computer or network. The network interface 26 may be configured to transmit or receive data using a variety of different communication protocols. The interface 26 may include mechanical, electrical, and signaling circuitry for communicating data over physical links coupled to the network.
It is to be understood that the network device 20 shown in
It is to be understood that the process shown in
In one embodiment, the policy tracer/editor 18 is implemented using a graphical user interface (GUI).
In one example, a past session stored in a database (e.g., session database 28 in
In another example, the GUI may be used to build a session that is then run through the policy trace tool. Any attribute or value available to the policy engine may be available to the administrator when building the session. While building the session, the administrator may have an option to query the system for current values for a particular client (user, endpoint), group, profile, stored attribute/value, etc.
As shown in
It is to be understood that the GUIs shown in
Once the complete output from the tracer is available, the editor mode may be enabled to allow the user to modify the sample session, conditions on one or more steps, or the end result. Once all changes are completed, the user may request a rerun of the trace on the modified session. The tracer may then repeat the steps shown in
It is to be understood that the process shown in
If after initial configuration of the policy server 14, a test session fails, the administrator may select the failed attempt from the session history and run the tracer on the failed attempt. The tracer may use attributes from the session and run it through policies at the policy server 14. The following is an example of output from the policy tracer:
The output from the policy tracer in the above example shows that the user is not part of the Active Directory group that is allowed access by Rule #1. The policy editor may then be enabled to allow the administrator to change authorization Rule #1 to match another group that is listed in step 5. Upon running the policy tracer again, the authorization rule in step 6 will be matched and the user will be allowed access. This tells the administrator the change needed in the actual rules that will cause an expected access result. It is then possible to apply the changes to the rules directly from the policy editor.
Although the method and apparatus have been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations made without departing from the scope of the embodiments. Accordingly, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
