Token-as-a-service generation system and method for software-defined zero trust network

Abstract

The invention relates to a token-as-a-service generation system and a method for enabling the operation of said system, which enables the maintenance of security in multi-tenant network systems and the creation of a zero-trust network for software-defined network-managed systems.

Description

[0001] DESCRIPTION

[0002] TOKEN-AS-A-SERVICE GENERATION SYSTEM AND METHOD FOR SOFTWARE- DEFINED ZERO TRUST NETWORK

[0003] Technical Field

[0004] The invention relates to a token -as-a-service (service token) generation system and a method for enabling the operation of said system, which enables the maintenance of security in multi-tenant network systems and the creation of a zero-trust network for software-defined network- man aged systems.

[0005] State of the Art

[0006] According to a National Institute of Standards and Technology (NIST) technical report published in 2020 [1], a Zero Trust Network (ZTN) is a network that provides dynamic control of network equipment and requires continuous authentication for access to its physical resources. Hence, there is an urgent need to migrate ZTN to next generation networks (NGN). Ericsson's technical report [2], published in 2021, states that for the implementation of zero trust in 5G networks, key points such as secure digital identification, secure transmission, policy frameworks, and secure monitoring of the network should be taken into account. However, this is very difficult to implement in multi-tenant systems such as, for example, Youtube (content as a service), Spotify (music as a service), Netflix (entertainment as a service), Office 365 (business as a service) and so on. Each network tenant has its own policies and these are not the same for all services. Advanced Mobile Broadband (eMBB) requires large bandwidth, Ultra Reliable Low Latency (URLLC) requires strict latency, and the massive internet of things (mloT) has high capacity needs. On the other hand, in multi-tenant systems, isolated parts of the network equipment also need to be dynamically accessed and configured by tenants. Today, multi-tenant configuration of switches is not allowed since most network problems are caused by human-based configurations.

[0007] In the state of the art, there is a lack of study on the implementation details of the multitenant system and the seamless transition from software defined networks (SDN) to ZTN. The studies in the state of the art do not take into account the distributed SDN architecture for multi-tenants, which is believed to reduce theauthorization / authentication burden on cloud servers. This can lead to configuration difficulties, inability to meet the desired response times, increased hardware costs due to the need to design different hardware for each tenant, as well as the need to produce additional network devices and increase in carbon emissions during device production, difficulties in keeping up with rapidly evolving technological innovations, negative impact on scalability, and failure to ensure sustainable network management.

[0008] There is a need to develop new systems and methods in order to eliminate said disadvantages stated above and in the state of the art.

[0009] Summary of the Invention

[0010] The present invention, in order to overcome the disadvantages mentioned above and to provide new advantages in the field, relates to a token-as-a-service generation system and a method for enabling the operation of said system, which enables the maintenance of security in multi-tenant network systems and the creation of a zerotrust network for software-defined network-managed systems.

[0011] The invention provides a new SDN-based architecture structure and management to sustain a trusted zone in a complex multi-tenant environment. The invention is a system that reduces the authentication / authorization burden while making security sustainable in multi-tenant network systems, provides network system management with simplified and distributed databases, and supports a smooth transition to a zero trust network with its simple implementation. In the system, each network equipment can be dynamically configured by many SDN controllers in a distributed manner without security breach. Furthermore, the dynamic nature of virtual deployment results in complex configuration requests that are not easy to manage in a trusted zone. The present invention therefore provides a cross-layer design to separate trusted and untrusted regions.

[0012] With the system and method of the invention, digital identification of multi-tenants in SDN is provided using token or session-based authentication. Controller services communicate with each other through protocols such as RESTCONF, NETCONF, gRPC-based gNMI, etc. The per-tenant session needs to be recorded in the central database, whereas the token is stored on the end device, and for this reason both SDNprotocols support token-based authentication, which is preferable to session-based. In this way, the invention overcomes the burden on the central authentication / authorization server for each configuration request received from multiple tenants. Considering the expiration time, it requires dynamic replacement of each generated token, reducing the vulnerability of network equipment dynamically configured by multi-tenant SDN controllers. More specifically, the JSON Web Token (JWT) also has simple coding in object-oriented programming languages. The most popular controller of the SDN environment is ONOS, which is also coded in Java, the most popular object-oriented programming language. Therefore, the use of JSON in the invention increases the sustainability of the network by securely authenticating the authentication procedure. There are many security algorithms for generating tokens as a service. However, since token similarity would greatly undermine ZTN's security, the invention provides a next-generation genetic algorithm-based approach that generates dissimilar tokens. In the invention, the token is generated by unique authentication per tenant within an appropriate response time. It also optimizes token service demand to minimize the cost of centralized authorization / authentication controllers in a complex multi-tenant environment.

