Methods, systems, and computer-readable media for resource object level authorization at a network function (NF)

Abstract

A method for resource object level authorization at a network function (NF) includes maintaining, by a first NF, a service-based interface (SBI) resource object access authorization policy database that contains policies for controlling access to SBI resource objects, and dynamically populating a resource object owner database that contains records of resource objects and corresponding resource object owners. The method also includes receiving, by the first NF from a second NF, a first SBI resource object access request to access 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 allowed, and blocking access to the resource object requested by the first resource object access request.

Description

[0001] Priority Statement

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

[0003] The topics described in this article relate to cybersecurity. More specifically, the topics described in this article relate to methods, systems, and computer-readable media for resource object-level authorization at the network function level. 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 may 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) addresses and port numbers 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 may 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] One issue with 5G communication networks is that authorization is defined at the network function level, rather than at the service-based interface (SBI) resource object level, where the resource object is a data structure created by the producer NF in response to a consumer NF's request to access a service provided by the producer NF. For example, 3GPP Technical Specification (TS) 33.501, Clause 13.4, indicates that OAuth 2.0-based authorization will be used to determine whether a consumer network function can access a service provided by a producer network function. The OAuth 2.0 authorization process is defined in Internet Engineering Task Force (IETF) Request for Comment (RFC) 6749. Using the OAuth 2.0 authorization process, the consumer network function seeking access to the 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 grants the consumer NF access to the requested service. Once the consumer NF is granted access to the service, there is no defined authorization mechanism to prevent network functions from accessing resource objects created by other network functions. That is, because the same access token is provided to all consumer NFs seeking access to services provided by a given producer NF, and no further authorization is performed after the access token is verified, consumer NF#2 can intentionally or unintentionally modify resource objects created by consumer NF#1.

[0010] Since there is no defined authorization mechanism at the resource object level, methods, systems, and computer-readable media are needed for authorization at the research object level at NF. Summary of the Invention

[0011] A method for resource object-level authorization at a network function (NF) includes having a first NF maintain a service-based interface (SBI) resource object access authorization policy database, the SBI resource object access authorization policy database containing policies for controlling access to SBI resource objects. The method also includes having the first NF dynamically populate a resource object owner database, the resource object owner database containing records of resource objects and their corresponding resource object owners. The method further includes having the first NF receive a first SBI resource object access request from a second NF for accessing a resource object. The method also includes having the first NF access the resource object access authorization policy database and the resource object owner database using information from the first SBI resource object access request, and determining that the access to the resource object requested by the first resource object access request is not permitted. The method further includes, in response to determining that the access to the resource object requested by the first resource object access request is not permitted, blocking the access to the resource object requested by the first resource object access request.

[0012] According to another aspect of the topic described in this article, the first NF includes the producer NF.

[0013] According to another aspect of the subject described in this article, the first NF includes the Service Communication Agent (SCP).

[0014] As another aspect of the topic described in this article, maintaining an SBI resource object access authorization policy database includes maintaining policies with 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.

[0015] According to another aspect of the subject described in this article, 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 successful creation of the resource object in response to the SBI resource object creation request, and in response to receiving the response, storing the NF instance identifier of the consumer NF and the corresponding resource object identifier in the resource object owner database.

[0016] As another aspect of the subject described in this article, extracting the NF instance identifier from the SBI resource object creation request includes extracting the NF instance identifier of the consumer NF from the sub-claim attribute of the access token in the SBI resource object creation request.

[0017] According to another aspect of the subject matter described herein, accessing the resource object access authorization policy database includes retrieving a resource object identifier from a first SBI resource object access request, searching the resource object identifier in the resource object access authorization policy database, and locating in the resource object access authorization policy database a record that has a resource object identifier that matches the resource object identifier retrieved from the first SBI resource object access request.

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

[0019] According to another aspect of the subject described in this article, 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.

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

[0021] According to another aspect of the subject matter described herein, a system for resource object-level authorization at a network function is provided. The system includes a first network function (NF), the first NF including at least one processor and memory. The system also includes a service-based interface (SBI) resource object access authorization policy database located in the memory, for storing policies for controlling access to SBI resource objects. The system further includes a resource object owner database for storing records containing resource object identifiers and corresponding resource object owner identifiers. The system also includes a resource object access authorization manager for dynamically populating the records in the resource object owner database, 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 request, determining that the access to the resource object requested by the first SBI resource object access request is not permitted, and, in response to determining that the access to the resource object requested by the first SBI resource object access request is not permitted, blocking the access to the resource object requested by the first SBI resource object access request.

[0022] As another aspect of the subject described in this article, the SBI resource object access authorization policy database includes policies that identify the attributes of SBI resource objects, Hypertext Transfer Protocol (HTTP) methods for accessing SBI resource objects, and consumer NF authorization scopes for SBI resource objects.

