Methods, systems, and computer-readable media for resource object-level authorization in network functions (NF).

Abstract

A method for resource object level authorization in a network function (NF) includes a first NF maintaining a service-based interface (SBI) resource object access authorization policy database including policies for controlling access to SBI resource objects, and dynamically populating a resource object owner database including records for resource objects and corresponding resource object owners. The method further includes the first NF receiving a first SBI resource object access request from a second NF for accessing a resource object, accessing the resource object access authorization policy database and the resource object owner database using information from the first SBI resource object access request, determining that access to the resource object requested by the first resource object access request is not permitted, and preventing access to the resource object requested by the first resource object access request.

Description

Technical Field

[0001] Priority Claim This application claims the benefit of priority of U.S. Patent Application Serial No. 17 / 192,800, filed on March 4, 2021, the disclosure of which is hereby incorporated by reference.

[0002] Technical Field The subject matter described herein relates to network security. More specifically, the subject matter described herein relates to methods, systems, and computer-readable media for resource object-level authorization in network functions.

Background Art

[0003] Background In a 5G telecommunications network, network functions that provide services are called producer network functions (NFs) or NF service producers. Network functions that consume services are called 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 consuming and producing a 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, and a service endpoint is a point of contact 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 by 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 the Producer NF that provides a service. A given Producer NF can contain multiple NF instances. Note that multiple NF instances can share the same service endpoint.

[0005] Producer NFs register with the Network Functionality Repository (NRF). The NRF maintains service profiles of available NF instances, identifying the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably here. Consumer NFs can subscribe to receive information about producer NF instances 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 a 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 either distributes traffic among producer NF service instances providing the requested services or routes that traffic directly to the destination producer NF instance.

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

[0008] One issue in 5G communication networks is that authorization is defined at the network function level, but not at the service-based interface (SBI) resource object level, where a resource object is a data structure created in the producer NF that represents a consumer NF's request to access a service provided by the producer NF. For example, Section 13.4 of the 3rd Generation Partnership Project (3GPP®) Technical Specification (TS) 33.501 indicates that OAuth 2.0-based authorization should be used to determine whether a consumer network function can access a service provided by a producer network function. The OAuth 2.0 authorization procedure is defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749. Using the OAuth 2.0 authorization procedure, a consumer network function seeking to access a service presents an access token to the producer NF. The access token is signed by the requesting consumer NF using the NRF's public key. The producer NF verifies the access token and authorizes the consumer NF to access the requested service. Once the consumer NF is authorized to access the service, there is no defined authorization mechanism to prevent one network function from accessing resource objects created by another network function. In other words, all consumer NFs attempting to access a service provided by a given producer NF are provided with the same access token, and after that access token has been verified, no further authorization is performed. Therefore, consumer NF #2 may intentionally or unintentionally modify resource objects created by consumer NF #1.

[0009] Because there is no defined approval mechanism at the resource object level, there is a need for methods, systems, and computer-readable media for resource object-level approval in NF. [Overview of the Initiative] [Means for solving the problem]

[0010] overview A method for resource object level authorization in a network function (NF) includes a first NF maintaining a service-based interface (SBI) resource object access authorization policy database containing policies for controlling access to SBI resource objects. The method further includes the first NF dynamically populating a resource object owner database containing records about resource objects and their corresponding owner. The method further includes the first NF receiving a first SBI resource object access request from a second NF for access to a resource object. The method further includes the first NF using information from the first SBI resource object access request to access the resource object access authorization policy database and the resource object owner database and determining that access to the resource object requested by the first resource object access request is not permitted. The method further includes preventing access to the resource object requested by the first resource object access request in response to the determination that access to the resource object requested by the first resource object access request is not permitted.

[0011] According to another aspect of the subject described here, the first NF includes the Producer NF. According to another aspect of the subject described here, the first NF includes a Service Communications Proxy (SCP).

[0012] According to another aspect of the subject described herein, maintaining an SBI resource object access authorization policy database includes holding policies that have attributes identifying SBI resource objects, hypertext transfer protocol (HTTP) methods for accessing SBI resource objects, and consumer NF authorization scopes for SBI resource objects.

[0013] According to another aspect of the subject described herein, dynamically populating the resource object owner database includes receiving SBI resource object creation requests from consumer NFs, extracting the NF instance identifier of the consumer NF that initiated the SBI resource object creation request from the SBI resource object creation request, receiving a response from a producer NF confirming the success of the resource object creation, and, in response to receiving the response, storing the consumer NF's NF instance identifier and the corresponding resource object identifier in the resource object owner database.

[0014] According to another aspect of the subject described herein, extracting an NF instance identifier from an SBI resource object creation request involves extracting the NF instance identifier of a consumer NF from the subclaim attributes of the access token within the SBI resource object creation request.

[0015] According to another aspect of the subject described herein, accessing the resource object access authorization policy database includes extracting a resource object identifier from a first SBI resource object access request, performing a lookup in the resource object access authorization policy database using the resource object identifier, and finding a record in the resource object access authorization policy database that has a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.

[0016] According to another aspect of the subject described herein, determining that the access requested by the first SBI resource object access request is not permitted includes determining that access is permitted only to the owner of the resource object and determining that the second NF is not the owner of the resource object.

[0017] According to another aspect of the subject described herein, determining that the access requested by the first SBI resource object access request is not permitted includes determining that the type of access requested by the first SBI resource object access request is not permitted.

[0018] According to another aspect of the subject described herein, the method for resource object level authorization includes, in a first NF, receiving a second SBI resource object access request from a third NF to access a resource object, using information from the second SBI resource object access request to access the resource object access authorization policy database and the resource object owner database, and granting the third NF access to the resource object.

[0019] According to another aspect of the subject described herein, a system for resource object level authorization in a network function is provided. The system includes a first network function (NF) which includes at least one processor and memory. The system further includes an SBI resource object access authorization policy database located in memory for storing policies to control access to service-based interface (SBI) resource objects. The system further includes a resource object owner database for storing records which include resource object identifiers and corresponding resource object owner identifiers. The system further includes a resource object access authorization manager which dynamically populates records in the resource object owner database, receives a first SBI resource object access request from a second NF for accessing a resource object, uses information from the first SBI resource request to access the resource object access authorization policy database and the resource object owner database, determines that access to the resource object requested by the first SBI resource object access request is not permitted, and prevents access to the resource object requested by the first SBI resource object access request in response to the determination that access to the resource object requested by the first SBI resource object access request is not permitted.

