Methods, systems, and computer-readable media for delegated authorization at a service communication proxy (SCP)

Abstract

A method for delegated authorization at 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 also includes operating as an access token authorization client to obtain a first access token on behalf of the consumer NF. The method also 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 SCR can also function as an access token authorization server on behalf of an NRF that does not support access token-based authorization.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 198,815, filed March 11, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The topics described in this document relate to cybersecurity and compatibility between Public Land Mobile Networks (PLMNs). More specifically, the topics described in this document relate to methods, systems, and computer-readable media for delegated authorization at SCPs. Background Technology

[0004] In 5G telecommunications networks, network functions that provide services are referred to as producer network functions (NFs) or NF service producers. Network functions that consume services are referred to as consumer NFs or NF service consumers. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or both services. 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.

[0005] A given producer NF can have multiple service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of Internet Protocol (IP) address and port number or a fully qualified domain name (FQDN), which resolves to the IP address and port number on the network node hosting the producer NF. An NF instance is an instance of the producer NF that provides a service. A given producer NF can include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the Network Functions Storehouse (NRF). The NRF maintains service profiles for available NF instances, which identify the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably in this document. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0007] Besides consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Agent, which load balances traffic between producer NF service instances providing the required services, or directly routes traffic to the destination producer NF instance.

[0008] Besides SCP, another example of an intermediate proxy node that routes traffic between producer NFs and consumer NFs is the Secure Edge Protection Proxy (SEPP). The SEPP is a network node used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Therefore, the SEPP performs message filtering, censorship, and topology hiding for all application programming interface (API) messages sent between PLMNs.

[0009] An issue arises in 5G communication networks when one PLMN or network function supports OAuth 2.0 authorization while another PLMN or network function does not. According to the OAuth 2.0 authorization framework defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749, an authorized client seeking access to protected resources 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 verifies the access token and grants access to the protected resource.

[0010] In the context of a 5G communication network, the NF service consumer acts as an OAuth 2.0 resource client, the NF service producer acts as an OAuth 2.0 resource server, and the NRF acts as an authorization server. Therefore, an NF service consumer seeking access to a service provided by an NF service producer communicates with the NRF via signaling to obtain an access token, thereby accessing the resources provided by the NF service producer. After obtaining the access token from the NRF, the NF service consumer sends a service request to the NF service producer, whereby the service request includes the access token. The NF service producer verifies the access token and grants access to the service requested by the NF service consumer.

[0011] While the OAuth 2.0 authorization framework aims to provide authorization in 5G communication networks, service requests 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 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.

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

[0013] Given these and other difficulties, there is a need for a method to improve interoperability between network functions in the presence of OAuth 2.0 authorization incompatibilities. Summary of the Invention