[0023] In accordance with another aspect of the subject described herein, 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, extract the NF instance identifier of the consumer NF that initiated the SBI resource object creation request from the SBI resource object creation request, receive a response from the producer NF confirming the successful creation of the resource object in response to the SBI resource object creation request, and, in response to receiving the response, store the NF instance identifier of the consumer NF and the corresponding resource object identifier in the resource object owner database.

[0024] In accordance with another aspect of the subject described herein, the resource object access authorization manager is configured to extract the NF instance identifier of the consumer NF from the sub-claim attribute of the access token in the SBI resource object creation request.

[0025] In accordance with 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, use the resource object identifier to search the resource object access authorization policy database, and locate in the resource object access authorization policy database a record having a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.

[0026] In accordance with another aspect of the subject described herein, when it is determined 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 access is permitted only for the owner of the resource object, and to determine that the second NF is not the owner of the resource object.

[0027] In accordance with another aspect of the subject described herein, when it is determined 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.

[0028] 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: a Service-Based Interface (SBI) resource object access authorization policy database maintained by a first network function (NF), the SBI resource object access authorization policy database containing policies for controlling access to SBI resource objects; the steps also include: the first NF dynamically populating a resource object owner database containing records of resource objects and their corresponding owners; the steps further include: the first NF receiving a first SBI resource object access request from a second NF for accessing the resource object; the steps also include: 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 the access to the resource object requested by the first SBI resource object access request is not permitted; and the steps further include: in response to determining that the access to the resource object requested by the first SBI resource object access request is not permitted, blocking the access to the resource object requested by the first SBI resource object access request.

[0029] 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

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

[0031] Figure 2A This is a message flow diagram illustrating an example message exchanged to create a resource object in an NF service producer using the HTTP POST method;

[0032] Figure 2B This is a message flow diagram illustrating an example message exchanged to create a resource object in an NF service producer using the HTTP PUT method;

[0033] Figure 3A This is a message flow diagram illustrating an example message exchanged to read a single resource object using the HTTP GET method;

[0034] Figure 3B This is a message flow diagram illustrating an example of messages exchanged to query a set of resource objects using the HTTP GET method;

[0035] Figure 4A This is a message flow diagram illustrating an example of messages exchanged to update a resource object using the HTTP PUT method;

[0036] Figure 4B This is a message flow diagram illustrating an example of messages exchanged to update a resource object using the HTTP PATCH method;

[0037] Figure 5 This is a message flow diagram illustrating an example message exchanged to delete a resource object using the HTTP DELETE method;

[0038] Figure 6A This is a message flow diagram illustrating an example message exchanged to create a subscription resource object using the HTTP POST method;

[0039] Figure 6B This is a message flow diagram illustrating an example of messages exchanged to create a subscription resource object using the HTTP PUT method;

[0040] Figure 6C This is a message flow diagram illustrating an example message exchanged to update a subscribed resource object using the HTTP PATCH method;

[0041] Figure 6D This is an exemplary message flow diagram illustrating information related to a subscribed resource object using the HTTP POST method;

[0042] Figure 7A This is a message flow diagram illustrating an example message exchanged by a producer NF to obtain an access token from an NRF;

[0043] Figure 7B This is a message flow diagram illustrating an example message exchanged for a consumer NF to obtain an access token from an NRF;

[0044] Figure 7C This is a message flow diagram illustrating how NF service consumers use access tokens to obtain services or access services provided by NF service producers.

[0045] Figure 8This is a message flow diagram illustrating unauthorized updates to resource objects using direct SBI communication;

[0046] Figure 9 This is a message flow diagram illustrating unauthorized updates to resource objects using indirect SBI communication;

[0047] Figure 10 This is a message flow diagram illustrating exemplary messages exchanged to prevent unauthorized access to resource objects using SBI indirect communication;

[0048] Figure 11 This is a block diagram illustrating an exemplary architecture for providing network functionality with SBI resource-level authorization; and

[0049] Figure 12 This is a flowchart illustrating an exemplary process for SBI resource object-level authorization. Detailed Implementation

[0050] Figure 1 This is a block diagram of 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 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 of connections between consumer and producer NFs.

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

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

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

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

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

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

[0057] As mentioned above, one issue with the 3GPP network architecture used in 5G networks is that while 3GPP TS 33.501 specifies that NF service producers should use the OAuth 2.0 authorization process to authorize requests from NF service requesters, different producer NFs can use the same OAuth 2.0 access token to access resources. This can lead to data breaches 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, delete, and update access. In one example, 5G SBI API resource object-level authorization is implemented at the service communication broker or SCP. In another implementation, 5G SBI API resource object-level authorization is implemented at the producer NF.