[0020] According to another aspect of the subject described here, the SBI Resource Object Access Authorization Policy Database includes policies having attributes that identify SBI resource objects, hypertext transfer protocol (HTTP) methods for accessing SBI resource objects, and consumer NF authorization scopes for SBI resource objects.

[0021] According to another aspect of the subject described here, when dynamically populating the resource object owner database, the resource object access authorization manager is configured to receive SBI resource object creation requests from consumer NFs, to extract the NF instance identifier of the consumer NF that initiated the SBI resource object creation request from the SBI resource object creation request, to receive a response to the SBI resource object creation request from a producer NF confirming the success of the resource object creation, and in response to receiving the response, to store the NF instance identifier of the consumer NF and the corresponding resource object identifier in the resource object owner database.

[0022] According to another aspect of the subject described here, the resource object access authorization manager is configured to extract the consumer NF instance identifier from the subclaim attributes of the access token in the SBI resource object creation request.

[0023] According to another aspect of the subject described herein, when accessing the resource object access authorization policy database, the resource object access authorization manager is configured to extract a resource object identifier from a first SBI resource object access request, to perform a lookup in the resource object access authorization policy database using the resource object identifier, and to find a record in the resource object access authorization policy database that has a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.

[0024] According to another aspect of the subject matter described herein, when determining that the access requested by the first SBI resource object access request is not permitted, the resource object access approval manager is configured to determine that the access is only permitted to the owner of the resource object, and that the second NF is not the owner of the resource object.

[0025] According to another aspect of the subject matter described herein, when determining that the access requested by the first SBI resource object access request is not permitted, the resource object access approval manager is configured to determine that the type of access requested by the SBI resource object access request is not permitted.

[0026] According to another aspect of the subject described herein, a non-temporary computer-readable medium is provided which stores executable instructions that, when executed by the computer's processor, control the computer to perform a step. The step includes a first network function (NF) maintaining a service-based interface (SBI) resource object access authorization policy database, which includes policies for controlling access to SBI resource objects. The step further includes the first NF dynamically populating a resource object owner database, which includes records about resource objects and their corresponding owner. The step further includes the first NF receiving a first SBI resource object access request from a second NF for access to a resource object. The step further includes the first NF using information from the first SBI resource object access request to access the resource object access authorization policy database and the resource object owner database and determining that access to the resource object requested by the first SBI resource object access request is not permitted. The step further includes preventing access to the resource object requested by the first SBI resource object access request in response to the determination that access to the resource object requested by the first SBI resource object access request is not permitted.

[0027] The subject matter described herein can be implemented in software combined with hardware and / or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In an exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer-readable medium storing computer-executable instructions that control a computer to perform steps when executed by a processor of the computer. 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. Additionally, the computer-readable media implementing the subject matter described herein may be located on a single device or computing platform, or may be distributed across multiple devices or computing platforms.

Brief Description of Drawings

[0028] [Figure 1] It is a network diagram showing an exemplary 5G system network architecture. [Figure 2A] It is a message flow diagram showing an exemplary message exchanged to create a resource object in an NF service producer using the HTTP POST method. [Figure 2B] It is a message flow diagram showing an exemplary message exchanged to create a resource object in an NF service producer using the HTTP PUT method. [Figure 3A] It is a message flow diagram showing an exemplary message exchanged to read a single resource object using the HTTP GET method. [Figure 3B] It is a message flow diagram showing an exemplary message exchanged to query a set of resource objects using the HTTP GET method. [Figure 4A]This message flow diagram illustrates the example messages exchanged to update a resource object using the HTTP PUT method. [Figure 4B] This message flow diagram illustrates the example messages exchanged to update a resource object using the HTTP PATCH method. [Figure 5] This message flow diagram illustrates the example messages exchanged to delete a resource object using the HTTP DELETE method. [Figure 6A] This message flow diagram shows an example of messages exchanged to create a subscription resource object using the HTTP POST method. [Figure 6B] This message flow diagram illustrates the example messages exchanged to create a subscription resource object using the HTTP PUT method. [Figure 6C] This message flow diagram illustrates the example messages exchanged to update a subscription resource object using the HTTP PATCH method. [Figure 6D] This message flow diagram illustrates the typical provision of information about subscription resource objects using the HTTP POST method. [Figure 7A] This message flow diagram shows exemplary messages exchanged for Producer NF to obtain an access token from NRF. [Figure 7B] This message flow diagram shows an example of messages exchanged for a consumer NF to obtain an access token from an NRF. [Figure 7C] This message flow diagram illustrates the use of an access token by an NF service consumer to obtain or access a service provided by an NF service producer. [Figure 8]This message flow diagram illustrates unauthorized updates to resource objects using direct SBI communication. [Figure 9] This message flow diagram illustrates unauthorized updates to resource objects using indirect SBI communication. [Figure 10] This message flow diagram shows exemplary messages exchanged to prevent unauthorized access to resource objects using SBI indirect communication. [Figure 11] This block diagram shows an exemplary architecture of network functionality for providing SBI resource-level authorization. [Figure 12] This flowchart shows an exemplary process for SBI Resource Object-Level Approval. [Modes for carrying out the invention]

[0029] Detailed explanation Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. The architecture in Figure 1 includes an NRF100 and an SCP101, which may reside in the same home public land mobile network (HPLMN). As described above, the NRF100 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 SCP101 may also support service discovery and selection of producer NF instances. The SCP101 may perform load balancing of connections between consumer NFs and producer NFs.

[0030] NRF100 is a repository for NF or service profiles of 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 NRF100. An NF or service profile is a JavaScript object notation (JSON) data structure as defined in 3GPP TS 29.510. An NF or service profile definition includes at least one of the following: a fully qualified domain name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address.

[0031] In Figure 1, any of the network functions can be a consumer NF, a producer NF, or both, depending on whether they request, provide, or both request and provide services. In the illustrated example, 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.