[0014] The method for delegated authorization at a Service Communication Agent (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 also includes acting as an access token authorization client agent to obtain a first access token on behalf of the first consumer NF. Furthermore, the method includes using the first access token to enable the first consumer NF to access services provided by a first producer NF that requires access token-based authorization.

[0015] As another aspect of the subject described in this article, operating as an access token authorization client agent involves signaling communication with the NF repository function (NRF) to obtain a first access token.

[0016] According to another aspect of the subject matter described herein, signaling communication with the NRF to obtain a first access token includes: 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 including the first access token from the NRF.

[0017] As in another aspect of the subject described herein, generating the access token request includes extracting values ​​of at least some attributes to be included in the access token request from the user agent header of the SBI request.

[0018] As in another aspect of the subject described herein, extracting the values ​​of at least some attributes includes extracting the NF instance ID of the first consumer NF from the user agent header of the SBI request.

[0019] According to another aspect of the subject matter described herein, 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 a first producer NF using a 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.

[0020] According to another aspect of the subject matter described herein, 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 a first producer NF using a first access token includes: generating an SBI service request based on delegation 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.

[0021] According to another aspect of the subject matter described herein, the method for delegated authorization at an SCP includes receiving an access token request from a second consumer NF or a second SCP; operating as an access token authorization server agent 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 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.

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

[0023] According to another aspect of the subject matter described herein, signaling communication with a second producer NF or a second SCP to enable a second consumer NF to access services provided by the second producer NF includes: receiving a second SBI service request from the second consumer NF, 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.

[0024] As another aspect of the subject described herein, generating a second access token includes generating an OAuth 2.0 access token, which includes a dummy access token with a syntactically correct claim.

[0025] In accordance with another aspect of the subject matter described herein, a system for delegated authorization at a Service Communication Agent (SCP) is provided. The system includes a first SCP, which includes at least one processor and memory. The system also includes an access token authorization client agent implemented by the at least one processor, configured to intercept Service-Based Interface (SBI) requests 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 services provided by a first producer NF that requires access token-based authorization.

[0026] In accordance with another aspect of the subject matter described herein, the access token authorization client agent is configured to signal with the NF repository function (NRF) to obtain a first access token.

[0027] In accordance with another aspect of the subject matter described herein, the access token authorization client agent is configured to obtain a first access token by signaling to the NRF in the following manner: 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 including the first access token from the NRF.

[0028] In accordance with another aspect of the subject described herein, the access token authorization client agent 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 the user agent header of the SBI request.

[0029] As with another aspect of the subject described herein, the value extracted by the access token-authorized client agent includes the NF instance ID of the first consumer NF from the user agent header of the SBI request.

[0030] According to another aspect of the subject matter described herein, the SBI request includes an SBI service request from a first consumer NF, and the access token authorization client agent is configured to enable the first consumer NF to access the service by using a first access token in the following manner: inserting the first access token into the SBI service request; forwarding the SBI service request including the first access token to a 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, the SBI request includes an SBI service access request from a first consumer NF, and the access token authorization client agent is configured to enable the first consumer NF to access services provided by a first producer NF by using a first access token in the following manner: generating an SBI service request based on delegation 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.

[0032] According to another aspect of the subject matter described herein, a system for delegated authorization at an SCP includes an access token authorization server agent that receives access token requests from a second consumer NF or a second SCP; operates as an access token authorization server representing 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 signals to 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.

[0033] In accordance with another aspect of the subject matter described herein, when operating as an access token authorization server, the access token authorization service agent 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 a second consumer NF or a second SCP.

[0034] According to another aspect of the subject matter described herein, the access token authorization server agent is configured to signal to the second consumer NF or second SCP and the second producer NF in such a way that the second consumer NF can access services provided by the second producer NF: receiving a second SBI service request including a second access token from the second consumer NF or 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 second SCP.

[0035] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon, which, when executed by a computer's processor, control the computer to perform steps. The steps include intercepting a service-based interface (SBI) request from a consumer network function (NF) that does not support access token-based authorization. The steps also include acting as an access token authorization client agent to obtain a first access token on behalf of a first consumer NF. The steps further include 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.

[0036] The subjects described herein can be implemented using software in conjunction with hardware and / or firmware. For example, the subjects described herein can be implemented using software executed by a processor. In one exemplary implementation, the subjects described herein can be implemented using a non-transitory computer-readable medium having computer-executable instructions stored thereon, which control computer execution steps when executed by a computer's processor. Exemplary computer-readable media suitable for implementing the subjects described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subjects described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0037] Figure 1 This is a network diagram illustrating an exemplary 5G system network architecture;

[0038] Figure 2A This is a message flow diagram illustrating exemplary messages exchanged when accessing services in a 5G communication network using the OAuth 2.0 authorization framework, where the message flow is used for indirect inter-PLMN communication without delegation discovery (Model C).

[0039] Figure 2B This is a message flow diagram illustrating exemplary messages exchanged when accessing services in a 5G communication network using the OAuth 2.0 authorization framework, where the message flow is used for indirect inter-PLMN communication with delegated discovery (Model D).

[0040] Figure 3A This is a message flow diagram illustrating an example of messages exchanged when a consumer NF does not support OAuth 2.0 authorization but a producer NF requires OAuth 2.0 authorization as a condition for accessing services provided by the producer NF. This message flow is used for indirect inter-PLMN communication without delegation discovery (Model C).

[0041] Figure 3BThis is a message flow diagram illustrating an example of messages exchanged when the consumer NF supports OAuth 2.0 authorization but the NRF does not, where the message flow is used for indirect inter-PLMN communication without delegation discovery (Model C).

[0042] Figure 3C This is a message flow diagram illustrating an example of messages exchanged when a consumer NF supports OAuth 2.0 authorization but the NRF does not, where the message flow is used for indirect inter-PLMN communication with delegated discovery (Model D).

[0043] Figure 4 This is a diagram illustrating the message flow of delegated OAuth 2.0 authorization when the SCP acts as an OAuth 2.0 authorization client agent representing a consumer NF that does not support OAuth 2.0 authorization, where the message flow is used for indirect inter-PLMN communication with delegation discovery (Model D).

[0044] Figure 5A This is a message flow diagram illustrating exemplary messages exchanged when an SCP acts as an OAuth 2.0 authorization server proxy representing an NRF that does not support OAuth 2.0 authorization, where the message flow is used for indirect inter-PLMN communication without delegation discovery (Model C).

[0045] Figure 5B This is a message flow diagram illustrating exemplary messages exchanged when an SCP acts as an OAuth 2.0 authorization server proxy representing an NRF that does not support OAuth 2.0 authorization, where the message flow is used for indirect inter-PLMN communication with delegation discovery (Model D).

[0046] Figure 6 This is a diagram illustrating an SCP that can represent an NF service consumer and an NRF that does not support OAuth 2.0 authorization to delegate OAuth 2.0 authorization;

[0047] Figure 7A This is a flowchart illustrating an exemplary process of delegated OAuth 2.0 authorization performed by a consumer NF that does not support OAuth 2.0 authorization;

[0048] Figure 7B A more detailed map explanation Figure 7A The flowchart shows the steps taken by the client agent to perform the access token authorization operation on behalf of a consumer NF that does not support OAuth 2.0 authorization;

[0049] Figure 7C A more detailed map explanation Figure 7AThe flowchart illustrates the steps involved in using access tokens to enable a consumer NF that does not support OAuth 2.0 authorization to access services provided by a producer NF that requires OAuth 2.0 authorization.

[0050] Figure 8A This is a flowchart illustrating an exemplary process for facilitating access to a service when the consumer NF supports OAuth 2.0 authorization but the producer NF does not. It shows how an OAuth 2.0 authorization server proxy, acting on behalf of the NRF that does not support OAuth 2.0 authorization, operates and facilitates access to the service.

[0051] Figure 8B A more detailed map explanation Figure 8A The flowchart shows the steps taken by an OAuth2.0 authorization server proxy representing an NRF that does not support OAuth 2.0 authorization.

[0052] Figure 8C A more detailed map explanation Figure 8A The flowchart illustrates the steps involved in signaling communication between the consumer NF and the producer NF when the consumer NF supports OAuth 2.0 authorization but the producer NF does not, to enable the consumer NF to access the services provided by the producer NF. Detailed Implementation

[0053] Figure 1 This is a block diagram illustrating an exemplary 5G system network architecture. Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Home Public Land Mobile Network (HPLMN). As described above, NRF 100 maintains profiles of available producer NF service instances and their supported services, and allows consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. SCP 101 also supports service discovery and producer NF instance selection. SCP 101 can perform load balancing for connections between consumer NFs and producer NFs.

[0054] NRF 100 is a repository of NF or service profiles for producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the producer NF instance's NF or service profile from 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.

[0055] exist Figure 1 In this context, any network function can be a consumer NF, a producer NF, or both, depending on whether it is requesting a service, providing a service, or both. In the example illustrated, the NF includes a PCF 102 that performs policy-related operations on the network, a UDM function 104 that manages user data, and an application function (AF) 106 that provides application services.

[0056] Figure 1 The NF shown also includes a Session Management Function (SMF) 108, which manages the session between the 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 a 4G network. The Authentication Server Function (AUSF) 112 provides authentication services for user equipment (UEs) seeking network access, such as user equipment (UE) 114.

[0057] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and characteristics associated with a network slice. The Network Open Function (NEF) 118 provides an application programming interface (API) for application functions seeking information about Internet of Things (IoT) devices and other UEs attached to the network. NEF 118 performs functions similar to the Service Capability Open Function (SCEF) in 4G networks.

[0058] Radio Access Network (RAN) 120 connects User Equipment (UE) 114 to the network via a radio link. This can be achieved using a g-Node B (gNB). Figure 1 (Not shown in the image) or other wireless access points to access the radio access network 120. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. An example of such a proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support performance measurement functions, which the UE 114 can use to obtain network performance measurement results. Figure 1 The diagram also illustrates data network (DN) 124, through which the UE accesses data network services, such as Internet services.

[0059] SEPP 126 filters incoming traffic from other PLMNs and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the external PLMN, which manages security for that external PLMN. Therefore, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the external PLMN.

[0060] As mentioned above, one potential issue in 5G networks is the lack of universal support for OAuth 2.0 authorization, which could lead to service incompatibility between networks. Figure 2A This is a diagram illustrating OAuth 2.0 authorization between PLMNs and the message flow diagram for accessing services across PLMN boundaries using access tokens. Figure 2A The message flow in this protocol is used for indirect inter-PLMN communication without delegated discovery, and it is defined as Model C in Annex E of 3GPP TS23.501. According to the Model C specification, the consumer NF performs discovery by querying the NRF. Based on the discovery result, the consumer NF selects a producer NF or a set of NFs. The consumer NF then sends an SBI service request to the SCP containing the address of the selected producer NF or set of producer NFs. If the service request specifies an NF set, 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.

[0061] See Figure 2A In the message flow, in line 1, consumer NF 200 performs NF discovery by signaling communication with NRF 100B via SCPs 101A and 101B and SEPPs 126A and 126B to select a producer NF instance or NF set. In line 2, after selecting a producer NF or NF set, consumer NF 200 sends an Nnrf access token request message to NRF 100A located in the visitor network (the network of the visitor PLMN in which the UE that triggered the access token request is currently roaming). NRF 100A forwards the access token request message to remote NRF 100B via SCPs 101A and 101B and SEPPs 126A and 126B. This forwarding is handled by... Figure 2A The instructions are in lines 2-6 of the document.

[0062] The 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 transmitted to the consumer NF 200 via SCPs 101A and 101B, SEPPs 126A and 126B, and NRF 100A.

[0063] Consumer NF 200 generates an SBI service request message including an access token and sends it to producer NF 202 via SCPs 101A and 101B and SEPPs 126A and 126B, as shown in lines 12-14. The SBI service request message includes an access token. The SBI request may optionally include a Client Credential Assertion (CCA) attribute, such as... Figure 2A As shown in "CCA*".

[0064] Producer NF 202 verifies the access token and grants consumer NF 200 access to the service. In lines 15-17, producer NF 202 returns an SBI service response message to consumer NF 200. A similar flow occurs when the consumer NF resides in the home network while the producer NF resides in the visitor or non-home network. Therefore, Figure 2A The diagram illustrates a scenario where two different networks communicate via SCP supporting OAuth 2.0 authorization and indirect PLMN communication, resulting in successful sending and receiving of access token messages and service request messages. However, if one or the other network does not support OAuth 2.0 authorization, the sending and receiving of service request and / or access token messages will fail.

[0065] Figure 2B This is a message flow diagram illustrating indirect PLMN communication with delegated discovery and OAuth 2.0 authorization. Indirect communication with delegated discovery is defined as Model D in Annex E of 3GPP TS23.501. According to Model D, the consumer NF does not perform NF selection or discovery. Instead, the consumer NF adds the necessary 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. See also Figure 2B In the message flow diagram, in line 1, consumer NF 200 sends an SBI service access request message with discovery and producer NF selection parameters to SCP 101A. In line 2, SCP 101A performs discovery with NRF 101B. The discovery results in the selection of producer NF 202 to handle the service request message. However, before sending the service request message to producer NF 202, SCP 101A must obtain an access token from NRF 100B in producer NF 202's network. Therefore, in line 3, 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 SCP 101A and 101B, and SEPP126A and 126B, as shown in lines 4-6 of the message flow diagram.

[0066] The NRF 100B determines whether the client is authorized and returns an access token via SCP 101B and 101A and SEPP 126B and 126A. Figure 2B The message flow in the diagram uses lines 7-10 to illustrate the return of the access token.

[0067] In lines 11 and 12, SCP 101A sends an SBI service request message to Producer NF 202, selected during the commissioned discovery process indicated in line 2, via SEPPs 126A and 126B. Producer NF 202 verifies the access token and, in lines 13–15, sends an SBI service response to Consumer NF 200 via his SCPs 101B and 101A, as well as SEPPs 126B and 126A. The SBI service response delivered to Consumer NF 200 may optionally include the access token, such as... Figure 2B As shown in the “Access Token**”.

[0068] A similar flow occurs when the consumer NF is in the home network and the producer NF is in the visitor network. Therefore, Figure 2B The diagram illustrates a scenario where the NRF in the network serving the consumer NF (SCP) and the producer NF (Non-RF) supports OAuth 2.0 authorization and conducts indirect inter-PLMN communication with delegated discovery.

[0069] Figure 3A This diagram illustrates the scenario of indirect communication between PLMNs without delegate discovery, where the NF service consumer does not support OAuth 2.0 authorization, while the NF service producer requires OAuth 2.0 authorization. See also... Figure 3A Since the visitor network in this example does not support OAuth 2.0 authorization, no event occurred. Figure 2A Lines 1-11 are the PLMN inter-signaling for obtaining the access token. Figure 3A The message flow in the N32 message begins with line 1, where consumer NF 200 sends an SBI service request message without an access token to producer NF 202, which is located in a different PLMN and requires access token authorization. Because this service request does not include an access token, the service request in line 2 is rejected by the home SEPP 126B. SEPP 126B rejects the service request because 3GPP TS33.501, section 13.4.1.2.2 recommends that the provider SEPP should check that the service PLMN in the subject claim in the access token matches the remote PLMN corresponding to the N32-f context ID in the N32 message. Since the service request message in line 2 does not include an access token, there is no subject claim for SEPP 126B to verify, therefore the message is rejected.

[0070] Although Figure 3A The diagram illustrates indirect inter-PLMN communication without delegate discovery, where the consumer NF does not support OAuth 2.0 authorization, while the producer NF does. Figure 3B This diagram illustrates indirect PLMN communication without delegated discovery, where the consumer NF supports OAuth 2.0 authorization, while the NRF in the producer NF's network does not. See also... Figure 3B In the message flow, in line 1, consumer NF 300 in the home network communicates with NRF 100A in the visitor network for service discovery. In this example, it is assumed that the result of service discovery is the selection of producer NF 302 in the visitor network to provide the requested service.

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

[0072] Figure 3C This diagram illustrates indirect inter-PLMN communication with delegated discovery, where the consumer NF supports OAuth 2.0 authorization, while the producer NF does not. See also Figure 3C In the message flow, on line 1, consumer NF 300, located in the home network, sends a service access request with discovery parameters to SCP 101B. On line 2, SCP 101B communicates with NRF 100A, located in the visitor network, for service discovery. In this example, it is assumed that the result of service discovery is the selection of producer NF 302, located in the visitor network, to provide the requested service.

[0073] Following service discovery, in line 3, SCP 101B sends an access token request to NRF 100B. In line 4, NRF 100B forwards the access token request to SCP 101B, and in line 5, SCP 101B routes the access token request to remote SCP 101A. In line 6, SCP 101A routes the access token request to NRF 100A located in the visitor network. In this example, visitor NRF 100A does not support OAuth 2.0 authorization. Therefore, visitor NRF 100A cannot respond to the access token request, causing the access token message to fail to be sent. As a result, consumer NF 300 may be unable to access services provided by the visitor network.

[0074] To avoid this difficulty, the SCP described herein acts as an access token authorization client proxy representing a consumer NF that does not support access token-based authorization, and as an access token authorization server representing an NRF that does not support access token-based authorization. For a consumer NF that does not support access token-based authorization, the SCP obtains an access token, adds it to the SBI request, and then forwards the request to the producer NF. The SCP may choose to cache the token to speed up processing. The SCP can 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, depending on whether delegation discovery is performed, the SCP issues an access token to the requesting consumer NF or the SCP.

[0075] Figure 4 This diagram illustrates indirect inter-PLMN communication with delegated discovery, where 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. See also Figure 4 In line 1 of the message flow diagram, consumer NF 200 sends an SBI service access request to SCP 101A without an access token. In line 2, SCP 101A performs delegated discovery on behalf of consumer NF 200 by signaling communication with NRF 100B, and the result of the delegated discovery is the selection of producer NF 202.

[0076] Instead of generating an SBI service request in response to the service access request in line 1, SCP 101A detects that the service access request does not include an access token, intercepts and stores the service access request, and acquires an access token on behalf of consumer NF 200. The acquisition of the access token begins in line 3 of the message flow graph, where SCP 101A formulates and sends an access token request to SCP 101B. In line 4, SCP 101B routes the access token request to NRF 100B located in the PLMN of producer NF 202. The formulation of the access token request message will be described in more detail below. NRF 100B authenticates consumer NF 200, generates an access token response including the access token, and in lines 5 and 6, sends the access token response to the network of consumer NF 200 via SEPP 126B and 126A and SCP 101B.

[0077] SCP 101A receives an access token response, extracts the access token from the response, generates an SBI service request based on the SBI service access request received in line 1, and inserts the access token into the generated SBI service request. In lines 7 and 8, SCP 101A forwards the SBI service request with the access token to producer NF 202. Producer NF 202 uses the access token to verify the service request, and in lines 9-11, generates an SBI service response message and sends it to consumer NF 200. Therefore, Figure 4 The diagram illustrates the role of an OAuth 2.0 authorized client proxy for a consumer NF that does not support OAuth 2.0 authorization, starting with SCP 101A.

[0078] In another example, SCP 101A can function as an access token authorization server. Figure 5A The diagram illustrates such an example. Figure 5A This diagram illustrates indirect inter-PLMN communication without delegated discovery, where a consumer NF 300, located in the home network and not supporting OAuth 2.0 authorization, attempts to access a service provided by a producer NF 302 located in the visitor network. See also Figure 5A In line 1, the consumer NF performs service discovery by communicating with the NRF 100A via signaling, and the result of the service discovery is the selection of the producer NF 302 to provide the service.

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

[0080] In line 10, consumer NF 300 generates an SBI service request and sends it to producer NF 302 via SCPs 101B and 101A, and SEPPs 126B and 126A, where the service request includes an access token. In line 11, SCP 101A intercepts the SBI service request and removes the access token from the service request because producer NF 302 does not support OAuth 2.0 authorization. In line 12, SCP 101A forwards the service request (without the access token) to producer NF 302. In lines 13-15, producer NF 302 generates an SBI service response message and sends it to consumer NF 300. Therefore, Figure 5A The diagram illustrates the role of SCP 101A and above as an OAuth 2.0 authorization server proxy for an NRF that does not support OAuth 2.0 authorization.

[0081] Although Figure 5A The diagram illustrates the scenario where SCP acts as an OAuth 2.0 authorization server for indirect inter-PLMN communication without delegate discovery, but... Figure 5B This diagram illustrates how an SCP acts as an OAuth 2.0 authorization server for indirect inter-PLMN communication with delegated discovery. See also... Figure 5B In line 1 of the message flow diagram, consumer NF300, located in the home network, sends a service access request message with discovery parameters to SCP 101B. In line 2, SCP 101B performs delegated NF discovery and selection by signaling communication with NRF 100A, located in the visitor network. The result of delegated discovery and NF selection is the selection of producer NF 302, located in the visitor network, to provide the requested service.

[0082] After delegation discovery and NF selection, in line 3, SCP 101B generates an access token request message and forwards it to NRF 100B. In lines 4 and 5, NRF 100B forwards the access token request message to NRF 100A. 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 native to SCP 101A. The access token can be syntactically correct, as it includes all required access token statements. In lines 6–8, SCP 101A forwards the access token response to SCP 101B.

[0083] In line 9, SCP 101B generates an SBI service request and sends it to producer NF 302 via SEPP 126B and 126A, as well as SCP 101A. This service request includes an access token. SCP 101A intercepts the SBI service request and removes the access token from it because producer NF 302 does not support OAuth 2.0 authorization. In line 10, SCP 101A forwards the service request (without the access token) to producer NF 302. In lines 11-13, producer NF 302 generates an SBI service response message and sends it to consumer NF 300. Therefore, Figure 5B The diagram illustrates how SCP 101A performs delegation discovery and NF selection, and acts as an OAuth 2.0 authorization server proxy for an NRF that does not support OAuth 2.0 authorization.

[0084] Figure 6 This is a block diagram illustrating an exemplary architecture of the SCP that supports the OAuth 2.0 authorization proxy described in this document. See also Figure 6 SCP 101A includes at least one processor 600 and memory 602. SCP 101A also includes an access token authorization client agent 604 for performing the above-mentioned... Figure 4 This describes the delegation discovery scenario, where a consumer NF representing a user NF that does not support OAuth 2.0 authorization obtains an OAuth 2.0 access token and generates an SBI service request message that includes the OAuth 2.0 access token to enable the consumer NF to access services provided by a producer NF that supports OAuth 2.0 authorization. In the non-delegation discovery scenario, the access token authorization client proxy 604 can obtain an OAuth 2.0 access token from a consumer NF that does not support OAuth 2.0 authorization and insert it into the SBI service request message.

[0085] SCP 101A also includes Access Token Authorization Server Proxy 606, which represents the functionality of an OAuth 2.0 authorization server for an NRF that does not support OAuth 2.0 authorization, as mentioned above. Figure 5A and Figure 5B The access token authorization server agent 606 can also remove the access token from service request messages destined for producer NFs that do not support access token-based authorization. The access token authorization client agent 604 and the access token authorization server agent 606 can be implemented using computer-executable instructions stored in memory 602, which cause processor 600 to perform the access token authorization client and server agent operations described above.

[0086] Figure 7A This is a flowchart illustrating an exemplary overall process for delegated authorization in SCP, where SCP acts as an access token authorization client proxy. See also Figure 7A In step 700, the process includes intercepting an SBI request from a consumer NF that does not support access token-based authorization for accessing a service provided by a producer NF that requires access token-based authorization. For example, in the case of indirect inter-PLMN communication without delegation discovery, SCP 101A may receive an SBI service request from the consumer NF for accessing a service provided by producer NF 202. In the case of indirect inter-PLMN communication with delegation discovery, SCP 101A may receive a service access request from the consumer NF.

[0087] In step 702, the process includes acting as an access token authorization client proxy to obtain an access token on behalf of the consumer NF. For example, SCP 101A can 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 Diagram Explanation Figure 7A Additional details for step 702 in [the document]. See also [the document]. Figure 7B In step 702A, the process includes generating an access token request message on behalf of the consumer NF. Table 1 below illustrates the attributes that must be included in the access token request message.

[0088]

[0089]

[0090] Table 1: Access Token Request Attributes

[0091] The minimum set of attributes that must be included in an access token request is grant type, NF instance ID, NF type, target NF type, scope, requester PLMN, and target PLMN. The grant type attribute can be obtained from the consumer NF credentials populated from the SBI service request or service access request message. The NF instance ID can be populated from the user agent header of the SBI service request or service access request message. According to 3GPP TS29.500, Section 5.2.2, the user agent header is a mandatory header in the SBI service request message. Table 2 below illustrates the structure of the user agent parameters.

[0092]

[0093] Table 2: User Agent Parameters

[0094] As shown in Table 2, user agent parameters can contain information that identifies the NF instance, such as the NF instance ID. SCP101A can 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 this information to populate the NF instance ID attribute of the access token request message. Similarly, the NF type can also be obtained from the user agent header of the SBI request message.

[0095] Returning to Table 1, the requester PLMN for the access token request can be populated based on the requester PLMN parameters configured in SCP 101A. The target PLMN attribute can be populated based on the API name extracted from the requester Uniform Resource Identifier (R-URI) of the SBI request message. The scope attribute of the access token request can be populated based on the service name extracted from the R-URI of the SBI request message.

[0096] return Figure 7B Once an access token request is established, in step 702B, SCP 101A sends the access token request to the NRF. For example, SCP 101A can send the access token request message to NRF 100B located in the PLMN where the producer NF resides.

[0097] In step 702C, the process includes receiving an access token response, which includes the access token, from the NRF. For example, SCP101A can receive an access token response, which includes the access token, from NRF 100B.

[0098] return Figure 7A In step 704, the process includes using an access token to enable the consumer NF to access the services provided by the producer NF. Figure 7C Diagram Explanation Figure 7A Additional details for step 704 in [the document]. See also [the document]. Figure 7C The process differs slightly depending on whether delegated or non-delegated discovery is being performed. If delegated discovery is being performed, control proceeds to step 704A1, where this process includes generating an SBI service request message in response to a previously received service access request and inserting an access token obtained on behalf of the consumer NF in step 702 into the SBI service request message. For example, SCP 101A can generate an SBI service request pointing to the producer NF identified during the delegated discovery process and insert its access token obtained from NRF 100B into the SBI service request message. In step 704B1, this process includes forwarding the SBI service request, including the access token, to the producer NF. For example, SCP 101A can forward the SBI service request, including the access token, to the producer NF identified during the delegated discovery process. The producer NF will then authorize the service request using the access token and respond to the service request. SCP 101A forwards this response to the consumer NF 200 that sent the service access request.

[0099] If delegated discovery is not achieved, control proceeds to step 704A2, in which SCP 101A inserts an access token into the previously received SBI service request. The message flow for non-delegated discovery scenarios is as follows: Figure 4 Similar to the diagram, except that in line 1, the received message is an SBI service request, not an SBI service access request, and discovery has already been performed. Not required. Figure 4 The second line contains the dispatching of the delegated discovery message. The remaining steps for non-delegated discovery are... Figure 4 The remaining steps are the same as those shown in the diagram. Therefore, in step 704B2, SCP 101A forwards the SBI service request, including the access token, to the producer NF. When SCP 101A receives a response from the producer NF, SCP 101A forwards that response to the consumer NF. Thus, Figures 7A-7C This diagram illustrates the delegation of authority by the SCP, where the SCP acts as an access token authorization client proxy. In the example described in this article, the access token authorization client proxy is an OAuth 2.0 authorization client proxy.

[0100] Figure 8A The diagram illustrates an exemplary delegated authorization process performed by an SCP acting as a proxy for an access token authorization server that does not support NRF-based access token authorization. See also Figure 8A In step 800, the process includes receiving an access token request from the consumer NF in the case of non-delegated discovery, or receiving an access token request from a remote SCP representing the consumer NF in the case of delegated discovery. For example, SCP 101A can receive an access token request in the case of non-delegated discovery (see...). Figure 5A ) Receive access token requests from consumer NF 300, or in the case of delegation discovery (see Figure 5B Receive an access token request from SCP 101B.

[0101] 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. Figure 8B A more detailed map illustration of step 802 is provided. See also... Figure 8B In step 802A, the process includes generating an access token in response to an access token request. For example, SCP 101A may generate an access token that includes the required claims as specified in IETF RFC 6749. The access token may be syntactically correct, conforming to the format and content specified in IETF RFC 6749. However, the access token need not be a real access token and may be a dummy access token with syntactically correct fields, as described below, SCP 101A will remove the access token from the service request message before forwarding it to the producer NF that does not support access token-based authorization.

[0102] In step 802B, the process includes sending an access token response to the consumer NF or SCP. For example, SCP 101A may 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.

[0103] return Figure 8A In step 804, the process includes signaling communication with the producer NF and the consumer NF or SCP to enable the consumer NF to access the service. Figure 8C A more detailed map illustration of step 804 is provided. See also... Figure 8C The processing of signaling communication with the producer NF and consumer NF or SCP includes, in step 804A, receiving an SBI service request including an access token from the consumer NF or SCP. For example, SCP 101A may receive an SBI service request including an NF access token generated by SCP 101A from NF service consumer 300 (in the case of non-delegated discovery), or receive an SBI service request from SCP 101B in the case of delegated discovery.

[0104] 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, SCP 101A can remove the access token it generated from the SBI service request and forward the SBI service request to the producer NF. Therefore, Figures 8A-8C The diagram illustrates exemplary steps that an SCP can take 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.

[0105] Exemplary advantages of the topics described herein include improved interoperability between PLMNs, where one PLMN supports access token-based authorization while another does not. Providing this solution within an SCP is advantageous because the SCP handles message sending and receiving 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.

[0106] The publicly available information in the following references is incorporated into this paper in its entirety through citation.

[0107] References

[0108] 1. Hardt, D. “The OAuth 2.0Authorization Framework,” IETF RFC 6749 (October 2012).

[0109] 2. 3GPP TS 33.501V17.0.0(2020-12),3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Securityarchitecture and procedures for 5G system (Release 17).

[0110] 3. 3GPP TS29.500V17.1.0(2020-12); 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5GSystem; Technical Realization of the Service Based Architecture; Stage 3(Release 17).

[0111] 4. 3GPP TS29.510V17.0.0(2020-12); 3 rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5GSystem; NetworkFunction Repository Services; Stage 3(Release 17).

[0112] 5. 3GPP TS23.501V16.7.0(2020-12); 3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System(5GS); Stage 2(Release 16).

[0113] It should be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for illustrative purposes only and not for limitation, as the subject matter described herein is defined by the claims set forth below.

Claims

1. A method for delegation authorization at a Service Communications Agent (SCP), the method comprising: At the first SCP, which includes at least one processor and memory: Intercept service-based interface SBI requests from the first consumer network function (NF) that does not support access token-based authorization; Act as an access token authorization client agent to obtain the first access token on behalf of the first consumer NF; The first access token enables the first consumer NF to access services provided by the first producer NF, which requires authorization based on the access token. Receive access token requests from the second consumer NF or the second SCP; In response to the access token request from the second consumer NF or the second SCP, it operates as an access token authorization server agent representing the NF repository function NRF that does not support access token authorization; as well as Signaling communication is established 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.

2. The method of claim 1, wherein operating as an access token authorization client agent includes signaling communication with an NRF that supports access token authorization to obtain a first access token.

3. The method of claim 2, wherein signaling communication with the NRF supporting access token authorization to obtain the first access token comprises: Generate an access token request on behalf of the first consumer NF; Send the access token request to the NRF that supports access token authorization; as well as Receive an access token response, including a first access token, from the NRF that supports access token authorization.

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

5. The method according to claim 4, wherein extracting the values ​​of at least some attributes includes extracting the NF instance ID of the first consumer NF from the user agent header of the SBI request.

6. The method according to any preceding claim, wherein receiving an SBI request includes receiving an SBI service request from a first consumer NF, and wherein using a first access token to enable the first consumer NF to access services provided by the first producer NF includes: Insert the first access token into the SBI service request; The SBI service request, including the first access token, is forwarded to the first producer NF. Receive SBI service response from the first producer NF; as well as The SBI service response is forwarded to the first consumer NF.

7. The method according to any one of claims 1 to 5, wherein receiving an SBI request includes receiving an SBI service access request from a first consumer NF, and wherein using a first access token to enable the first consumer NF to access a service provided by a first producer NF includes: The SBI service request is generated based on delegation discovery and NF selection performed in response to the SBI service access request. Insert the first access token into the SBI service request; Forward the SBI service request, which includes the first access token, to the first producer NF; Receive SBI service response from the first producer NF; as well as The SBI service response is forwarded to the first consumer NF.

8. The method according to claim 1, wherein operating as an access token authorization server proxy comprises: In response to the access token request, a second access token is generated; as well as Send an access token response, including the second access token, to the second consumer NF or the second SCP.

9. The method according to claim 1, wherein signaling communication with the second producer NF to enable the second consumer NF to access the services provided by the second producer NF comprises: Receive a second SBI service request, including a second access token, from the second consumer NF or the second SCP; Remove the second access token from the second SBI service request; Forward the second SBI service request to the second producer NF; Receive SBI service response from the second producer NF; as well as The SBI service response is forwarded to the second consumer NF or the second SCP.

10. A system for delegation authorization at a Service Communications Agent (SCP), the system comprising: The first SCP includes at least one processor and memory. An access token authorization client proxy, implemented by the at least one processor, is used to intercept service-based interface SBI requests 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 services provided by a first producer NF that requires access token-based authorization. and An access token authorization server proxy implemented by the at least one processor, the access token authorization server proxy being used to: receive access token requests from a second consumer NF or a second SCP; In response to the access token request from the second consumer NF, an access token authorization server is operated as an NF repository function NRF that does not support access token authorization; And to communicate signaling with the second consumer NF or the second SCP and the second producer NF so that the second consumer NF can access the services provided by the second producer NF.

11. The system of claim 10, wherein the access token authorization client agent is configured to communicate signalingly with an NRF that supports access token authorization to obtain a first access token.

12. The system of claim 11, wherein the access token authorization client agent is configured to obtain a first access token by signaling to the NRF supporting access token authorization in the following manner: Generate an access token request on behalf of the first consumer NF; Send the access token request to the NRF that supports access token authorization; as well as Receive an access token response, including a first access token, from the NRF that supports access token authorization.

13. The system of claim 12, wherein the access token authorization client agent 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 the user agent header of the SBI request.

14. The system of claim 13, wherein the value extracted by the access token authorization client agent includes the NF instance ID of the first consumer NF from the user agent header of the SBI request.

15. The system according to any one of claims 10 to 14, wherein the SBI request includes an SBI service request, and the access token authorization client agent is configured to enable a first consumer NF to access the service using a first access token: Insert the first access token into the SBI service request; The SBI service request, including the first access token, is forwarded to the first producer NF. Receive SBI service response from the first producer NF; as well as The SBI service response is forwarded to the first consumer NF.

16. The system according to any one of claims 10 to 14, wherein the SBI request includes an SBI service access request from a first consumer NF, and the access token authorization client agent is configured to enable the first consumer NF to access a service provided by a first producer NF by using a first access token in the following manner: The SBI service request is generated based on delegation discovery and NF selection performed in response to the SBI service access request. Insert the first access token into the SBI service request; The SBI service request, including the first access token, is forwarded to the first producer NF. Receive SBI service response from the first producer NF; as well as The SBI service response is forwarded to the first consumer NF.

17. The system according to claim 10, wherein when operating as an access token authorization server, the access token authorization server proxy is configured to: In response to the access token request, a second access token is generated; as well as An access token response, including a second access token, is sent to the second consumer NF or the second SCP, wherein the access token authorization server agent is configured to communicate signalingly with the second consumer NF or the second SCP and the second producer NF in a manner that enables the second consumer NF to access services provided by the second producer NF: Receive a second SBI service request, including a second access token, from the second consumer NF or the second SCP; Remove the second access token from the second SBI service request; Forward the SBI service request to the second producer NF; Receive SBI service response from the second producer NF; as well as The SBI service response is forwarded to the second consumer NF.

18. A non-transitory computer-readable medium storing executable instructions that, when executed by a computer's processor, control the computer to perform steps, the steps including: Intercept service-based interface (SBI) requests from consumer network functions (NFs) that do not support access token-based authorization; Act as an access token authorization client to obtain the first access token on behalf of the consumer NF; The first access token enables the consumer NF to access services provided by the producer NF, which requires authorization based on the access token. Receive access token requests from the second consumer NF or the second service communication agent SCP; In response to the access token request from the second consumer NF or the second SCP, it operates as an access token authorization server agent representing the NF repository function NRF that does not support access token authorization; as well as Signaling communication is established 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.

Images