[0013] The invention is the first to use a next-generation evolutionary-based genetic algorithm, which generally performs well in service optimization, for a new Token as-a-Service (TaaS). The invention defines a new Zero Trust Evaluation (ZTE) metric to theoretically analyze the level of zero trust, taking into account token similarity and vulnerability. It divides its cyber and physical layers into two, where the physical layer includes the routing engine of the forged OpenFlow switches and the cyber layer includes the Policy Enforcement Point (PEP) of the OpenFlow switches and the Policy Decision Point (PDP) of the authentication / authorization server. The system and method of the invention enables virtual separation of the forwarding engine of OpenFlow switches between multi-tenants, where authorized SDN controllers can configure tables according to their policies. In PDP, a new Token as a Service (TaaS) is proposed that dynamically orchestrates the authentication / authorization of multiple tenants to configure their virtual parts in the physical layer. The TaaS in the invention runs a new Genetic Algorithm-based optimization service that solves microservice assignment problems with different datasets randomly determined to generate tokens per request. The invention enables simple implementation of any platform through the use of ahighly secure and object-oriented JWT (JSON Web Token) module carried in the header of each configuration request.

[0014] The invention is proposed against various types of attacks that directly damage the security of network equipment, such as Address Resolution Protocol (ARP) spoofing attack, MAC overflow / CAM table overflow, Spanning Tree Protocol (STP) attack, Virtual Local Area Network (VLAN) hopping.

[0015] The system and method of the invention reduce the authentication / authorization burden while making security sustainable in multi-tenant network systems. It provides network system management with simplified and distributed databases. Its simple coding supports a seamless transition to a zero-trust network.

[0016] To meet different service requirements and minimize the risk of physical deployment and operational / capital expenditures, investments in Software as a Service (SaaS) are twice as high as those in Platform / lnfrastructure as a Service implementations in the physical network. It is now being proven that multi-tenant slicing can be orchestrated through the development of open and virtualized technology called Software Defined Networks (SDN). SDN divides the network into data and control planes. Here, the central controller periodically and dynamically monitors and manages the topology through the global view. The OpenFlow protocols of the invention embed the transmission rules in the data plane. Human-induced configuration issues are overcome without touching the physical equipment in the data plane. This minimizes the risk of distribution. This allows tenants to edit their configurations on their virtual partitions.

[0017]

[0018] The embodiments of the invention, briefly summarized above and discussed in more detail below, can be understood with reference to the example embodiments of the invention described in the accompanying drawings. It should be noted, however, that the accompanying drawings only illustrate typical embodiments of this invention and are not to be considered as limiting to its scope.Fig. 1. A schematic representative view of the system of the invention.

[0019] Fig. 2. A detailed schematic representative view of the system of the invention.

[0020] Fig. 3. A representative view of a diagram showing the working principle of the method of the invention.

[0021]

[0022] For a better understanding of the invention, the description of the numbers in the figures is given below:

[0023] 1. Physical Topology

[0024] 2. SDN Controller

[0025] 3. Network device

[0026] 4. Policy Implementation Point

[0027] 5. Cloud Layer

[0028] 6. Controller

[0029] 7. Policy Decision Point

[0030] 8. Digital Network Device Twin

[0031] 9. Token-as-a-Service Module

[0032] 10. Token Generation Module

[0033] 11. JWT (JSON Web Token) Module

[0034] 12. Policy Request Sorting Module

[0035] 13. Authorization Module

[0036] 14. Token Control Module

[0037] 15. Security Database

[0038] 16. Partitioned OpenFlow Table Module

[0039] 1001. Creating a digital network device twin of the network devices in the physical topology with the data transmitted on the cloud layer

[0040] 1002. Sending requests to policy implementation point with configuration permission from SDN controller in multi-tenant system

[0041] 1003. Sorting and queuing all requests received by the policy enforcement point in the policy request sorting module with the FIFO method1004. Sending the relevant information to the cloud layer by the authorization module in case the configuration request pending in the queue of the policy request module is performed by a previously unregistered SDN controller

