Platform and method for authenticating service requests in service mesh network

The platform and method for authenticating service requests in a service mesh network address the need for ZT and ZTA compliance by using a prediction model to categorize A&A service modules and selectively access them, thereby improving performance and reducing latency.

WO2025116796A1PCT designated stage expired Publication Date: 2025-06-05TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/SE2023/051205
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-11-30
Publication Date
2025-06-05

AI Technical Summary

Technical Problem

There is a need for an improved method for authenticating service requests in a service mesh network that adheres to Zero Trust (ZT) and Zero Trust Architecture (ZTA) principles, while minimizing the impact on the overall performance of the service mesh architecture.

Method used

A platform and method that utilize a prediction model to predict a security risk score for each service request, categorize authentication and authorization (A&A) service modules based on this score, and selectively access the appropriate A&A service module for authentication, thereby reducing the computational overhead and improving performance.

Benefits of technology

The proposed solution enhances the end-user experience by reducing service request latency, improves platform performance by simplifying A&A operations, and conserves energy due to reduced latency and improved system efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure SE2023051205_05062025_PF_FP_ABST
    Figure SE2023051205_05062025_PF_FP_ABST
Patent Text Reader

Abstract

Embodiments of the present disclosure provide platform (4000) for service mesh network (400) being implemented in one or more clusters (2000). The platform (4000) comprises application layer (401) to receive incoming client service requests and a plurality of authentication and authorization, A&A, service modules (408) arranged to authenticate incoming client service requests. The platform (4000) further comprises service mesh, SM, proxy modules (406) arranged to receive service requests through gateway (402) and arranged to selectively provide access to the plurality of A&A service modules (408). The platform (4000) further comprises processor (410) configured in gateway (402) of the service mesh network (400) for predicting security risk score for service requests; categorizing the plurality of A&A service modules according to service risk score, selecting categorized A&A service module according to the risk score. Incoming client service request are authenticated by the SM proxy modules (406) through categorized A&A service module (408).
Need to check novelty before this filing date? Find Prior Art

Description

[0001] PLATFORM AND METHOD FOR AUTHENTICATING SERVICE REQUESTS IN SERVICE MESH NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to a field of service mesh architecture. More particularly, it relates to a platform and a method for authenticating service requests in a service mesh network implemented in a micro-service architecture.

[0004] BACKGROUND

[0005] A service mesh is as a dedicated infrastructure layer built into an application to optimize communication between services as the application expands. In a service mesh architecture, different services (i.e., different parts of an application) are provided to share data among the different services and perform authentication and authorization, A&A, given to these services with strong adaptability. The service mesh architecture provides a platform to plugin a variety of service authentication modules for authenticating different services, such service authentication modules include for example Certificate Management Modules, and Identity Access Management Modules, etc. For cloud native applications built in a micro-service architecture, the service mesh may have a large number of different services within a functional application. The micro-service may be deployed either in a centralized system or in a distributed system.

[0006] In 5G core (5GC) networks, all network functions (NFs) are designed based on the microservice architecture as this architecture has been widely adopted in developing, deploying, and operating network applications in the past. It is now anticipated that the NFs will be implemented in 5GC networks based on the micro-service architecture using containerized technology such as Kubernetes. The introduction of a service mesh proxy as a sidecar improves the efficiency of managing the applications deployed in the container-based platform by decoupling a non-feature function, such as authentication and authorization, A&A, service discovery, and load balancing functions from feature service function. For enhanced security considerations, many governing authorities are pushing to follow zero trust, ZT, concept and correspond to a zero trust architecture, ZTA, implementation in order to protect the individual services offered in the network. Zero trust, ZT, provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture, ZTA, is an enterprise's cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.

[0007] ZTA is designed and deployed with adherence to the following zero trust seven tenets.

[0008] Tenet-1: All data sources and computing services are considered resources.

[0009] Tenet-2: All communication is secured regardless of network location.

[0010] Tenet-3: Access to individual enterprise resources is granted on a per session basis.

[0011] Tenet-4: Access to resources is determined by dynamic policy - including the observable state of client identity, application / service, and the requesting asset - and may include other behavioral and environmental attributes.

[0012] Tenet-5: The enterprise monitors and measures the integrity and security posture of all owned and associated assets.

[0013] Tenet-5: All resource authentication and authorization are dynamic and strictly enforced before access is allowed.

[0014] Tenet-7: The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

[0015] SUMMARY

[0016] There is a need for an improved method for authenticating service requests in a service mesh network that adheres to ZT and ZTA having a reduced impact on the overall performance of service mesh architecture.

[0017] It is therefore an object of the present disclosure to provide a platform and a method for authenticating service requests in a service mesh network, to mitigate, alleviate, or eliminate all or at least some of the above-discussed drawbacks of presently known solutions. This and other objects are achieved by means of a platform, and a method defined in the appended claims. The term exemplary is in the present context to be understood as serving as an instance, example or illustration.

[0018] According to a first aspect of the present disclosure, a platform for a service mesh network being implemented in one or more clusters and forming a micro-service architecture, is provided. The platform comprises an application layer configured in the service mesh network and having one or more service instances, wherein the application layer is arranged to receive one or more service requests. The platform further comprises a plurality of authentication and authorization, A&A, service modules each arranged to authenticate service requests, wherein each A&A service module is implemented in one or more of the one or more clusters in the service mesh network. The platform further comprises one or more service mesh, SM, proxy modules each arranged to receive one or more of the one or more service requests received through the application layer and each arranged to selectively provide access to the plurality of authentication and authorization, A&A, service modules. The platform further comprises a processor configured in a gateway of the service mesh network. The processor is communicatively coupled to the one or more SM proxy modules, and the gateway is arranged to receive the one or more incoming client service requests from the one or more clients and forward the one or more incoming client service requests to the one or more SM proxy modules. The processor executes by executing a set of instructions stored in a memory, wherein the memory is communicatively coupled to the processor and is configured in the service mesh network. The processor is configured for: predicting, through a prediction model, a security risk score for each service request from the one or more incoming client service requests; categorizing, through a classification module, the plurality of A&A service modules into a plurality of categorized A&A service modules, wherein the plurality of A&A service modules are categorized according to the service risk score; and selecting, through a selection model, at least one categorized A&A, service module from the plurality of categorized A&A service modules according to the risk score associated with each incoming client service request. The one or more SM proxy modules are configured for: authenticating, each of the incoming client service requests from the one or more incoming client service requests by selectively accessing the at least one categorized A&A service module selected by the selection model; and forwarding, through a load balancer, the one or more service requests to the one or more service instances based on the selected authentication through the at least one categorized A&A service module.

[0019] Optionally, the security risk score is selected from a group comprising at least one of: one or more low security risk score, one or more medium security risk score and one or more high security risk score.

[0020] Optionally, the processor is further configured for identifying, through an identification module, each of the incoming client service requests as one of a trusted service request when the security risk score is the one or more low security risk score, an untrusted service request when the security risk score is the one or more high security risk score, an unknown service request when the security risk score is the one or more medium security risk score.

[0021] Optionally, the processor is further configured for forwarding, after the authentication, the incoming client service request to one or more target service instances from the one or more service instances, wherein the one or more target service instances are configured to generate a service response for the one or more incoming client service requests.

[0022] Optionally, the processor is further configured for: identifying, if the one or more target service instances to be selected are running in a same cluster from the one or more clusters; selecting, at least one similar categorized A&A service module from the plurality of categorized A&A service modules; authenticating, through the SM proxy module, the one or more incoming client service requests by using the at least one similar categorized A&A service module; and generating, through the one or more target service instances, the service response towards the one or more incoming client service requests based on the selected authentication through the at least one categorized A&A service module.

