Method, system, and computer-readable medium for delegated authorization in a service communication proxy (SCP)

Abstract

A method for delegated authorization in a service communication proxy (SCP) includes intercepting a service-based interface (SBI) request from a consumer network function (NF) that does not support access token-based authorization. The method further includes operating as an access token authorization client to obtain a first access token on behalf of the consumer NF. The method further includes using the first access token to enable the consumer NF to access a service provided by a first producer NF that requires access token-based authorization. The SCP can also act as an access token authorization server on behalf of an NRF that does not support access token-based authorization.

Description

[Technical Field]

[0001] Priority claim This application claims the benefit of priority to U.S. patent application Ser. No. 17 / 198,815, filed March 11, 2021, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to network security and inter-Public Land Mobile Network (PLMN) compatibility. More particularly, the subject matter described herein relates to a method, system, and computer-readable medium for delegated authorization in an SCP. [Background technology]

[0003] background In 5G telecommunications networks, a network function that provides a service is called a producer Network Function (NF) or an NF service producer. A network function that consumes a service is called a consumer NF or an NF service consumer. A network function may be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or consuming and producing the service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0004] A given producer NF can have many service endpoints, which are contact points for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and port number, or a fully qualified domain name that resolves to an IP address and port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may contain multiple NF instances. Note also that multiple NF instances can share the same service endpoint.

[0005] Producer NFs register with a Network Function Repository Function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably herein. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0006] In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the service communication proxy (SCP). SCPs subscribe to the NRF and obtain reachability and service profile information about producer NF service instances. Consumer NFs connect to the service communication proxy, which distributes traffic among producer NF service instances that offer the requested service or routes the traffic directly to the destination producer NF instance.

[0007] In addition to the SCP, another example of an intermediate proxy node that routes traffic between producer and consumer NFs is the Security Edge Protection Proxy (SEPP). A SEPP is a network node used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). Thus, the SEPP performs message filtering, monitoring, and topology hiding for all application programming interface (API) messages sent between PLMNs.

[0008] One issue in 5G communication networks arises when one PLMN or network function supports OAuth 2.0 authorization while another does not. According to the OAuth 2.0 authorization framework defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749, an authorization client attempting to access a protected resource available from a resource server first obtains an access token from the authorization server. After obtaining the access token, the client sends a service request to the resource server. The resource server validates the access token and provides access to the protected resource.

[0009] In the context of a 5G communication network, an NF service consumer acts as an OAuth2.0 resource client, an NF service producer acts as an OAuth2.0 resource server, and the NRF acts as an authorization server. Thus, an NF service consumer attempting to access a service provided by an NF service producer signals with the NRF to obtain an access token to access the resource provided by the NF service producer. After the NF service consumer obtains the access token from the NRF, the NF service consumer sends a service request to the NF service producer, where the service request includes the access token. The NF service producer validates the access token and provides access to the service requested by the NF service consumer.

[0010] Although the OAuth 2.0 authorization framework functions to provide authorization in 5G communication networks, if a service request is sent from a consumer NF that does not support OAuth 2.0 authorization to a producer NF that requires an OAuth 2.0 access token, the service request will be rejected. Similarly, if a consumer NF that supports OAuth 2.0 authorization sends an access token request to an NRF that does not support OAuth 2.0 authorization, the requesting consumer NF will not be able to obtain an access token.

[0011] These types of incompatibility problems can occur when a service consumer's PLMN supports OAuth 2.0 authorization and a service producer's PLMN does not, or vice versa. These types of incompatibility problems can also occur when an NF from one vendor supports OAuth 2.0 authorization and an NF from another vendor does not.

[0012] In light of these and other difficulties, there is a need for methods for improved interoperability between network functions when OAuth 2.0 authorization incompatibilities exist. Summary of the Invention [Means for solving the problem]

[0013] overview A method for delegated authorization in a service communication proxy (SCP) includes intercepting a service-based interface (SBI) service request from a first consumer network function (NF) that does not support access token-based authorization. The method further includes operating as an access token authorization client proxy to obtain a first access token on behalf of the first consumer NF. The method further includes using the first access token to enable the first consumer NF to access a service provided by a first producer NF that requires access token-based authorization.

[0014] According to another aspect of the subject matter described herein, operating as an access token authorization client proxy includes signaling with an NF Repository Function (NRF) to obtain a first access token.

[0015] According to another aspect of the subject matter described herein, signaling with the NRF to obtain the first access token includes generating an access token request on behalf of the first consumer NF, sending the access token request to the NRF, and receiving an access token response from the NRF that includes the first access token.

[0016] According to another aspect of the subject matter described in this specification, generating the access token request includes extracting values ​​of at least some attributes to be included in the access token request from a user-agent header of the SBI request.

[0017] According to another aspect of the subject matter described herein, extracting values ​​of at least some of the attributes includes extracting an NF instance ID of the first consumer NF from a User-Agent header of the SBI request.

[0018] According to another aspect of the subject matter described in this specification, receiving an SBI request includes receiving an SBI service request from a first consumer NF, and enabling the first consumer NF to access a service provided by the first producer NF using the first access token includes inserting the first access token into the SBI service request, forwarding the SBI service request including the first access token to the first producer NF, receiving an SBI service response from the first producer NF, and forwarding the SBI service response to the first consumer NF.

