Method, system, and computer-readable medium for delegated authorization in a security edge protection proxy (SEPP)

Abstract

A method for delegating authorization in a security edge protection proxy (SEPP) includes intercepting a service-based interface (SBI) service request for accessing a service provided by a producer NF that requires access token-based authorization 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 enabling the consumer NF to access the service provided by the first producer NF using the first access token. The SEPP may also operate 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,740, 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 a SEPP. [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 public 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 security edge protection proxy (SEPP) includes intercepting a first service-based interface (SBI) service request from a first consumer network function (NF) that does not support access token-based authorization to access a service provided by a first producer NF that requires 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 the service provided by the first producer NF.

[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 first SBI service request.

[0017] According to another aspect of the subject matter described in this specification, 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 first SBI service request.

[0018] According to another aspect of the subject matter described herein, enabling a first consumer NF to access a service provided by a first producer NF using a first access token includes inserting the first access token into a first SBI service request, forwarding the first 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 herein, a method for delegated authorization in an SEPP includes receiving an access token request from a second consumer NF; operating 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; and performing signaling communication with the second consumer NF and the second producer NF to enable the second consumer NF to access a service provided by the second producer NF.

[0020] 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 to the second consumer NF, the access token response including the second access token.

[0021] According to another aspect of the subject matter described in this specification, signaling with the second producer NF to enable the 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.

[0022] 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.

[0023] According to another aspect of the subject matter described herein, there is provided a system for delegated authorization in a security edge protection proxy (SEPP). The system includes an SEPP 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 first service-based interface (SBI) service request from a first consumer network function (NF) that does not support access token-based authorization to access a service provided by a first producer NF that requires 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 enable the first consumer NF to access the service provided by the first producer NF using the first access token.

[0024] 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.

[0025] 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.

[0026] According to another aspect of the subject matter described in this specification, the access token authorization client proxy is configured to generate an 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 first SBI service request.

[0027] 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 first SBI service request.

[0028] According to another aspect of the subject matter described in this specification, the access token authorization client proxy is configured to enable a first consumer NF to access a service using a first access token by inserting the first access token into a first SBI service request, forwarding the first 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.

[0029] According to another aspect of the subject matter described herein, a system for delegated authorization in a SEPP includes an access token authorization server proxy for receiving an access token request from a second consumer NF, and for signaling with the second consumer NF 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 and enable the second consumer NF to access a service provided by the second producer NF.

[0030] According to another aspect of the subject matter described in this specification, the access token authorization server proxy, when operating as the 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 to the second consumer NF, the access token response including the second access token.

[0031] 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 and a second producer NF by receiving a second SBI service request from the second consumer NF, the second SBI service request including the second access token, 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, 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, a non-transitory computer-readable medium having stored thereon executable instructions that, when executed by a processor of a computer, control a computer to perform steps including intercepting a service-based interface (SBI) service request from a consumer network function (NF) that does not support access token-based authorization to access a service provided by a producer NF that requires 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 enabling the consumer NF to access the service provided by the producer NF using the first access token.

[0033] The subject matter described herein may be implemented in software in combination with 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]

[0034] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Figure 2] A message flow diagram showing example messages exchanged when accessing a service in a 5G communication network using the OAuth 2.0 authorization framework. [Figure 3] FIG. 10 is a message flow diagram illustrating example 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 a service provided by the producer NF. [Figure 4] FIG. 10 is a message flow diagram illustrating example messages exchanged when a consumer NF supports OAuth 2.0 authorization and an NRF does not support OAuth 2.0 authorization. [Figure 5]FIG. 10 is a message flow diagram illustrating proxy OAuth 2.0 authorization when a SEPP acts as an OAuth 2.0 authorization client proxy on behalf of a consumer NF that does not support OAuth 2.0 authorization. [Figure 6] FIG. 10 is a message flow diagram illustrating example messages exchanged when a SEPP acts as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization. [Figure 7] FIG. 10 is a block diagram illustrating a SEPP 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 8A] 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 8B] 8B is a flowchart illustrating in more detail the steps from FIG. 8A acting as an access token authorization client proxy on behalf of a consumer NF that does not support OAuth 2.0 authorization. [Figure 8C] 8B is a flowchart illustrating in more detail the steps from FIG. 8A 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 9A] 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 9B] 9B is a flowchart illustrating in more detail the steps from FIG. 9A acting as an OAuth 2.0 authorization server proxy on behalf of an NRF that does not support OAuth 2.0 authorization. [Figure 9C]9B is a flowchart illustrating in more detail the steps from FIG. 9A of signaling communication between a producer NF and a consumer NF to enable the consumer NF to access services 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

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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 2 is a message flow diagram illustrating OAuth 2.0 authorization between PLMNs and the use of access tokens to access services across PLMN boundaries. Referring to the message flow in Figure 2, on line 1, the consumer NF 200 sends an intra-NRF access token request message to the NRF 100A located in the visitor network. The NRF 100A forwards the access token request message to the remote NRF 100B via the SEPPs 126A and 126B. This forwarding is indicated by lines 2-4 in Figure 2.