[0042] 1005. Registering the SDN controller by the token-as-a-service module and generating the token generation request in the token generation module with the genetic algorithm 1006. Using the parents selected in the token generation module, separating the maternal and paternal chromosomes from two randomly determined points, and removing the first and last part of the maternal chromosome and the middle part of the paternal chromosome and generating new generations

[0043] 1007. Performing mutation at a randomly determined point on the new generations produced in the token generation module

[0044] 1008. Updating the token generation module, in case new generations have parts that do not comply with the optimization formula constraints, and updating the cost metrics 1009. Running the survival phase by mixing new generations with the parent pool in the token generation module

[0045] 1010. Transmitting the generated token to the JWT module when the number of iterations to be run in the token generation module is completed

[0046] 1011. Generating hashed bearer tokens in the JWT module using the generated token and SDN controller information and returning these values to the token-as-a-service module

[0047] 1012. Transmitting the token value of the generated token-as-a-service to the authorization module with the digital network device twin

[0048] 1013. Storing the information of the SDN controller with the token received by the authorization module in the security database and transmitting the generated token to the SDN controller

[0049] 1014. Transmitting the configuration request of network devices to the policy implementation point using a token via the SDN controller and network management protocols

[0050] 1015. Transmitting the request to the token control module in case a previously registered SDN controller fulfills the configuration request that is pending in the queue of the policy request sorting module

[0051] 1016. Checking the request by the token control module through queries to the security database1017. Making the relevant configurations in the partitioned OpenFlow table module in case the token is valid and granting authorization permission to the SDN controller via network devices

[0052] 1018. Issuing a rejection response to the SDN controller via network devices in case the token is not valid

[0053] Detailed Description of the Invention

[0054] The example embodiments are described in more detail below with reference to the accompanying descriptions. Furthermore, the embodiments can be established in different forms and should not be interpreted as being limited to the embodiments specified herein. Rather, these example embodiments are provided so that this description will be thorough, and will fully convey the scope to those skilled in the art.

[0055] The invention relates to a computer-aided token-as-a-service generation system that includes at least one processor, which enables the maintenance of security in multitenant network systems and the creation of a zero-trust network for software-defined network-managed systems. Said system comprises:

[0056] at least one physical topology (1), which is the physical environment in which network devices reside and are managed,

[0057] - at least one SDN controller (2) that defines OpenFlow network protocol rules according to the multi-tenant system's own network policies,

[0058] at least one network device (3) that is wired to each other with OpenFlow network switches and provides wireless and / or wired access to all physical topology (1) elements within the topology,

[0059] - at least one policy implementation point (4) that enables the collection of statistics within the network device (3), the periodic transmission of said statistics to the controller (6) via the OpenFlow protocol, and realizes the management of the queuing, authorization, acceptance or rejection of policy requests from multitenant SDN controllers (2),

[0060] - at least one cloud layer (5) with a centralized data processing resource,

[0061] - at least one controller (6), which is the center where the system is coded, implemented and executed in software,- at least one policy decision point (7), which is a security center that grants authorization for configuration requests that SDN controllers (2) want to perform on the network device (3) in the multi-tenant system,

[0062] - at least one digital network device twin (8) that corresponds to digital representations of devices in the physical topology (1) environment and performs periodic state updates with data received from the physical topology (1),

[0063] - at least one token-as-a-service module (9), which is a token generation center according to the configuration requests that SDN controllers (2) want to perform on the network device (3) in a multi-tenant system,

[0064] - at least one token generation module (10) that enables token generation by performing parent selection, crossover, mutation, and survival selection processes with a genetic algorithm, respectively,

[0065] - at least one JWT module (11) that allows the token generated by the genetic algorithm to be given as an argument to the bearer token (authorization token) in the JWT library and to be finalized as a hashed token,

[0066] - at least one policy request sorting module (12) that enables queuing requests from multi-tenants' SDN controllers (2) according to the FIFO method,

[0067] - at least one authorization module (13) that handles registration and token generation process when a multi-tenant SDN controller (2) first requests to configure its policies,

[0068] - at least one token control module (14) that checks the validity and authorization limit of the token value generated according to the multi-tenant SDN controller (2) that has been authorized,

[0069] - at least one security database (15) that provides authorized SDN controller (2) information and token controls,

[0070] - at least one partitioned OpenFlow table module (16) that allows configuration requests to be executed via network management protocols by partitioning physical or software-based tables as a result of the authorization of SDN controllers (2) in a multi-tenant system.