[0023] Optionally, the processor is further configured for: identifying, if the one or more target service instances are running in a different cluster from the one or more clusters; evaluating, through a gateway of the different cluster, the category of the categorized A&A service module from the plurality of categorized A&A service modules; selecting, through the selection module, the categorized A&A service module from the plurality of categorized A&A service modules based on the evaluation; authenticating, through the SM proxy module, the one or more incoming client service requests by using the at least one categorized A&A service module based on the evaluation; and generating, through the one or more target service instances, the service response towards the one or more incoming client service requests based on the selected authentication through the at least one categorized A&A service module.

[0024] Optionally, the prediction model is configured for: developing a Machine Learning, ML, model for predicting the security risk score, wherein the machine leaning model is developed by using one or more parameters functionally related to the one or more incoming client service requests.

[0025] Optionally, the one or more parameters comprise a time stamp associated with one or more of: payload data, Source, Src IP, Destination, dest IP, client IP, App / service ID, HTTP headers, and at least one input risk levels comprising one or more low levels, one or more medium levels, or one or more high levels.

[0026] Optionally, the ML model is selected from a group of supervised ML model, a semi-supervised ML model, an unsupervised ML model.

[0027] Optionally, the A&A service module is selected from a group comprising of Identity Access Management, 1AM, module, and Certificate Management Module, CMS.

[0028] Optionally, the plurality of categorized A&A service modules are categorized into one or more categories, wherein the one or more categories is selected from a group comprising simple A&A service module when the security risk score comprises the one or more low security risk score, a basic A&A service module when the security risk score comprises the one or more medium security risk score and an advance A&A service module when the security risk score comprises the one or more high security risk score.

[0029] Optionally, the plurality of A&A service modules comprise one of: a centrally deployed authentication service module, and a distributed deployed authentication service module, wherein the centrally deployed authentication service module is deployed in a central location within a cluster, and wherein the distributed deployed authentication service module is provided within the SM proxy module.

[0030] Optionally, the plurality of A&A service modules is deployed as a combination of a centrally deployed authentication service module and a distributed deployed authentication module. Optionally, each SM proxy modules of the one or more SM proxy modules Is configured to authenticate and authorize the service request by using service identity and a location of the service request, wherein the location is identified through a user's identity.

[0031] Optionally, the prediction model comprises one of, a centrally deployed prediction module deployed in a central location within a cluster having the A&A service module implemented in the central location, and a distributed deployed prediction module.

[0032] Optionally, the selection model comprises one of, a centrally deployed selection model deployed in a central location within a cluster having the A&A service module implemented in the central location, and a distributed deployed selection model.

[0033] According to a second aspect of the present disclosure, a computer implemented method for providing authentication of service requests through a platform for a service mesh network implemented in a Micro-Service Architecture, is provided, wherein the service mesh network is implemented in one or more clusters. The method comprises receiving, through an application layer configured in the service mesh network and having one or more service instances, wherein the application layer is arranged to receive one or more incoming client service requests. The method further comprises receivingthrough a gateway, the one or more incoming client service requests, forwarding, through the gateway, the one or more incoming client service requests to one or more service mesh, SM, proxy modules, wherein the one or more SM proxy modules is arranged to access a plurality of authentication and authorization, A&A, service modules, wherein the A&A service modules are implemented in one or more clusters in the service mesh network. The method further comprises predicting, through a prediction model, a security risk score for each service request from the one or more incoming client service requests. The method further comprises categorizing, through a classification module, the plurality of A&A service modules into a plurality of categorized A&A service modules, wherein the plurality of A&A service modules are categorized according to the service risk score. The method further comprises selecting, through a selection model, at least one categorized A&A, service module from the plurality of categorized A&A service modules according to the risk score associated with each incoming client service request. The method further comprises authenticating, through the one or more SM proxy modules, each of the incoming client service requests from the one or more incoming client service requests by using the at least one categorized A&A service module selected by the selection model. The method furthermore comprises forwarding, through a load balancer, the one or more incoming client service requests to the one or more service instances based on the selected authentication through the at least one categorized A&A service module.

[0034] According to a third aspect of the present disclosure, there is provided a computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions. The computer program is loadable into a data processing unit and configured to cause execution of the method according to the first and second aspects when the computer program is run by the data processing unit.

[0035] Some embodiments disclosed herein have one or more of the following advantages:

[0036] - Improving the end user / client experience since the end-to-end service request latency will be significantly reduced in scenarios with trusted clients.

[0037] - Improving the platform system performance due to the simplification of A&A operations for targeting the clients based on the model prediction.

[0038] - Saving the energy consumption due to reduced latency and improved system performance.

[0039] Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

[0040] BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

[0042] Figs 1A, IB, 2A, and 2B show a non-public reference design.

[0043] Fig. 1A discloses an example non-public reference service mesh architecture, where authentication and authorization, A&A service module is implemented in a centralized system;

[0044] Fig. IB discloses another example non-public reference service mesh architecture, where the A&A service module is implemented in a distributed system; Fig. 2A discloses an example non-public reference illustration of service traffic flows within the distributed A&A service module;

[0045] Fig. 2B discloses an example non-public reference illustration of flow of service traffic steps within the conventional centralized A&A;

[0046] Fig. 3 discloses a wireless communication system according to some examples;

[0047] Fig. 4 is a schematic block diagram illustrating an example platform according to some embodiments;

[0048] Fig. 5 provides an overview of authentication and authorization, A&A service modules configured in a distributed computing system according to some embodiments;

[0049] Fig. 6 provides an overview of A&A service modules configured in a centralized computing system, according to some embodiments;

[0050] Fig. 7 provides an overview of A&A service modules configured in a combination of a distributed computing system and a centralized computing system, according to some embodiments;

[0051] Fig. 8 provides an overview of a flow of service request within a single cluster deployment, according to some embodiments;

[0052] Fig. 9 provides an overview of a flow of service request across any two clusters (A and B), according to some embodiments;

[0053] Fig. 10 provides an overview of a settings for training service request risk predictor model, SRRPM, and doing the inference according to some embodiments;

[0054] Fig. 11 is a flowchart illustrating steps for a method providing authentication of service requests in a service mesh network, according to some examples; and

[0055] Fig. 12 discloses an example computing environment according to some embodiments.

[0056] DETAILED DESCRIPTION

[0057] Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The apparatus and methods disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the aspects set forth herein. Like numbers in the drawings refer to like elements throughout.

[0058] The terminology used herein is for the purpose of describing particular aspects of the disclosure only and is not intended to limit the invention. It should be emphasized that the term "comprises / comprising" when used in this specification is taken to specify the presence of stated features, integers, steps, or components, but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0059] Embodiments of the present disclosure will be described and exemplified more fully hereinafter with reference to the accompanying drawings. The solutions disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the embodiments set forth herein.

[0060] It will be appreciated that when the present disclosure is described in terms of a platform and a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors.

[0061] As mentioned above, Figs. 1A, IB, 2A, and 2B show a non-public internal reference implementation by the applicant.

[0062] Fig. 1A discloses an example centralized micro-service deployment 1000-A within a single cluster X where all services in an application rely on a common A&A service module 108 deployed in a central location within the single clusterX The micro-service deployment within the single cluster X comprises an application layer 101 with multiple service instances 104, where the application layer 101 is configured to receive one or more service requests from one or more users / clients 103. The centralized micro-service deployment also comprises one or more service mesh, SM proxy modules 106 for receiving the one or more service requests received at the application layer 101. The deployment is configured in a gateway 102 of the service mesh network 100, where the gateway 102 is communicatively coupled to the one or more SM proxy modules 106 and the common A&A service module 108. As disclosed in Fig. 1A, the multiple service instances 104 in the application layer 101 rely on the common A&A service module 108 deployed in a central location within the cluster X for availing different services or applications, such as certificate management module, or identity access management module, etc.

[0063] Fig. IB discloses an example of distributed micro-service deployment 1000-B where the A&A service module 108 is provided within the service mesh, SM, proxy module 106 which is deployed next to a service instance 104a in a different cluster Y, wherein the SM proxy module 106 is implemented as a sidecar. Cluster X also comprises multiple service mesh, SM proxy modules 106 for receiving the one or more service requests received at the application layer 101. The whole distributed micro-service deployment is configured in both the gateway 102- X and the gateway 102-Y in the service mesh network 100. The gateway 102-X in cluster X is communicatively coupled to gateway 102-Y in cluster Y.