[0043] In line 5, 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 5-7, the access token response message is communicated to the consumer NF 200.

[0044] At line 9, the consumer NF 200 generates an SBI service request message including the access token, and sends the SBI service request message to the producer NF 202 via the SEPPs 126A and 126B, as shown by lines 9-11.

[0045] The producer NF 202 verifies the access token and grants the consumer NF 200 access to the service. In lines 12-14, the producer NF 202 returns an SBI service response message to the consumer NF 200. Thus, FIG. 2 illustrates a case where two different networks support OAuth 2.0 authorization, 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.

[0046] Figure 3 illustrates a case where an NF service consumer does not support OAuth 2.0 authorization and an NF service producer requires OAuth 2.0 authorization. Referring to Figure 3, in line 1, a consumer NF 200 sends an SBI service request message to a producer NF 202 located in a different PLMN and requiring access token authorization. Because the service request does not include an access token, the service request in line 2 is rejected by the home SEPP 126B. Because section 13.4.1.2.2 of 3GPP TS 33.501 suggests that a provider SEPP checks 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, the SEPP 126B rejects the service request. Because the service request message in line 2 does not include an access token, there is no subject claim for the SEPP 126B to verify, and therefore the message is rejected.

[0047] While FIG. 3 illustrates a case where a consumer NF does not support OAuth 2.0 authorization and a producer NF supports OAuth 2.0 authorization, FIG. 4 illustrates a case where a consumer NF supports OAuth 2.0 authorization and an NRF does not. Referring to the message flow in FIG. 4 , in line 1, a consumer NF 300 located in a home network in this example sends an access token request message to an NRF 100B located in the home network to access a service provided by a producer NF 302 located in the home network. The NRF 100B forwards the access token request message to a remote NRF 100A located in a visitor network. This forwarding is indicated by lines 2 to 4 in the message flow diagram in FIG. 4 . 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 the services provided by the producer NF 302 in the visited network.

[0048] To avoid these difficulties, the SEPP 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 SEPP fetches the access token and adds the access token to the SBI request before forwarding the SBI request to the producer NF. The SEPP may choose to cache the token to speed up processing. The SEPP may use fields from the user-agent header provided by the consumer NF in the SBI service 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 SEPP acts as an OAuth 2.0 authorization server, the SEPP issues an access token to the requesting consumer NF.

[0049] FIG. 5 illustrates a case in which a SEPP 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 FIG. 5 , in line 1 of the message flow diagram, the consumer NF 200 sends an SBI service request message to the producer NF 202, which is located in a different PLMN. The SEPP 126A intercepts the access token request and determines that the request does not have an access token. In line 2 of the message flow diagram, the SEPP 126A formulates and sends the access token request to the NRF 100B, which is located in the PLMN of the producer NF. The formulation of the access token request message is described in further detail below. Lines 2 and 3 of FIG. 5 illustrate forwarding the access token request to the NRF 100B. 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 consumer NF 200's network via the SEPPs 126B and 126A in lines 4 and 5. Instead of forwarding the access token response to the consumer NF 200, the SEPP 126A intercepts the access token response, extracts the access token from the response, and inserts the access token into the SBI service request message received on line 1. On lines 6 and 7, the SEPP 126A forwards the SBI service request along with the access token to the producer NF 202. The producer NF 202 validates the service request using the access token and generates and sends an SBI service response message to the consumer NF 200 on lines 8-10. Thus, FIG. 5 illustrates the case where the SEPP 126A acts as an OAuth 2.0 authorization client proxy on behalf of a consumer NF that does not support OAuth 2.0 authorization.

[0050] In another example, the SEPP 126A may function as an access token authorization server. This example is shown in FIG. 6. Referring to FIG. 6, in line 1, the consumer NF 300 generates an access token request message and forwards the access token request message to the NRF 100B located in the home network. In lines 2 and 3, the NRF 100B forwards the access token request message to the NRF 100A located in the network where the producer NF 302 exists. However, the NRF 100A does not support OAuth 2.0 authorization. Therefore, the SEPP 126A intercepts the access token request message and generates an access token response message on behalf of the NRF 100A in line 4. The access token response message includes an access token generated by the SEPP 126A using information local to the SEPP 126A. The access token may be syntactically correct in that it includes all of the required access token claims. In lines 4 to 6, the SEPP 126A forwards the access token to the consumer NF 300.