[0071] Figure 1 shows in detail the proposed network architecture for a software-defined zero trust network (SDZTN). The system of the invention referred to herein is divided into data and control planes. The data plane is defined as the physical topology (1) and the control plane as the cloud layer (5). The physical topology (1) includes a physical layer with physical network switches, such as customer premises equipment forindoor / outdoor end users, base stations, access points or roadside units for communication of vehicles with intelligent transport systems, routers, switches and firewalls, and is the backbone of the topology. There are also mobile users and application servers where data flows are routed between these pairs. Data flows between physical equipment are routed and configured by the physical network device (3). A network device (3) that is wired to each other with OpenFlow network switches is defined as an OpenFlow network device. The network device (3) mentioned here is OpenFlow switches. This network device (3) communicates periodically with the cloud layer (5) through the Token as a Service (TaaS) service to maintain the zero-trust network. Some multi-tenant SDN controllers (2) use a virtual network device (3) in the topology. Not only can it embed OpenFlow rules in the partitioned OpenFlow table module (16), but it can also configure the tables according to its own policies. The network management protocols mentioned in the invention are NETCONF, RESTCONF, SNMP or OpenFlow protocols. The invention can manage its policies using said NETCONF, RESTCONF, SNMP, and OpenFlow protocols that enable communication between the control and data planes. To do this, firstly, multi-tenant SDN controllers (2) are authenticated and then, based on the token authentication result, they can edit their policies in their own virtual slices on the network device (3), which is a single OpenFlow switch. As a result of the authorization process, the information of the new SDN controllers (2) is kept in this security database (15) for a certain period of time. Token checks are implemented through queries to this security database (15). Said security database (15) is the database of the OpenFlow network switch.

[0072] Figure 2 shows a detailed version of a network device (3). Policy requests from the SDN controllers (2) of the multi-tenant system are queued in the policy request sorting module (12) according to the FIFO method and the authorization of the requests is evaluated. If the requesting SDN controller (2) makes a configuration request to the policy implementation point (4) of the network device (3) for the first time, the system login record of the SDN controller (2) is examined through the authorization module (13) and if the authentication is verified, the token is generated through the token generation module (10) with the genetic algorithm. After token generation, the SDN controller (2) stores the information in the security database (15). If it is a previously registered and authorized SDN controller (2), the token control module (14) checks theauthorization field and token validity with queries to the security database (15) and authorization is granted or denied.

[0073] The invention relates to a method for enabling the operation of a computer-aided token-as-a-service generation system that includes at least one processor, which enables the maintenance of security in multi-tenant network systems and the creation of a zero-trust network for software-defined network-managed systems, comprising the following process steps:

[0074] - creating a digital network device twin (8) of the network devices (3) in the physical topology (1 ) with the data transmitted on the cloud layer (5) (1001 ), - sending requests to policy implementation point (4) with configuration permission from SDN controller (2) in multi-tenant system (1002),

[0075] - sorting and queuing all requests received by the policy enforcement point (4) in the policy request sorting module (12) with the FIFO method (1003),

[0076] - sending the relevant information to the cloud layer (5) by the authorization module (13) in case the configuration request pending in the queue of the policy request module (12) is performed by a previously unregistered SDN controller (2) (1004),

[0077] - registering the SDN controller (2) by the token-as-a-service module (9) and generating the token generation request in the token generation module (10) with the genetic algorithm (1005),

[0078] - using the parents selected in the token generation module (10), separating the maternal and paternal chromosomes from two randomly determined points, and removing the first and last part of the maternal chromosome and the middle part of the paternal chromosome and generating new generations (1006),

[0079] - performing mutation at a randomly determined point on the new generations produced in the token generation module (10) (1007),

[0080] - updating the token generation module (10), in case new generations have parts that do not comply with the optimization formula constraints, and updating the cost metrics (1008),

[0081] running the survival phase by mixing new generations with the parent pool in the token generation module (10) (1009),

[0082] - transmitting the generated token to the JWT module (11) when the number of iterations to be run in the token generation module (10) is completed (1010),- generating hashed bearer tokens in the JWT module (11) using the generated token and SDN controller (2) information and returning these values to the token-as-a-service module (9) (1011),

[0083] - transmitting the token value of the generated token-as-a-service to the authorization module (13) with the digital network device twin (8) (1012), - storing the information of the SDN controller (2) with the token received by the authorization module (13) in the security database (15) and transmitting the generated token to the SDN controller (2) (1013),