[0064] As disclosed in Fig. IB, the cluster X comprises the application layer 101 with multiple service instances 104, where the application layer 101 is configured to receive the one or more service requests from the one or more users / clients 103. The A&A service module 108 in the cluster Y is made available in a distributed fashion to the one or more service requests from the application layer 101 in the cluster X.

[0065] Fig. 2A discloses an example of service traffic flows within the distributed A&A deployment 2000-A. As illustrated in Fig. 2A, a client 203 sends a service request to an application that consists of two service instances i.e., a service instance A and a service instance B. Both the service instance A and the service instance Bare initiated and operated using the service mesh network 200 based on service demands using a same A&A service module from a plurality of A&A service modules 208 for both the service instances A and the service instance B in the cluster X. The distributed A&A deployment is configured through each of a gateway 202x and a gateway 202y in the service mesh network 200.

[0066] As disclosed in Fig. 2A, the service flow through multiple SM proxy modules 206 comprises receiving one or more service requests from multiple clients and communicating with the distributed A&A service modules 208 which is shown through flow steps 1 to 15. In step-1, the client 203 sends a service request to the service instance A 204a through the gateway 202x. Subsequently, in step-2, the gateway 202x selects one of the two service instance A 204a in the cluster X using an applicable load balance rule. Thereafter, in step-3, the gateway 202x forwards the service request to the SM proxy 206 for the selected service instance A 204a. Further, in step-4, the SM proxy 206 performs the A&A service on the service request using service request identity and the location where the service request originates based on using the distributed A&A service module 208.

[0067] Further, in step-5, the SM proxy 206 forwards the service request to the selected service instance A 204a after authentication and authorization, A&A service is successfully performed through the distributed A&A service module 208. Further, in step-6, the service instance A 204a performs service A business logics and requires service provided by the service instance B 204b. Further, in step-7, the service instance A 204a sends request for service offered by service instance B 204b to the SM proxy 206 of the service instance B 204b. Further, in Step- 8, the SM proxy 206 performs a service lookup to locate the service offered by service instance B 204b. Further, in step-9, the SM proxy 206 for service instance A 204a forwards the service request to the SM proxy 206 of service instance B 204b. Further, in step-10, the SM proxy 206 for service instance B 204b performs A&A service on a requestor i.e., the service instance A 204a and an original service client 203 using the distributed A&A service module 208.

[0068] Further, in step-11, the SM proxy 206 for the service instance B 204b forwards the service request after A&A is successful applied. Further, in Step-12, the service instance B 204b performs service offered by it. Further, in step-13, the service instance B 204b sends the results back to the service instance A 204a through two SM proxies 206. Furthermore, in step- 14, the service instance A 204a utilizes service results obtained from the service instance B 204b and generates a service response for the client 203. Finally, in step-15, the service instance A 204a sends a final service response back to the client 203.

[0069] Fig. 2B discloses an example centralized A&A deployment 2000-B in a service mesh 200. As disclosed in Fig. 2B, the client 203 sends the request to the application that consists of the two service instances i.e., the service instance A and the service instance B. Both the service instance A and the service instance B are initiated and operated using the service mesh network 200 based on the service demands using a common external A&A service module 208 for both the service instance A and the service instance B in the cluster X. The centralized deployment is configured through the gateway 202 in the service mesh network 200. Further, in Fig. 2B, the SM proxy 206 delegates the authentication and authorization, A&A to the external A&A service module 208 as shown in the service flow steps of 1 to 15. In step-1 the client 203 sends a service request to service instance A 204a through the gateway 202. Subsequently, in step-2, the gateway 202 selects one of the two service instance A 204a in the cluster X using an applicable load balance rule. Thereafter, in step-3, the gateway 202 forwards the service request to the SM proxy 206 for the selected service instance A 204a.

[0070] Further, in step-4, the SM proxy 206 performs the A&A service on the service request using service request identity and the location where the service request originates by using the common external A&A service module 208. Further, in step-5, the SM proxy 206 forwards the service request to the selected service instance A 204a after the A&A service is successfully performed by the common external A&A service module 208. Further, in step-6, the service instance A 204a performs service A business logics and now require service provided by service instance B 204b. Further, in step-7, the service instance A 204a sends request for service offered by service instance B 204b to SM proxy 206 of the service instance 204b.

[0071] Further, in step-8, the SM proxy 206 performs a service lookup to locate the service offered by service instance B 204b. Further, in step-9, the SM proxy 206 for service instance A 204a forwards the service request to the SM proxy 206 of service instance B 204b. Further, in step- 10, the SM proxy 206 for service instance B 204b performs the A&A service on a requestor i.e., the service instance A 204a and the original service client 203 based on the common external A&A service module 208. Further, in step-11, the SM proxy 206 for service instance B 204b forwards the service request after A&A is successfully performed. Further, in step-12, the service instance B 204b performs service offered by it. Further, in step-13, the service instance B 204b sends results back to the service instance A 204a through two SM proxies 206. Furthermore, in step-14, the service instance A 204a utilizes the results from service instance B 204b and generates a service response to be shared with the client 203. Finally, in step-15, the service instance A 204a sends a final response back to the client 203.

[0072] It is to be noted that the steps 4 and 10 in the service flow steps as discussed in Figs 2A and 2B above are the common essential steps for ZTA consideration in both the distributed A&A deployment and the centralized A&A deployment. In accordance with the non-public reference architecture illustrated in Figs 2A and 2B, the A&A may be implemented in either a centralized computing system or a distributed computing system. In an existing service mesh architecture, it is necessary to apply an authentication and authorization, A&A to each service request towards targeted services irrespective of the deployment mode to comply with ZT and ZTA. In addition, due to decoupling between service function feature and non-service function feature, the A&A is performed through SM proxy server. However, this kind of implementation of the A&A has a significant performance impact because extra computational cost is required to apply A&A on each service request to comply with ZT and ZTA. In addition, one may expect service degradation in the latency in view of service requestors, and performance degradation due to the traffic load distribution in a cloud platform.

[0073] Fig. 3 discloses an example wireless communication system 300. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in related to a wireless communication system / wireless network, such as the example wireless communication system 300 described in Fig. 3.

[0074] The wireless communication system 300 may comprise and / or interface with any type of communication, telecommunication, data, cellular, and / or radio network or other similar type of system. In some embodiments, the wireless communication system 300 may be configured to operate according to specific standards or other types of predefined rules of procedures. Thus, particular embodiments of the wireless communication system 300 may implement communication standards, such as, but are not limited to, global system for mobile communications, GSM, universal mobile telecommunications system, UMTS, long term evolution, LTE, and / or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network, WLAN, standards such as, IEEE 802.11 standards, and / or any other appropriate wireless communication standards, such as, worldwide interoperability for microwave access, WiMax, Bluetooth, Z-Wave and / or ZigBee standards.

[0075] For simplicity, as depicted in Fig. 3, the wireless communication system 300 comprises a platform, 4000, a network node 304, and a network 306. The platform 4000 and the network node 304 operate together in order to provide wireless connections in the wireless communication system 300. The network 306 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks, PSTNs, packet data networks, optical networks, wide-area networks, WANs, local area networks, LANs, wireless local area networks, WLANs, wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices (for example, wireless devices and network node).

[0076] The network node 304 may refer to equipment capable, configured, arranged, and / or operable to communicate directly or indirectly with the platform 4000 and / or with other network nodes or equipment in the wireless communication system 300 to enable and / or provide wireless access to the platform 4000 and / or to perform other functions (for example, administration) in the wireless communication system 300. Examples of the network node 304 may include, but are not limited to, access points, APs (for example, radio access points), base stations, BSs (for example, radio base stations, nodeBs, evolved NodeBs, eNBs, new radio, NR, nodes (gNBs), or the like). The BSs may be categorized based on an amount of coverage the BSs provide (or, stated different, their transmit power level) and may then also be referred to as femto BSs, pico BSs, micro BSs, macro BSs. The BS may be a relay node or a relay donor node controlling a relay.