[0058] An SBI resource object is a data structure created at the NF service producer using the SBI interface. The SBI interface allows NF service consumers to access services provided by NF service producers. Figure 2A This diagram illustrates an example of creating an SBI resource object using the HTTP POST method. See also... Figure 2A In line 1 of the message flow diagram, NF service consumer 200 sends an HTTP POST message to NF service producer 202 to create a new resource object. The HTTP POST message uses a Uniform Resource Identifier (URI) to identify the sub-resource. In response to the HTTP POST message, NF service producer 202 creates the requested resource object and, in line 2, sends a 201 Created message to NF service consumer 200, indicating that the requested resource object has been created. It should be noted that there is no authorization for accessing the newly created resource object, meaning that NF service consumers other than NF service consumer 200 can access the newly created resource object.

[0059] In another example, the HTTP PUT method can be used to create resource objects in an NF service producer. Figure 2B The method is illustrated in the diagram. Figure 2BIn the first line of the message stream, NF service consumer 200 sends an HTTP PUT message to NF service producer 202. The PUT message specifies the resource object that NF service consumer 200 wants to create in NF service producer 202. In response to the HTTP PUT message, NF service producer 202 creates the requested resource object and sends a 201 Created message to NF service consumer 200 in the second line. 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 has obtained an access token from the NRF.

[0060] One way for a consumer NF to access an SBI resource object is by using the HTTP GET method. Figure 3A This diagram illustrates an example of accessing an SBI resource object using the HTTP GET method. As mentioned above, an existing resource object can be accessed by either the consumer NF that created the resource object or a consumer NF that did not create it. Figure 3A In the remaining diagrams, it is assumed that NF service consumer 200 is the resource object creator, and that NF service consumer 300 is a consumer NF other than the resource object creator seeking access to the resource object. See also Figure 3A In line 1, NF service consumer 200 or 300 sends an HTTP GET message identifying the SBI resource object to NF service producer 202. Figure 3A In this context, a resource object is a single resource identified by the URI and possibly other query parameters. In line 2, NF service producer 202 responds to the HTTP GET message by sending a 200 OK message with the requested representation of the resource object. It should be noted that NF service producer 202 does not perform any authorization before providing the resource object representation, except that a valid network access token is required. Therefore, authorized consumer NFs, such as consumer NF 200 which creates the resource object, can access the resource object, while unauthorized consumer NFs, such as consumer NF 300, can also access it because there is no authorization process defined at the resource object level.

[0061] In another example, an NF service consumer with a 200 or 300 status code can use the HTTP GET method to access a set of resources. This example is illustrated in... Figure 3B In. Figure 3BIn the first line of the message stream, NF service consumer 200 or 300 sends an HTTP GET message to NF service producer 202. The HTTP GET message specifies query parameters that identify a set of resources. The query component contains non-hierarchical data, which, along with the data in the path component, is used by NF service producer 202 to filter 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 a first "?" character and ends with a "#" character at the end of the URI. Access to multiple resources can also be provided to unauthorized consumer NFs, similar to access to a single resource.

[0062] Another type of resource object access is access that updates the resource object. Figure 4A This 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 performing a complete replacement. The PUT method replaces the current representation of a resource object with a new representation. Referring to the message flow diagram in Figure 4, in line 1, NF service consumer 200 or 300 sends an HTTP PUT message to NF service producer 202. The PUT message includes the identifier of the resource object and the resource object representation representing the resource object being replaced. In line 2 of the message flow diagram, NF service producer 202 replaces the resource object with the new resource representation and responds with a 200 OK message if the replacement is successful, or a 204 No Content message if the replacement operation fails. No authorization at the resource object level exists before the resource object replacement is performed.

[0063] Figure 4B This is a diagram illustrating the message flow of updating an existing resource object using the HTTP PATCH method. The HTTP PATCH method allows the consumer NF to update information stored in the producer NF through partial replacement. The PATCH method modifies the current representation of the resource object according to the modification instructions provided in the PATCH method. See also Figure 4B In the message flow diagram, in line 1, NF service consumer 200 or 300 sends an HTTP PATCH message to NF service producer 202. The HTTP PATCH message identifies the resource object being modified and includes a modification instruction. In line 2 of the message flow diagram, if the resource object exists at NF service producer 202, NF service producer 202 replaces or modifies the resource object; otherwise, if the resource object does not exist, a 204 no content message is sent. Similarly, there is no authorization at the resource object level. Legitimate consumers, such as consumer NF 200 that created the resource, or other consumers NF 300 that did not create the resource, can modify the resource object by presenting a valid access token obtained from the NRF.

[0064] Another type of access to a resource object is deletion access. Figure 5 This is a message flow diagram illustrating the use of the HTTP DELETE method to delete a resource object. The HTTP DELETE method enables NF service consumers to delete the entire resource object at the NF service producer. See also Figure 5 In the message flow, in line 1, NF service consumer 200 or 300 sends an HTTP DELETE message to NF service producer 202. NF service producer 202 determines whether the resource object identified in the DELETE message exists in NF service producer 202, and if it exists, deletes the resource object. In line 2, if the deletion operation is successful, NF service producer 202 responds with a 202 Accepted message, or if the deletion operation is unsuccessful, it responds with a 204 No Content message. There is no resource object-level authorization for the HTTP DELETE method. NF service consumer 200 or 300 can access and delete resource objects as long as it has a signed access token obtained using the OAuth 2.0 process for producer NF 202.