[0051] At line 7, the consumer NF300 generates an SBI service request and sends it to the producer NF302, where the service request includes the access token. At line 8, the SEPP126A receives the SBI service request and removes the access token from the service request because the producer NF302 does not support OAuth2.0 authorization. At line 9, the SEPP126A forwards the service request to the producer NF302. At lines 10 to 12, the producer NF202 generates an SBI service response message and sends it to the consumer NF300. Thus, FIG. 6 shows a case where the SEPP126A functions as an OAuth2.0 authorization server proxy on behalf of an NRF that does not support OAuth2.0 authorization.

[0052] FIG. 7 is a block diagram illustrating an example architecture of a SEPP supporting OAuth 2.0 authorization proxying as described herein. Referring to FIG. 7, the SEPP 126A includes at least one processor 700 and memory 702. The SEPP 126A further includes an access token authorization client proxy 704 for performing the operations described above with respect to FIG. 5 to obtain an OAuth 2.0 access token on behalf of a consumer NF that does not support OAuth 2.0 authorization and modify an SBI service request message to include 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. The SEPP 126A further includes an access token authorization server proxy 706 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 FIG. 6. The access token authorization server proxy 706 may also remove the access token from service request messages addressed to producer NFs that do not support access token-based authorization. The access token authorization client proxy 704 and the access token authorization server proxy 706 may be implemented using computer-executable instructions stored in memory 702 that cause the processor 700 to perform the access token authorization client and server proxying operations described above.

[0053] 8A is a flowchart illustrating an example overall process for performing delegated authorization in a SEPP in which the SEPP acts as an access token authorization client proxy. Referring to FIG. 8A, at step 800, the process includes intercepting an SBI service 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, the SEPP 126A may receive an SBI service request from the consumer NF 200 to access a service provided by the producer NF 202.

[0054] In step 802, 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 SEPP 126A may act as an OAuth 2.0 authorization client proxy to obtain an access token on behalf of a consumer NF 200 that does not support OAuth 2.0 authorization. Figure 8B shows further details of step 802 of Figure 8A. Referring to Figure 8B, in step 802A, 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.

[0055] [Table 1]

[0056] 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, Scope, Requesting PLMN, and Target PLMN. The Authorization Type attribute may be obtained from the Consumer NF Identity populated from the SBI Service Request message. The NF Instance ID may be populated from the User Agent header of the SBI Service 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.

[0057] [Table 2]

[0058] As shown in Table 2, the user agent parameter may include information that identifies the NF instance, such as an NF instance ID. SEPP 126A may extract the NF instance ID from the user agent header of the SBI service request message 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 service request message.

[0059] Returning to Table 1, the requesting PLMN of the access token request may be populated based on the configured requesting PLMN parameter of the SEPP 126A. The target PLMN attribute may be populated from the API name extracted from the requesting uniform resource identifier (R-URI) of the SBI service 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 service request message.

[0060] 8B, once the access token request is formulated, in step 802B, the SEPP 126A sends the access token request to the NRF 100B. For example, the SEPP 126A may send an access token request message to the NRF 100B, which is located in the PLMN in which the producer NF 202 is located.

[0061] In step 802C, the process includes receiving an access token response from the NRF, the access token response including the access token. For example, the SEPP 126A may receive an access token response from the NRF 100B, the access token response including the access token.

[0062] Returning to FIG. 8A, in step 804, the process includes enabling the consumer NF to access a service provided by the producer NF using the first access token. FIG. 8C shows further details of step 804 of FIG. 8A. Referring to FIG. 8C, in step 804A, the process includes inserting the access token into an SBI service request message. For example, the SEPP 126A can insert the access token obtained from the NRF 100B into the service request message intercepted from the consumer NF 200.

[0063] In step 804B, the process includes forwarding the SBI service request including the first access token to the producer NF. For example, the SEPP 126A may forward the SBI service request including the access token to the producer NF 202. The producer NF 202 then authorizes the service request using the access token and responds to the service request. The SEPP 126A forwards the response to the consumer NF 200. Thus, Figures 8A-8C illustrate delegated authorization by the SEPP, where the SEPP acts as an access token authorization client proxy, which in the example described herein is an OAuth 2.0 authorization client proxy.

[0064] 9A illustrates an exemplary delegated authorization process performed by a SEPP acting as an access token authorization server proxy on behalf of an NRF that does not support access token authorization. Referring to FIG. 9A, the process includes receiving an access token request from a consumer NF in step 900. For example, the SEPP 126A receives the access token request from the consumer NF 300.

[0065] In step 902, 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 902 is shown in further detail in FIG. 9B. Referring to FIG. 9B, in step 902A, the process includes generating an access token in response to the access token request. For example, the SEPP 126A 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 SEPP 126A 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.