[0077] The platform 4000 may refer to a device capable, configured, arranged and / or operable to communicate wirelessly with the network node 304 and / or other wireless devices.

[0078] In some examples, the platform 4000 may include one or more of: computing devices, wireless devices that operate based on energy harvesting (hereinafter referred to as Zero- Energy, ZE, wireless devices), ultra-low power wireless devices, Internet of Things, loT, devices, and so on.

[0079] Examples of the computing devices may include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over Internet Protocol, IP, VoIP, phone, a wireless local loop phone, a desktop computer, a personal digital assistant, PDA, a wireless camera, a gaming console or device, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment, LEE, a laptop-mounted equipment, LME, a smart device, a wireless customer-premise equipment, CPE, a vehicle- mounted wireless terminal device, and so on. The ZE wireless devices may harvest energy to operate based on ambient sources such as vibrations, solar power, Radio Frequency, RF, or the like. Alternatively, the ZE wireless devices may harvest energy to operate based on back-scattering communication.

[0080] It should be understood that the platform 4000 may need not be limited to the abovedescribed wireless devices and may be extended to other wireless devices of different classes or categories providing different services while supporting, for example, Enhanced Mobile Broadband, eMBB, massive Machine-Type Communication, MTC, Ultra-Reliable Low Latency Communication, URLLC, Time Sensitive Networking, TSN, or the like.

[0081] In the wireless communication system 300, the network node 304 and the platform 4000 are connected through 3GPP 5G core network where specific network services and operations are provided through software components called network functions (NFs). In 5GC network, these NFs are designed as microservice using service mesh architecture with containerized technology such as the Kubernetes. The microservices are deployed using a service mesh architecture either in a centralized or in a distributed deployment fashion. In the service mesh architecture, it is necessary to apply A&A through a SM proxy to each service request irrespective of the deployment mode, which will have a significant performance impact because of the extra computational cost required to apply the A&A on each service request. This problem would further be amplified if the service mesh architecture needs to comply with ZT and ZTA.

[0082] Thus, embodiments herein enable the wireless communication network 300, the network node 304 and the platform 4000 to implement the service mesh architecture with minimum impact on overall performance to apply A&A on service requests while the architecture complies with ZT and ZTA.

[0083] Fig. 4 discloses a schematic block diagram of a platform 4000 for a service mesh network 400. The service mesh network 400 being implemented in one or more clusters 2000 to form a Micro-Service Architecture. The platform 4000 comprises an application layer 401 configured in the service mesh network 400 and having one or more service instances 404. The application layer 401 is arranged to receive one or more incoming client service requests also referred as service requests. The one or more service requests are received from one or more users. The platform 4000 further comprises a plurality of authentication and authorization, A&A, service modules 408 each arranged to authenticate the one or more service requests. Each A&A service module 408 is implemented in one or more of the one or more clusters 2000 in the service mesh network 400.

[0084] The platform 4000 further comprises a gateway 402 configured to receive the one or more incoming client service requests. The gateway 402 then forwards the one or more incoming client service requests to one or more service mesh, SM, proxy modules 408, each arranged to receive one or more of the one or more incoming client service requests received through the application layer gateway 402. Each SM proxy module 408 is arranged to provide access to the plurality of authentication and authorization, A&A, service modules 408.

[0085] The platform 4000 further comprises a processor 410 configured in the gateway 402 of the service mesh network 400. The processor 410 is communicatively coupled to the one or more SM proxy module 406 and is arranged to receive the one or more incoming client service requests from the one or more clients. The processor 410 executes a set of instructions stored in a memory 412 communicatively coupled to the processor 410 and is configured in the service mesh network 400.

[0086] The processor 410 is configured for predicting a security risk score for each service request from the one or more incoming client service requests. The security risk score is predicted through a prediction model 414.

[0087] Optionally, the security risk score is selected from a group comprising at least one of one or more low security risk score, one or more medium security risk score and one or more high security risk score.

[0088] The processor 410 is further configured for categorizing the plurality of A&A service modules 408 into a plurality of categorized A&A service modules. The plurality of A&A service modules 408 are categorized, through a classification module 416 according to the service risk score.

[0089] Optionally, the processor 410 is further configured for identifying, through an identification module, each of the incoming client service requests as one of a trusted service request when the security risk score is the one or more low security risk score, an untrusted service request when the security risk score is the one or more high security risk score, or an unknown service request when the security risk score is the one or more medium security risk score. Advantageously, the identification of trusted service requests reduces the service request latency thereby improving the client / user experience.

[0090] The processor 410 is further configured for selecting at least one categorized A&A, service module 408 from the plurality of categorized A&A service modules 408 according to the risk score associated with each incoming client service request. The at least one A&A service module 408 is selected through a selection model 418.

[0091] The one or more SM proxy modules 406 are configured for authenticating and authorizing, each service request from the one or more service requests by selectively accessing the at least one categorized A&A service module 408 selected by the selection model 418. The SM proxy module 406 may then forward the one or more service requests to the one or more service instances 404 after the selected authentication through the at least one categorized A&A service module 408. The one or more service requests are forwarded through a load balancer 420.

[0092] Optionally, the processor 410 is further configured for forwarding, after the authentication, the one or more service requests to one or more target service instances from the one or more service instances 404. The one or more target service instances are configured to generate a service response towards the one or more service requests. In some examples, the service request is sent to a service instance co-located with one of the selected categorized A&A service module 408.

[0093] Optionally, the prediction model 414 is configured for developing a Machine Learning, ML, model for predicting the security risk score, wherein the machine leaning model is developed by using one or more parameters. The one or more parameters comprise time stamp associated with one or more of: payload data; Source, Src IP; Destination, dest IP; client IP, App / service ID; HTTP headers; and at least one input risk level comprising: one or more low levels, one or more medium levels, or one or more high levels. The ML model may be selected from a group of supervised ML model, a semi-supervised ML model, and an unsupervised ML model.

[0094] Optionally, the plurality of A&A service modules 408 are selected from a group comprising of

[0095] Identity Access Management, 1AM, module, and Certificate Management Module, CMS. Optionally, the plurality of categorized A&A service modules are categorized into one or more categories, wherein the one or more categories is selected from a group comprising simple A&A service module when the security risk score comprises the one or more low security risk score, a basic A&A service module when the security risk score comprises the one or more medium security risk score and an advance A&A service module when the security risk score comprises the one or more high security risk score.

[0096] Optionally, each A&A service module 408 from the plurality of A&A service modules 408 comprises one of: a centrally deployed authentication and authorization, A&A service module, and a distributed deployed authentication and authorization, A&A service module, wherein the centrally deployed A&A service module is deployed in a central location within a cluster 2000, and wherein the distributed deployed A&A service module is provided within the SM proxy module 406.

[0097] Optionally, each A&A service module 408 may be deployed as a combination of the centrally deployed A&A service module and the distributed deployed A&A service module.

[0098] Optionally, each SM proxy module 406 from the one or more SM proxy modules 406 is configured to authenticate and authorize the one or more service requests by using service identity and a location of the service request, wherein the location is identified through a user's identity.

[0099] Optionally, the processor 410 is further configured for: identifying, if the one or more target service instances 404 to be selected are running in a same cluster from the one or more clusters 2000. Optionally, the processor 410 is further configured for selecting at least one similar categorized A&A service module from the plurality of categorized A&A service modules 408 and authenticating, through the SM proxy module 406, the one or more service requests by using the at least one similar categorized A&A service module. Optionally, the processor 410 is configured for generating a service response for the one or more service requests based on the authentication. The service response is generated through the one or more target service instances.

[0100] Optionally, the processor 410 is further configured for: identifying, if the one or more target service instances 404 are running in a different cluster from the one or more clusters 2000 and evaluating, through a gateway of the different cluster, the category of the categorized