[0032] The NF shown in Figure 1 further includes a Session Management Function (SMF) 108 that manages the session between the Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs operations similar to the mobility management operations performed by the Mobility Management Entity (MME) in a 4G network. The Authentication Server Function (AUSF) 112 performs authentication services for user devices (UEs), such as user devices (UEs) 114, that request access to the network.

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

[0034] The Wireless Access Network (RAN) 120 connects the User Equipment (UE) 114 to the network via a wireless link. The Wireless Access Network 120 may be accessed using a g-Node B (gNB) (not shown in Figure 1) or other wireless access points. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. One example of such a proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 may also support performance measurement functions that may be used by the UE 114 to obtain network performance measurements. Figure 1 also shows the Data Network (DN) 124, which the UE uses to access data network services such as Internet services.

[0035] SEPP126 filters incoming traffic from another PLMN and performs topology concealment for traffic leaving the home PLMN. SEPP126 may also communicate with SEPP within the external PLMN, which manages the security of the external PLMN. Thus, traffic between NFs within different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the external PLMN.

[0036] As mentioned above, one issue with the 3GPP network architecture for 5G networks is that while 3GPP TS 33.501 specifies that the OAuth 2.0 authorization procedure should be used for NF service producers to authorize requests from NF service requesters, different producer NFs can access resources using the same OAuth 2.0 access token, which could lead to data disclosure to unauthorized 5G NFs, data loss, denial of service, or data manipulation. The subject matter described herein provides a method for protecting 5G SBI API resource objects from unauthorized access by 5G consumer NFs. Examples of unauthorized access include read access, delete access, and update access. In one implementation, 5G SBI API resource object level authorization is implemented at the service communication proxy or SCP. In another implementation, 5G SBI API resource object level authorization is implemented at the producer NF.

[0037] An SBI resource object is a data structure created in an NF service producer using the SBI interface, which allows NF service consumers to access services provided by the NF service producer. Figure 2A shows an example of creating an SBI resource object using the HTTP POST method. Referring to Figure 2A, at line 1 of the message flow diagram, NF service consumer 200 sends an HTTP POST message to NF service producer 202, which then creates a new resource object. The HTTP POST message identifies the child resource using a Unified Resource Identifier (URI). In response to the HTTP POST message, NF service producer 202 creates the requested resource object and, at line 2, sends a 201 Created message to NF service consumer 200 indicating that the requested resource object has been created. Note that there is no authorization for access to the newly created resource object, meaning that any NF service consumer other than NF service consumer 200 can access that newly created resource object.

[0038] In another example, a resource object may be created in an NF service producer using the HTTP PUT method. This method is shown in Figure 2B. In line 1 of the message flow in Figure 2B, an NF service consumer 200 sends an HTTP PUT message to an NF service producer 202. The PUT message specifies the resource object that the NF service consumer 200 wishes to create in the NF service producer 202. In response to the HTTP PUT message, the NF service producer 202 creates the requested resource object and sends a 201 Created message to the NF service consumer 200 on line 2. Similar to resource objects created using the POST method, resource objects created using the PUT method can also be accessed without authorization at the resource object level by any consumer NF that obtains an access token from the NRF.

[0039] One way a consumer NF can access an SBI resource object is by using the HTTP GET method. Figure 3A shows an example of accessing an SBI resource object using the HTTP GET method. As mentioned above, an existing resource object can be accessed by the consumer NF that created the resource object, or by a consumer NF that did not create the resource object. In Figure 3A and the rest of the figures, it is assumed that NF service consumer 200 is the creator of the resource object, and NF service consumer 300 is a consumer NF other than the creator of the resource object that is attempting to access that resource object. Referring to Figure 3A, at line 1, NF service consumer 200 or 300 sends an HTTP GET message to NF service producer 202 that identifies the SBI resource object. In Figure 3A, the resource object is a single resource identified by a URI and possibly other query parameters. NF service producer 202 responds to the HTTP GET message at line 2 by sending a 200 OK message along with the requested representation of the resource object. It should be noted that, aside from requiring a valid network access token, no authorization is performed by the NF service producer 202 before the provision of the resource object representation. Therefore, authorized consumer NFs, such as consumer NF200 that created the resource object, can access the resource object, while unauthorized consumer NFs, such as consumer NF300, can access the resource object because there is no authorization procedure defined at the resource object level.

[0040] In another example, an NF service consumer 200 or 300 can access a set of resources using the HTTP GET method. This example is shown in Figure 3B. In line 1 of the message flow in Figure 3B, the NF service consumer 200 or 300 sends an HTTP GET message to the NF service producer 202. The HTTP GET message specifies query parameters that identify the set of resources. The query component, along with the data in the routing component, contains non-hierarchical data used by the NF service producer 202 to filter the resources identified within the scope of the URI scheme into a subset of resources that match the query parameters. The query component is indicated by an initial "?" character and terminated by a "#" character at the end of the URI. Access to multiple resources, as well as access to a single resource, may be provided to an unauthorized consumer NF.

[0041] Another type of resource object access is access to update resource objects. Figure 4A is a message flow diagram illustrating the use of the HTTP PUT method to update a resource object. The HTTP PUT method allows a service consumer NF to update information stored in a producer NF by complete replacement. The PUT method replaces the current representation of a resource object with a new representation. Referring to the message flow shown in Figure 4, on line 1, an NF service consumer 200 or 300 sends an HTTP PUT message to an NF service producer 202. The PUT message includes the identifier of the resource object and the resource object representation representing the resource object to be replaced. On line 2 of the message flow diagram, the NF service producer 202 replaces the resource object with the new resource representation and responds with a 200 OK message if the replacement was successful, or a 204 No Content message if the replacement operation was unsuccessful. There is no authorization at the resource object level before performing resource object replacement.

[0042] Figure 4B is a message flow diagram illustrating the use of the HTTP PATCH method to update an existing resource object. The HTTP PATCH method allows a consumer NF to update information stored in a producer NF by partial replacement. The PATCH method modifies the current representation of the resource object according to the modification instructions provided in the PATCH method. Referring to the message flow in Figure 4B, at line 1, an NF service consumer 200 or 300 sends an HTTP PATCH message to an NF service producer 202. The HTTP PATCH message identifies the resource object to be modified and includes modification instructions. At line 2 of the message flow diagram, the NF service producer 202 replaces or modifies the resource object if it exists in the NF service producer 202, or sends a 204 No Content message if it does not exist. Again, there is no authorization at the resource object level in this case. A legitimate consumer, such as consumer NF200 which created the resource or another consumer NF300 which did not create the resource, can modify the resource object by presenting a valid access token obtained from the NRF.