[0019] According to another aspect of the subject matter described in this specification, receiving an SBI request includes receiving an SBI service access request from a first consumer NF, and enabling the first consumer NF to access a service provided by the first producer NF using the first access token includes generating an SBI service request based on proxy discovery and NF selection performed in response to the SBI service access request, inserting the first access token into the SBI service request, forwarding the SBI service request including the first access token to the first producer NF, receiving an SBI service response from the first producer NF, and forwarding the SBI service response to the first consumer NF.

[0020] According to another aspect of the subject matter described herein, a method for delegated authorization at an SCP includes receiving an access token request from a second consumer NF or a second SCP; acting as an access token authorization server proxy on behalf of an NF Repository Function (NRF) that does not support access token authorization in response to the access token request from the second consumer NF or the second SCP; and performing signaling communication with the second consumer NF or the second SCP and the second producer NF to enable the second consumer NF to access a service provided by the second producer NF.

[0021] According to another aspect of the subject matter described herein, operating as an access token authorization server proxy includes generating a second access token in response to the access token request and sending an access token response including the second access token to a second consumer NF or a second SCP.

[0022] According to another aspect of the subject matter described in this specification, signaling with a second producer NF or a second SCP to enable a second consumer NF to access a service provided by the second producer NF includes receiving a second SBI service request from the second consumer NF, the second SBI service request including a second access token, removing the second access token from the second SBI service request, forwarding the second SBI service request to the second producer NF, receiving an SBI service response from the second producer NF, and forwarding the SBI service response to the second consumer NF or the second SCP.

[0023] According to another aspect of the subject matter described herein, generating the second access token includes generating an OAuth 2.0 access token that includes a dummy access token with syntactically correct claims.

[0024] According to another aspect of the subject matter described herein, there is provided a system for delegated authorization in a service communication proxy (SCP). The system includes a first SCP including at least one processor and a memory. The system further includes an access token authorization client proxy implemented by the at least one processor to intercept a service-based interface (SBI) request from a first consumer network function (NF) that does not support access token-based authorization, operate as an access token authorization client to obtain a first access token on behalf of the first consumer NF, and use the first access token to enable the first consumer NF to access a service provided by a first producer NF that requires access token-based authorization.

[0025] According to another aspect of the subject matter described herein, an access token authorization client proxy is configured to signal with an NF repository function (NRF) to obtain a first access token.

[0026] According to another aspect of the subject matter described herein, the access token authorization client proxy is configured to signal with an NRF to obtain a first access token by generating an access token request on behalf of a first consumer NF, sending the access token request to the NRF, and receiving an access token response from the NRF that includes the first access token.

[0027] According to another aspect of the subject matter described in this specification, the access token authorization client proxy is configured to generate the access token request by extracting values ​​of at least some attributes to be included in the access token request from a user-agent header of the SBI request.

[0028] According to another aspect of the subject matter described herein, the value extracted by the access token authorization client proxy includes the NF instance ID of the first consumer NF from the User-Agent header of the SBI request.

[0029] According to another aspect of the subject matter described in this specification, the SBI request includes an SBI service request from a first consumer NF, and the access token authorization client proxy is configured to enable the first consumer NF to access a service using the first access token by inserting the first access token into the SBI service request, forwarding the SBI service request including the first access token to the first producer NF, receiving an SBI service response from the first producer NF, and forwarding the SBI service response to the first consumer NF.

[0030] According to another aspect of the subject matter described in this specification, the SBI request includes an SBI service access request from a first consumer NF, and the access token authorization client proxy is configured to enable the first consumer NF to access a service provided by the first producer NF using the first access token by generating an SBI service request based on proxy discovery and NF selection performed in response to the SBI service access request, inserting the first access token into the SBI service request, forwarding the SBI service request including the first access token to the first producer NF, receiving an SBI service response from the first producer NF, and forwarding the SBI service response to the first consumer NF.

[0031] According to another aspect of the subject matter described herein, a system for delegated authorization at an SCP includes an access token authorization server proxy for receiving an access token request from a second consumer NF or a second SCP, and for signaling with the second consumer NF or a second SCP and the second producer NF to act as an access token authorization server on behalf of an NF Repository Function (NRF) that does not support access token authorization in response to the access token request from the second consumer NF to enable the second consumer NF to access a service provided by the second producer NF.

[0032] According to another aspect of the subject matter described herein, the access token authorization server proxy, when operating as an access token authorization server, is configured to generate a second access token in response to the access token request and send an access token response including the second access token to the second consumer NF or the second SCP.

[0033] According to another aspect of the subject matter described in this specification, the access token authorization server proxy is configured to perform signal communication with a second consumer NF or a second SCP and a second producer NF by receiving a second SBI service request including a second access token from the second consumer NF or the second SCP, removing the second access token from the second SBI service request, forwarding the SBI service request to the second producer NF, receiving an SBI service response from the second producer NF, and forwarding the SBI service response to the second consumer NF or the second SCP, to enable the second consumer NF to access a service provided by the second producer NF.

[0034] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having stored thereon executable instructions that, when executed by a processor of a computer, control the computer to perform steps including intercepting a service-based interface (SBI) request from a consumer network function (NF) that does not support access token-based authorization, the steps further including operating as an access token authorization client proxy to obtain a first access token on behalf of a first consumer NF, and using the first access token to enable the consumer NF to access a service provided by a producer NF that requires access token-based authorization.

[0035] The subject matter described herein may be implemented in a combination of software, hardware, and / or firmware. For example, the subject matter described herein may be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a processor of a computer, control a computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform or distributed across multiple devices or computing platforms. [Brief explanation of the drawings]