[0066] In step 902B, the process includes sending an access token response to the consumer NF. For example, the SEPP 126A can send an access token response including the access token generated in step 902A to the requesting consumer NF 300.

[0067] Returning to Figure 9A, in step 904, the process includes signaling with the producer NF and the consumer NF to enable the consumer NF to access the service. Step 904 is shown in more detail in Figure 9C. Referring to Figure 9C, the process of signaling with the consumer NF and the producer NF includes, in step 904A, receiving an SBI service request from the consumer NF, the SBI service request including the access token. For example, the SEPP 126A may receive an SBI service request from the NF service consumer 300, the SBI service request including the NF access token generated by the SEPP 126A.

[0068] In step 904B, the process includes removing the access token from the SBI service request. In step 904C, the process includes forwarding the SBI service request to the producer NF. Thus, Figures 9A-9C illustrate example steps that may be performed by a SEPP 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.

[0069] 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 a solution in a SEPP is beneficial because the SEPP sits at the boundary between networks. It is also a scalable solution because a single SEPP can perform the functions described herein for or on behalf of consumer NFs and producer NFs.

[0070] 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 rdGeneration 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). 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 for purposes of illustration only, and not for purposes of limitation, and the subject matter described herein is defined by the claims set forth below.

Claims

1. 1. A method for delegated authorization in a security edge protection proxy (SEPP), comprising: A SEPP including at least one processor and a memory, Intercepting a first service-based interface (SBI) service request from a first consumer network function (NF) that does not support access token-based authorization to access a service provided by a first producer NF that requires access token-based authorization; - acting as an access token authorization client proxy to obtain a first access token on behalf of said first consumer NF; and enabling the first consumer NF to access the service provided by the first producer NF using the first access token; and operating as the access token authorization client proxy includes signaling with a Network Function Repository Function (NRF) to obtain the first access token; signaling with the NRF to obtain the first access token; generating an access token request on behalf of the first consumer NF; sending the access token request to the NRF; receiving an access token response from the NRF, the access token response including the first access token; The method, 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 first SBI service request.

2. 2. The method of claim 1, 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 first SBI service request.

3. Enabling the first consumer NF to access the service provided by the first producer NF using the first access token includes: Inserting the first access token into the first SBI service request; forwarding the first 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.

4. A method for proxy authorization in a security edge protection proxy (SEPP), comprising: A SEPP including at least one processor and a memory, Intercepting a first service-based interface (SBI) service request from a first consumer network function (NF) that does not support access token-based authorization to access a service provided by a first producer NF that requires access token-based authorization; - acting as an access token authorization client proxy to obtain a first access token on behalf of said first consumer NF; using the first access token to enable the first consumer NF to access the service provided by the first producer NF; receiving an access token request from a second consumer NF; 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; and performing signaling communication with the second consumer NF and the second producer NF to enable the second consumer NF to access a service provided by the second producer NF.

5. 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 to the second consumer NF, the access token response including the second access token.

6. 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, the second SBI service request including the 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.

7. 6. The method of claim 5, wherein generating the second access token comprises generating an OAuth 2.0 access token including a dummy access token with syntactically correct claims.

8. 1. A system for delegated authorization in a security edge protection proxy (SEPP), comprising: a SEPP including at least one processor and a memory; an access token authorization client proxy implemented by the at least one processor; The access token authorization client proxy: Intercepting a first service-based interface (SBI) service request from a first consumer network function (NF) that does not support access token-based authorization to access a service provided by a first producer NF that requires access token-based authorization; acting as an access token authorization client to obtain a first access token on behalf of said first consumer NF; enabling the first consumer NF to access the service provided by the first producer NF using the first access token; the access token authorization client proxy is configured to signal with a Network Facility Repository Function (NRF) to obtain the first access token; signaling with the NRF to obtain the first access token; generating an access token request on behalf of the first consumer NF; sending the access token request to the NRF; receiving an access token response from the NRF, the access token response including the first access token; The system, 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 first SBI service request.

9. A system for proxy authorization in a security edge protection proxy (SEPP), comprising: a SEPP including at least one processor and a memory; an access token authorization client proxy implemented by the at least one processor; The access token authorization client proxy: Intercepting a first service-based interface (SBI) service request from a first consumer network function (NF) that does not support access token-based authorization to access a service provided by a first producer NF that requires access token-based authorization; acting as an access token authorization client to obtain a first access token on behalf of said first consumer NF; enabling the first consumer NF to access the service provided by the first producer NF using the first access token; an access token authorization server proxy; The access token authorization server proxy receiving an access token request from a second consumer NF; and acting 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; A system in signal communication with a second consumer NF and a second producer NF to enable the second consumer NF to access a service provided by the second producer NF.

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

Images