[0043] Another type of access to resource objects is delete access. Figure 5 is a message flow diagram illustrating the use of the HTTP DELETE method to delete a resource object. The HTTP DELETE method allows an NF service consumer to delete an entire resource object in an NF service producer. Referring to the message flow in Figure 5, on line 1, an NF service consumer 200 or 300 sends an HTTP DELETE message to an NF service producer 202. The NF service producer 202 determines whether the resource object identified in the DELETE message exists in the NF service producer 202, and if it does, deletes the resource object. On line 2, the NF service producer 202 responds with a 202 Accepted message if the delete operation was successful, and with a 204 No Content message if the delete operation was unsuccessful. There is no resource object level authorization performed for the HTTP DELETE method. As long as NF service consumer 200 or 300 has a signed access token to producer NF202 obtained using the OAuth 2.0 procedure, NF service consumer 200 or 300 can access and delete its resource object.

[0044] In addition to the request / response communications described above, resource objects can be created, read, and modified using subscribe / notification communications. Figure 6A is a message flow diagram showing how an NF service consumer creates a subscription resource object using the HTTP POST method. Referring to Figure 6A, on line 1, an NF service consumer 200 or 300 sends an HTTP POST message to an NF service producer 202. The HTTP POST message identifies the subscription resource object to be created. In response to the HTTP POST message, on line 2, the NF service producer 202 creates the requested subscription resource object and responds to the POST message with a 201 Created message indicating that the subscription resource object has been created.

[0045] Figure 6B illustrates the updating of a subscription resource object using the HTTP PUT method. The HTTP PUT method allows an NF service consumer to replace an existing subscription resource object in an NF service producer. Referring to Figure 6B, on line 1, an NF service consumer 200 or 300 sends an HTTP PUT message to an NF service producer 202. The HTTP PUT message identifies the subscription resource object created in Figure 6A. In response to the HTTP PUT method, the NF service producer 202 either replaces the subscription resource object with the new representation of the subscription resource object specified in the PUT message, or, if the PUT operation is unsuccessful, responds with a 204 No Content message. No resource object level authorization is required to perform a PUT operation for an existing subscription.

[0046] Figure 6C illustrates the use of the HTTP PATCH method to modify a subscription. Referring to Figure 6C, at line 1 of the message flow diagram, an NF service consumer 200 or 300 sends an HTTP PATCH message to an NF service producer 202, along with the identifier of the subscription resource object and the instruction to modify the subscription resource object. In response to the HTTP PATCH message, the NF service producer 202 responds with a 200 OK message if the subscription has been successfully modified, or with a 204 No Content message if the subscription has not been successfully modified. There is no authorization at the resource object level.

[0047] Figure 6D illustrates the use of the HTTP POST method to send notifications about existing subscriptions. Referring to Figure 6D, in line 1 of the message flow diagram, NF service producer 202 sends an HTTP POST message to NF service consumer 200 or 300 containing a notification triggered by a condition specified in the existing subscription resource object. In line 2, NF service consumer 200 or 300 responds with a 200 OK or 204 No Content message, depending on whether the POST operation was successful. Thus, Figure 6D demonstrates that a legitimate or unauthorized service consumer can obtain information about existing subscriptions by receiving notifications triggered by resource events without resource object-level authorization.

[0048] Figures 7A and 7B illustrate the authorization framework specified in 3GPP TS 33.501. According to Section 13.4.1 of 3GPP TS 33.501, NF service producers authorize requests from NF service request consumers using the OAuth 2.0 framework, as specified in IETF RFC 6749. According to Section 4.4 of IETF RFC 6749, the authorization is of the client credential authorization type, meaning that the client's credentials are authorized at the client level. The mechanism for NF service consumers to access services provided by NF service producers is a JSON web token, as specified in IETF RFC 7515, protected by a digital signature based on a JSON web signature, as specified in IETF RFC 7515, or a message authentication code.

[0049] Figure 7A illustrates the procedure for an NF service producer to create a profile with the NRF. Referring to Figure 7A, in line 1, the NF service producer 202 sends an Nnrf_NFManagement_NFRegister request to the NRF 100. In step 2, the NRF 100 stores the NF profile for the producer NF. In step 3, the NRF 100 responds with an Nnrf_NFManagement_NFRegister response indicating that the NF profile has been successfully established.

[0050] Figure 7B illustrates the process by which an NF service consumer obtains an access token from NRF100. Referring to Figure 7B, in line 1, an NF service consumer 200 or 300 sends an NRF access token GET request to NRF100, identifying the service for which access is requested. In line 2, NRF100 authorizes the client (NF service consumer 200 or 300) and generates an access token for accessing the service identified in the NRF access token GET request. In line 3, NRF100 responds with an NRF access token GET response containing the access token, providing the access token to the NF service consumer 200 or 300. The access token allows any service consumer to access resource objects created in producer NF202, regardless of whether the NF service consumer is the creator of the resource object.

[0051] Figure 7C illustrates the use of an access token by an NF service consumer 200 or 300 to obtain or access a service provided by an NF service producer 202. Referring to Figure 7C, in line 1, the NF service consumer 200 or 300 sends a service request to the NF service producer 202. The service request includes an access token. In line 2, the NF service producer 202 verifies the access token and provides access to the requested service. No authorization is performed at the resource object level. As long as the NF service consumer 200 or 300 presents a valid access token, the resource object can be read, modified, or deleted.

[0052] Figure 8 is a message flow diagram illustrating direct SBI communication, where a consumer NF communicates directly with a producer NF to create an SBI resource object and access that resource object. Referring to Figure 8, in line 1, consumer NF200 sends a message to producer NF202 to create a resource object. It is assumed that consumer NF200 has previously obtained an access token from the NRF to access the service provided by producer NF202. The access token is included in the resource creation request message, which is an HTTP PUT or POST message in the illustrated example. In line 2, producer NF202 responds to the resource creation request message with a 201 Created message containing the resource data.