[0036] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Figure 2A]FIG. 1 is a message flow diagram illustrating exemplary messages exchanged when accessing services in a 5G communications network using the OAuth 2.0 authorization framework, where the message flow is for indirect inter-PLMN communication without proxy discovery (Model C). [Figure 2B] FIG. 1 is a message flow diagram illustrating exemplary messages exchanged when accessing services in a 5G communications network using the OAuth 2.0 authorization framework, where the message flow is for indirect inter-PLMN communication with surrogate discovery (Model D). [Figure 3A] FIG. 10 is a message flow diagram illustrating exemplary messages exchanged when a consumer NF does not support OAuth 2.0 authorization and a producer NF requires OAuth 2.0 authorization as a condition for granting access to services provided by the producer NF, the message flow being for indirect inter-PLMN communication without proxy discovery (Model C). [Figure 3B] FIG. 10 is a message flow diagram showing exemplary messages exchanged when a consumer NF supports OAuth 2.0 authorization and the NRF does not support OAuth 2.0 authorization, the message flow being for indirect inter-PLMN communication without proxy discovery (Model C). [Figure 3C] FIG. 10 is a message flow diagram showing exemplary messages exchanged when a consumer NF supports OAuth 2.0 authorization and the NRF does not support OAuth 2.0 authorization, the message flow being for indirect inter-PLMN communication with proxy discovery (Model D). [Figure 4] FIG. 10 is a message flow diagram illustrating delegated OAuth 2.0 authorization when an SCP acts as an OAuth 2.0 authorization client proxy on behalf of a consumer NF that does not support OAuth 2.0 authorization; the message flow is for indirect inter-PLMN communication with delegated discovery (Model D). [Figure 5A]FIG. 10 is a message flow diagram showing example messages exchanged when an SCP acts as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization, the message flow is for indirect inter-PLMN communication without proxy discovery (Model C). [Figure 5B] FIG. 10 is a message flow diagram showing exemplary messages exchanged when an SCP acts as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization, the message flow being for indirect inter-PLMN communication with proxy discovery (Model D). [Figure 6] FIG. 10 is a block diagram illustrating an SCP that can perform proxy OAuth 2.0 authorization on behalf of an NF service consumer and an NRF that do not support OAuth 2.0 authorization. [Figure 7A] 10 is a flowchart illustrating an example process for performing delegated OAuth 2.0 authorization on behalf of a consumer NF that does not support OAuth 2.0 authorization. [Figure 7B] 7B is a flowchart illustrating in more detail the steps from FIG. 7A acting as an access token authorization client proxy on behalf of a consumer NF that does not support OAuth 2.0 authorization; [Figure 7C] FIG. 7B is a flowchart illustrating in more detail the steps from FIG. 7A of using an access token to enable a consumer NF that does not support OAuth 2.0 authorization to access a service provided by a producer NF that requires OAuth 2.0 authorization. [Figure 8A] 10 is a flowchart illustrating an example process for acting as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization to facilitate access to a service when a consumer NF supports OAuth 2.0 authorization and a producer NF does not support OAuth 2.0 authorization. [Figure 8B]8B is a flowchart illustrating in more detail the steps from FIG. 8A acting as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization. [Figure 8C] 8B is a flowchart illustrating in more detail the steps from FIG. 8A of signaling communication with a producer NF and a consumer NF to enable the consumer NF to access a service provided by the producer NF when the consumer NF supports OAuth 2.0 authorization and the producer NF does not support OAuth 2.0 authorization. DETAILED DESCRIPTION OF THE INVENTION

[0037] Detailed Description Figure 1 is a block diagram illustrating an example 5G system network architecture. The architecture of Figure 1 includes an NRF 100 and an SCP 101, which may be located in the same home public land mobile network (HPLMN). As described above, the NRF 100 maintains profiles of available producer NF service instances and their supported services and may enable consumer NFs or SCPs to subscribe to new / updated producer NF service instances and be notified of their registration. The SCP 101 may also support service discovery and selection of producer NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

[0038] The NRF 100 is a repository for the NF or service profile of a producer NF instance. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF or service profile of the producer NF instance from the NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS 29.510. The NF or service profile definition includes at least one of a fully qualified domain name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address.

[0039] 1, any of the network functions can be a consumer NF, a producer NF, or both, depending on whether they are requesting, providing, or requesting and providing a service. In the illustrated example, the NFs include a PCF 102 that performs policy-related operations in the network, a UDM function 104 that manages user data, and an application function (AF) 106 that provides application services.

[0040] 1 further includes a Session Management Function (SMF) 108 that manages sessions between an Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in 4G networks. An Authentication Server Function (AUSF) 112 performs authentication services for user equipment (UE), such as user equipment (UE) 114, seeking access to the network.

[0041] The Network Slice Selection Function (NSSF) 116 provides network slice services for devices that want to access specific network functions and features associated with the network slice. The Network Publish Function (NEF) 118 provides an application programming interface (API) for application functions that want to obtain information about Internet of Things (IoT) devices and other UEs connected to the network. The NEF 118 performs a function similar to the Service Capability Publish Function (SCEF) in 4G networks.

[0042] The radio access network (RAN) 120 connects the user equipment (UE) 114 to the network via wireless links. The radio access network 120 may be accessed using a g-Node B (gNB) (not shown in FIG. 1) or other wireless access point. The user plane function (UPF) 122 may support various proxy functions for user plane services. One example of such a proxy function is a multipath transmission control protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that may be used by the UE 114 to obtain network performance measurements. Also shown in FIG. 1 is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0043] The SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. The SEPP 126 may communicate with a SEPP in a foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

