For secure management of service access in communication systems
By generating access tokens containing multiple service producer endpoint addresses in the 5G network, the problem of binding access tokens to specific service producer instances in the existing technology is solved, and the selection of multiple service producer instances is realized. and load balancing capabilities.
Patent Information
- Application Number
- CN201980043678.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2018-06-29
- Filing Date
- 2019-06-19
- Publication Date
- 2025-01-24
- Estimated Expiration
- 2039-06-19
AI Technical Summary
There are challenges in service access authorization in existing 5G networks, especially when access tokens are bound to specific service producer instances, resulting in the selection logic being restricted and cannot be selected from multiple service producer instances.
Generating a JSON web token allows a service consumer or proxy to select one or more service producer instances based on selection criteria by capturing the endpoint addresses of all discovered service producer instances in the access token.
The ability to select from multiple service producers, support the flexibility of load balance and service selection, and avoid the defects that need to be re -obtained when the service producer changes.
Smart Images

Figure CN112335274B_ABST
Abstract
Description
Technical Field
[0001] The field relates generally to communications systems and, more particularly, but not exclusively, to the management of security within such systems. Background Art
[0002] This section introduces various aspects that may help promote a better understanding of the present invention. Therefore, the statements in this section should be read from this perspective and should not be understood as an admission that there is something in the prior art or something that does not exist in the prior art.
[0003] Fourth generation (4G) wireless mobile telecommunication technology, also known as Long Term Evolution (LTE) technology, is designed to provide high capacity mobile multimedia with high data rates, particularly for human interaction. The next or fifth generation (5G) technology is intended not only for human interaction but also for machine type communications in so-called Internet of Things (IoT) networks.
[0004] While 5G networks are designed to enable massive IoT services (e.g., large numbers of limited-capability devices) and mission-critical IoT services (e.g., requiring high reliability), they still support improvements to traditional mobile communication services in the form of enhanced mobile broadband (eMBB) services that provide improved wireless Internet access to mobile devices.
[0005] In an exemplary communication system, a user equipment (5G UE in a 5G network, or more broadly, UE) such as a mobile terminal (subscriber) communicates with a base station or access point (referred to as a gNB in a 5G network) over an air interface. Illustratively, an access point (e.g., a gNB) is part of an access network of a communication system. For example, in a 5G network, the access network is referred to as a 5G system and is described in the 5G Technical Specification (TS) 23.501, V15.0.0 entitled "Technical Specification Group Services and System Aspects; System Architecture for the 5G System", the disclosure of which is incorporated herein by reference in its entirety. Typically, an access point (e.g., a gNB) provides a UE with access to a core network (CN), which then provides the UE with access to other UEs and / or data networks such as packet data networks (e.g., the Internet).
[0006] TS 23.501 goes on to define a 5G service-based architecture (SBA) that models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).
[0007] In addition, the 5G Technical Specification (TS) 33.501, V15.1.0, entitled "Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System", further describes security management details associated with the 5G network, the contents of which are incorporated herein by reference in their entirety.
[0008] Security management is an important consideration in any communication system. For example, authorization to access services is an example of security management in 5G networks. However, service access authorization presents several challenges in existing 5G approaches. Summary of the invention
[0009] The exemplary embodiments provide improved techniques for security management in communication systems, particularly with respect to service access authorization.
[0010] For example, in an exemplary embodiment, a method includes the following steps: At an authorization entity in a communication system including a service-based architecture, a request for access to a given service type is received from a service consumer in the communication system. The authorization entity obtains an access token identifying a plurality of service producers for the given service type, and sends the access token to the service consumer.
[0011] In another embodiment, a method includes the following steps. A service consumer in a communication system including a service-based architecture sends a request for access to a given service type to an authorization entity in the communication system. The service consumer receives an access token from the authorization entity, wherein the access token identifies a plurality of service producers in the communication system for the given service type. Based on one or more selection criteria, one of the plurality of service producers is selected according to the access token.
[0012] In another embodiment, a method includes the following steps. An access token is received at a proxy unit in a communication system including a service-based architecture, wherein the access token identifies a plurality of service producers in the communication system for a given service type and is generated by an authorized entity in the communication system in response to a request for access to the given service type by a service consumer in the communication system. At the proxy unit, a service producer among the plurality of service producers is selected according to the access token based on one or more selection criteria. In an additional embodiment, the proxy unit sends identification information for the selected service producer to the service consumer.
[0013] In yet another embodiment, a method includes the following steps: receiving an access token from an authorization entity at a service consumer in a communication system including a service-based architecture, wherein the access token identifies a plurality of proxy units corresponding to service producers for a given service type in the communication system. The service consumer selects one of the plurality of proxy units based on the access token and sends a request for access to the given service type to the selected proxy unit.
[0014] Further exemplary embodiments are provided in the form of a non-transitory computer-readable storage medium having executable program code embodied therein, which when executed by a processor causes the processor to perform the above steps. Still further exemplary embodiments include an apparatus having a processor and a memory configured to perform the above steps.
[0015] These and other features and advantages of the embodiments described herein will become more apparent from the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] Figure 1 A communication system is shown in which one or more exemplary embodiments may be implemented.
[0017] Figure 2 Network elements / functions for providing security management are shown with which one or more exemplary embodiments may be implemented.
[0018] Figure 3 A communication system architecture with which one or more exemplary embodiments may be implemented is shown with network functions interacting between and within a visited network and a home network.
[0019] Figure 4 A method for service access authorization in a communication system according to an exemplary embodiment is shown.
[0020] Figure 5 A method for generating an access token for use in service access authorization in a communication system according to an exemplary embodiment is shown.
[0021] Figure 6 At least a portion of an access token used in service access authorization in a communication system according to an exemplary embodiment is shown.
[0022] Figure 7 A method for service discovery in a communication system according to an exemplary embodiment is shown. DETAILED DESCRIPTION
[0023] Embodiments will be described herein in conjunction with exemplary communication systems and associated techniques for providing security management in communication systems. However, it should be understood that the scope of the claims is not limited to the specific type of communication system and / or process disclosed. The embodiments may be implemented in various other types of communication systems using alternative processes and operations. For example, although described in the context of a wireless cellular system (such as a 3GPP Next Generation System (5G)) using 3GPP system elements, the disclosed embodiments may be adapted to various other types of communication systems in a straightforward manner.
[0024] According to exemplary embodiments implemented in a 5G communication system environment, one or more 3GPP technical specifications (TS) and technical reports (TR) provide further descriptions of network elements / functions and / or operations that interact with one or more exemplary embodiments, for example, 3GPP TS 23.501 and 3GPP TS 33.501 mentioned above. Other 3GPP TS / TR documents provide other conventional details that will be recognized by those of ordinary skill in the art. However, although very suitable for 5G-related 3GPP standards, these embodiments are not intended to be limited to any particular standard.
[0025] Exemplary embodiments relate to security management associated with a service-based architecture (SBA) for a 5G network. Figure 1 and 2 A general description of the main components of a 5G network is described in the context of .
[0026] Figure 1 1 shows a communication system 100 in which an exemplary embodiment is implemented. It should be understood that the units shown in the communication system 100 are intended to represent the main functions provided within the system, such as UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. Therefore, Figure 1 The boxes shown in refer to specific units in the 5G network that provide these main functions. However, in other embodiments, other network units are used to implement some or all of the main functions represented. In addition, it should be understood that Figure 1Not all functions of the 5G network are shown in the figure. Instead, functions are presented to help explain the exemplary embodiments. Subsequent figures depict some additional units / functions.
[0027] Thus, as shown, the communication system 100 includes a user equipment (UE) 102 that communicates with an access point (gNB) 104 via an air interface 103. In some embodiments, the UE 102 is a mobile station, and such a mobile station may include, for example, a mobile phone, a computer, or any other type of communication device. Thus, the term "user equipment" as used herein is intended to be interpreted broadly to cover a variety of different types of mobile stations, subscriber stations, or more generally communication devices, including examples such as combinations of data cards inserted into a laptop or other device (such as a smartphone). Such communication devices are also intended to cover devices that are generally referred to as access terminals.
[0028] In one embodiment, UE 102 includes a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. UICC is the user-related part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and suitable application software. USIM securely stores permanent subscription identifiers and their associated keys, which are used to identify and authenticate subscribers accessing the network. ME is the user-independent part of the UE and contains Terminal Equipment (TE) functions and various Mobile Terminal (MT) functions.
[0029] Note that in one example, the permanent subscription identifier is the International Mobile Subscriber Identity (IMSI) of the UE. In one embodiment, the length of the IMSI is a fixed 15 digits and includes a 3-digit mobile country code (MCC), a 3-digit mobile network code (MNC), and a 9-digit mobile station identification number (MSIN). In a 5G communication system, the IMSI is called a subscription permanent identifier (SUPI). If the IMSI is used as a SUPI, the MSIN provides a subscriber identity. Therefore, it is usually only necessary to encrypt the MSIN part of the IMSI. The MNC and MCC parts of the IMSI provide routing information, which the service network uses to route to the correct home network. When the MSIN of the SUPI is encrypted, it is called a subscription hidden identifier (SUCI).
[0030] The access point 104 is illustratively part of an access network of the communication system 100. Such an access network comprises, for example, a 5G system having a plurality of base stations and one or more associated radio network control functions. In some embodiments, the base stations and the radio network control functions are logically separate entities, but in some embodiments, they are implemented in the same physical network element (e.g., a base station router or a femtocell access point).
[0031] In this exemplary embodiment, the access point 104 is operably coupled to a mobility management function 106. In a 5G network, the mobility management function is implemented by an access and mobility management function (AMF). In some embodiments, a security anchor function (SEAF) is also implemented by connecting the UE to the mobility management function through the AMF. As used herein, a mobility management function is a unit or function (i.e., an entity) in the core network (CN) portion of a communication system that manages or otherwise participates in access and mobility (including authentication / authorization) operations (through the access point 104) and other network operations with the UE. The AMF is also more generally referred to herein as an access and mobility management entity.
[0032] In the exemplary embodiment, the AMF 106 is operably coupled to a home subscriber function 108, i.e., one or more functions residing in the subscriber's home network. As shown, some of these functions include a unified data management (UDM) function and an authentication server function (AUSF). The AUSF and UDM (individually or collectively) are also more generally referred to herein as authentication entities. In addition, the home subscriber function includes, but is not limited to, a network slice selection function (NSSF), a network exposure function (NEF), a network function storage function (NRF), a policy control function (PCF), and an application function (AF).
[0033] An important point to note is that in SBA communication systems such as 5G systems, the control plane uses a service model approach where components (NFs) query the NRF to discover and communicate with each other through an application programming interface (API). The NF service discovery and authorization approach will be described in further detail below.
[0034] Access point 104 is also operatively coupled to a serving gateway function, session management function (SMF) 110, which is operatively coupled to a user plane function (UPF) 112. UPF 112 is operatively coupled to a packet data network, such as the Internet 114. Other typical operations and functions of such network elements are not described here, as they are not the focus of the exemplary embodiments and can be found in suitable 3GPP 5G documents.
[0035] It should be understood that this particular arrangement of system units is merely an example, and in other embodiments, additional or alternative units of other types and arrangements may be used to implement the communication system. For example, in other embodiments, system 100 includes other units / functions not explicitly shown herein.
[0036] therefore, Figure 1 The configuration of is only one exemplary configuration of a wireless cellular system, and a variety of alternative system unit configurations may be used. Figure 1 Only a single unit / function is shown, but this is only for simplicity and clarity of description. A given alternative embodiment may of course include a greater number of such system units, as well as additional or alternative units of the type normally associated with conventional system implementations.
[0037] It should also be noted that although Figure 1 The system unit is shown as a single functional block, but the various subnets that make up the 5G network are divided into so-called network slices. A network slice (network partition) includes a series of network function (NF) sets (i.e., function chains), each function corresponding to a service type using network function virtualization (NFV) on a common physical infrastructure. Network slices can be instantiated on demand for a given service (e.g., eMBB services, large-scale IoT services, and mission-critical IoT services). Therefore, when an instance of a network slice or function is created, the network slice or function is instantiated. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via gNB 104. NFs can also access services of other NFs.
[0038] Figure 2 2 is a block diagram of a network element / function for providing security management in an exemplary embodiment. System 200 is shown to include a first network element / function 202 and a second network element / function 204. It should be understood that network elements / functions 202 and 204 represent any network element / function configured to provide security management and other techniques described herein, such as, but not limited to, AMF, SEAF, UDM, AUSF, NSSF, NEF, NRF, PCF, and AF.
[0039] The network element / function 202 includes a processor 212 coupled to a memory 216 and an interface circuit 210. The processor 212 of the network element / function 202 includes a security management processing module 214, which can be implemented at least in part in the form of software executed by the processor. The processing module 214 performs security management described in conjunction with subsequent figures and otherwise herein. The memory 216 of the network element / function 202 includes a security management storage module 218, which stores data generated or otherwise used during security management operations.
[0040] The network element / function 204 includes a processor 222 coupled to a memory 226 and an interface circuit 220. The processor 222 of the network element / function 204 includes a security management processing module 224, which may be implemented at least in part in the form of software executed by the processor 222. The processing module 224 performs security management as described in connection with subsequent figures and otherwise herein. The memory 226 of the network element / function 204 includes a security management storage module 228, which stores data generated or otherwise used during security management operations.
[0041] The processors 212 and 222 of the corresponding network elements / functions 202 and 204 may include, for example, a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), or other types of processing devices or integrated circuits, and parts or combinations of these elements. Such integrated circuit devices and parts or combinations thereof are examples of the term "circuitry" as used herein. Various other arrangements of hardware and associated software or firmware may be used to implement exemplary embodiments.
[0042] The memories 216 and 226 of the respective network elements / functions 202 and 204 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, the security management operations and other functionality described in connection with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by the processors 212 and 222.
[0043] Thus, a given one of memories 216 or 226 may be considered an example of what is generally referred to herein as a computer program product or more generally as a processor-readable storage medium in which executable program code is embodied. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media in any combination. Exemplary embodiments may include articles of manufacture that include such computer program products or other processor-readable storage media.
[0044] The memory 216 or 226 may, for example, more particularly include an electronic random access memory (RAM), such as a static RAM (SRAM), a dynamic RAM (DRAM), or other types of volatile or non-volatile electronic memory. The latter may, for example, include non-volatile memory, such as flash memory, magnetic RAM (MRAM), phase change RAM (PC-RAM), or ferroelectric RAM (FRAM). The term "memory" as used herein is intended to be interpreted broadly and may additionally or alternatively include, for example, read-only memory (ROM), disk-based memory, or other types of storage devices, and parts or combinations of these devices.
[0045] The interface circuits 210 and 220 of the respective network elements / functions 202 and 204 illustratively include transceivers or other communication hardware or firmware that allow the associated system elements to communicate with each other in the manner described herein.
[0046] from Figure 2 204, and vice versa. This communication involves the network element / function 202 sending data to the network element / function 204, and the network element / function 204 sending data to the network element / function 202. However, in alternative embodiments, other network elements may be operably coupled between the network elements / functions 202 and 204. The term "data" as used herein is intended to be broadly interpreted to cover any type of information that may be sent between network elements / functions (and between user equipment and the core network), including but not limited to messages, identifiers, keys, indicators, user data, control data, etc.
[0047] Thus, in one example, the network element / function 202 is a NF (such as an AMF) and the network element / function 204 is an NRF. In this case, the AMF and the NRF participate in the service access authorization method (discovery and selection) and exchange messages / data as needed. This service access authorization method will be described in further detail below.
[0048] It should be understood that Figure 2 The specific arrangement of components shown in is merely an example, and a variety of alternative configurations are used in other embodiments. For example, any given network element / function may be configured to incorporate additional or alternative components and to support other communication protocols.
[0049] Other system elements such as UE 102 and gNB 104 may also each be configured to include components such as processors, memory, and network interfaces. These elements need not be implemented on separate independent processing platforms, but may represent different functional parts of a single common processing platform, for example.
[0050] Given the general concepts described above, exemplary embodiments that address certain security management issues will now be described. More particularly, exemplary embodiments provide security management techniques for 5G systems. The architecture for 5G systems is currently being standardized in 3GPP. As described above, 3GPP TS 23.501 defines the 5G system architecture as service-based, e.g., service-based architecture (SBA).
[0051] Figure 3 A 5G architecture 300 is depicted employing a configuration including a visited public land mobile network (VPLMN) 310 operatively coupled to a home public land mobile network (HPLMN) 330 via an intermediary Internet Packet Exchange (IPX) network 320. Note that there can be more than one IPX network operatively coupled between the VPLMN 310 and the HPLMN 330. Figure 3 Also shown is the presence of a Security Edge Protection Proxy (SEPP) at the edge of each PLMN, i.e., vSEPP 312 in VPLMN 310 and hSEPP 332 in HPLMN 330. It should be understood that the various network functions shown in VPLMN 310 and HPLMN 330 are known and described in detail in various 5G specifications such as, but not limited to, TS 23.501 and TS 33.501 mentioned above.
[0052] As described above, in 5G, SBA is introduced to model services as network functions (NFs) that communicate with each other using RESTful application programming interfaces (representational state transfer APIs). In a scenario where two communicating NFs are in two different PLMNs (e.g., VPLMN 310 and HPLMN 330), the communication occurs over the roaming inter-network interface (N32) between the two participating PLMNs.
[0053] In order to protect NF-specific content in messages sent over the roaming inter-network interface, 5G introduces SEPP as an entity residing at the periphery of the PLMN network to protect the PLMN from external traffic, and additionally implements transport layer security (TLS) and application layer security (ALS) for all data and signaling exchanged between two inter-network network functions at the service layer. For example, before sending a message from the outside over the roaming N32 interface, the SEPP performs security management functions on the information elements (IEs) in the Hypertext Transfer Protocol (HTTP) message. Protected HTTP messages are referred to as N32 messages. Protection such as ALS involves protecting the information sent in various parts of the HTTP message, including but not limited to HTTP request / response lines, HTTP headers, and HTTP payload. However, some parts of this message may need to be protected by an intermediary between the two SEPPs (e.g., Figure 3 Modify the IPX 330 network provider as shown in the figure.
[0054] Therefore, in 5G SBA, the PLMN operator deploys SEPP at the edge of its network to interoperate and obtain services from the network function in its roaming partner network. The SEPP interfaces with one or more other SEPPs in one or more other networks via the N32 interface. As an edge proxy, the SEPP implements the ALS as described above to protect the HTTP messages exchanged between the network function in its network and another network function in the roaming partner network.
[0055] Although Figure 3 The two NFs shown can be in different PLMNs, but some NFs in the same PLMN also have the need to communicate. In either scenario (inter-PLMN communication or intra-PLMN communication), the SBA communication model includes a secure method that enables "NF service consumers" (service clients) to be authenticated and authorized to access services provided by or otherwise associated with "NF service producers" (service servers). One of the authorization methods supported in the 3GPP TS 33.501 (Release 15) cited above is based on the OAuth 2.0 access token method. In the 5G system, the following model is adopted when OAuth 2.0 is used: (i) NRF is the OAuth 2.0 authorization server; (ii) NF service consumer is the OAuth 2.0 client; and (iii) NF service producer is the OAuth 2.0 resource server.
[0056] The NF Service Consumer (Client) discovers the NF Service Producer (Resource Server) via the NRF and then obtains an access token to present to the NF Service Producer when invoking a service API request. In existing methods (such as described in 3GPP TS 33.501 (Release 15) cited above), the access token is bound to a specific NF Producer instance selected by the NRF or NF Service Consumer at the end of the discovery process.
[0057] The exemplary embodiments recognize that by binding the access token to a specific single NF Producer instance, the selection logic is prevented from selecting from a pool of NF Producer instances. The exemplary embodiments further recognize that selecting from a pool of instances is relevant in situations where the currently used instance fails, or when it is desired to quickly select a different instance for load balancing purposes, or where an intermediate proxy entity will make the selection on behalf of the NF Service Consumer. In addition, the exemplary embodiments recognize that having a 1:1 association between an access token and an NF Producer instance is suboptimal because it forces the NF Consumer to obtain a new token each time the Service Producer changes. In fact, the current 3GPP standardization scheme requires the NF Service Consumer to obtain a new access token for each service request, and such access token is based on each NF Producer instance from which the NF Service Consumer wants to obtain service. See 3GPP TS 33.501, clause 13.4, cited above.
[0058] As will be explained in further detail herein, an exemplary embodiment provides improved service access authorization that enables service selection logic to select from two or more NF producer instances. For example, in one embodiment, the NRF generates an access token based on a JavaScript Object Notation (JSON) Web Token and populates an audience claim field in the token with endpoint addresses (i.e., uniform resource locators or URLs) for a set of discovered producer NF instances or producer NF service instances. When the NF service consumer requests an access token after the discovery step, the NRF returns the generated token. The NF selection logic uses the audience claim field to select a producer NF instance based on various factors, such as, but not limited to, load balancing.
[0059] Figure 4 An example of the entire process is shown as method 400 .
[0060] As shown in step 402, during the NF service discovery process, the NRF captures the endpoint addresses of all discovered NF service producer instances in the access token.
[0061] In step 404, the NRF returns the stored access token to the NF service consumer instance in an access token response message.
[0062] In step 406, the selection logic (in the NF service consumer or the proxy, as will be further explained below) applies a set of criteria to select a NF service producer instance based on the entry in the access token. If the selection logic is implemented in the proxy, the proxy can provide the address of the selected producer instance to the NF service consumer instance.
[0063] Each of steps 402, 404, and 406 will now be described in further detail.
[0064] All discovered NF service producer instances are captured in the access token (step 402). As part of the discovery process, the NRF determines the discovered NF instances or NF service instances, and provides a set of information about the discovered NF instances or NF service instances to the NF service consumer via the Nnrf_NFDiscovery_Request response message. The information includes: FQDN (fully qualified domain name), IP (Internet Protocol) address, or endpoint address (i.e., URL) for the group of discovered NF instances or NF service instances. The details of the discovery process are further described in clause 4.17.4 of the 5G Technical Specification (TS) 23.502, V15.2.0 entitled "Technical Specification Group Services and System Aspects; Procedures for the 5G System, Stage 2", the contents of which are incorporated herein by reference in their entirety.
[0065] Figure 5 Method 500 is shown with additional steps that the NRF performs as part of the discovery process, according to an exemplary embodiment.
[0066] In step 502, the NRF generates an access token in the JSON Web Token (JWT) format, as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 7519 "JSON Web Token (JWT)", May 2015, the disclosure of which is incorporated herein by reference in its entirety. As will be explained, this format is modified to include multiple discovered service producers, as per the next step.
[0067] In step 504, the NRF populates the audience claim field in the JSON Web Token structure with all discovered NF Service Producer instances or endpoint addresses of NF Service instances. In another embodiment, as will be further explained below, the access token may alternatively store the endpoint address of the proxy unit corresponding to the NF Service Producer instance.
[0068] In step 506, the NRF stores the access token so that it can be provided to the NF service consumer instance in an access token response message (step 404).
[0069] Figure 6 At least a portion of a JSON Web Token (JWT) 600 is shown, and in particular, how an audience claim field is used to capture the address of a discovered NF producer instance having an access token. As shown, the JWT 600 includes an NRF identification field 602 (identifying the NRF generating the access token), an NF consumer identification 604 (identifying the NF requesting the access token), and an audience claim field 606 having multiple NF producer identifications and addresses.
[0070] exist Figure 6 In the example embodiment shown in , the audience statement is an array, where each element of the array includes the NF instance ID (identification) and the endpoint address of the discovered producer instance. Alternative embodiments are possible as to how the audience statement is formatted.
[0071] The NRF returns the stored requested access token in an access token response message (step 404). Clause 13.4.1.1 of 3GPP TS 33.501 cited above describes a process for obtaining an access token from the NRF. This is performed by the consumer NF instance prior to service access. The exemplary embodiment provides, among other things, the following changes to the existing process:
[0072] 1) When NRF receives an Access Token Request message from a NF Instance ID (Service Consumer ID) that has been authorized for a specific target NF Type and Service Name in the discovery step, NRF skips re-authorizing the NF Service Consumer instance again (which is step 2 in the existing process).
[0073] 2) The NRF fetches the access token generated for this NF Instance ID during the discovery process (step 402) and provides it in the Access Token Response.
[0074] As described above in the context of step 402, the access token is populated with all the required information of the discovered NF Service Producer instance.
[0075] Figure 7A modified message flow for a service discovery method 700 according to an exemplary embodiment is shown. More specifically, as shown in step 1, the NF service consumer 702 sends an access token request to the NRF (authorization server) 704. The access token request includes the NF instance ID, the expected NF service name, and the expected NF service type. In step 2, the NRF 704 obtains the stored access token for this request. Then, in step 3, the NRF 704 sends an access token response to the NF service consumer 702, which includes the access token, the expiration time of the token, and the scope of the token.
[0076] The selection logic selects an NF service producer instance (step 406). The NF service consumer instance receives an access token response message including an access token. The NF service consumer instance then applies a set of evaluation factors to determine which NF service producer instance to use for the service request. The NF service consumer executes the service request API to obtain the service from the selected NF service producer instance. The access token is included in the request. Note that in some embodiments, the selection logic is part of the NF service consumer instance, while in other embodiments, the selection logic is part of the proxy unit.
[0077] Given the above illustrative description, some exemplary embodiments are further described below.
[0078] 1. Service-based architecture (Release 15 of TS 33.501), where the selection is performed by the NF Service Consumer instance. This is the Rel-15 model, where the NF Service Consumer obtains an access token from the NRF to obtain services from the selected NF Producer instance and includes this token in the API service request addressed to the NF Service Producer instance. This implementation allows the NF Service Consumer to obtain services from more than one eligible NF Service Producer instance using one access token.
[0079] 2. In an architecture where a proxy acts as a central hub for all or some service layer messages between NFs within a PLMN.
[0080] a. The proxy is an entity that selects the NF service producer from the list of NF service producers provided by the NRF in the NF service discovery response. In some embodiments, the proxy function also resides in the NRF itself or has a proprietary interface to the NRF. The NRF provides this information to the NF service consumer in the NF service discovery response message.
[0081] b. The NF Service Consumer includes the obtained access token in the API service request addressed to the NF Service Producer instance.
[0082] c. In some embodiments, the proxy applies load balancing to the API service request, which may result in the proxy selecting a new NF Producer instance from the list of NF Producer instances present in the access token. In some embodiments, the proxy also selects the NF Producer instance based on reasons other than load balancing.
[0083] d. The proxy routes the service request to the selected NF service producer instance.
[0084] 3. In the architecture where the proxy is only between the NF service consumer and the NF service producer. In this model, there is no proxy between the NF service consumer and the NRF. That is, the proxy only listens to the communication between the two NFs.
[0085] Thus, in some embodiments, the proxy receives the access token from the service consumer rather than from the NRF.
[0086] As shown in scenario 2c above, in some embodiments, the proxy applies load balancing, or some other selection-related functionality, to the API service requests by altering the selection made by the NF service consumer based on information in the access token.
[0087] In an alternative embodiment, as above in Figure 5 As described in step 504 of , the NRF can generate an access token for the endpoint address of the storage proxy unit instead of storing the endpoint address of the service producer. This embodiment is useful, for example, when the proxy is located between two NFs (service consumer and service producer) and the service producer address is not visible externally. The proxy is used as a gatekeeper for one or more service producer instances in the backend. Therefore, in this alternative model, the NRF populates the audience declaration field with the endpoint address of the proxy (unit). The NF service consumer selects an address and sends the message to the proxy. The proxy then selects a service provider instance.
[0088] Thus, advantageously, in this model, the service consumer communicates with a proxy unit associated with the service producer. In other words, there is no direct connection between the service consumer and the selected service producer. The connection is made through the proxy. Furthermore, in this model, the proxy may choose to change the selected producer based on load balancing criteria or other criteria. The proxy uses the audience claim field in the access token to select a different service producer.
[0089] In other embodiments, the proxy unit may reside in the NRF, in a NF service consumer, and / or in one or more NF service producers.
[0090] In addition to load balancing criteria being used as service producer selection criteria, other criteria may also be used, such as availability (e.g., a service producer becomes unavailable / failed) and / or planned maintenance (e.g., for software upgrades). In addition, in some embodiments, the selection criteria include one or more operator-configured policy criteria.
[0091] Therefore, it should be emphasized again that the various embodiments described herein are presented only by way of exemplary examples and should not be interpreted as limiting the scope of the claims. For example, alternative embodiments may use different communication system configurations, user equipment configurations, base station configurations, key pair provision and use processes, message protocols, and message formats than those described above in the context of the exemplary embodiments. These and various other alternative embodiments within the scope of the appended claims will be apparent to those skilled in the art.
Claims
1. A method for security management, the method comprising: At an authorization entity in a communication system including a service-based architecture, receiving a request for access to a given network function service type from a network function service consumer in the communication system; obtaining, at the authorization entity, an access token, the access token identifying a plurality of network function service producers for the given network function service type; as well as The access token is sent from the authorization entity to the network function service consumer.
2. The method according to claim 1, further comprising: Prior to receiving an access token request from the network function service consumer, the authorization entity authenticates the network function service consumer in a discovery step.
3. The method according to claim 1, wherein: The obtaining step further includes retrieving the access token generated during the discovering step from a storage device.
4. The method according to claim 1, wherein: The authorization entity is a network function storage function, the network function service consumer is a first network function, and the plurality of network function service producers are two or more other network functions.
5. The method according to claim 1, wherein: The access token includes an identifier and an address for each of the plurality of network function service producers identified therein.
6. The method according to claim 4, wherein: The address for a given network function service producer includes a unified location identifier.
7. The method according to claim 1, wherein: The access token includes a JavaScript Object Notation Web Token format.
8. The method according to claim 7, wherein: The plurality of network function service producers for the given network function service type are identified in an audience claim field of the JavaScript Object Notation Web Token format.
9. A non-transitory computer-readable storage medium having executable program code embodied therein, the executable program code, when executed by a processor, causing the processor to perform the following steps: At an authorization entity in a communication system including a service-based architecture, receiving a request for access to a given network function service type from a network function service consumer in the communication system; obtaining, at the authorization entity, an access token, the access token identifying a plurality of network function service producers for the given network function service type; as well as The access token is sent from the authorization entity to the network function service consumer.
10. A device for security management, the device comprising: In a communication system comprising a service-based architecture, wherein the communication system comprises an authorization entity, at least one network function service consumer, and a network function service producer; at least one processor coupled to a memory associated with the authorization entity and configured to: receiving a request from the network function service consumer to access a given network function service type; Obtaining access tokens identifying a plurality of network function service producers for the given network function service type; as well as The access token is sent to the network function service consumer.
11. A method for security management, the method comprising: sending, from a network function service consumer in a communication system comprising a service-based architecture, a request for access to a given network function service type to an authorization entity in said communication system; receiving, at the network function service consumer, an access token from the authorization entity, wherein the access token identifies a plurality of network function service producers for the given network function service type in the communication system; as well as Based on one or more selection criteria, one of the plurality of network function service producers is selected according to the access token.
12. The method according to claim 11, further comprising: The network function service consumer sends a service request to the selected network function service producer, wherein the service request includes the access token.
13. The method according to claim 12, wherein: The service request comprises an application programming interface service request.
14. The method according to claim 11, further comprising: Then another network function service producer is selected based on the same access token; as well as Sending a service request to the selected another network function service producer, wherein the service request includes the access token.
15. A non-transitory computer-readable storage medium having executable program code embodied therein, the executable program code, when executed by a processor, causing the processor to perform the following steps: sending, from a network function service consumer in a communication system comprising a service-based architecture, a request for access to a given network function service type to an authorization entity in said communication system; receiving an access token from the authorization entity at the network function service consumer, wherein: The access token identifies a plurality of network function service producers for the given network function service type in the communication system; as well as Based on one or more selection criteria, one of the plurality of network function service producers is selected according to the access token.
16. A device for security management, the device comprising: In a communication system comprising a service-based architecture, wherein the communication system comprises an authorization entity, at least one network function service consumer, and a network function service producer; at least one processor coupled to a memory associated with the network function service consumer and configured to: sending a request to the authorization entity for access to a given network function service type; receiving, at the network function service consumer, an access token from the authorization entity, wherein the access token identifies a plurality of network function service producers for the given network function service type in the communication system; as well as Based on one or more selection criteria, one of the plurality of network function service producers is selected according to the access token.
17. A method for security management, the method comprising: receiving an access token at a proxy unit in a communication system including a service-based architecture, wherein the access token identifies a plurality of network function service producers for a given network function service type in the communication system and is generated by an authorized entity in the communication system in response to a request by a network function service consumer in the communication system for access to the given network function service type; and At the proxy unit, one of the plurality of network function service producers is selected according to the access token based on one or more selection criteria.
18. The method according to claim 17, further comprising: When the proxy unit resides between the authorization entity and the network function service consumer, the proxy unit sends identification information for the selected network function service producer to the network function service consumer.
19. The method according to claim 17, further comprising: When the proxy unit resides between the authorization entity and the network function service consumer, the proxy unit then selects another network function service producer according to the access token based on a change in at least one of the one or more selection criteria.
20. The method according to claim 19, further comprising: The proxy unit sends identification information for a subsequently selected network function service producer to the network function service consumer.
21. The method of claim 17, further comprising: When the proxy unit resides between the network function service consumer and one or more of the network function service producers, the proxy unit sends identification information for the selected network function service producer to the network function service consumer.
22. The method according to claim 21, further comprising: When the proxy unit resides between the network function service consumer and one or more of the network function service producers, the proxy unit then selects another network function service producer according to the access token based on a change in at least one of the one or more selection criteria.
23. The method according to claim 22, further comprising: The proxy unit sends identification information for a subsequently selected network function service producer to the network function service consumer.
24. The method according to claim 19, wherein: The selection criteria for the change include one or more of the following: Load balancing guidelines; usability guidelines; and Maintenance guidelines.
25. The method of claim 19, wherein: The one or more selection criteria include one or more operator-configured policy criteria.
26. The method of claim 17, wherein: The proxy unit resides in the authorization entity.
27. The method of claim 17, wherein: The proxy unit resides in the network function service consumer.
28. The method of claim 17, wherein: The proxy unit resides in one or more of the network function service producers.
29. The method of claim 17, wherein: The proxy unit receives the access token from one of the authorization entity and the network function service consumer.
30. A non-transitory computer-readable storage medium having executable program code embodied therein, the executable program code, when executed by a processor, causing the processor to perform the following steps: An access token is received at a proxy unit in a communication system including a service-based architecture, wherein: The access token identifies a plurality of network function service producers for a given network function service type in the communication system and is generated by an authorized entity in the communication system in response to a request by a network function service consumer in the communication system for access to the given network function service type; as well as At the proxy unit, one of the plurality of network function service producers is selected according to the access token based on one or more selection criteria.
31. A device for security management, the device comprising: In a communication system comprising a service-based architecture, wherein the communication system comprises an authorization entity, at least one proxy unit, at least one network function service consumer, and a network function service producer; at least one processor coupled to a memory associated with the proxy unit and configured to: receiving an access token at the proxy unit, wherein the access token identifies a plurality of network function service producers for a given network function service type and is generated by the authorization entity in response to a request by the network function service consumer to access the given network function service type; and Based on one or more selection criteria, one of the plurality of network function service producers is selected according to the access token.
32. A method for security management, the method comprising: receiving, at a network function service consumer in a communication system including a service-based architecture, an access token from an authorization entity, wherein the access token identifies a plurality of proxy units corresponding to network function service producers in the communication system for a given network function service type; At the network function service consumer, selecting one of the plurality of proxy units according to the access token; and A request for access to the given network function service type is sent from the network function service consumer to the selected proxy unit.
33. A non-transitory computer-readable storage medium having executable program code embodied therein, the executable program code, when executed by a processor, causing the processor to perform the following steps: An access token is received from an authorization entity at a network function service consumer in a communication system including a service-based architecture, wherein: The access token identifies a plurality of proxy units corresponding to network function service producers for a given network function service type in the communication system; At the network function service consumer, selecting one of the plurality of proxy units according to the access token; as well as A request for access to the given network function service type is sent from the network function service consumer to the selected proxy unit.
34. A device for security management, the device comprising: In a communication system comprising a service-based architecture, wherein the communication system comprises an authorization entity, at least one proxy unit, at least one network function service consumer, and a network function service producer; at least one processor coupled to a memory associated with the network function service consumer and configured to: receiving an access token from the authorization entity, wherein the access token identifies a plurality of proxy units corresponding to network function service producers for a given network function service type; selecting one of the plurality of proxy units according to the access token; and A request for access to the given network function service type is sent to the selected proxy unit.
Citation Information
Patent Citations
Securing web services
US20060041669A1