[0084] - transmitting the configuration request of network devices (3) to the policy implementation point (4) using a token via the SDN controller (2) and network management protocols (1014),

[0085] - transmitting the request to the token control module (14) in case a previously registered SDN controller (2) fulfills the configuration request that is pending in the queue of the policy request sorting module (12) (1015),

[0086] - checking the request by the token control module (14) through queries to the security database (15) (1016),

[0087] - making the relevant configurations in the partitioned OpenFlow table module (16) in case the token is valid and granting authorization permission to the SDN controller (2) via network devices (3) (1017),

[0088] - issuing a rejection response to the SDN controller (2) via network devices (3) in case the token is not valid (1018).

[0089] In the 1005th process step of the method steps of the invention, the registration of the SDN controller (2) with the token-as-a-service module (9) is realized. With the genetic algorithm method, a token generation request is generated in the token generation module (10). The genetic algorithm method solves the microservice assignment problem shown in Equation 1 defined below for different data sets by iterating over a given number of iterations.

[0090]

[0091] Equation-1

[0092] The cost specified in said equation is calculated based on the assignment of microservice (c) to theawvirtual field. Tcwdetermines the response time to locate microservice (c) in theawvirtual machine.Scomprises the cost of creating theawvirtualfield. Total cost is calculated as in Equation 1. In Equation 2 and Equation 3 below, the specific constraints of this problem are defined.

[0093]

[0094] Equation-3

[0095] According to Equation 2, the total field requirements of the microservices specified in constraint C1 should not exceed the capacity of theawfield. Wherein dcis the field requirement for each microservice (c) to run and capwis the total memory capacity of the virtual machine. According to Equation 3, in constraint C2, each microservice can be assigned to only one virtual field. The genetic algorithm solves this problem by using the parents selected in the token generation module (10) to separate the maternal and paternal chromosomes at two randomly selected points.

[0096] In the 1009th process step of the method steps of the invention, in the token generation module (10), the survival phase is run by mixing the new generations with the parent pool. The best ones according to cost metrics remain in the pool, while the others are deleted from the pool.

[0097] The network management protocols mentioned in the 1014th process step of the method steps of the invention are NETCONF, RESTCONF, SNMP or OpenFlow protocols, however the application is not limited thereto.

[0098] The above embodiments are intended only to describe the technical concept and features of the present invention, and the purpose of the present invention is to ensure that those skilled in the art understand the content of the present invention and practice the present invention, and the scope of the present invention is not limited thereto. Equivalent changes or modifications made in accordance with the spirit of the invention are intended to be included in the scope of the invention.Industrial Applicability of the Invention

[0099] The invention relates to a token-as-a-service generation system and a method for enabling the operation of said system, which enables the maintenance of security in multi-tenant network systems and the creation of a zero-trust network for software-defined network- man aged system, and is industrially applicable.

[0100] The invention is not limited to the example embodiments above, and the person skilled in the art can readily present other different embodiments of the invention. These should be considered within the protection scope of the invention claimed by the claims.References

[0101] [1] Rose, S., Borchert, O., Mitchell, S., Connelly, S.: Zero trust architecture. Nat. Inst. Standards Technol. NIST Special Publication (SP) (800-207) (2020)

[0102] [2] Olsson, J., Shorov, A., Abdelrazek, L., Whitefield, J.: 5g zero trust: a zero trust architecture for telecom. Ericsson Technol. Rev. 5, 2-11 (2021)

Claims