[0044] As mentioned above, one issue that may arise in 5G networks is the lack of universal support for OAuth 2.0 authorization, which may result in service incompatibility between networks. Figure 2A is a message flow diagram illustrating OAuth 2.0 authorization between PLMNs and the use of access tokens to access services across PLMN boundaries. The message flow in Figure 2A is for indirect inter-PLMN communication without delegated discovery, defined as Model C in Appendix E of 3GPP TS 23.501. According to the Model C specification, a consumer NF performs discovery by querying the NRF. Based on the discovery results, the consumer NF selects a producer NF or set of NFs. The consumer NF then sends an SBI service request to the SCP, including the address of the selected producer NF or set of producer NFs. If the service request specifies a set of NFs, the SCP can interact with the NRF to obtain selection parameters such as location and capacity and use these parameters to select a producer NF instance. The SCP routes the SBI service request to the selected producer NF instance.

[0045] Referring to the message flow of FIG. 2A , in line 1, the consumer NF 200 performs NF discovery and selects a producer NF instance or set of NFs by signaling with the NRF 100B via the SCPs 101A and 101B and the SEPPs 126A and 126B. In line 2, after selecting the producer NF or set of NFs, the consumer NF 200 sends an Nnrf access token request message to the NRF 100A located in the visited network (a network local to the visited PLMN to which the UE that triggered the access token request is currently roaming). The NRF 100A forwards the access token request message to the remote NRF 100B via the SCPs 101A and 101B and the SEPPs 126A and 126B. This forwarding is indicated by lines 2 through 6 in FIG. 2A .

[0046] The home NRF 100B determines whether the client is authorized to receive the access token and returns the access token by sending an access token response message. In lines 7-11, the access token response message is communicated to the consumer NF 200 via the SCPs 101A and 101B, the SEPPs 126A and 126B, and the NRF 100A.

[0047] The consumer NF 200 generates an SBI service request message including the access token, as shown by lines 12-14, and sends the SBI service request message to the producer NF 202 via the SCPs 101A and 101B and the SEPPs 126A and 126B. The SBI service request message includes the access token. The SBI request may optionally include a Client Identity Assertion (CCA) attribute, as shown by "CCA*" in FIG. 2A.

[0048] The producer NF 202 verifies the access token and grants the consumer NF 200 access to the service. In lines 15-17, the producer NF 202 returns an SBI service response message to the consumer NF 200. A similar flow occurs when the consumer NF resides in a home network and the producer NF resides in a visitor or non-home network. Thus, FIG. 2A illustrates a case where two different networks support OAuth 2.0 authorization and indirect inter-PLMN communication via an SCP, resulting in successful access token messaging and service request messaging. However, if one or the other network does not support OAuth 2.0 authorization, the service request messaging and / or access token messaging will not be successful.

[0049] FIG. 2B is a message flow diagram illustrating indirect inter-PLMN communication and OAuth 2.0 authorization with proxy discovery. Indirect communication with proxy discovery is defined as Model D in Appendix E of 3GPP TS 23.501. According to Model D, the consumer NF does not perform NF selection or discovery. Instead, the consumer NF adds the required discovery and selection parameters to the discovery request sent to the SCP. The SCP then performs discovery with the NRF, obtains the discovery result, and sends an SBI service request to the selected NF. Referring to the message flow of FIG. 2B, in line 1, the consumer NF 200 sends an SBI service access request message to the SCP 101A along with the discovery parameters and producer NF selection parameters. In line 2, the SCP 101A performs discovery with the NRF 101B. The result of the discovery is the selection of a producer NF 202 to process the service request message. However, before sending the service request message to the producer NF 202, the SCP 101A must obtain an access token from the NRF 100B in the network of the producer NF 202. Thus, in line 3, the SCP 101A sends an access token request message to the local NRF 100A. The local NRF 100A forwards the access token request message to the remote NRF 100B via the SCPs 101A and 101B and the SEPPs 126A and 126B, as shown by lines 4-6 in the message flow diagram.

[0050] NRF 100B determines whether the client is authorized and returns an access token via SCPs 101B and 101A and SEPPs 126B and 126A. The return of the access token is shown via lines 7-10 of the message flow in Figure 2B.

[0051] In lines 11 and 12, SCP 101A sends an SBI service request message via SEPPs 126A and 126B and SCP 101B to producer NF 202 selected during the proxy discovery procedure represented by line 2. Producer NF 202 verifies the access token and in lines 13-15 sends an SBI service response to consumer NF 200 via its SCPs 101B and 101A and SEPPs 126B and 126A. The SBI service response communicated to consumer NF 200 may optionally include the access token, as indicated by "Access Token**" in FIG. 2B .

[0052] A similar flow occurs when the consumer NF is in a home network and the producer NF is in a visited network. Thus, Figure 2B shows the case where the SCP serving the consumer NF and the NRF in the network of the producer NF support OAuth 2.0 authorization and indirect inter-PLMN communication with proxy discovery is performed.

[0053] FIG. 3A illustrates the case of inter-PLMN indirect communication without proxy discovery, where the NF service consumer does not support OAuth 2.0 authorization and the NF service producer requires OAuth 2.0 authorization. Referring to FIG. 3A, because the visited network in this example does not support OAuth 2.0 authorization, no inter-PLMN signaling occurs to obtain an access token from lines 1-11 in FIG. 2A. The message flow in FIG. 3A begins at line 1, where the consumer NF 200 sends an SBI service request message without an access token to the producer NF 202, which is located in a different PLMN and requires access token authorization. Because the service request does not include an access token, the service request at line 2 is rejected by the home SEPP 126B. Because section 13.4.1.2.2 of 3GPP TS 33.501 suggests that the provider SEPP check that the serving PLMN of the subject claim in the access token matches the remote PLMN corresponding to the N32-f context ID in the N32 message, SEPP 126B rejects the service request. Because the service request message on line 2 does not include an access token, there is no subject claim for SEPP 126B to verify, and the message is therefore rejected.