[0101] A&A service module from the plurality of categorized A&A service modules 408.

[0102] Optionally, the processor 410 is configure selecting, through the selection module 418, the categorized A&A service module from the plurality of categorized A&A service modules 408 based on the evaluation and authenticating, through the SM proxy module 406, the one or more service requests by using the at least one categorized A&A service module based on the evaluation.

[0103] The processor is configured for generating a service response for the one or more service requests based on the authentication. The service response is generated through the one or more target service instances 404.

[0104] Advantageously, the proposed platform 4000 simplifies the A&A operations by targeting clients by predicting security risk score without applying A&A individually on each service request, thereby improving an overall performance of the platform 4000 and reducing the service request latency over the platform 4000, due to which energy consumption of the platform 4000 is also reduced.

[0105] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the disclosure.

[0106] Fig. 5 is an overview 500 of authentication and authorization, A&A service modules configured within the SM proxy module and configured in a distributed computing system through a distributed framework like an edge cloud based framework. A gateway, GW 502 receives one or more service requests from client A 503 and forwards the one or more service requests to an application layer. The GW 502, comprises a load balancer 520, an A&A model selectors, AMS, 510, and a service request risk predictor, SRRPM module 509. The application layer comprises a plurality of service instances 504 connected to a plurality of service mesh proxies 506 each having an in-built A&A service module.

[0107] Each service mesh, SM, proxy module 506 processes the one or more service requests. At least one SM proxy module 506 from the plurality of SM proxy modules 506 may be implemented as a sidecar. In Fig. 5, each service instance 504a of the plurality service instances 504a is tied to one of three different service mesh (SM)-proxies, SM-P, 506, having different A&A service modules.

[0108] A number of service instances as shown, are managed by a microservice platform with a capability of service mesh network 400a When a number of clients / users increases, the number of service instances 504a may be scaled up by the platform 4000 to meet an increasing service traffic demand of generating response for the service requests. When the service traffic reduces, the number of service instances 504 may be scaled down accordingly by the platform 4000.

[0109] In Fig. 5, the SRRPM 509 predicts a security risk score for each service request and the plurality of A&A service modules are categorized as one of a simple A&A service module, a basic A&A service module and an advanced A&A service module (not shown in Fig. 5). For example, the SM-Ps506scomprises the SM proxy modules having the simple A&A service module for the low security risk score. Further, the SM-PB506bcomprises the SM proxy modules having the basic A&A service module for the medium security risk score and similarly, the SM-PA 506acomprises the SM proxy modules having the advance A&A service module for the high security risk score.

[0110] The SRRPM 509 is then configured to select the categorised A&A service module which is then executed by a respective SM proxy module from the plurality of SM proxy modules 506 having the in-built categorized A&A service module according to the security risk score of the one or more service requests.

[0111] The SM proxy modules 506 are configured for authenticating and authorizing each service request from the one or more service requests by using the at least one categorized A&A service module selected by the A&A model selectors, AMS, 511. Once the service request is authenticated, the service request is forwarded to at least one service instance from the one or more service instances 504 through the load balancer 520.

[0112] Fig. 6 provides an overview 600 of at least one A&A service modules 608 configured in a centralized computing system according to some embodiments. Here, A&A model selectors, AMS, 611, and a service request risk predictor, SSRPM, module 608 are moved to a centralized place in the centralised computing system where the A&A service modules 608 are configured in the service mesh network 400b. Different A&A service modules 608 may be plugged into this centralized computing system thereby improving the performance for centralized A&A service modules 608. The implementation as shown in Fig. 6 is provided through a centralized framework like legacy mainframe.

[0113] In the centralised implementation of the plurality of A&A service modules (AA-model-l,...,AA- model-k), the SRRPM 609 first predicts the security risk score for the one or more service request and then accordingly each A&A service module 608 is categorized into the one or more categories. The at least one categorised A&A service module is first selected by the AMS 611 according to the security risk score and then the SM proxy module selectively accesses the categorised A&A service module selected by the AMS 611 for authorizing the one or more service requests. The centralised deployment of the A&A service module 608 is different from the distributed implementation of the A&A service modules, where the A&A service modules are in-built into the SM proxy modules.

[0114] Fig. 7 provides an overview 700 of a service mesh network 400c illustrating a plurality of A&A service modules 722 implemented in a combination of a distributed computing system and a centralized computing system according to some embodiments. The mixture / combination of the centralized computing system and the distributed computing system provides a flexibility of executing the plurality of A&A service modules 722 for different scenarios (discussed in subsequent paragraphs below) in the deployment and operation phases of the microservice architecture.

[0115] Three example scenarios are discussed to exemplify some common use cases in industry:

[0116] Scenario 1 - Migration of the service mesh network 400c from a legacy-centralized system to a distributed system: The distributed implementation of the plurality of A&A service modules 722 provides more flexibility, availability, and sustainability in terms of application usage, the industry, for example, telecom where the A&A service modules form the core part of the ZTA, the industry may move from the centralized legacy solution to the distributed solution.

[0117] Since the migration from the centralised A&A service module to the distributed service modules may be time consuming, the plurality of A&A service modules 722 may therefore be implemented in the combination where the legacy-centralized solution co-exists with the new distributed solution.

[0118] To facilitate this transition of the implementation, the centralized A&A service modules as disclosed in overview 600 of Fig. 6 may be implemented first, as such implementation may have a minimum impact on the legacy centralized A&A service modules. Such implementation may also improve the performance of the service mesh network 400c. Then, A&A model selectors, AMS and service request risk predictor, SSRPM module may be introduced into the Gateway 702. Such introduction gives the flexibility to only configure the AMS module and the SSRPM module to handle the service requests for any new services instances launched by the service mesh platform 400c. Hence, on a same platform, partial service requests may rely on the centralized A&A service modules, while the service requests may rely on newly implemented distributed A&A service modules 722. Eventually all the service requests and the services offered through the platform may adopt the distributed A&A service modules 722 implementation.

[0119] Scenario 2 - External Identity and Access Management (1AM) for untrusted service requests received from untrusted clients:

[0120] In case that an A&A service module from the plurality of A&A service modules 708 requires an external 1AM service, the centralized A&A service modules 708 may be considered in view of service mesh platform 400 (as discussed in Fig. 1) where the at least one A&A service modules 708 in the 1AM may be configured as the "Advanced A&A service modules". The advance A&A service modules may process the service requests only from "untrusted clients" through the centralized A&A service modules, and the other service requests may be handled by local A&A service modules 722 deployed as the distributed A&A service modules 722. In an example, current open-source service mesh platforms may support both, internal authorization and external authorization of the one or more service requests. Internal authorization of the one or more service request may use authorization policies configured in control plane component of the open-source service mesh platform, and then pushes the authorization to a different open-source service mesh sidecar proxy. External authorization uses an external authorization server, where the authorization engine in the open-source service mesh platform's sidecar proxy may communicate with the external authorization server to perform authorization through different A&A service modules.

[0121] Scenario 3 - An application specific A&A service module in comparison with a framework specific A&A service module:

[0122] In a normal scenario, each application may leverage a common A&A service module 722 deployed in the SM proxy module 706 where the A&A service module 722 is the framework specific A&A service module and there is no application specific A&A service module configured in the service mesh network 400-C. Since under ZTA, it is mandatory for an application owner to have a control on the access to its application to take responsibility over the service, the application specific A&A service module may be managed or configured by the application owner. For such application specific A&A service module, a corresponding A&A service module may be provided by a third party who doesn't own the microservice framework, in which the service / application is deployed and executed. This external A&A service is therefore a kind of an application specific A&A.

[0123] For example, if one concrete application consists of 10 services in the mixture of both centralized A&A service modules and the distributed A&A service modules, then among the 10 services, 7 services need the framework specific A&A since they are involved in service interaction without the engagement from end user. The remaining three services involve the end user, thereby necessitating to invoke the external 1AM to execute the application specific A&A service modules. Therefore proposed configuration of the A&A service modules on the mixture of centralized computing system and the computing system A&A solution may be easily achieved using open-source service mesh platforms.