[0065] In addition to the request / response communication described above, subscription / notification communication can also be used to create, read, and modify resource objects. Figure 6A This is a diagram illustrating the message flow of an NF service consumer creating a subscription resource object using the HTTP POST method. See also... Figure 6A In line 1, NF service consumer 200 or 300 sends an HTTP POST message to NF service producer 202. The HTTP POST message identifies the subscription resource object being created. In response to the HTTP POST message, in line 2, 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.

[0066] Figure 6B This diagram illustrates how to update a subscribed resource object using the HTTP PUT method. The HTTP PUT method allows NF service consumers to replace existing subscribed resource objects at the NF service producer. See also Figure 6B In line 1, NF service consumer 200 or 300 sends an HTTP PUT message to NF service producer 202. The HTTP PUT message is recognized in... Figure 6AThe subscription resource object is created in the PUT method. In response to the HTTP PUT method, the NF service producer either returns a 202 response or replaces the subscription resource object with a new representation specified in the PUT message, or responds with a 204 No Content message if the PUT operation fails. No resource object-level authorization is required to perform a PUT operation on an existing subscription.

[0067] Figure 6C A diagram illustrating how to modify a subscription using the HTTP PATCH method. See also Figure 6C In line 1 of the message flow diagram, NF service consumer 200 or 300 sends an HTTP PATCH message to NF service producer 202 containing an identifier of the subscribed resource object and instructions to modify the subscribed resource object. In response to the HTTP PATCH message, NF service producer 202 responds with a 200 OK message if the subscription is successfully modified, or with a 204 No Content message if the subscription is not successfully modified. There is no authorization at the resource object level.

[0068] Figure 6D This diagram illustrates how to send a notification about an existing subscription using the HTTP POST method. See also... 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. This HTTP POST message contains a notification triggered by conditions specified in an existing subscribed resource object. In line 2, NF service consumer 200 or 300 responds with a 200 OK message or a 204 No Content message, depending on whether the POST operation was successful. Therefore, Figure 6D This diagram illustrates how legitimate or unauthorized service consumers can obtain information about their existing subscriptions by receiving notifications triggered by resource events, even without authorization at the resource object level.

[0069] Figure 7A and Figure 7BThis diagram illustrates the authorization framework specified in 3GPP TS 33.501. According to Clause 13.4.1 of 3GPP TS 33.501, NF service producers use the OAuth 2.0 framework, as specified in IETF RFC 6749, to authorize requests from NF service request consumers. According to Clause 4.4 of IETF RFC 6749, the grant should be of the type granted to the client certificate, meaning the client is granted a certificate at the client level. The mechanism by which NF service consumers access services provided by NF service producers is a JSON web token as described in IETF RFC 7519, which is protected using a digital signature or a message authentication code based on a JSON web signature, as specified in IETF RFC 7515.

[0070] Figure 7A This diagram illustrates the process by which NF service producers create profiles using NRF. See also... Figure 7A In line 1, NF service producer 202 sends an Nnrf_NFManagement_NFRegister request to NRF 100. In step 2, NRF 100 stores the NF profile of the producer NF. In step 3, NRF 100 responds with an Nnrf_NFManagement_NFRegister response indicating that the NF profile has been successfully established.

[0071] Figure 7B This diagram illustrates the process of an NF service consumer obtaining an access token from NRF 100. See also... Figure 7B In line 1, NF service consumer 200 or 300 sends an NRF access token GET request to NRF 100, which identifies the service requested for access. In line 2, NRF 100 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, NRF 100 responds with an NRF access token GET response containing the access token and provides the access token to NF service consumer 200 or 300. The access token allows any service consumer to access resource objects created in producer NF 202, regardless of whether the NF service consumer is the creator of the resource object.

[0072] Figure 7C This diagram illustrates how NF service consumers 200 or 300 use access tokens to obtain services or access services provided by NF service producers 202. (See also...) Figure 7CIn line 1, NF service consumer 200 or 300 sends a service request to NF service producer 202. The service request includes an access token. In line 2, NF service producer 202 verifies the access token and grants access to the requested service. No authorization is performed at the resource object level. As long as NF service consumer 200 or 300 presents a valid access token, it can read, modify, or delete the resource object.

[0073] Figure 8 This is a message flow diagram illustrating direct SBI communication, where the consumer NF communicates directly with the producer NF to create and access SBI resource objects. See also... Figure 8 In line 1, consumer NF 200 sends a message to producer NF 202 to create a resource object. Assume consumer NF 200 has previously obtained an access token from the NRF to access the services provided by producer NF 202. The access token is contained in the Create Resource Request message, which, in the example shown in the diagram, is located within an HTTP PUT or POST message. In line 2, producer NF 202 responds to the Create Resource Request message with a 201 Created message containing the resource data.