[0054] 3A illustrates a case of indirect inter-PLMN communication without proxy discovery in which a consumer NF does not support OAuth 2.0 authorization and a producer NF supports OAuth 2.0 authorization, and FIG. 3B illustrates a case of indirect inter-PLMN communication without proxy discovery in which a consumer NF supports OAuth 2.0 authorization and an NRF in the network of the producer NF does not. Referring to the message flow in FIG. 3B, on line 1, a consumer NF 300 located in a home network performs service discovery by signaling with an NRF 100A located in a visited network. In this example, it is assumed that the result of the service discovery is the selection of a producer NF 302 located in the visited network to provide the requested service.

[0055] After service discovery, in line 2, the consumer NF 300 sends an access token request message to the SCP 101B located in the home network. In line 3, the SCP 101B sends the access token request to the NRF 100B. In line 4, the NRF 100B forwards the access token request to the SCP 101B, and in line 5, routes the access token request to the remote SCP 101A. In line 6, the SCP 101A routes the access token request to the NRF 100A located in the visitor network. In this example, the visitor NRF 100A does not support OAuth 2.0 authorization. Therefore, the visitor NRF 100A cannot respond to the access token request, resulting in a failure of the access token messaging. As a result, the consumer NF 300 may not be able to access services provided by the visitor network.

[0056] Figure 3C shows the case of indirect inter-PLMN communication with proxy discovery, where the consumer NF supports OAuth 2.0 authorization and the producer NF does not. Referring to the message flow in Figure 3C, in line 1, the consumer NF 300 located in the home network sends a service access request with discovery parameters to the SCP 101B. In line 2, the SCP 101B performs service discovery by signaling with the NRF 100A located in the visited network. In this example, it is assumed that the result of the service discovery is the selection of the producer NF 302 located in the visited network to provide the requested service.

[0057] After service discovery, in line 3, the SCP 101B sends an access token request to the NRF 100B. In line 4, the NRF 100B forwards the access token request to the SCP 101B, and in line 5, the NRF 100B routes the access token request to the remote SCP 101A. In line 6, the SCP 101A routes the access token request to the NRF 100A located in the visitor network. In this example, the visitor NRF 100A does not support OAuth 2.0 authorization. Therefore, the visitor NRF 100A cannot respond to the access token request, resulting in a failure of the access token messaging. As a result, the consumer NF 300 may not be able to access services provided by the visitor network.

[0058] To avoid these difficulties, the SCP described herein acts as an access token authorization client proxy on behalf of consumer NFs that do not support access token-based authorization, and as an access token authorization server on behalf of NRFs that do not support access token-based authorization. For consumer NFs that do not support access token-based authorization, the SCP fetches the access token and adds it to the SBI request before forwarding the SBI request to the producer NF. The SCP may choose to cache the token to speed up processing. The SCP may utilize fields from the User-Agent header provided by the consumer NF in the SBI service or SBI service access request to obtain the NF type and NF instance ID used to create the access token request on behalf of the consumer NF. When the SCP acts as an OAuth 2.0 authorization server, the SCP issues an access token to the requesting consumer NF or SCP, depending on whether delegated discovery is performed.

[0059] Figure 4 shows the case of indirect inter-PLMN communication with proxy discovery, in which the SCP acts as an OAuth 2.0 authorization client proxy on behalf of a consumer NF that does not support OAuth 2.0 authorization. Referring to Figure 4, in line 1 of the message flow diagram, the consumer NF 200 sends an SBI service access request to the SCP 101A without an access token. In line 2, the SCP 101A performs proxy discovery on behalf of the consumer NF 200 through signaling with the NRF 100B, and the result of the proxy discovery is the selection of the producer NF 202.

[0060] Rather than generating an SBI service request in response to the service access request on line 1, the SCP 101A detects that the service access request does not include an access token, intercepts and stores the service access request, and fetches the access token on behalf of the consumer NF 200. The process of fetching the access token begins on line 3 of the message flow diagram, where the SCP 101A formulates an access token request and sends it to the SCP 101B, which routes the access token request to the NRF 100B, located within the PLMN of the producer NF 202, on line 4. The formulation of the access token request message is described in further detail below. The NRF 100B validates the consumer NF 200, generates an access token response including the access token, and transmits the access token response to the network of the consumer NF 200 via the SEPPs 126B and 126A and the SCP 101B on lines 5 and 6.

[0061] SCP101A receives the access token response, extracts the access token from the response, generates an SBI service request based on the SBI service access request received on line 1, and inserts the access token into the generated SBI service request. On lines 7 and 8, SCP101A forwards the SBI service request together with the access token to producer NF202. Producer NF202 validates the service request using the access token, and on lines 9-11 generates an SBI service response message and sends it to consumer NF200. Thus, Figure 4 shows the case where SCP101A acts as an OAuth 2.0 authorization client proxy on behalf of a consumer NF that does not support OAuth 2.0 authorization.