[0053] In line 3 of the message flow in Figure 8, consumer NF200 sends a message to producer NF202 to update the resource object. The update message may be an HTTP PUT or PATCH message and includes an access token obtained from the NRF. In line 4, producer NF202 verifies the access token and updates the resource object as shown by the 5G resource table 800. The data at timestamp T4 is modified compared to the data when the resource object was created at timestamp T2.

[0054] In line 5 of the message flow diagram, Consumer NF300, which is not authorized to access the resource object created by Consumer NF200, can access the resource object by obtaining an access token from NRF100 and accessing the 5G NF service API. Consumer NF300 sends an update message about the resource created by Consumer NF200. In line 6, Producer NF202 verifies the access token and updates the resource object to include the corrected data, as indicated by the timestamp T6 in the 5G SBI resource table 800.

[0055] In another example, consumer NF300 can read data from a resource object created by another consumer NF. This example is shown in lines 7 and 8 of the message flow diagram, where consumer NF202 sends an HTTP GET request to producer NF202, which verifies the access token in the GET request and responds with the resource data in line 8.

[0056] Lines 9 and 10 of the message flow diagram illustrate yet another example of unauthorized access to a resource object created by another consumer NF. In line 9, consumer NF300 sends an HTTP DELETE message to delete the resource object created by consumer NF200 in lines 1 and 2. The DELETE message includes an access token obtained from the NRF. In line 10, producer NF202 responds with a 202 Accepted message indicating that the DELETE operation was successful. Thus, Figure 8 illustrates unauthorized access to an SBI resource object using the 5G direct SBI communication model.

[0057] Figure 9 illustrates unauthorized access to an SBI resource object using an indirect communication model in which a consumer NF sends resource creation and update requests to an intermediate SCP, and the SCP communicates with the producer NF to create and update the corresponding resource object. Referring to Figure 9, in line 1 of the message flow diagram, consumer NF200 sends a resource creation message to SCP101. SCP101 forwards the resource creation request to producer NF202. In line 2, producer NF202 creates the requested resource and sends a 201 Created message along with the resource data to SCP101. SCP101 forwards the 201 Created message to consumer NF200.

[0058] In line 3 of the message flow diagram, consumer NF200 sends a resource update message to SCP101 to update the resource object created in lines 1 and 2. SCP101 forwards the update message to producer NF202. In line 4, producer NF202 verifies the access token and updates the resource object to include the data in the update message, as indicated by the timestamp T4 in the 5G SBI resource table 800. Producer NF202 sends a 200 OK message indicating that the resource was successfully updated, or a 204 No Content message if the update failed.

[0059] In line 5 of the message flow diagram, consumer NF300 sends an update request to SCP101. SCP101 forwards the update request to producer NF202. Since the request has a valid access token, in line 6, producer NF202 updates the resource object to include the data in the update request, as indicated by the timestamp T6 in the 5G resource table 800. Producer NF202 sends an update message to SCP101, which forwards the message to consumer NF200.

[0060] In line 7 of the message flow diagram, consumer NF300 sends a message to SCP101 to read a resource created by producer NF202. SCP101 forwards the request to producer NF202. In line 8, producer NF202 verifies the access token and sends the message along with the resource data to SCP101. SCP101 forwards the message along with the resource data to consumer NF300.

[0061] In line 9, consumer NF300 sends a message to SCP101 to delete a resource created by consumer NF200. SCP101 forwards the message to producer NF202. Producer NF202 verifies the access token in the DELETE message, deletes the resource, and responds with a 202 Accepted message indicating that the deletion operation was successful. Thus, Figure 9 illustrates the use of 5G SBI indirect communication, where resource objects can be updated or even deleted without authorization at the resource object level.

[0062] To avoid the difficulties associated with unauthorized access to resource objects, the subject matter described herein includes an SBI resource object level access authorization service, which may be maintained in the SCP for use in an indirect communication model, or in the Producer NF for use in a direct communication model. The SBI resource object level authorization service may operate separately and independently from the OAuth 2.0 authorization implemented by the Producer NF. Therefore, even if an NF service consumer has a valid OAuth 2.0 access token, the SBI resource object level authorization service may prevent the NF service consumer from accessing the resource object if the access requested by the NF service consumer fails to access the SBI resource object level authorization service described herein.

[0063] According to one aspect of the subject described herein, the SBI Resource Object Level Authorization Service dynamically populates the resource object owner database with SBI resource object owner information. To dynamically populate the database, the SBI Resource Object Level Access Authorization Service may extract consumer NF information from the access token received in the 5G SBI resource creation request when it receives a success response message from the producer NF confirming the creation of the resource. Consumer NF information may be extracted from the sub-access token claims defined in 3GPP TS 29.510, section 6.3.5.2.4. Table 1 shown below is a copy of Table 6.3.5.2.4-1 from 3GPP TS 29.510.

[0064] [Table 1-1]

[0065] [Table 1-2]

[0066] As shown in Table 1, the sub-access token claim includes the NF instance ID of the consumer NF, which, in the context of the resource object creation request message for creating a resource from the consumer NF to the producer NF, includes the NF instance ID of the resource creator. The SBI Resource Object Level Access Authorization Service stores this NF instance ID, along with the resource ID extracted from either the resource object request or response message, in the resource object owner database. For subsequent requests concerning 5G resource objects, the Resource Object Level Access Authorization Service evaluates the instance identifier of the consumer NF in the request against the dynamically stored instance identifier of the resource object owner, applies the 5G SBI Resource Object Level Authorization policy set by the operator, and permits or denies the 5G SBI resource access request based on that policy.

[0067] Tables 2 and 3 below show the records that may appear in the 5G SBI Resource Object Access Approval Policy Database and the 5G SBI Resource Object Owner Database, respectively, which may be maintained by the Resource Object Level Access Approval Service in SCP or Producer NF.

[0068] [Table 2]

[0069] [Table 3]