[0074] exist Figure 8 In line 3 of the message stream, consumer NF 200 sends a message to update the resource object via producer NF 202. The update message can be an HTTP PUT or PATCH message and includes an access token obtained from the NRF. In line 4, producer NF 202 verifies the access token and updates the resource object, as shown in 5G resource table 800. The data at timestamp T4 is modified from the data at timestamp T2 when the resource object was created.

[0075] In line 5 of the message flow diagram, consumer NF 300, which is not authorized to access resource objects created by consumer NF 200, can access the resource objects by obtaining an access token from NRF 100 to access the 5G NF service API. Consumer NF 300 sends an update message for the resource created by consumer NF 200. In line 6, producer NF 202 verifies the access token and updates the resource object to include the modified data, as shown by timestamp T6 in the 5G SBI resource table 800.

[0076] In another example, consumer NF 300 can read data from resource objects created by other consumer NFs. This example is shown in lines 7 and 8 of the message flow diagram, where consumer NF 202 sends an HTTP GET request to producer NF 202, producer NF 202 verifies the access token in the GET request, and responds with resource data in line 8.

[0077] Rows 9 and 10 of the message flow diagram illustrate another example of unauthorized access to resource objects created by other consumer NFs. In row 9, consumer NF 300 sends an HTTP DELETE message to delete the resource object created by consumer NF 200 in rows 1 and 2. The DELETE message contains an access token obtained from the NRF. In row 10, producer NF 202 responds with a 202 accepted message indicating that the DELETE operation was successful. Therefore, Figure 8 This diagram illustrates unauthorized access to SBI resource objects using the 5G direct SBI communication model.

[0078] Figure 9 This diagram illustrates unauthorized access to SBI resource objects using an indirect communication model, where the consumer NF sends resource creation and update requests to the intermediate SCP, and the SCP communicates with the producer NF to create and update the corresponding resource objects. See also Figure 9 In line 1 of the message flow graph, consumer NF 200 sends a create resource message to SCP 101. SCP 101 forwards the create resource request to producer NF 202. In line 2, producer NF 202 creates the requested resource and sends a 201 Created message with resource data to SCP 101. SCP 101 forwards the 201 Created message to consumer NF 200.

[0079] In line 3 of the message flow graph, consumer NF 200 sends a resource update message to SCP 101 to update the resource object created in lines 1 and 2. SCP 101 forwards the update message to producer NF 202. In line 4, producer NF 202 verifies the access token and updates the resource object to include the data in the update message, as shown by the timestamp T4 in the 5G SBI resource table 800. Producer NF 202 sends a 200 OK message indicating that the resource was successfully updated, or a 204 No Content message if the update is unsuccessful.

[0080] In line 5 of the message flow graph, consumer NF 300 sends an update request to SCP 101. SCP 101 forwards the update request to producer NF 202. Because the request has a valid access token, in line 6, producer NF 202 updates the resource object to include the data in the update request, as shown by timestamp T6 in 5G resource table 800. Producer NF 202 sends an update message to SCP 101, which forwards the message to consumer NF 200.

[0081] In line 7 of the message flow diagram, consumer NF 300 sends a message to SCP 101 to read a resource created by producer NF 202. SCP 101 forwards this request to producer NF 202. In line 8, producer NF 202 verifies the access token and sends a message with the resource data to SCP 101. SCP 101 forwards the message with the resource data to consumer NF 300.

[0082] In line 9, consumer NF 300 sends a message to SCP 101 to delete the resource created by consumer NF 200. SCP 101 forwards this message to producer NF 202. Producer NF 202 verifies the access token in the DELETE message, deletes the resource, and responds with a 202 accepted message indicating successful deletion. Therefore, Figure 9 The diagram illustrates a scenario using 5G SBI for indirect communication, where resource objects can be updated or even deleted without resource object-level authorization.

[0083] To avoid difficulties associated with unauthorized access to resource objects, the topics described herein include SBI resource object-level access authorization services that can be maintained at the SCP for indirect communication models or at the producer NF for direct communication models. The SBI resource object-level authorization service can operate independently of the OAuth 2.0 authorization implemented by the producer NF. Therefore, even if the NF service consumer has a valid OAuth 2.0 access token, the SBI resource object-level authorization service can prevent the NF service consumer from accessing the resource object if the access requested by the NF service consumer is not processed through the SBI resource object-level authorization service described herein.

[0084] As one aspect of the subject matter described herein, the SBI Resource Object Level Authorization Service dynamically populates the SBI Resource Object Owner Database with SBI Resource Object Owner Information. To dynamically populate the database, the SBI Resource Object Level Access Authorization Service can extract consumer NF information from the access token received in the 5G SBI resource creation request upon receiving a successful response message confirming resource creation from the producer NF. The consumer NF information can be extracted from the sub-access token statement defined in Section 6.3.5.2.4 of 3GPP TS29.510. Table 1 below is a copy of Table 6.3.5.2.4-1 of 3GPP TS29.510.