[0062] In another example, the SCP 101A may function as an access token authorization server. One such example is shown in FIG. 5A, which illustrates indirect inter-PLMN communication without proxy discovery, in which a consumer NF 300 located in a home network and that does not support OAuth 2.0 authorization attempts to access a service provided by a producer NF 302 located in a visited network. Referring to FIG. 5A, in line 1, the consumer NF performs service discovery by signaling with the NRF 100A, and the result of the service discovery is the selection of a producer NF 302 to provide the service.

[0063] In line 2, the consumer NF300 generates an access token request message and forwards the access token request to the SCP 101B. In line 3, the SCP 101B forwards the access token request to the NRF 100B. The NRF 100B forwards the access token request message to the NRF 100A in lines 4 and 5. However, the NRF 100A does not support OAuth 2.0 authorization. Therefore, instead of forwarding the access token request to the NRF 100A, the SCP 101A intercepts the access token request message and generates an access token response message on behalf of the NRF 100A. The access token response message includes an access token generated by the SCP 101A using information local to the SCP 101A. The access token may be syntactically correct in that it includes all of the required access token claims. In lines 6 to 9, the SCP 101A forwards the access token response to the consumer NF300.

[0064] At line 10, the consumer NF300 generates an SBI service request and sends it to the producer NF302 via the SCPs 101B and 101A and the SEPPs 126B and 126A, where the service request includes an access token. At line 11, the SCP 101A intercepts the SBI service request and removes the access token from the service request because the producer NF302 does not support OAuth 2.0 authorization. At line 12, the SCP 101A forwards the service request (without the access token) to the producer NF302. At lines 13 to 15, the producer NF302 generates an SBI service response message and sends it to the consumer NF300. Thus, FIG. 5A shows the case where the SCP 101A acts as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization.

[0065] 5A illustrates a case in which an SCP acts as an OAuth 2.0 authorization server for indirect inter-PLMN communication without proxy discovery, and FIG. 5B illustrates a case in which an SCP acts as an OAuth 2.0 authorization server for indirect inter-PLMN communication with proxy discovery. Referring to FIG. 5B, in line 1 of the message flow diagram, a consumer NF 300 located in the home network sends a service access request message with discovery parameters to the SCP 101B. In line 2, the SCP 101B performs proxy NF discovery and selection by signaling with an NRF 100A located in the visited network. The result of proxy discovery and NF selection is the selection of a producer NF 302 located in the visited network to provide the requested service.

[0066] After performing proxy discovery and NF selection, SCP 101B generates an access token request message and forwards it to NRF 100B on line 3. NRF 100B forwards the access token request message to NRF 100A on lines 4 and 5. However, NRF 100A does not support OAuth 2.0 authorization. Instead of forwarding the access token request to NRF 100A, SCP 101A intercepts the access token request and generates an access token response on behalf of NRF 100A. The access token response includes an access token generated by SCP 101A using information local to SCP 101A. The access token may be syntactically correct in that it includes all of the required access token claims. On lines 6-8, SCP 101A forwards the access token response to SCP 101B.

[0067] At line 9, the SCP 101B generates an SBI service request and sends it to the producer NF 302 via the SEPPs 126B and 126A and the SCP 101A, where the service request includes the access token. The SCP 101A intercepts the SBI service request and removes the access token from the service request because the producer NF 302 does not support OAuth 2.0 authorization. At line 10, the SCP 101A forwards the service request (without the access token) to the producer NF 302. At lines 11 to 13, the producer NF 302 generates an SBI service response message and sends it to the consumer NF 300. Thus, FIG. 5B shows the case where the SCP 101A performs delegation discovery and NF selection and acts as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization.

[0068] Figure 6 is a block diagram illustrating an example architecture of an SCP supporting OAuth 2.0 authorization proxying as described herein. Referring to Figure 6, SCP 101A includes at least one processor 600 and memory 602. SCP 101A further includes an access token authorization client proxy 604 for performing the operations described above with respect to Figure 4 for the delegated discovery example, obtaining an OAuth 2.0 access token on behalf of a consumer NF that does not support OAuth 2.0 authorization and generating an SBI service request message including the OAuth 2.0 access token to enable the consumer NF to access a service provided by a producer NF that supports OAuth 2.0 authorization. In the case of non-delegated discovery, access token authorization client proxy 604 may obtain an OAuth 2.0 access token and insert it into an SBI service request message from a consumer NF that does not support OAuth 2.0 authorization.

[0069] SCP 101A further includes an access token authorization server proxy 606 that performs the functions of an OAuth 2.0 authorization server on behalf of an NRF that does not support OAuth 2.0 authorization, as described above with respect to Figures 5A and 5B. The access token authorization server proxy 606 may also remove access tokens from service request messages addressed to producer NFs that do not support access token-based authorization. The access token authorization client proxy 604 and the access token authorization server proxy 606 may be implemented using computer-executable instructions stored in memory 602 that cause the processor 600 to perform the access token authorization client and server proxying operations described above.

[0070] 7A is a flowchart illustrating an example overall process for performing delegated authorization at an SCP, where the SCP functions as an access token authorization client proxy. Referring to FIG. 7A, in step 700, the process includes intercepting an SBI request from a consumer NF that does not support access token-based authorization to access a service provided by a producer NF that requires access token-based authorization. For example, in the case of indirect inter-PLMN communication without delegated discovery, the SCP 101A may receive an SBI service request from the consumer NF to access a service provided by the producer NF 202. In the case of indirect inter-PLMN communication with delegated discovery, the SCP 101A may receive a service access request from the consumer NF.