[0070] In Table 2, an exemplary 5G SBI resource object access authorization policy database record includes the following attributes for a given resource object access authorization policy: 5G SBI NF service, 5G SBI resource URI, HTTP method, and authorized consumer NF range. The 5G SBI NF service attribute stores the name of the 3GPP-defined SBI NF service and can store the name of any 3GPP-defined NF service. Exemplary values ​​for the 5G SBI NF service attribute in Table 2 include Npcf-eventexposure and Nnrf-udm. The 5G resource URI attribute stores the 3GPP-defined 5G SBI resource URI for the resource object. Exemplary values ​​for this attribute in Table 2 include / subscriptions and / nf-instances, which are intended to represent URIs for a particular 5G resource object. The HTTP method attribute stores the HTTP method for a particular policy rule. In Table 2, defined HTTP methods for exemplary policy rules are GET, PUT, PATCH, and DELETE. The approved consumer NF range attribute defines the range of consumer NFs to which the policy rule applies. The values ​​for this attribute in Table 2 include NF instance, NF-Set, NF-Type, NetworkSlice, PLMN, and all.

[0071] The data in Table 2 may be provisioned by the network operator at NF configuration time, according to network operator-specific policies. The data in Table 3 may be dynamically populated at runtime, when resource objects are created. In Table 3, exemplary attributes for resource object ownership database records include resource URI and resource owner. The resource URI attribute stores the URI for the newly created resource object. The resource owner attribute stores the NF instance ID of the consumer NF that requested the creation of the resource. If the resource owner database is maintained in the SCP, the fields in Table 3 may be populated using resource object owner information extracted from the corresponding resource object creation request when the SCP receives a resource request creation response from the producer NF. If the resource owner database is maintained in the producer NF, the data in Table 3 may be populated using resource object owner information extracted from the resource object creation request when the producer NF creates the resource object.

[0072] The data in the resource owner database will be used in conjunction with the data in the resource object access authorization policy database to determine whether to grant consumer NF access to a particular resource object. For example, if the defined scope for a particular resource object in the resource object access authorization policy database is an NF instance, and a message arrives to update that resource object, the resource object level access authorization service may determine whether a policy is set for that resource object. Determining whether a policy is set for that resource object may involve performing a lookup in the resource object access authorization policy database using the resource URI identified in the update request message. If the resource URI in the resource object update request message matches that resource URI for one of the policy rules, the resource object level access authorization service may use the data stored in the resource object owner database to determine whether granting access would violate the policy. For example, if the resource object access policy indicates that access to a resource object should only be granted if the NF instance ID of a consumer NF in the access request message matches the NF instance ID of the resource object owner, then the access request should be denied if the NF instance IDs do not match.

[0073] Figure 10 illustrates the use of the resource object level authorization access authorization service described above for managing access to SBI resource objects at the resource object level. Figure 10 shows an example of a resource object access authorization policy database 1000 containing resource object access authorization policy rules configured by the network operator, and a resource object owner database 1002 containing dynamically populated resource object owner information. In Figure 10, databases 1000 and 1002 are located in SCP101. However, as mentioned above, these databases may alternatively be configured in a producer NF that provides services corresponding to the protected resource objects.

[0074] Referring to the message flow in Figure 10, on line 1, consumer NF200 sends a message to SCP101 to create a resource object in producer NF202. SCP101 forwards the resource object creation request to producer NF202. SCP101 can extract the NF instance ID from the access token subclaims of the resource object creation request. On line 2, producer NF202 creates the resource object and responds with a 201 Created message. Producer NF202 forwards the 201 Created message to SCP101, and SCP101 stores the resource URI extracted from the response message, along with the consumer NF's NF instance ID extracted from the resource object creation request message, in the resource object owner database. Alternatively, instead of extracting the resource URI from the response message, SCP101 may extract the resource URI from the resource object creation request message. SCP101 then has a complete record for the resource at this point, identifying the resource object and its owner. SCP101 forwards the 201 Created message to consumer NF200.

[0075] On line 3, consumer NF200 sends a message to update the resource object. SCP101 receives the message, determines that a certain policy applies to the resource object, and determines that the update request should be allowed because the NF instance ID of the consumer NF in the resource object update request matches the NF instance ID of the resource object owner identified in the SBI resource table. Therefore, on line 4, SCP101 forwards the resource object update request to producer NF202, and producer NF updates the resource object. On line 4, producer NF202 forwards a 200 OK message to SCP101, and SCP101 forwards a 200 OK message to consumer NF200.

[0076] On line 5, consumer NF300 generates a message and sends it to SCP101 requesting that the resource created by consumer NF200 be updated. SCP101 determines that a certain policy applies to the resource update request, compares the NF instance ID of consumer NF300 obtained from the update request with the NF instance ID of the resource object owner, and determines that the request violates the policy. Therefore, on line 6, SCP101 rejects the update request and sends an error response, such as a 403 Forbidden message, to consumer NF300.

[0077] In line 7, consumer NF300 sends a read request to read a resource object created at the request of consumer NF200. SCP101 receives the read request and approves or rejects the request based on the authorization policy set for that resource. In the illustrated example, the read request is approved. However, if the read operation is not permitted, the read request will be rejected, similar to an update request.

[0078] In line 9 of the message flow diagram, consumer NF300 sends a delete request to SCP101 for a resource object created at the request of consumer NF200. In this example, SCP101 evaluates the delete request against the configured policy, determines that the delete request is not permitted, and rejects the delete request message. Thus, using the steps shown in Figure 10, unauthorized access to the resource object is prevented based on the resource access level authorization policy.

[0079] Figure 11 is a block diagram illustrating an exemplary architecture of an SCP or producer NF101 or NF202 that implements the resource object level authorization described herein. Referring to Figure 11, the SCP101 or producer NF202 includes at least one processor 1100 and memory 1102. The resource object access authorization policy database 1000 may be stored in memory 1102 and may contain the operator-configured resource object level policy rules described above. The resource object owner database 1002 may also be stored in memory 1102 and may be populated by the SCP101 or producer NF202 at runtime. The SCP101 or consumer NF202 may further include a resource object access authorization manager 1104 that dynamically populates the resource object owner database 1002 and uses the data in databases 1000 and 1002 to perform the steps described herein for resource object level access authorization. The resource object access authorization manager 1104 may be implemented using computer executable instructions stored in memory 1102 and executed by the processor 1100.