[0124] The example implementation described in Fig. 7 may accordingly be configured for the example scenarios discussed above. In some examples, it is now demonstrated how parameters i.e., data is collected to build the machine learning model for both simple and complex service flows. In simple service flow, there is only a single client that sends the service request and gets the response as disclosed in Fig. 5, meaning that only a single service instance is involved which follows a simple clientserver request response pattern. Here, the incoming request is evaluated by SRRPM module 508. Based on the outcome of the prediction on security risk, AMS selects the right A&A applied for this service request, and forwards to the load balancing module 520 within the Gateway 502. Eventually the service request is sent to the service instance co-located with one of the selected A&A. Complex services are the ones that have multiple service flows involving multiple service instances deployed. Figs. 8 describes the complex service flows within a single cluster, whereas Fig. 9 describes the complex service flow across two clusters.

[0125] Fig. 8 discloses an overview 800 of flow of a service request within a single cluster deployment 8000 of the service mesh network 400-D according to some embodiments. A service requested by client refers here to a simple service as service instances are selected within a same single cluster. Client A 803 may send the service request to a service mesh network 400d. The requested service may consist of at least two service instances deployed within the same cluster. Gateway, GW, 802 is deployed at the front to control incoming and outgoing traffic of the service requests.

[0126] In step 1, Client A 803 sends the service request to GW 802. Subsequently, in step 2, SRRPM 808 performs security risk prediction and predicts a security risk score for the service request received from client A 803. Thereafter, in step 3, as the security risk score for the incoming service request is low, AMS 810 selects simple A&A service module. Further, in step 4, a Load Balancer, LB, 820 forwards the service request to one of the at least two service instance A, SIA804awith simple A&A service module. Here, the service mesh proxy module, SM-Ps806sexecutes the simple A&A service module for authenticating the service request, and then relays the service request to the service instance Sl 804a. Further, in step 5, the SI 804alooks up for service instance B, SIB804band sends the service request to the simple A&A service module 822. This is because the same security risk level is maintained even after the GW 802 in the cluster predicts the security risk score. Further, in step 6, SM-Ps806sco-located with SIA804asends the request to SM-Ps806sco-located with SIB804b. Further, in step 7, after the simple A&A service request is applied / executed successfully, the SM-Ps806sco-located with SIB804brelays the request to SIB804b. Then SIB804bbuilds the response for the service request. Further, in step 8, SIB804b sends the response back to the SIA804a. Furthermore, in step 9, the SIA804areceives the response from the SIB804b and continues the service logics to build a final service response for the service request. Finally, in step 10, the SIA804asends the response back to the client A 803.

[0127] Fig. 9 discloses an overview 900 of flow of a service request flow across at least two clusters (A and B) of a service mesh network 400e according to some examples. The service requested by client refers here to a complex service as the service instances are selected from different clusters (A and B). Client A 903 sends the service request to the service mesh network 400e. The requested service consists of at least two service instances deployed across two different clusters A and B. Gateway, GW, 902 is deployed at the front of each cluster A and B to control incoming and outgoing traffic of the one or more service requests. In step 1, client A 903 sends the service request to GW 902 in cluster A. Subsequently, in step 2, SRRPM 908A in cluster A performs the security risk prediction for the service request and generated the security risk score. Thereafter, in step 3, as the security risk score for the incoming service request is low, AMS 910A in cluster A selects simple A&A service module. Further, in step 4, a Load Balancer, LB, 920A in cluster A forwards the service request to one of two service instance A, SIA904awith simple A&A. Here, service mesh proxy module, SM-Ps906sexecuted the simple A&A service module 922 and then relays the service request to the SIA904a. Further, in step 5, SIA904alooks up for service instance B, SIB904b, which is deployed in cluster B.

[0128] Further, in step 6, SM-Ps906sco-located with SIA904asends the service request to the cluster B. Further, in step 7, SRRPM 908B in cluster B does the security risk prediction for the incoming service request and generated the security risk score. Further, in step 8, since the security risk score for the incoming service request is Medium at this point, the AMS 910B in cluster B selects basic A&A service module 922. Further, in step 9, LB 920B in GW forwards the service request to SIB904b with basic A&A service module. Here SM-PB906 executes the basic A&A service module and then relays the request to SIB904b. Further, in step 10, after the basic A&A service module is applied / executed successfully, SM-PB906b co-located with SIB904 relays the request to SIB904 . Then SIB904 builds the service response. Further, in step 11, SIB904b in cluster B sends the response back to SIA904ain cluster A. Furthermore, in step 12, the SIA904ain cluster A receives the response from SIB904b, continue the service logics, and build a final service response for the service request. Finally, in step 13, SIA904ain cluster A sends the response back to client A 903.

[0129] In some examples as discussed above, the prediction model is configured for developing the ML model using information (one or more parameters related to the one or more service requests) from different protocol layers. The one or more parameters comprises a time seriesbased dataset, which contains five features list with security risk label / score.

[0130] In some examples, the definition of security risk score may be indicated in three categories viz., Low security risk score, Medium security risk score and High security risk score.

[0131] In some examples with reference to Figs. 5 and 6, a recurrent neural network, RNN, or a long short term memory, LSTM, or a transformer may be selected as a baseline ML model to configure the prediction model.

[0132] Table: Example of dataset used to train the prediction model (SRRPM)

[0133] Fig. 10 discloses an overview of settings for training the SRRPM and making inference according to some examples. Multiple headers from the date format described in example dataset is provided to SRRPM to predict the security risk score for an incoming service requests and detect any anomalies in the dataset. The predicted anomalies may then be categorized into the security risk score comprising one or more low security risk score, one or more medium security risk score and one or more high security risk score. Thereafter, the categorized security risk scores may be used to classify the one or more service requests as one of a trusted service request when the security risk score is the one or more low security risk score, an untrusted service request when the security risk score is the one or more high security risk score, or an unknown service request when the security risk score is the one or more medium security risk score.

[0134] Fig. 11 is a flowchart illustrating example method steps of a method 1100 performed for providing authentication of service requests through a platform for a service mesh network 400 implemented in a Micro-Service Architecture 3000.

[0135] The order in which the method 1100 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 1100 or alternate methods. Additionally, individual blocks may be deleted from the method 1100 without departing from the spirit and scope of the embodiments described herein.

[0136] At step 1102, the method 1100 comprises receiving, through an application layer 401 configured in the service mesh network 400, one or more incoming client service requests, wherein the application layer 401 is having one or more service instances 404;

[0137] At step 1104, the method 1100 comprises authenticating, through each authentication and authorization, A&A, service modules 408 of a plurality of A&A service modules. Each A&A service module 408 is implemented in one or more of the one or more clusters 2000 in the service mesh network 400.

[0138] At step 1106, the method 1100 comprises receiving, through a gateway 402 the one or more incoming client service requests and forwarding the one or more incoming client service requests to one or more service mesh, SM, proxy modules 406. Each SM proxy module is arranged to provide access to the plurality of authentication and authorization, A&A, service modules 408.

[0139] At step 1108, the method 1100 comprises receiving, through a processor 410 configured in the gateway 402 of the service mesh network 400, the one or more service requests from the one or more SM proxy modules 406. The processor 410 is communicatively coupled to the one or more SM proxy module 406. The processor 410 executes a set of instructions stored in a memory 412.

[0140] At step 1110, the method 1100 comprises predicting, through a prediction model 414, a security risk score for each service request from the one or more service requests.

[0141] In some examples, the security risk score is selected from a group comprising at least one of: one or more low security risk score, one or more medium security risk score and one or more high security risk score.

[0142] In some examples, a Machine Learning (ML) model is developed for predicting the security risk component. The machine leaning model is developed by using one or more parameters comprising time stamp associated with payload data, Source, Src IP, Destination, dest IP, client IP, App / service ID, HTTP headers, one or more input risk levels comprising a one or more low levels, one or more medium levels, or one or more high levels.