[0085]

[0086]

[0087]

[0088]

[0089] Table 1: Access Token Statement

[0090] As shown in Table 1, the sub-access token claim includes the NF instance ID of the consumer NF. In the context of a resource object creation request message from the consumer NF to the producer NF, this NF instance ID will contain the NF instance ID of the resource creator. The SBI resource object level access authorization service stores this NF instance ID together with the resource ID extracted from the resource object request or response message in the resource object owner database. For subsequent requests regarding 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 operator-configured 5G SBI resource object level authorization policy, and allows or denies the 5G SBI resource access request based on the policy.

[0091] Tables 2 and 3 below illustrate the records that will appear in the 5G SBI resource object access authorization policy database and the 5G SBI resource object owner database, which can be maintained by the resource object level access authorization service at the SCP or producer NF.

[0092]

[0093]

[0094] Table 2: Sample Resource Object Access Authorization Policy Database Records

[0095]

[0096] Table 3: Sample Resource Object Owner Database Records

[0097] In Table 2, the example 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 scope. 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. Example 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 of the resource object. Example values ​​for this attribute in Table 2 include / subscription and / nf-instance, which are used to represent the URI of a specific 5G resource object. The HTTP method attribute stores the HTTP method for a specific policy rule. In Table 2, the HTTP methods used to define the example policy rule are GET, PUT, PATCH, and DELETE. The authorized consumer NF scope attribute defines the scope of consumer NFs to which the policy rule applies. Values ​​for this attribute in Table 2 include NF instance, NF-set, NF-type, network slice, PLMN, and all.

[0098] The data in Table 2 can be provided by the network operator during NF configuration according to operator-specific policies. The data in Table 3 can be dynamically populated at runtime when a resource object is created. Example attributes of the resource object ownership database record in Table 3 include the resource URI and resource owner. The resource URI attribute stores the URI of the newly created resource object. The resource owner attribute stores the NF instance ID of the consumer NF that requested the resource creation. If the resource owner database is maintained by the SCP, the fields in Table 3 can be populated when the SCP receives a resource request creation response from the producer NF using the resource object owner information extracted from the corresponding resource object creation request. If the resource owner database is maintained by the producer NF, the data in Table 3 can be populated when the producer NF creates a resource object using the resource object owner information extracted from the resource object creation request.

[0099] Data in the resource owner database is combined with information in the resource object access authorization policy database to determine whether to allow consumer NFs to access a specific resource object. For example, if the scope of a specific resource object defined in the resource object access authorization policy database is an NF instance, and a message to update the resource object arrives, the resource object-level access authorization service can determine whether a policy has been configured for that resource object. Determining whether a policy has been configured for a resource object may include looking up the resource URI identified in the update request message in the resource object access authorization policy database. If the resource URI in the resource object update request message matches a resource URI in one of the policy rules, the resource object-level access authorization service can use data stored in the resource object owner database to determine whether allowing access would violate the policy. For example, if a resource object access policy indicates that access to a resource object should only be allowed if the NF instance ID of the consumer NF in the access request message matches the NF instance identifier of the resource object owner, then if the NF instance ID does not match, the access request should be denied.

[0100] Figure 10 This is a diagram illustrating how to manage access to SBI resource objects at the resource object level using the resource object-level authorization access authorization service described above. Figure 10 The diagram illustrates 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. Figure 10 Databases 1000 and 1002 are located in SCP 101. However, as mentioned above, these databases may also be configured at the producer NF that provides services corresponding to the protected resource objects.

[0101] See Figure 10In the message flow, on line 1, consumer NF 200 sends a message to SCP 101 to create a resource object via producer NF 202. SCP 101 forwards the resource object creation request to producer NF 202. SCP 101 can extract the NF instance ID from the sub-claim of the access token of the resource object creation request. On line 2, producer NF 202 creates the resource object and responds with a 201 Created message. Producer NF 202 forwards the 201 Created message to SCP 101, and SCP 101 stores the URI of the resource extracted from the response message along with the NF instance ID of the consumer NF extracted from the resource object creation request message in the resource object owner database. Alternatively, SCP 101 can extract the resource URI from the resource object creation request message instead of the response message. In this case, SCP 101 has a complete record of the resource used to identify the resource object and its owner. SCP 101 forwards the 201 Created message to consumer NF 200.

[0102] In line 3, consumer NF 200 sends a message to update a resource object. SCP 101 receives this message, determines that the 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, in line 4, SCP 101 forwards the resource object update request to producer NF 202, which updates the resource object. In line 4, producer NF 202 forwards a 200 OK message to SCP 101, which then forwards the 200 OK message to consumer NF 200.