[0080] Figure 12 is a flowchart illustrating an exemplary process for providing resource object level authorization in a network function. Referring to Figure 12, in step 1200, the process includes a first network function (NF) maintaining a service-based interface (SBI) resource object access authorization policy database containing policies for controlling access to SBI resource objects. For example, an SCP or producer NF may be configured with a database containing resource object access authorization policies set by the network operator. Examples of such policies are described above in Table 2 and with respect to resource object access authorization policy database 1000. A policy may have identifiers for the resource objects to which each policy relates, and a range of identifiers for the NFs to which the policy applies.

[0081] In step 1202, the process includes the first NF dynamically populating a resource object owner database containing records about resource objects and their corresponding resource object owners. For example, the resource object access authorization manager 1104 may extract an NF instance identifier from the access token subclaims contained in the resource object creation request message from the consumer NF and, in response to receiving a success response from the producer NF confirming the creation of the resource object, create a record in the resource object owner database that identifies the consumer NF and its corresponding resource object.

[0082] In step 1204, the process includes the first NF receiving a first SBI resource access request from the second NF to access a resource object. For example, an SCP or producer NF may receive an HTTP GET, PUT, PATCH, or DELETE message from a consumer NF attempting to read, update, or delete an existing resource object.

[0083] In step 1206, the process includes the first NF using information from the SBI resource object access request to access the resource object access authorization policy database and the resource object owner database, and determining that the access requested by the resource object access request is not permitted. For example, the resource object access authorization manager 1104 may determine from the resource object access control policy that only the resource owner can access the resource, and that the requesting consumer NF is not the owner. In another example, the resource object access authorization manager 1104 may determine that the type of access requested by the first SBI resource object access request is not permitted. For example, a resource object authorization policy may stipulate that a consumer NF of the same type as the resource object owner can read the resource object using the HTTP GET method, but cannot modify or delete the resource object using the HTTP PUT, PATCH, or DELETE methods. The resource object owner may be permitted to modify the resource object using the HTTP PUT, PATCH, or DELETE methods.

[0084] In step 1208, the process includes preventing access requested by a resource object access request in response to determining that the access requested by the resource object access request is not permitted. For example, in the case of an SCP, the resource object access authorization manager 1104 may prevent access by not forwarding the access request to the producer NF. If the producer NF implements access control, preventing the requested access may include ignoring the request. In either the SCP or producer NF implementation, the resource object access authorization manager 1104 may generate and send an error message to the requesting party, store the request, and notify the network operator of the denied access attempt.