[0143] In some examples, the ML model is selected from a group of supervised ML model, a semisupervised ML model, an unsupervised ML model.

[0144] At step 1112, the method 1100 comprises categorizing, through a classification module 416 executed by the processor 410, the plurality of A&A service modules 408 into a plurality of categorized A&A service modules. The plurality of A&A service modules are categorized according to the service risk score.

[0145] At step 1114, the method 1100 comprises selecting, through a selection model 418 executed by the processor 410, at least one categorized A&A, service module from the plurality of categorized A&A service modules according to the risk score associated with each service request.

[0146] In some examples, the A&A service module 408 is selected from a group comprising of Identity Access Management, 1AM, module, and Certificate Management Module, CMS.

[0147] In some examples, the one or more categories is selected form a group comprising simple A&A service module when the security risk score comprises the one or more low security risk score, a basic A&A service module when the security risk score comprises the one or more medium security risk score and an advance A&A service module when the security risk score comprises the one or more high security risk score.

[0148] At step 1116;the method 1100 comprises authenticating, through the one or more SM proxy modules 406, each of the service requests from the one or more service requests by selectively accessing the at least one categorized A&A service module selected by the selection model 418.

[0149] In some examples, the service request is authenticated and authorized, through the SM proxy modules 406, by using service identity and a location of the service request, wherein the location is identified through a user's identity.

[0150] At step 1118, the method 1100 comprises forwarding, through a load balancer 420, the one or more service requests to the one or more service instances based on the authentication.

[0151] All other details of method 1100 are similar to platform 4000 and hence are not repeated for the sake of brevity.

[0152] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors, DSPs, special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, RAM, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0153] Fig. 12 illustrates an example-computing environment 1200 implementing a platform and a method as shown in Figs. 4, and 11 for authenticating service requests in a service mesh implemented in a micro-service architecture. As depicted in Fig. 12, the computing environment 1200 comprises at least one data processing module 1206 that is equipped with a control module 1202 and an Arithmetic Logic Unit (ALU) 1204, a plurality of networking devices 1208 and a plurality Input output, I / O devices 1210, a memory 1212, a storage 1214. The data processing module 1206 may be responsible for implementing the platform and method described in Figs. 4 and 11 respectively. For example, the data processing module 1206 in some embodiments be equivalent to the controlling circuitry of the platform described above in conjunction with Figs. 4 and 11. The data processing module 1206 is capable of executing software instructions stored in memory 1212. The data processing module 1206 receives commands from the control module 1202 in order to perform its processing. Further, any logical and arithmetic operations involved in the execution of the instructions are computed with the help of the ALU 1204.

[0154] The computer program is loadable into the data processing module 1206, which may, for example, be comprised in an electronic apparatus (such as the platform). When loaded into the data processing module 1206, the computer program may be stored in the memory 1212 associated with or comprised in the data processing module 1206. According to some embodiments, the computer program may, when loaded into and run by the data processing module 1206, cause execution of method steps according to, for example, any of the methods illustrated in Figs. 4 and 11, or otherwise described herein.

[0155] The overall computing environment 1200 may be composed of multiple homogeneous and / or heterogeneous cores, multiple CPUs of different kinds, special media and other accelerators. Further, the plurality of data processing modules 1206 may be located on a single chip or over multiple chips.

[0156] The algorithm comprising of instructions and codes required for the implementation are stored in either the memory 1212 or the storage 1214 or both. At the time of execution, the instructions may be fetched from the corresponding memory 1212 and / or storage 1214, and executed by the data processing module 1206.

[0157] In case of any hardware implementations various networking devices 1208 or external I / O devices 1210 may be connected to the computing environment to support the implementation through the networking devices 1208 and the I / O devices 1210. The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in Fig. 12 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

Claims

CLAIMS1. A platform (4000) for a service mesh network (400), said service mesh network being implemented in one or more clusters (2000) and forming a Micro-Service Architecture (3000), the platform (4000) comprising: an application layer (401) configured in the service mesh network (400) and having one or more service instances (404), wherein the application layer (401) is arranged to receive one or more incoming client service requests; a plurality of authentication and authorization, A&A, service modules (408) each arranged to authenticate service requests, wherein each A&A service module (408) is implemented in one or more of the one or more clusters (2000) in the service mesh network (400); one or more service mesh, SM, proxy modules (406) each arranged to receive one or more of the one or more incoming client service requests received th rough the application layer (401) and each arranged to provide access to the plurality of authentication and authorization, A&A, service modules (408); and a processor (410) configured in a gateway (402) of the service mesh network, wherein the processor (410) is communicatively coupled to the one or more SM proxy module (406), and the gateway (402) is arranged to receive the one or more incoming client service requests from the one or more clients and forward each incoming client service request to the one or more SM proxy modules (406), wherein the processor executes a set of instructions stored in a memory (412), wherein the memory (412) is communicatively coupled to the processor (410) and is configured in the service mesh network (400), wherein the processor (410) is configured for: predicting, through a prediction model (414), a security risk score for each incoming client service request from the one or more incoming client service requests; categorizing, through a classification module (416), the plurality of A&A service modules (408) into a plurality of categorized A&A service modules, wherein the plurality of A&A service modules are categorized according to the service risk score; andselecting, through a selection model (418), at least one categorized A&A, service module from the plurality of categorized A&A service modules according to the risk score associated with each service request; wherein the one or more SM proxy modules (406) are configured for: authenticating, each incoming client service request from the one or more incoming client service requests by selectively accessing the at least one categorized A&A service module selected by the selection model (418); and forwarding, through a load balancer (420), the one or more incoming client service requests to the one or more service instances based on the selected authentication through the at least one categorized A&A service module.

2. The platform according to claim 1, wherein the security risk score is selected from a group comprising at least one of: one or more low security risk score, one or more medium security risk score and one or more high security risk score.

3. The platform according to any of the preceding claims, wherein the processor is further configured for: identifying, through an identification module, each of the incoming client service requests as one of a trusted service request when the security risk score is the one or more low security risk score, an untrusted service request when the security risk score is the one or more high security risk score, and an unknown service request when the security risk score is the one or more medium security risk score.

4. The platform according to any of the preceding claims, wherein the processor is further configured for: forwarding, after the authentication, the incoming client service request to one or more target service instances from the one or more service instances, wherein the one or more target service instances are configured to generate a service response for the one or more incoming client service requests.

5. The platform according to claims 1 and 4, wherein the processor is further configured for: identifying, if the one or more target service instances to be selected are running in a same cluster from the one or more clusters; and selecting, at least one similar categorized A&A service module from the plurality of categorized A&A service modules; authenticating, through the SM proxy module, the one or more incoming client service requests by using the at least one similar categorized A&A service module; and generating, through the one or more target service instances, the service response towards the one or more incoming client service requests based on the selected authentication through the at least one categorized A&A service module.

6. The platform according to claims 1 and 4, wherein the processor is further configured for: identifying, if the one or more target service instances are running in a different cluster from the one or more clusters; evaluating, through a gateway of the different cluster, the category of the categorized A&A service module from the plurality of categorized A&A service modules; selecting, through the selection module, the categorized A&A service module from the plurality of categorized A&A service modules based on the evaluation; authenticating, through the SM proxy module, the one or more incoming client service requests by using the at least one categorized A&A service module based on the evaluation; and generating, through the one or more target service instances, the service response towards the one or more incoming service requests based on the selected authentication through the at least one categorized A&A service module.

7. The platform according to any of the preceding claims, wherein the prediction model is configured for:developing a Machine Learning (ML) model for predicting the security risk score, wherein the machine leaning model is developed by using one or more parameters functionally related to the one or more incoming client service requests.

8. The platform according to claim 7, wherein the one or more parameters comprise a time stamp associated with one or more of:• payload data,• Source, Src IP,• Destination, dest IP,• client IP,• App / service ID,• HTTP headers, and• at least one input risk levels comprising one or more low levels, one or more medium levels, or one or more high levels.