[0071] In step 702, the process includes acting as an access token authorization client proxy to obtain an access token on behalf of a consumer NF. For example, the SCP 101A may act as an OAuth 2.0 authorization client proxy to obtain an access token on behalf of a consumer NF that does not support OAuth 2.0 authorization. Figure 7B shows further details of step 702 of Figure 7A. Referring to Figure 7B, in step 702A, the process includes generating an access token request message on behalf of the consumer NF. Table 1 below shows the attributes that must be included in the access token request message.

[0072] [Table 1]

[0073] The minimum set of attributes that must be included in the access token request are authorization type, NF instance ID, NF type, target NF type, range, requesting PLMN, and target PLMN. The authorization type attribute may be obtained from the consumer NF identity populated from the SBI service request or service access request message. The NF instance ID may be populated from the user agent header of the SBI service request or service access request message. According to section 5.2.2 of 3GPP TS 29.500, the user agent header is a mandatory header in the SBI service request message. Table 2 below shows the structure of the user agent parameter.

[0074] [Table 2]

[0075] As shown in Table 2, the user agent parameter may include information that identifies the NF instance, such as an NF instance ID. SCP 101A may extract the NF instance ID from the user agent header of the SBI request message (i.e., a service access request message for delegated discovery or a service request message for non-delegated discovery) and use that information to populate the NF instance ID attribute of the access token request message. Similarly, the NF type may also be obtained from the user agent header of the SBI request message.

[0076] Returning to Table 1, the requesting PLMN of the access token request may be populated based on the configured requesting PLMN parameter of SCP 101A. The target PLMN attribute may be populated from the API name extracted from the requesting uniform resource identifier (R-URI) of the SBI request message. The scope attribute of the access token request may be populated from the service name extracted from the R-URI of the SBI request message.

[0077] 7B, once the access token request is formulated, in step 702B, the SCP 101A sends the access token request to the NRF 100B. For example, the SCP 101A may send an access token request message to the NRF 100B located in the PLMN in which the producer NF is located.

[0078] In step 702C, the process includes receiving an access token response from the NRF, the access token response including the access token. For example, the SCP 101A may receive an access token response from the NRF 100B, the access token response including the access token.

[0079] Returning to FIG. 7A , in step 704, the process includes enabling the consumer NF to access a service provided by the producer NF using the access token. FIG. 7C shows further details of step 704 of FIG. 7A . Referring to FIG. 7C , the process differs slightly depending on whether a delegated or non-delegated discovery was performed. If a delegated discovery was performed, control proceeds to step 704A1, where the process includes generating an SBI service request message in response to a previously received service access request and inserting the access token obtained on behalf of the consumer NF in step 702 into the SBI service request message. For example, the SCP 101A can generate an SBI service request directed to the producer NF identified in the delegated discovery procedure and insert the access token it obtained from the NRF 100B into the SBI service request message. In step 704B1, the process includes forwarding the SBI service request, including the access token, to the producer NF. For example, the SCP 101A can forward the SBI service request, including the access token, to the producer NF identified in the proxy discovery procedure. The producer NF then authorizes the service request using the access token and responds to the service request. The SCP 101A forwards the response to the consumer NF 200 that sent the service access request.

[0080] If delegated discovery is not performed, control proceeds to step 704A2, where the SCP 101A inserts the access token into the previously received SBI service request. The message flow for the non-delegated discovery case is similar to that shown in FIG. 4, except that the message received in line 1 is an SBI service request rather than an SBI service access request, and discovery has already been performed. The delegated discovery messaging in line 2 of FIG. 4 is not required. The remaining steps for the non-delegated discovery case are the same as those shown in FIG. 4. Thus, in step 704B2, the SCP 101A forwards the SBI service request, including the access token, to the producer NF. Upon receiving a response from the producer NF, the SCP 101A forwards the response to the consumer NF. Thus, FIGS. 7A-7C illustrate delegated authorization by the SCP, where the SCP acts as an access token authorization client proxy, which in the example described herein is an OAuth 2.0 authorization client proxy.

[0081] 8A illustrates an exemplary delegated authorization process performed by an SCP acting as an access token authorization server proxy on behalf of an NRF that does not support access token-based authorization. Referring to FIG. 8A, the process includes, in step 800, receiving an access token request from a consumer NF in the case of non-delegated discovery, or from a remote SCP on behalf of the consumer NF in the case of delegated discovery. For example, SCP 101A may receive the access token request from consumer NF 300 in the case of non-delegated discovery (see FIG. 5A) or from SCP 101B in the case of delegated discovery (see FIG. 5B).

[0082] In step 802, the process includes operating as an access token authorization server proxy on behalf of an NRF that does not support access token-based authorization in response to an access token request. Step 802 is shown in more detail in FIG. 8B. Referring to FIG. 8B, in step 802A, the process includes generating an access token in response to the access token request. For example, the SCP 101A may generate an access token that includes required claims specified in IETF RFC 6749. The access token may be syntactically correct according to the format and content specified in IETF RFC 6749. However, as described below, the access token need not be an actual access token but may be a dummy access token with syntactically correct fields because the SCP 101A will remove the access token from the service request message before forwarding it to a producer NF that does not support access token-based authorization.

[0083] In step 802B, the process includes sending the access token response to the consumer NF or SCP. For example, SCP 101A can send the access token response it generated in step 802A to the requesting consumer NF in the case of non-delegated discovery, or to the remote SCP in the case of delegated discovery.