[0085] Each of the following references is incorporated herein by reference in its entirety. reference 1. 3GPP TS 33.501 V17.0.0 (2020-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architectures and Procedures for 5G System (Release 17). 2. 3GPP TS 29.510 V17.0.0 (2020-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17). 3. 3GPP TS 29.500 V17.1.0 (2020-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 17). 4. 3GPP TS 29.501 V17.0.0 (2020-12) 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Principles and Guidelines for Services Definition; Stage 3 (Release 17). 5. Hardt, D., The OAuth2.0 Authorization Framework, IETF RFC 6749 (October 2012). 6. Jones et al., JSON Web Token, IETF RFC 7519 (May 2015). 7. Jones et al., JSON Web Signature, IETF RFC 7515 (May 2015). It will be understood that various details of the subject matter described herein may be modified without deviating from the scope of the subject matter described herein. Furthermore, the foregoing description is for illustrative purposes only and not intended to be limiting, and the subject matter described herein is defined by the claims set forth below.

Claims

1. A method for resource object-level authorization in network functionality, The first network function (NF) maintains an SBI resource object access authorization policy database, which includes policies for controlling access to service-based interface (SBI) resource objects, The first NF dynamically populates a resource object owner database containing records about resource objects and their corresponding owner, The first NF receives a first SBI resource object access request from the second NF to access the resource object, The first NF uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, and determines that access to the resource object requested by the first SBI resource object access request is not permitted. This includes preventing access to the resource object requested by the first SBI resource object access request in response to a determination that the access to the resource object requested by the first SBI resource object access request is not permitted, A method for maintaining the SBI resource object access authorization policy database, comprising maintaining policies having attributes that identify an SBI resource object, hypertext transfer protocol (HTTP) methods for accessing the SBI resource object, and consumer NF authorization scopes for the SBI resource object.

2. A method for resource object-level authorization in network functionality, The first network function (NF) maintains an SBI resource object access authorization policy database, which includes policies for controlling access to service-based interface (SBI) resource objects, The first NF dynamically populates a resource object owner database containing records about resource objects and their corresponding owner, The first NF receives a first SBI resource object access request from the second NF to access the resource object, The first NF uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, and determines that access to the resource object requested by the first SBI resource object access request is not permitted. This includes preventing access to the resource object requested by the first SBI resource object access request in response to a determination that the access to the resource object requested by the first SBI resource object access request is not permitted, A method for accessing the SBI resource object access authorization policy database, comprising: extracting a resource object identifier from the first SBI resource object access request; performing a lookup in the SBI resource object access authorization policy database using the resource object identifier; and finding a record in the SBI resource object access authorization policy database that has a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.

3. A method for resource object-level authorization in network functionality, The first network function (NF) maintains an SBI resource object access authorization policy database, which includes policies for controlling access to service-based interface (SBI) resource objects, The first NF dynamically populates a resource object owner database containing records about resource objects and their corresponding owner, The first NF receives a first SBI resource object access request from the second NF to access the resource object, The first NF uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, and determines that access to the resource object requested by the first SBI resource object access request is not permitted. This includes preventing access to the resource object requested by the first SBI resource object access request in response to a determination that the access to the resource object requested by the first SBI resource object access request is not permitted, A method for determining that the access requested by the first SBI resource object access request is not permitted, comprising determining that such access is permitted only to the owner of the resource object, and determining that the second NF is not the owner of the resource object.

4. A method for resource object-level authorization in network functionality, The first network function (NF) maintains an SBI resource object access authorization policy database, which includes policies for controlling access to service-based interface (SBI) resource objects, The first NF dynamically populates a resource object owner database containing records about resource objects and their corresponding owner, The first NF receives a first SBI resource object access request from the second NF to access the resource object, The first NF uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, and determines that access to the resource object requested by the first SBI resource object access request is not permitted. This includes preventing access to the resource object requested by the first SBI resource object access request in response to a determination that the access to the resource object requested by the first SBI resource object access request is not permitted, A method for determining that the access requested by the first SBI resource object access request is not permitted, which includes determining that the type of access requested by the first SBI resource object access request is not permitted.

5. A method for resource object-level authorization in network functionality, The first network function (NF) maintains an SBI resource object access authorization policy database, which includes policies for controlling access to service-based interface (SBI) resource objects, The first NF dynamically populates a resource object owner database containing records about resource objects and their corresponding owner, The first NF receives a first SBI resource object access request from the second NF to access the resource object, The first NF uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, and determines that access to the resource object requested by the first SBI resource object access request is not permitted. In response to determining that the access to the resource object requested by the first SBI resource object access request is not permitted, the system prevents the access to the resource object requested by the first SBI resource object access request. A method comprising: the first NF receiving a second SBI resource object access request from a third NF for accessing the resource object; using information from the second SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database; and granting the third NF access to the resource object.

6. The method according to any one of claims 1 to 5, wherein the first NF includes a producer NF.

7. The method according to any one of claims 1 to 5, wherein the first NF includes a service communication proxy (SCP).

8. The method according to any one of claims 1 to 7, wherein dynamically populating the resource object owner database includes receiving an SBI resource object creation request from a consumer NF, extracting the NF instance identifier of the consumer NF that initiated the SBI resource object creation request from the SBI resource object creation request, receiving a response from a producer NF confirming the success of the creation of the resource object, and storing the NF instance identifier of the consumer NF and the corresponding resource object identifier in the resource object owner database in response to receiving the response to the SBI resource object creation request.

9. The method according to claim 8, wherein extracting the NF instance identifier from the SBI resource object creation request includes extracting the NF instance identifier of the consumer NF from the subclaim attribute of the access token in the SBI resource object creation request.

10. A system for resource object-level authorization in network functions, A first network function (NF) comprising at least one processor and memory, The aforementioned memory contains an SBI resource object access authorization policy database for storing policies to control access to service-based interface (SBI) resource objects, A resource object owner database for storing records containing resource object identifiers and corresponding resource object owner identifiers, The system includes a resource object access authorization manager that dynamically populates the records in the resource object owner database, receives a first SBI resource object access request from a second NF to access a resource object, uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, determines that access to the resource object requested by the first SBI resource object access request is not permitted, and, in response to the determination that access to the resource object requested by the first SBI resource object access request is not permitted, prevents access to the resource object requested by the first SBI resource object access request. The SBI resource object access authorization policy database is a system that includes policies having attributes that identify SBI resource objects, hypertext transfer protocol (HTTP) methods for accessing the SBI resource objects, and consumer NF authorization scopes for the SBI resource objects.

11. A system for resource object-level authorization in network functions, A first network function (NF) comprising at least one processor and memory, The aforementioned memory contains an SBI resource object access authorization policy database for storing policies to control access to service-based interface (SBI) resource objects, A resource object owner database for storing records containing resource object identifiers and corresponding resource object owner identifiers, The system includes a resource object access authorization manager that dynamically populates the records in the resource object owner database, receives a first SBI resource object access request from a second NF to access a resource object, uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, determines that access to the resource object requested by the first SBI resource object access request is not permitted, and, in response to the determination that access to the resource object requested by the first SBI resource object access request is not permitted, prevents access to the resource object requested by the first SBI resource object access request. A system in which, when accessing the SBI resource object access authorization policy database, the resource object access authorization manager is configured to extract a resource object identifier from the first SBI resource object access request, to perform a lookup in the SBI resource object access authorization policy database using the resource object identifier, and to find a record in the SBI resource object access authorization policy database that has a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.

12. A system for resource object-level authorization in network functions, A first network function (NF) comprising at least one processor and memory, The aforementioned memory contains an SBI resource object access authorization policy database for storing policies to control access to service-based interface (SBI) resource objects, A resource object owner database for storing records containing resource object identifiers and corresponding resource object owner identifiers, The system includes a resource object access authorization manager that dynamically populates the records in the resource object owner database, receives a first SBI resource object access request from a second NF to access a resource object, uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, determines that access to the resource object requested by the first SBI resource object access request is not permitted, and, in response to the determination that access to the resource object requested by the first SBI resource object access request is not permitted, prevents access to the resource object requested by the first SBI resource object access request. A system configured such that, when determining that the access requested by the first SBI resource object access request is not permitted, the resource object access authorization manager determines that the access is permitted only to the owner of the resource object, and that the second NF is not the owner of the resource object.

13. A system for resource object-level authorization in network functions, A first network function (NF) comprising at least one processor and memory, The aforementioned memory contains an SBI resource object access authorization policy database for storing policies to control access to service-based interface (SBI) resource objects, A resource object owner database for storing records containing resource object identifiers and corresponding resource object owner identifiers, The system includes a resource object access authorization manager that dynamically populates the records in the resource object owner database, receives a first SBI resource object access request from a second NF to access a resource object, uses information from the first SBI resource object access request to access the SBI resource object access authorization policy database and the resource object owner database, determines that access to the resource object requested by the first SBI resource object access request is not permitted, and, in response to the determination that access to the resource object requested by the first SBI resource object access request is not permitted, prevents access to the resource object requested by the first SBI resource object access request. A system in which, when determining that the access requested by the first SBI resource object access request is not permitted, the resource object access authorization manager is configured to determine that the type of access requested by the first SBI resource object access request is not permitted.

14. The system according to any one of claims 10 to 13, wherein the first NF includes a producer NF.

15. The system according to any one of claims 10 to 13, wherein the first NF includes a service communication proxy (SCP).

16. The system according to any one of claims 10 to 15, wherein when dynamically populating the resource object owner database, the resource object access authorization manager is configured to receive SBI resource object creation requests from consumer NFs, to extract the NF instance identifier of the consumer NF that initiated the SBI resource object creation request from the SBI resource object creation request, to receive a response from a producer NF confirming the success of the creation of the resource object, and in response to receiving the response, to store the NF instance identifier of the consumer NF and the corresponding resource object identifier in the resource object owner database.

17. The system according to claim 16, wherein the resource object access authorization manager is configured to extract the NF instance identifier of the consumer NF from the subclaim attributes of the access token in the SBI resource object creation request.

18. A program for causing a processor to perform the method described in any one of claims 1 to 9.

Images