[0103] In line 5, consumer NF 300 generates and sends a message to SCP 101 to update a resource created by consumer NF 200. SCP 101 determines that a policy applies to the resource update request, compares the NF instance ID of consumer NF 300 obtained from the update request with the NF instance ID of the resource object owner, and determines that the request violates the policy. Therefore, in line 6, SCP 101 rejects the update request and sends an error response, such as a 403 Forbidden message, to consumer NF 300.

[0104] In line 7, consumer NF 300 sends a read request to read the resource object created in response to a request from consumer NF 200. SCP 101 receives the read request and allows or denies it based on the authorization policy configured for that resource. In the example illustrated, the read request is allowed. However, if read operations are not allowed, the read request will be denied in a similar manner to an update request.

[0105] In line 9 of the message flow diagram, consumer NF 300 sends a deletion request to SCP 101 for a resource object created in response to a request from consumer NF 200. In this example, SCP 101 evaluates the deletion request against its configured policy, determines that the deletion request is not allowed, and rejects the deletion request message. Therefore, using Figure 10 The steps illustrated in the diagram can prevent unauthorized access to resource objects based on resource access level authorization policies.

[0106] Figure 11 This is a block diagram illustrating an exemplary architecture for implementing the Resource Object Level Authorization (SCP) or Producer NF 101 or 202 described herein. See also Figure 11 SCP 101 or producer NF 202 includes at least one processor 1100 and memory 1102. A resource object access authorization policy database 1000 may be stored in memory 1102 and may include operator-configured resource object-level policy rules as described above. A resource object owner database 1002 may also be stored in memory 1102 and may be populated by SCP 101 or producer NF 202 at runtime. SCP 101 or consumer NF 202 may also include a resource object access authorization manager 1104, which dynamically populates the resource object owner database 1002 and uses data from databases 1000 and 1002 to perform the steps for resource object-level access authorization described herein. The resource object access authorization manager 1104 may be implemented using computer-executable instructions stored in memory 1102 and executed by processor 1100.

[0107] Figure 12 This is a flowchart illustrating an exemplary process for providing resource object-level authorization at the network function level. See also Figure 12 In step 1200, the process includes maintaining a Service-Based Interface (SBI) resource object access authorization policy database by a first network function (NF). This database contains 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 with reference to Table 2 and the resource object access authorization policy database 1000. Policies may have an identifier for the resource object to which each policy belongs and an identifier for the scope of the NF to which the policy applies.

[0108] In step 1202, the process includes dynamically populating a resource object owner database by a first NF, which contains records of resource objects and their corresponding owners. For example, the resource object access authorization manager 1104 can extract the NF instance identifier from a sub-claim of the access token included in a resource object creation request message from a consumer NF, and in response to receiving a successful response from the producer NF confirming the creation of the resource object, create a record in the resource object owner database identifying the consumer NF and the corresponding resource object.

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

[0110] In step 1206, the process includes the first NF accessing the resource object access authorization policy database and the resource object owner database using information from the SBI resource object access request, and determining that the access requested by the resource object access request is not permitted. In one example, the resource object access authorization manager 1104 may determine that the resource object access control policy indicates that only the resource owner can access the resource, and determine from the resource object owner database 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, the resource object authorization policy may stipulate that a consumer NF of the same type as the resource object owner can use the HTTP GET method to read the resource object, but a consumer NF of the same type as the resource object owner cannot use the HTTP PUT, PATCH, or DELETE methods to modify or delete the resource object. The resource object owner may be allowed to modify the resource object using the HTTP PUT, PATCH, or DELETE methods.

[0111] In step 1208, the process includes blocking the access requested by the 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 can block access by not forwarding the access request to the producer NF. In the case of access control implemented in a producer NF, blocking the requested access may include ignoring the request. In either an SCP or a producer NF implementation, the resource object access authorization manager 1104 may generate an error message and send it to the requester, store the request, and notify the network operator of the denied access attempt.

[0112] The disclosures of the following respective references are hereby incorporated by reference in their entirety into this document.

[0113] References

[0114] 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).

[0115] 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).

[0116] 3. 3GPP TS 29.500 V17.1.0 (2020-12), 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 17).

[0117] 4. 3GPP TS 29.501 V17.0.0 (2020-12) 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Principles and Guidelines for Services Definition; Stage 3 (Release 17).

[0118] 5. Hardt, D., The OAuth2.0 Authorization Framework, IETF RFC 6749 (October2012).

[0119] 6. Jones et al., JSON Web Token, IETF RFC 7519 (May 2015).

[0120] 7. Jones et al., JSON Web Signature, IETF RFC 7515 (May 2015).