9. The platform according to any of the claims 7 or 8, wherein the ML model is selected from a group of supervised ML model, a semi-supervised ML model, an unsupervised ML model.

10. The platform according to any of the preceding claims, wherein the A&A service module is selected from a group comprising of Identity Access Management, 1AM, module, and Certificate Management Module, CMS.

11. The platform according to any of the preceding claims, wherein the plurality of categorized A&A service modules are categorized into one or more categories, wherein the one or more categories is selected from a group comprising simple A&A service module when the security risk score comprises the one or more low security risk score, a basic A&A service module when the security risk score comprises the one or more medium security risk score and an advance A&A service module when the security risk score comprises the one or more high security risk score.

12. The platform according to any of the preceding claims, wherein the plurality of A&A service modules comprise one of,• a centrally deployed authentication service module, and• a distributed deployed authentication service module, wherein the centrally deployed authentication service module is deployed in a central location within a cluster, and wherein the distributed deployed authentication service module is provided within the SM proxy module.

13. The platform according to any of the claims 1 - 11, wherein the plurality of A&A service modules is deployed as a combination of a centrally deployed authentication service module and a distributed deployed authentication module.

14. The platform according to any of the preceding claims, wherein each SM proxy modules of the one or more SM proxy modules Is configured to authenticate and authorize the incoming client service request by using service identity and a location of the incoming service request, wherein the location is identified through a user's identity.

15. The platform according to any of the preceding claims, wherein the prediction module comprise one of,• a centrally deployed prediction module deployed in a central location within a cluster having the A&A service module implemented in the central location; and• a distributed deployed prediction module.

16. The platform according to any of the preceding claims, wherein the selection model comprise one of,• a centrally deployed selection model deployed in a central location within a cluster having the A&A service module implemented in the central location; and• a distributed deployed selection model.

17. A compute-implemented method (1100) providing authentication of service requests through a platform (4000) for a service mesh network (400), said service mesh network (400) being implemented in one or more clusters (2000) and forming a Micro-Service Architecture (3000), the platform (4000) comprising: receiving, through an application layer (401)a gateway configured in the service mesh network (400), one or more incoming client service requests, wherein the application layer (401) is having one or more service instances (404); authenticating, through each authentication and authorization, A&A, service modules (408) of a plurality of A&A service modules, wherein each A&A service module (408) is implemented in one or more of the one or more clusters (2000) in the service mesh network (400); receiving, through a gateway (402) the one or more incoming client service requests; forwarding, through the gateway (402), the one or more incoming client service requests to one or more service mesh, SM, proxy modules (406), , wherein each SM proxy module (406) is arranged to provide access to the plurality of authentication and authorization, A&A, service modules (408); and predicting, through a prediction model (414) executed by a processor (410), a security risk score for each service request from the one or more incoming client service requests, wherein the processor (410) is communicatively coupled to the one or more SM proxy module (406), wherein the processor (410) executes a set of instructions stored in a memory (412); categorizing, through a classification module (416) executed by the processor (410), the plurality of A&A service modules (408) into a plurality of categorized A&A service modules, wherein the plurality of A&A service modules are categorized according to the service risk score; and selecting, through a selection model (418) executed by the processor (410), at least one categorized A&A, service module from the plurality of categorized A&A service modules according to the risk score associated with each service request; authenticating, through the one or more SM proxy modules (406), each incoming client service request from the one or more incoming client servicerequests by selectively accessing the at least one categorized A&A service module selected by the selection model (418); and forwarding, through a load balancer (420), the one or more incoming client service requests to the one or more service instances based on the selected authentication through the at least one categorized A&A service module.

18. The method according to claim 17, wherein the security risk score is selected from a group comprising at least one of: one or more low security risk score, one or more medium security risk score and one or more high security risk score.

19. The method according to any of the claims 17-18, wherein the method further comprising: identifying, through an identification module, each of the incoming client service requests as one of a trusted service request when the security risk score is the one or more low security risk score, an untrusted service request when the security risk score is the one or more high security risk score, and an unknown service request when the security risk score is the one or more medium security risk score.

20. The method according to any of the claims 17-19, wherein the method further comprising: forwarding, after the authentication, the incoming client service request to one or more target service instances from the one or more service instances, wherein the one or more target service instances are configured to generate a service response for the one or more incoming service requests.

21. The method according to any of the claims 17 or 20, wherein the method further comprising: identifying, if the one or more target service instances to be selected are running in a same cluster from the one or more clusters; and selecting, at least one similar categorized A&A service module from the plurality of categorized A&A service modules;authenticating, through the SM proxy module, the one or more incoming client service requests by using the at least one similar categorized A&A service module; and generating, through the one or more target service instances, the service response towards the one or more incoming client service requests based on the selected authentication through the at least one categorized A&A service module.

22. The method according to any of the claims 17 or 20, wherein the method further comprising: identifying, if the one or more target service instances are running in a different cluster from the one or more clusters; evaluating, through a gateway of the different cluster, the category of the categorized A&A service module from the plurality of categorized A&A service modules; selecting, through the selection module, the categorized A&A service module from the plurality of categorized A&A service modules based on the evaluation; authenticating, through the SM proxy module, the one or more incoming client service requests by using the at least one categorized A&A service module based on the evaluation; and generating, through the one or more target service instances, the service response towards the one or more incoming client service requests after the authentication.

23. The method according to claim 17, wherein the prediction model is configured for: developing a Machine Learning (ML) model for predicting the security risk score, wherein the machine leaning model is developed by using one or more parameters functionally related to the one or more incoming service requests.

24. The method according to claim 23, wherein the one or more parameters comprise a time stamp associated with one or more of: payload data,Source, Src IP,• Destination, dest IP,• client IP,• App / service ID,• HTTP headers, and• at least one input risk levels comprising one or more low levels, one or more medium levels, or one or more high levels.

25. The method according to any of the claims 23 or 24, wherein the ML model is selected from a group of supervised ML model, a semi-supervised ML model, an unsupervised ML model.

26. The method according to any of the claims 17-25, wherein the A&A service module is selected from a group comprising of Identity Access Management, 1AM, module, and Certificate Management Module, CMS.

27. The method according to any of the claims 17-26, wherein the plurality of categorized A&A service modules are categorized into one or more categories, wherein the one or more categories is selected from a group comprising simple A&A service module when the security risk score comprises the one or more low security risk score, a basic A&A service module when the security risk score comprises the one or more medium security risk score and an advance A&A service module when the security risk score comprises the one or more high security risk score.

28. The method according to any of the claims 17-27, wherein the plurality of A&A service modules comprise one of,• a centrally deployed authentication service module, and• a distributed deployed authentication service module, wherein the centrally deployed authentication service module is deployed in a central location within a cluster, and wherein the distributed deployed authentication service module is provided within the SM proxy module.

29. The method according to any of the claims 17-28, wherein the plurality of A&A service modules is deployed as a combination of a centrally deployed authentication service module and a distributed deployed authentication module.

30. The method according to any of the claims 17-29, wherein each SM proxy modules of the one or more SM proxy modules Is configured to authenticate and authorize the incoming client service request by using service identity and a location of the incoming client service request, wherein the location is identified through a user's identity.

31. The method according to any of the claims 17-30, wherein the prediction module comprise one of,• a centrally deployed prediction module deployed in a central location within a cluster having the A&A service module implemented in the central location, and• a distributed deployed prediction module.

32. The method according to any of the claims 17-31, wherein the selection model comprise one of,• a centrally deployed selection model deployed in a central location within a cluster having the A&A service module implemented in the central location, and• a distributed deployed selection model.

33. A computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions, the computer program is loadable into a data processing unit and configured to cause execution of the method according to any of claims 17 through 32 when the computer program is run by the data processing unit.

Citation Information

Patent Citations

  • Web Service System and Method

    US20100299437A1

  • Microservice architecture for identity and access management

    US20190273746A1

  • Dynamic authorization and access management

    US20220224535A1