[0084] Returning to Figure 8A, in step 804, the process includes signaling with the producer NF and the consumer NF or SCP to enable the consumer NF to access the service. Step 804 is shown in more detail in Figure 8C. Referring to Figure 8C, the process of signaling with the producer NF and the consumer NF or SCP includes receiving an SBI service request from the consumer NF or SCP, the SBI service request including the access token. For example, the SCP 101A can receive an SBI service request from the NF service consumer 300, the SBI service request including the NF access token generated by the SCP 101A (in the case of non-delegated discovery), or from the SCP 101B in the case of delegated discovery.

[0085] In step 804B, the process includes removing the access token from the SBI service request. In step 804C, the process includes forwarding the SBI service request to the producer NF. For example, the SCP 101A can remove the access token it generated from the SBI service request and forward the SBI service request to the producer NF. Thus, Figures 8A-8C show example steps that may be performed by an SCP when acting as an access token authorization server proxy and signaling intermediary on behalf of an NRF that does not support access token-based authorization.

[0086] Example advantages of the subject matter described herein include improved interoperability between PLMNs where one PLMN supports access token-based authorization and another does not. Providing this solution in an SCP is beneficial because the SCP handles messaging on behalf of multiple consumer NFs. It is also a scalable solution because a single SCP can perform the functions described herein for or on behalf of consumer NFs and producer NFs.

[0087] The disclosure of each of the following references is incorporated herein by reference in its entirety. reference 1. Hardt, D. "The OAuth 2.0 Authorization Framework," IETF RFC 6749 (October 2012). 2. 3GPP TS 33.501 V17.0.0 (2020-12), 3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 17). 3. 3GPP TS 29.500 V17.1.0 (2020-12); 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of the Service Based Architecture; Stage 3 (Release 17). 4. 3GPP TS 29.510 V17.0.0 (2020-12); 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17). 5. 3GPP TS 23.501 V16.7.0 (2020-12); 3 rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16). It will be understood that various details of the subject matter described herein can be changed without departing from the scope of the subject matter described herein. Moreover, the foregoing description is by way of example only, and not by way of limitation, since the subject matter described herein is defined by the claims set forth below.

Claims

1. A method for delegated authorization in a service communication proxy (SCP), comprising: A first SCP, including at least one processor and a memory, located in a visitor network, intercepts a service-based interface (SBI) request from a first consumer network function (NF) located in the visitor network, the first consumer network function (NF) not supporting access token-based authorization; the first SCP acting as an access token authorization client proxy to obtain a first access token on behalf of the first consumer NF; Acting as the access token authorization client proxy to obtain the first access token comprises: generating an access token request on behalf of the first consumer NF; sending the access token request to a NF Repository Function (NRF) located in a home network; receiving an access token response from the NRF, the access token response including the first access token, the method further comprising: and wherein the first SCP uses the first access token to enable the first consumer NF to access a service provided by a first producer NF that requires access token-based authorization.

2. 2. The method of claim 1, wherein generating the access token request includes extracting values ​​of at least some attributes to be included in the access token request from a user-agent header of the SBI request.

3. The method of claim 2 , wherein extracting values ​​of at least some of the attributes includes extracting an NF instance ID of the first consumer NF from the User-Agent header of the SBI request.

4. Intercepting the SBI request includes receiving an SBI service request from the first consumer NF, and enabling the first consumer NF to access the service provided by the first producer NF using the first access token: Inserting the first access token into the SBI service request; forwarding the SBI service request including the first access token to the first producer NF; receiving an SBI service response from the first producer NF; and forwarding the SBI service response to the first consumer NF.

5. Intercepting the SBI request includes receiving an SBI service access request from the first consumer NF, and enabling the first consumer NF to access the service provided by the first producer NF using the first access token: generating an SBI service request based on proxy discovery and NF selection performed in response to the SBI service access request; Inserting the first access token into the SBI service request; forwarding the SBI service request including the first access token to the first producer NF; receiving an SBI service response from the first producer NF; and forwarding the SBI service response to the first consumer NF.

6. The first SCP receiving an access token request from a second consumer NF or a second SCP; the first SCP acting as an access token authorization server proxy on behalf of an NF Repository Function (NRF) that does not support access token authorization in response to the access token request from the second consumer NF or the second SCP; The method of any one of claims 1 to 5, comprising: the first SCP performing signaling communication with the second consumer NF or the second SCP and the second producer NF to enable the second consumer NF to access services provided by the second producer NF.

7. The operation of the access token authorization server proxy includes: generating a second access token in response to the access token request; and sending an access token response including the second access token to the second consumer NF or the second SCP.

8. performing signaling communication with the second producer NF to enable the second consumer NF to access the service provided by the second producer NF; receiving a second SBI service request from the second consumer NF or the second SCP, the second SBI service request including a second access token; removing the second access token from the second SBI service request; forwarding the second SBI service request to the second producer NF; receiving an SBI service response from the second producer NF; and forwarding the SBI service response to the second consumer NF or the second SCP.

9. 1. A system for delegated authorization in a service communication proxy (SCP), comprising: a first SCP including at least one processor and memory and located in a visited network; The first SCP Intercepting a service-based interface (SBI) request from a first consumer network function (NF) located in the visitor network, the first consumer network function (NF) not supporting access token-based authorization; acting as an access token authorization client to obtain a first access token on behalf of said first consumer NF; Acting as the access token authorization client proxy to obtain the first access token comprises: generating an access token request on behalf of the first consumer NF; sending the access token request to a NF Repository Function (NRF) located in a home network; receiving an access token response from the NRF, the access token response including the first access token; The system, wherein the first SCP uses the first access token to enable the first consumer NF to access a service provided by a first producer NF that requires access token-based authorization.

10. A computer readable program for causing a processor to execute the method according to any one of claims 1 to 8.

Images