[0121] 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 resource object-level authorization in a network function, the method comprising: A Service-Based Interface (SBI) resource object access authorization policy database is maintained by a first network function (NF), the SBI resource object access authorization policy database containing policies for controlling access to SBI resource objects; The resource object owner database is dynamically populated by the first NF, and the resource object owner database contains records of resource objects and their corresponding resource object owners; The first NF receives a first SBI resource object access request from the second NF for accessing the resource object; The first NF uses 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 determines that the access to the resource object requested by the first SBI resource object access request is not allowed. In response to determining that the access to the resource object requested by the first SBI resource object access request is not allowed, the access to the resource object requested by the first SBI resource object access request is blocked. as well as The first NF receives a second SBI resource object access request from the third NF for accessing the resource object, uses the 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 grants the third NF access to the resource object.

2. The method according to claim 1, wherein the first NF includes the producer NF.

3. The method according to claim 1, wherein the first NF includes a Service Communication Agent (SCP).

4. The method according to any one of the preceding claims, wherein maintaining the SBI resource object access authorization policy database includes maintaining policies having attributes that identify SBI resource objects, a Hypertext Transfer Protocol (HTTP) method for accessing SBI resource objects, and consumer NF authorization scopes for SBI resource objects.

5. The method according to claim 1, 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 successful creation of the resource object in response to the SBI resource object creation request, 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.

6. The method according to claim 5, 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 sub-claim attribute of the access token in the SBI resource object creation request.

7. The method according to any one of claims 1 to 3, wherein accessing the resource object access authorization policy database includes extracting a resource object identifier from a first SBI resource object access request, searching the resource object identifier in the resource object access authorization policy database, and locating in the resource object access authorization policy database a record having a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.

8. The method according to any one of claims 1 to 3, wherein determining that the access requested by the first SBI resource object access request is not permitted includes determining that the access is permitted only for the owner of the resource object, and determining that the second NF is not the owner of the resource object.

9. The method according to any one of claims 1 to 3, wherein 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 resource object access request is not permitted.

10. A system for resource object-level authorization at a network function level, the system comprising: A first network function (NF) includes at least one processor and memory; A service-based interface (SBI) resource object access authorization policy database located in the memory is used to store policies for controlling access to SBI resource objects; The resource object owner database stores records containing resource objects and their corresponding resource object owners. A resource object access authorization manager dynamically populates records in the resource object owner database. It 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 resource object access authorization policy database and the resource object owner database, determines that the access to the resource object requested by the first SBI resource object access request is not allowed, and blocks the access to the resource object requested by the first SBI resource object access request in response to determining that the access to the resource object requested by the first SBI resource object access request is not allowed. It also receives a second SBI resource object access request from a third NF to access a resource object, uses 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 grants the third NF access to the resource object.

11. The system according to claim 10, wherein the first NF includes the producer NF.

12. The system according to claim 10, wherein the first NF includes a service communication agent (SCP).

13. The system according to any one of claims 10 to 12, wherein the SBI resource object access authorization policy database includes a policy having attributes that identify SBI resource objects, a Hypertext Transfer Protocol (HTTP) method for accessing SBI resource objects, and consumer NF authorization scopes for SBI resource objects.

14. The system according to claim 10, wherein when dynamically populating the resource object owner database, the resource object access authorization manager is configured to receive an SBI resource object creation request from a consumer NF, extract the NF instance identifier of the consumer NF that initiated the resource object creation request from the SBI resource object creation request, receive a response from a producer NF confirming the successful creation of the resource object in response to the SBI resource object creation request, and in response to receiving the response, store the NF instance identifier of the consumer NF and the corresponding resource object identifier in the resource object owner database.

15. The system of claim 14, wherein the resource object access authorization manager is configured to extract the NF instance identifier of the consumer NF from the sub-claim attribute of the access token in the SBI resource object creation request.

16. The system according to any one of claims 10 to 12, wherein 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, search the resource object identifier in the resource object access authorization policy database, and locate 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.

17. The system according to any one of claims 10 to 12, wherein when it is determined 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 access is permitted only for the owner of the resource object, and to determine that the second NF is not the owner of the resource object.

18. The system according to any one of claims 10 to 12, wherein when it is determined 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 resource object access request is not permitted.

19. A non-transitory computer-readable medium storing executable instructions, which, when executed by a processor of a computer, control the computer to perform steps, the steps including: A Service-Based Interface (SBI) resource object access authorization policy database is maintained by a first network function (NF), the SBI resource object access authorization policy database containing policies for controlling access to SBI resource objects; The resource object owner database is dynamically populated by the first NF, and the resource object owner database contains records of resource objects and their corresponding resource object owners; The first NF receives a first SBI resource object access request from the second NF for accessing the resource object; The first NF uses 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 determines that the access to the resource object requested by the first SBI resource object access request is not allowed. In response to determining that the access to the resource object requested by the first SBI resource object access request is not allowed, the access to the resource object requested by the first SBI resource object access request is blocked. as well as The first NF receives a second SBI resource object access request from the third NF for accessing the resource object, uses the 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 grants the third NF access to the resource object.

Images