CLAIMS1. A system for generating a computer-aided token-as-a-service, including at least one processor, which enables the maintenance of security in multi-tenant network systems and the creation of a zero-trust network for software-defined network-managed systems, characterized in that it comprises:- at least one physical topology (1), which is the physical environment in which network devices reside and are managed,- at least one SDN controller (2) that defines OpenFlow network protocol rules according to the multi-tenant system's own network policies,- at least one network device (3) that is wired to each other with OpenFlow network switches and provides wireless and / or wired access to all physical topology (1) elements within the topology,- at least one policy implementation point (4) that enables the collection of statistics within the network device (3), the periodic transmission of said statistics to the controller (6) via the OpenFlow protocol, and realizes the management of the queuing, authorization, acceptance or rejection of policy requests from multi-tenant SDN controllers (2),- at least one cloud layer (5) with a centralized data processing resource, - at least one controller (6), which is the center where the system is coded, implemented and executed in software,- at least one policy decision point (7), which is a security center that grants authorization for configuration requests that SDN controllers (2) want to perform on the network device (3) in the multi-tenant system,- at least one digital network device twin (8) that corresponds to digital representations of devices in the physical topology (1) environment and performs periodic state updates with data received from the physical topology (1),- at least one token-as-a-service module (9), which is a token generation center according to the configuration requests that SDN controllers (2) want to perform on the network device (3) in a multi-tenant system,- at least one token generation module (10) that enables token generation by performing parent selection, crossover, mutation, and survival selection processes with a genetic algorithm, respectively,- at least one JWT module (11) that allows the token generated by the genetic algorithm to be given as an argument to the bearer token in the JWT library and to be finalized as a hashed token,- at least one policy request sorting module (12) that enables queuing requests from multi-tenants' SDN controllers (2) according to the FIFO method,- at least one authorization module (13) that handles registration and token generation process when a multi-tenant SDN controller (2) first requests to configure its policies,- at least one token control module (14) that checks the validity and authorization limit of the token value generated according to the multi-tenant SDN controller (2) that has been authorized,- at least one security database (15) that provides authorized SDN controller (2) information and token controls,- at least one partitioned OpenFlow table module (16) that allows configuration requests to be executed via network management protocols by partitioning physical or software-based tables as a result of the authorization of SDN controllers (2) in a multi-tenant system.

2. The system according to claim 1, characterized by network management protocols, which are NETCONF, RESTCONF, SNMP or OpenFlow protocols.

3. A method for enabling the operation of a computer-aided token-as-a-service generation system that includes at least one processor, which enables the maintenance of security in multi-tenant network systems and the creation of a zero-trust network for software-defined network- man aged systems, characterized in that it comprises the process steps of:- creating a digital network device twin (8) of the network devices (3) in the physical topology (1 ) with the data transmitted on the cloud layer (5) (1001 ), - sending requests to policy implementation point (4) with configuration permission from SDN controller (2) in multi-tenant system (1002),- sorting and queuing all requests received by the policy enforcement point (4) in the policy request sorting module (12) with the FIFO method (1003), - sending the relevant information to the cloud layer (5) by the authorization module (13) in case the configuration request pending in the queue of thepolicy request module (12) is performed by a previously unregistered SDN controller (2) (1004),- registering the SDN controller (2) by the token-as-a-service module (9) and generating the token generation request in the token generation module (10) with the genetic algorithm (1005),- using the parents selected in the token generation module (10), separating the maternal and paternal chromosomes from two randomly determined points, and removing the first and last part of the maternal chromosome and the middle part of the paternal chromosome and generating new generations (1006),- performing mutation at a randomly determined point on the new generations produced in the token generation module (10) (1007),- updating the token generation module (10), in case new generations have parts that do not comply with the optimization formula constraints, and updating the cost metrics (1008),running the survival phase by mixing new generations with the parent pool in the token generation module (10) (1009),transmitting the generated token to the JWT module (11) when the number of iterations to be run in the token generation module (10) is completed (1010),- generating hashed bearer tokens in the JWT module (11) using the generated token and SDN controller (2) information and returning these values to the token-as-a-service module (9) (1011 ),- transmitting the token value of the generated token-as-a-service to the authorization module (13) with the digital network device twin (8) (1012), storing the information of the SDN controller (2) with the token received by the authorization module (13) in the security database (15) and transmitting the generated token to the SDN controller (2) (1013),- transmitting the configuration request of network devices (3) to the policy implementation point (4) using a token via the SDN controller (2) and network management protocols (1014),- transmitting the request to the token control module (14) in case a previously registered SDN controller (2) fulfills the configuration request that is pending in the queue of the policy request sorting module (12) (1015),- checking the request by the token control module (14) through queries to the security database (15) (1016),- making the relevant configurations in the partitioned OpenFlow table module (16) in case the token is valid and granting authorization permission to the SDN controller (2) via network devices (3) (1017),- issuing a rejection response to the SDN controller (2) via network devices (3) in case the token is not valid (1018).

4. The method according to claim 3, characterized in that said network management protocols in the process step of transmitting the configuration request of network devices (3) to the policy implementation point (4) using a token via the SDN controller (2) and network management protocols (1014) are NETCONF, RESTCONF, SNMP or OpenFlow protocols.

Images