CN115361183A - Proxy subscription authorization method and device - Google Patents

Proxy subscription authorization method and device Download PDF

Info

Publication number
CN115361183A
CN115361183A CN202210945552.4A CN202210945552A CN115361183A CN 115361183 A CN115361183 A CN 115361183A CN 202210945552 A CN202210945552 A CN 202210945552A CN 115361183 A CN115361183 A CN 115361183A
Authority
CN
China
Prior art keywords
token
subscription
request
network function
nrf
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210945552.4A
Other languages
Chinese (zh)
Inventor
赵绪文
张博
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN115361183A publication Critical patent/CN115361183A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity

Abstract

The application provides an authorization method and device for proxy subscription, which are used for improving the security in the proxy subscription process. The method comprises the following steps: a network function storage function, NRF, receiving a token request from a first network function, NF, the token request comprising an identification of the first NF and an identification of the second NF; the NRF generating a first token based on the token request, the first token indicating that the first NF has the right to proxy the second NF to subscribe to network function services from the third NF and indicating that the second NF has the right to receive network function services provided by the third NF; the NRF sends the first token to the first NF.

Description

Proxy subscription authorization method and device
The application is a divisional application, the application number of the original application is 201910888767.5, the date of the original application is 09 and 19 in 2019, and the entire content of the original application is incorporated by reference in the application.
Technical Field
The embodiment of the application relates to the technical field of communication, in particular to an authorization method and device for proxy subscription.
Background
The fifth generation mobile communication system (5G) employs a Service Based Architecture (SBA). Service based architecture enhancements (eSBA) have also been proposed by the third generation partnership project (3 rd generation partnership project,3 gpp). In the SBA or the eSBA, a service call mode is used for communication between Network Functions (NFs) in a core network. For example, a "subscription-notification" interaction is employed between two NFs. The NF _ a subscribes to services from the NF _ B, and the NF _ B notifies the relevant services to the NF _ a after corresponding conditions are satisfied.
In addition, the SBA or eSBA architecture also supports proxy subscriptions. In the proxy subscription scenario, the NF _ a may also subscribe to the service from the NF _ B on behalf of the NF _ C, and the NF _ B directly notifies the relevant service to the NF _ C after the corresponding condition is satisfied. In the proxy subscription scenario, the subscription, modification, and unsubscription of a service are all done by NF _ a on behalf of NF _ C, which only receives service notifications for NF _ B.
But how to ensure the security of the proxy subscription in the proxy subscription scenario is a problem to be solved.
Disclosure of Invention
The embodiment of the application provides an authorization method and device for proxy subscription, which are used for solving the problem of how to ensure the security of the proxy subscription under a proxy subscription scene.
In a first aspect, a method for authorizing a proxy subscription is provided, which may be performed by a network function storage function NRF, the method comprising the steps of: a network function storage function, NRF, receiving a token request from a first network function, NF, the token request comprising an identification of the first NF and an identification of the second NF; the NRF generating a first token based on the token request, the first token indicating that the first NF has the right to proxy the second NF to subscribe to network function services from the third NF and indicating that the second NF has the right to receive network function services provided by the third NF; the NRF sends the first token to the first NF. Authorization judgment is carried out on the authority of two service requesters subscribed by the agent through the NRF under the agent subscription scene, and indication is carried out through the token, so that the safety of the agent subscription under the agent subscription scene can be guaranteed.
In one possible design, the NRF receives a token request from the first network function NF; the NRF executes authorization based on the token request, and if the authorization is successful, a first token is sent to the first NF; wherein the authorizing comprises: and judging whether the first NF has the authority of acting the second NF to subscribe the network function service to the third NF or not, and judging whether the second NF has the authority of receiving the network function service provided by the third NF or not. Authorization judgment is carried out on the authority of two service requesters subscribed by the agent through the NRF under the agent subscription scene, and indication is carried out through the token, so that the safety of the agent subscription under the agent subscription scene can be guaranteed.
In one possible design, the token request includes first indication information for indicating that the first NF is to proxy the second NF to subscribe to a network function service from the third NF; such that the NRF determines from the indication information that generation of the first token is required.
In one possible design, the first token includes an identification of the second NF, and is used to determine information of the second NF after the third NF verifies that the token is successful.
In one possible design, the first token includes the second indication information indicating to the third NF to indicate: the first token proxies the second NF to the third NF for the first NF to subscribe to network function services.
In one possible design, the first token is to indicate that the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF, and to indicate that the second NF has a right to receive the network function service provided by the third NF. The rights are characterized by a token.
In one possible design, the NRF receives a check request from the third NF, the check request including a second token, the check request requesting that the second token be checked; and the NRF checks the second token and returns a check result to the third NF. Here, the third NF is a service provider, and the NRF may check a token provided by the service provider, so as to further ensure the security of the proxy subscription.
In one possible design, the verification includes one or more of: the method comprises the steps of carrying out integrity check on the second token, checking whether the second token is used for indicating that the second NF has the authority of receiving network function services provided by the third NF, checking the validity of the second token, checking whether the identification of a service provider contained in the token is the same as the identification of the third NF and checking whether the second token is consistent with the first token.
In a second aspect, a method for authorizing a proxy subscription is provided, which may be performed by a first network function NF, the method comprising the steps of: a first network function, NF, sending a token request to a network function storage function, NRF, the token request comprising an identification of the first NF and an identification of the second NF; the first NF receiving a token from the NRF indicating that the first NF has authority to proxy the second NF for subscribing network function services to the third NF, and indicating that the second NF has authority to receive network function services provided by the third NF. The first NF requests the NRF to perform authorization judgment on a service requester subscribed by the proxy under the proxy subscription scene, and the token indication is used for helping to ensure the security of the proxy subscription under the proxy subscription scene.
In one possible design, the first network function NF sends a token request to a network function storage function NRF, the token request requesting the NRF to perform authorization, the authorization comprising: judging whether the first NF has the authority of acting the second NF to subscribe the network function service to the third NF or not, and judging whether the second NF has the authority of receiving the network function service provided by the third NF or not; the first NF receives a token from the NRF. The first NF requests the NRF to perform authorization judgment on a service requester subscribed by the proxy under the proxy subscription scene, and the token indication is used for helping to ensure the security of the proxy subscription under the proxy subscription scene.
In one possible design, the token request includes an identification of the first NF and an identification of the second NF. The proxy subscription scenario can be characterized by the identification of two service requesters.
In one possible design, the token request includes first indication information for instructing the first NF to broker the second NF to subscribe to network function services from the third NF. And characterizing the proxy subscription scene by the indication information.
In one possible design, the token includes an identification of the second NF, and is used to determine information of the second NF after the third NF verifies that the token is successful.
In one possible design, the first token includes the second indication information for indicating the third NF, and the first token proxies the second NF to subscribe to a network function service from the third NF for the first NF.
In one possible design, the token is to indicate that the first NF has a right to proxy the second NF to subscribe to network function services from the third NF, and to indicate that the second NF has a right to receive network function services provided by the third NF. The rights are characterized by a token.
In one possible design, the first NF sends a subscription request to the third NF, where the subscription request carries the token. And indicating that two service requesters have the authority in the proxy subscription scene by carrying the token in the subscription request.
In one possible design, the first NF receives a subscription response from the third NF, where the subscription response carries the token or the authorization result, and the authorization result includes: the second NF has a right to receive the network function service provided by the third NF, and the first NF has a right to proxy the second NF to subscribe the network function service to the third NF. If the subscription response carries the token, the token carried in the subscription request can be represented to be verified or successfully verified. If the subscription response carries the authorization result, it can represent that the service requester subscribed by the proxy has completed authorization. Further, after receiving the token or the authorization result, the first NF may also forward the token or the authorization result to the third NF, so as to achieve the purpose of notifying the second NF of the information whether the authorization is successful.
In one possible design, the first NF receives a notification from the third NF, where the notification carries the token or the authorization result, and the authorization result includes that the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF, and that the second NF has a right to receive the network function service provided by the third NF. If the notification carries the token, it can be characterized that the token carried in the subscription request passes the verification or the verification is successful. If the notification carries the authorization result, it can represent that the service requester subscribed by the proxy has completed authorization. Further, after receiving the token or the authorization result, the first NF may also forward the token or the authorization result to the third NF, so as to achieve the purpose of notifying the second NF of the information about whether the authorization is successful.
In a third aspect, a method for authorizing a proxy subscription is provided, which may be performed by a third network function NF, the method comprising the steps of: a third network function NF receives a subscription request from the first NF, wherein the subscription request carries a token; the third NF verifies the token contained in the subscription request to obtain a verification result, wherein if the verification is successful, the first NF has the authority of acting the second NF to subscribe the network function service to the third NF, and the second NF has the authority of receiving the network function service provided by the third NF; if the verification is unsuccessful, the first NF does not have the authority for acting the second NF to subscribe the network function service to the third NF, and the second NF does not have the authority for receiving the network function service provided by the third NF; and the third NF sends a subscription response to the first NF, and the subscription response carries the check result. After receiving the subscription request, the third NF determines that the subscription scenario is an agent subscription scenario according to the token carried in the subscription request, and verifies the token, so that the authorization effect of the agent subscription scenario can be further improved, and the security of the agent subscription is ensured.
In one possible design, the token carries an identification of the second NF. And determining the information of the second NF after the token is successfully verified by the third NF.
In one possible design, the third NF obtains an identification of the second NF from the token upon successful verification.
In one possible design, the token carries indication information, where the indication information is used to indicate that the first NF proxies the second NF to subscribe to the network function service to the third NF, so that the third NF can know that the first token is a token that the first NF proxies the second NF to subscribe to the network function service to the third NF.
In one possible design, the third NF sends an authorization notification to the second NF when the verification is successful, the authorization notification including an authorization result, the authorization result including that the second NF has a right to receive the network function service provided by the third NF. The result of the authorization can be delivered to the second NF by the authorization notification.
In one possible design, the verification includes one or more of: the method comprises the steps of carrying out integrity check on the token, checking whether the token is used for indicating that a second NF has the authority of receiving network function services provided by a third NF, checking validity of the token, checking whether the identification of a service provider contained in the token is the same as the identification of the third NF, and checking whether the token is consistent with the token stored by the third NF.
In one possible design, the subscription request further carries an identifier of the first NF and an identifier of the second NF. The subscription request of this time can be represented as a proxy subscription scene through the identification of two service requesters.
In one possible design, the subscription response further carries the token or the authorization result, where the authorization result includes that the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF, and that the second NF has a right to receive the network function service provided by the third NF. If the token is carried in the subscription response, it can be characterized that the token carried in the subscription request passes the verification or the verification is successful. If the subscription response carries the authorization result, it can represent that the service requester subscribed by the proxy has completed authorization. Further, after receiving the token or the authorization result, the first NF may also forward the token or the authorization result to the third NF, so as to achieve the purpose of notifying the second NF of the information about whether the authorization is successful.
In one possible design, the third NF sends a notification to the first NF, where the notification carries the token or the authorization result, and the authorization result includes that the first NF has a right to proxy that the second NF subscribes to the network function service from the third NF, and that the second NF has a right to receive the network function service provided by the third NF. If the notification carries the token, it can be characterized that the token carried in the subscription request passes the verification or the verification is successful. If the notification carries the authorization result, it can represent that the service requester subscribed by the proxy has completed authorization. Further, after receiving the token or the authorization result, the first NF may also forward the token or the authorization result to the third NF, so as to achieve the purpose of notifying the second NF of the information whether the authorization is successful.
In a fourth aspect, a proxy subscription system is provided, the system comprising: the first network functions NF and NRF. Wherein the first network function NF is configured to send a token request to a network function storage function NRF, the token request including an identification of the first NF and an identification of the second NF; the NRF is configured to receive the token request from the first NF, generate a token based on the token request, and send the token to the first NF, where the token is used to indicate whether the first NF has a right to proxy the second NF to subscribe to a network function service from the third NF, and is used to indicate whether the second NF has a right to receive a network function service provided by the third NF. The method comprises the steps that a first NF requests an NRF to carry out authorization judgment on a service requester subscribed by the proxy under a proxy subscription scene, the first NF requests the NRF to carry out authorization judgment on the service requester subscribed by the proxy under the proxy subscription scene, the NRF carries out authorization judgment on the authorities of two service requesters subscribed by the proxy under the proxy subscription scene, and indication is carried out through a token, so that the safety of proxy subscription under the proxy subscription scene can be guaranteed.
In one possible design, a first network function NF to send a token request to a network function storage function NRF, the token request comprising an identification of the first NF and an identification of the second NF; the NRF is used for receiving the token request from the first NF, executing authorization based on the token request, and sending a token to the first NF if the authorization is successful; wherein the authorizing comprises: and judging whether the first NF has the authority of acting the second NF to subscribe the network function service to the third NF or not, and judging whether the second NF has the authority of receiving the network function service provided by the third NF or not. The authorization judgment is carried out on the service requesters subscribed by the proxy to the NRF through the first NF in the proxy subscription scene, the authorization judgment is carried out on the authorities of the two service requesters subscribed by the proxy through the NRF in the proxy subscription scene, and the indication is carried out through the token, so that the security of proxy subscription in the proxy subscription scene can be ensured.
In one possible design, the token request includes first indication information for instructing the first NF to proxy the second NF to subscribe to network function services from the third NF; so that the NRF determines from the indication information that the token needs to be generated.
In one possible design, the first NF is further configured to send a subscription request to the third NF, where the subscription request carries the token. And indicating that two service requesters have the authority in the proxy subscription scene by carrying the token in the subscription request.
In one possible design, the token includes an identification of the second NF, and is used to determine information of the second NF after the third NF verifies that the token is successful.
In one possible design, the second indication information is included, and the second indication information is used to indicate that the first NF proxies the second NF to subscribe to the network function service from the third NF.
In one possible design, the system further includes the third NF, where the third NF is configured to receive a subscription request from the first NF, check a token carried in the subscription request, and obtain a check result; if the verification is successful, the first NF has the authority of acting the second NF to subscribe the network function service to the third NF, and the second NF has the authority of receiving the network function service provided by the third NF; if the verification is unsuccessful, the first NF does not have the authority for acting the second NF to subscribe the network function service to the third NF, and the second NF does not have the authority for receiving the network function service provided by the third NF. After receiving the subscription request, the third NF determines that the subscription scenario is a proxy subscription scenario according to the token carried in the subscription request, and verifies the token, so that the authorization effect of the proxy subscription scenario can be further improved, and the security of proxy subscription is ensured.
In one possible design, the third NF is further configured to send a subscription response to the first NF, where the subscription response carries the token or the authorization result; the authorization result comprises that the first NF has the authority of acting the second NF to subscribe the network function service to the third NF and the second NF has the authority of receiving the network function service provided by the third NF; the first NF is further configured to receive the subscription response from the third NF.
In one possible design, the third NF is further configured to send an authorization notification to the second NF when the verification is successful, where the authorization notification includes an authorization result, and the authorization result includes that the second NF has a right to receive a network function service provided by the third NF. The second NF is further configured to receive the authorization notification from the third NF. If the token is carried in the subscription response, it can be characterized that the token carried in the subscription request passes the verification or the verification is successful. If the subscription response carries the authorization result, it can represent that the service requester subscribed by the proxy has completed authorization. Further, after receiving the token or the authorization result, the first NF may also forward the token or the authorization result to the third NF, so as to achieve the purpose of notifying the second NF of the information whether the authorization is successful.
In one possible design, the verification includes one or more of: the method comprises the steps of carrying out integrity check on the token, checking whether the token is used for indicating that a second NF has the authority of receiving network function services provided by a third NF, checking validity of the token, checking whether the identification of a service provider contained in the token is the same as the identification of the third NF, and checking whether the token is consistent with the token stored by the third NF.
In one possible design, the third NF is further configured to send a notification to the first NF, where the notification carries the token or the authorization result, and the authorization result includes that the second NF has a right to receive a network function service that the first NF has to proxy the second NF to subscribe to the network function service from the third NF and a right to receive the network function service provided by the third NF; the first NF is further configured to receive the notification from the third NF. If the notification carries the token, it can be characterized that the token carried in the subscription request passes the verification or the verification is successful. If the notification carries the authorization result, it can represent that the service requester subscribed by the proxy has completed authorization. Further, after receiving the token or the authorization result, the first NF may also forward the token or the authorization result to the third NF, so as to achieve the purpose of notifying the second NF of the information whether the authorization is successful.
In one possible design, the token request includes an identification of the first NF and an identification of the second NF. The proxy subscription scenario can be characterized by the identification of two service requesters.
In a fifth aspect, a method for authorizing a proxy subscription is provided, where an execution subject of the method may be a service communication proxy SCP, and the method may be executed by: the SCP receives a subscription request from a first Network Function (NF), wherein the subscription request is used for the first NF to request a proxy to subscribe a network function service from a third NF by a second NF; the SCP determines that the second NF has the authority of receiving the network function service provided by the third NF; and the SCP sends an authorization notice to the second NF, wherein the authorization notice is used for indicating that the second NF has the authority of receiving the network function service provided by a third NF. The SCP judges the authority of two service requesters subscribed by the proxy under the proxy subscription scene, so that the safety of proxy subscription under the proxy subscription scene can be ensured.
In one possible design, the subscription request includes one or more tokens; the SCP determines that the second NF has the authority of receiving the network function service provided by the third NF, and the method is realized by the following steps: the SCP determines, based on the one or more tokens, that the second NR has authority to receive network function services provided by a third NF. One token may indicate that the first NF has the right to proxy the second NF for subscribing network function services to the third NF and that the second NF has the right to receive network function services provided by the third NF. The plurality of tokens may be, for example, two tokens, such one token indicating that the first NF has the right to proxy the second NF to subscribe to network function services from the third NF, and another token indicating that the second NF has the right to receive network function services provided by the third NF.
In one possible design, the SCP verifies the token; the verification includes one or more of: and carrying out integrity check on the token, checking whether the token is used for indicating that the second NF has the authority of receiving the network function service provided by the third NF and checking the validity of the token. The verification fails when any one verification fails, and the verification succeeds when all verifications succeed. Specifically, it is required to check whether the subscription request includes the identifier of the third NF. It is also necessary to check whether the identity of the service provider (service provider) contained in the audio container in the token is the same as the identity of the third NF queried by the SCP. Specifically, the SCP may obtain the identifier of the third NF according to information query configured locally, or obtain the identifier of the third NF according to information query obtained from the NRF. It may also be checked whether the third NF is capable of providing the subscribed network function service.
In one possible design, if the verification is successful, the SCP sends an authorization notification to the second NF, where the authorization notification includes an authorization result, and the authorization result includes that the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF, and the second NF has a right to receive the network function service provided by the third NF. Or if the verification is successful, the SCP sends a token to the second NF, and the token indicates that the first NF has the authority of acting the second NF to subscribe the network function service to the third NF and that the second NF has the authority of receiving the network function service provided by the third NF.
In one possible design, the one or more tokens include a first token and a second token; the first token is used for indicating that the first NF has the authority of proxying the second NF to subscribe the network function service to the third NF; the second token is to indicate that the second NF has a right to receive a network function service provided by the third NF.
In one possible design, the SCP determines that the second NF has the right to receive the network function service provided by the third NF by: the SCP sends an authorization request to the NRF; the SCP receives a response to the authorization request from the NRF indicating that the second NF has authority to receive network function services provided by the third NF. The authorization judgment is executed through the NRF, and the authorization result is returned to the SCP, so that the safety of the agent subscription scene can be improved.
In a sixth aspect, a method for authorizing a proxy subscription is provided, the method being executable by a third network function NF, the method comprising: the third NF receives a subscription request from the first NF, wherein the subscription request is used for the first NF to proxy the second NF and subscribe the network function service to the third NF; the third NF determining that the second NF has the authority of receiving the network function service provided by the third NF; and the third NF sends an authorization notice to the second NF, wherein the authorization notice is used for indicating that the second NF has the authority of receiving the network function service provided by the third NF. The third NF judges the authority of the two service requesters in the subscription request, so that the safety of proxy subscription can be improved.
In one possible design, the third NF determines whether the first NF has an authority to proxy the second NF to subscribe the network function service to the third NF, and determines whether the second NF has an authority to receive the network function service provided by the third NF, and if both the two determination results are yes, the third NF obtains an authorization result of yes.
In one possible design, the subscription request includes one or more tokens; the third NF checks a token included in the subscription request, and when the check is successful, it is determined that the second NF has a right to receive a network function service provided by the third NF, wherein the check includes one or more of: and carrying out integrity check on the token, checking whether the token is used for indicating that the second NF has the authority of receiving the network function service provided by the third NF and checking the validity of the token. The verification fails when any one verification is unsuccessful, and the verification succeeds when all verifications are successful. Specifically, it is required to check whether the subscription request includes the identifier of the third NF.
In one possible design, the subscription request includes a first token and a second token; the first token is used for indicating that the first NF has the authority of proxying the second NF to subscribe the network function service to the third NF; the second token is to indicate that the second NF has permission to receive network function services provided by the third NF.
In a seventh aspect, there is provided an apparatus for authorizing a proxy subscription, the apparatus having a function of implementing NRF behavior in any one of the above first aspect and possible designs of the first aspect. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.
In one possible design, the device may be a chip or an integrated circuit.
In one possible design, the apparatus includes a memory storing a set of programs and a processor for executing the programs stored in the memory, and when the programs are executed, the apparatus may perform the method described in any one of the possible designs of the first aspect and the first aspect.
In one possible design, the apparatus further includes a transceiver for communicating between the apparatus and other functions.
In one possible design, the device is NRF.
In an eighth aspect, there is provided an apparatus for authorizing a proxy subscription, the apparatus having a function of implementing the first NF behavior in any one of the possible designs of the second aspect and the second aspect. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.
In one possible design, the device may be a chip or an integrated circuit.
In one possible design, the apparatus includes a memory storing a set of programs and a processor for executing the programs stored in the memory, and when the programs are executed, the apparatus may perform the method described in any one of the possible designs of the second aspect and the second aspect.
In one possible design, the apparatus further includes a transceiver for communicating between the apparatus and other functions.
In one possible design, the device is an NF.
A ninth aspect provides an authorization apparatus for proxy subscription, which has a function of implementing a third NF action in any one of the possible designs of the third and fourth aspects. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.
In one possible design, the device may be a chip or an integrated circuit.
In one possible design, the apparatus includes a memory storing a set of programs and a processor for executing the programs stored in the memory, and when the programs are executed, the apparatus may perform the method described in any one of the possible designs of the third aspect and the third aspect.
In one possible design, the apparatus further includes a transceiver for communicating between the apparatus and other functions.
In one possible design, the device is an NF.
A tenth aspect provides an authorization means for proxy subscription, the means having functionality to implement SCP behaviour in any one of the possible designs of the fifth and fifth aspects described above. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above.
In one possible design, the device may be a chip or an integrated circuit.
In one possible design, the apparatus includes a memory storing a set of programs and a processor for executing the programs stored in the memory, and when the programs are executed, the apparatus may perform the method described in any one of the possible designs of the fifth aspect and the fifth aspect.
In one possible design, the apparatus further includes a transceiver for communicating between the apparatus and other functions.
In one possible design, the device is an SCP.
In an eleventh aspect, there is provided an authorization apparatus for proxy subscription, the apparatus having a function of implementing the third NF behavior in any one of the possible designs of the above sixth and sixth aspects. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.
In one possible design, the device may be a chip or an integrated circuit.
In one possible design, the apparatus includes a memory storing a set of programs and a processor for executing the programs stored in the memory, and when the programs are executed, the apparatus may perform the method described in any one of the possible designs of the sixth aspect and the sixth aspect.
In one possible design, the apparatus further includes a transceiver for communicating between the apparatus and other functions.
In one possible design, the device is NF.
In a twelfth aspect, a chip is provided, which is connected to a memory or which comprises a memory for reading and executing a software program stored in said memory for carrying out the method as described in the above aspects and in any of the possible designs of the aspects.
In a thirteenth aspect, there is provided a computer storage medium storing a computer program comprising instructions for performing the aspects described above and any possible in-design method of aspects.
In a fourteenth aspect, a computer program product is provided that, when read and executed by a computer, causes the computer to perform the method as set forth in any one of the above aspects and possible designs of aspects.
Drawings
FIG. 1a is a schematic diagram of a service architecture system according to an embodiment of the present application;
FIG. 1b is a second schematic diagram of a service architecture system according to an embodiment of the present application;
FIG. 2 is a flowchart illustrating an authorization method for proxy subscription according to an embodiment of the present application;
FIG. 3 is a schematic flowchart of a second method for authorizing a proxy subscription according to an embodiment of the present application;
FIG. 4 is a schematic flowchart illustrating a third method for authorizing a proxy subscription according to an embodiment of the present application;
FIG. 5 is a diagram illustrating a fourth flowchart of an authorization method for proxy subscription in an embodiment of the present application;
FIG. 6 is a diagram illustrating a fifth flowchart of an authorization method for proxy subscription according to an embodiment of the present application;
FIG. 7 is a six-flow diagram illustrating an authorization method for proxy subscription according to an embodiment of the present application;
FIG. 8 is a schematic structural diagram of an authorization apparatus for proxy subscription in an embodiment of the present application;
FIG. 9 is a second structural diagram of an authorization apparatus for proxy subscription according to an embodiment of the present application;
FIG. 10 is a flowchart illustrating another method for authorizing a subscription in an embodiment of the present application;
fig. 11 is a flowchart illustrating another method for authorizing a subscription according to an embodiment of the present application.
Detailed Description
The embodiment of the application provides an authorization method, device and system for proxy subscription, which are used for realizing the security of the proxy subscription. The method and the device are based on the same inventive concept, and because the principles of solving the problems of the method and the device are similar, the implementation of the device and the method can be mutually referred, and repeated parts are not repeated. In the description of the embodiment of the present application, "and/or" describes an association relationship of an association object, which means that three relationships may exist, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. At least one referred to in this application means one or more; plural means two or more. In addition, it is to be understood that the terms first, second, etc. in the description of the present application are used for distinguishing between the descriptions and not necessarily for describing a sequential or chronological order.
The communication method provided by the embodiment of the application can be applied to a 5G communication system or various future communication systems.
The embodiments of the present application will be described in detail below with reference to the accompanying drawings.
Fig. 1a illustrates a possible service architecture system to which the authorization method for proxy subscription provided in the embodiment of the present application is applicable. As shown in fig. 1a, the service architecture system 100 includes at least three NFs 101. Three NFs are taken as an example in the present application and can be denoted as NF _ a, NF _ B, and NF _ C. NF _ A, NF _ B, and NF _ C are denoted by reference numerals 101_a, 101_b, and 101 _c. Optionally, the service architecture 100 further includes a network storage function (NRF) 102. Optionally, the service architecture 100 further includes a Service Communication Proxy (SCP) 103.
Wherein:
the NFs 101 are network functions in a core network, and communication between the NFs is realized by adopting a service interface through a service call mode. The NRF102 is used for registering and discovering the NFs 101, storing registration information of each NF in the same PLMN, serving as an authorization server to complete authorization and generate a token (token), and verifying the token.
The SCP103 is used for forwarding communication between the NFs, realizing load balancing and NF selection, and having NF registration, discovery and authorization functions.
The NF of the present application may be any NF, for example, fig. 1b illustrates a possible architecture of a communication system based on a service interface in a non-roaming scenario. In the system architecture shown in FIG. 1B, NF _ A may be NEF, NF _ B may be AMF, and NF _ C may be UDM. Other functions are of course possible. In addition, in fig. 1b, the system architecture includes a network open function network element, a policy control function network element, a data management network element, an application function network element, a core network access and mobility management function network element, a session management function network element, a terminal device, an access network device, a user plane function network element UPF, and a data network. The core network access and mobility management function network element and the terminal equipment can be connected through an N1 interface, the core network access and mobility management function network element and the access network equipment can be connected through an N2 interface, the access network equipment and the user plane function network element can be connected through an N3 interface, the session management function network element and the user plane function network element can be connected through an N4 interface, and the user plane function network element and the data network can be connected through an N6 interface. The interface name is merely an illustration.
In fig. 1b, a data network, such as a Data Network (DN), may be the Internet (Internet), an IP Multimedia Service (IMS) network, a local area network (i.e., a local network, such as a Mobile Edge Computing (MEC) network), and so on. The data network comprises an application server, and the application server provides service for the terminal equipment by carrying out data transmission with the terminal equipment.
The core network access and mobility management function network element may be configured to manage access control and mobility of the terminal device, and in an actual application, the core network access and mobility management function network element includes a mobility management function in a Mobility Management Entity (MME) in a network frame in Long Term Evolution (LTE), and is added with an access management function, and may be specifically responsible for registration, mobility management, a tracking area update procedure, reachability detection, selection of a session management function network element, mobility state transition management, and the like of the terminal device. For example, in 5G, the core network access and mobility management function network element may be an AMF (access and mobility management function) network element. In future communications, for example, in 6G, the core network access and mobility management function network element may still be an AMF network element, or have another name, which is not limited in this application. When the core network access and mobility management function network element is an AMF network element, the AMF may provide a Namf service.
The session management function network element may be configured to be responsible for session management of the terminal device (including establishment, modification, and release of a session), selection and reselection of a user plane function network element, internet Protocol (IP) address allocation of the terminal device, quality of service (QoS) control, and the like. For example, in 5G, the session management function network element may be an SMF (session management function) network element, and in future communication, for example, in 6G, the session management function network element may still be an SMF network element, or may have another name, which is not limited in this application. When the session management function network element is an SMF network element, the SMF may provide an Nsmf service.
The policy control function network element can be used for taking charge of policy control decision, providing functions of service data flow and application detection, gating, qoS (quality of service) and flow-based charging control and the like. For example, in 5G, the policy control function network element may be a PCF (policy control function) network element, and in future communication, for example, in 6G, the policy control function network element may still be a PCF network element, or have another name, which is not limited in this application. When the policy control function network element is a PCF network element, the PCF network element may provide an Npcf service.
The application function network element mainly functions to interact with a third generation partnership project (3 gpp) core network to provide services, which affect traffic routing, access network capability opening, policy control, and the like. For example, in 5G, the application function network element may be an AF (application function) network element, and in future communication, for example, in 6G, the application function network element may still be an AF network element, or have another name, which is not limited in this application. When the application function network element is an AF network element, the AF network element may provide a Naf service.
And the data management network element can be used for managing the subscription data of the terminal equipment, the registration information related to the terminal equipment and the like. For example, in 5G, the data management network element may be a unified data management network element (UDM), and in future communications, for example, in 6G, the data management network element may still be a UDM network element, or may have another name, which is not limited in this application. When the data management network element is a UDM network element, the UDM network element may provide a numm service.
A network open function network element, which may be used to enable the 3GPP to securely provide network service Capability to an AF (e.g., a Service Capability Server (SCS), an Application Server (AS), etc.) of a third party. For example, in 5G, the network open function network element may be an NEF (network open function), and in future communication, for example, in 6G, the network open function network element may still be an NEF network element, or may have another name, which is not limited in this application. When the network open function network element is a NEF, the NEF may provide an Nnef service to other network function network elements.
Namf is a service-based interface exposed by the AMF. Nsmf is a service-based interface exposed by SMF. Nnef is the service-based interface exposed by NEF. Npcf is a service-based interface exposed by PCF. Nudm is a service-based interface exposed by UDMs. Naf is the service-based interface exposed by the AF. Nrrf is a service-based interface exposed by NRF. Nausf is a service-based interface presented by AUSF.
The system architecture may also include other network elements, such as a Network Slice Selection Function (NSSF) element, an authentication server function (AUSF) element, etc., which are not listed here.
The various network elements described in fig. 1b may also be referred to as functional entities, or as functions. The individual network elements may be network elements implemented on dedicated hardware, or may be software instances running on dedicated hardware, or instances of virtualized functionality on a suitable platform.
Based on the service architecture system of fig. 1a and fig. 1b, the method for authorizing the proxy subscription provided in the embodiment of the present application is described in detail below.
The concept of proxy subscription is introduced first. Taking NF _ a, NF _ B, and NF _ C as examples, assume that NF _ B is a service provider (service provider) and NF _ a and NF _ C are service requesters (service provider). The NF _ a proxy NF _ C subscribing to the NF _ B service means: and the NF _ A sends a subscription request to the NF _ B, the NF _ B determines that the NF _ A agent NF _ C subscribes to the NF _ B after receiving the subscription request, and the NF _ B directly sends a notification to the NF _ C when the conditions are met, wherein the notification is used for providing the subscribed service. This enables the NF _ a proxy NF _ C to subscribe to the service from the NF _ B. In the present application, the proxy subscription may also be implemented in a request-response manner. For example, the NF _ a proxy NF _ C subscribes to the NF _ B for a service, and it can also be understood that the NF _ a proxy NF _ C requests the service from the NF _ B. The scenario of proxy subscription may be extended to NF _ a proxy NF _ C requesting network function services from NF _ B.
The identification of NFs referred to in this application includes: an instance identification (instance ID) of the NF, and/or a Uniform Resource Identifier (URI) of the NF, and/or a Notification end point (Notification end point) of the NF, and/or a Notification Target Address (Notification Target Address) of the NF, and/or a Notification Correlation identification (Notification Correlation ID), and/or a Notification Uniform Resource Locator (Notification URL), and/or a Notification Uniform Resource Identifier (Notification Uniform Resource Identifier, notification), and/or a Callback Uniform Resource Locator (Callback Uniform Resource Locator, callback URL), and/or a Callback Reference (Callback Reference), and/or other forms of ID or Address information capable of uniquely identifying the NF. The following embodiment describes an authorization method for proxy subscription by taking an instance ID of NF identified as NF and/or URI of NF as an example.
The concept of tokens is referred to in this application. The token is used to indicate the invocation authority of the network function service. Any one or more of the following items of information may be included in the token:
an identity of the Service requester NF, an identity of the Service provider NF, a type of the Service provider NF, a Service type of the Service requester NF, a Service Name (S)), an identity of the NRF, a Public Land Mobile Network identity (PLMN ID), a validity Time (Expiration Time), single Network slice selection assistance information (S-NSSAI), an NF set identity (NF set ID), a Service instance set identity (Service instance ID), a Service Area identity (Service ID), a Service Area (Service Area), a Data Network Name (Data Network Name, DNN), a Tracking Area identity (Tracking Area ID, TAI), public Land Mobile Network identity (PLMN ID), location information of a target Network function or Network function Service (location information of the target NF or NF Service), event identity (Event ID (S)), event List (Event List), subscription Change Notification Uniform Resource identity (Subscription Change Notification Uniform Resource Identifier), subscription Change Notification related Uniform Resource identity (Subscription Change Notification Identifier), subscription Permanent identity (Subscription Permanent Identifier, SUPI), group identity (Group ID), general Public Subscription identity (Generic Public Subscription Identifier, GPSI), permanent device identity (PEI). Different tokens can also be distinguished by token identification.
In the embodiment of the application, an authorization flow is added in the process of proxy subscription so as to ensure the security of the proxy subscription.
The embodiments described below relate to interactions between a plurality of NFs, including a first NF, a second NF, a third NF, an NRF, and an SCP. Wherein, the first NF corresponds to the NF _ A, the second NF corresponds to the NF _ C, and the third NF corresponds to the NF _ B. The first NF proxies the second NF to subscribe to the service from the third NF. The network function service provided by a service provider or service provider (service provider) in this application may also be referred to as simply a service.
One of the authorization methods of the proxy subscription and the other of the authorization methods of the proxy subscription described below are based on interactions between four network functions, including a first NF, an NRF, a second NF, and a third NF.
As shown in fig. 2, a flow of one of the methods for authorizing a proxy subscription provided in the embodiment of the present application is as follows.
S201, the first NF sends a token request to the NRF, and the NRF receives the token request from the first NF.
The token request (token request) is used to request execution authorization. The process of performing authorization includes: and judging whether the first NF has the authority of sending the subscription request to the third NF, for example, whether the first NF has the authority of acting on the second NF to subscribe the network function service to the third NF. The process of authorizing further comprises: and judging whether the second NF has the authority of receiving the network function service provided by the third NF.
The token request carries an identifier of a service requester (service provider), that is, an identifier of the first NF and an identifier of the second NF. For example, an instance identifier (instance ID) and/or a Uniform Resource Identifier (URI) of the first NF, and an instance identifier (instance ID) and/or a Uniform Resource Identifier (URI) of the second NF. The token request may also carry a network function service, a type of a service provider (service provider), and/or an identifier of the service provider (service provider), which is a third NF in this embodiment. For example, an instance identification (instance ID) and/or a Uniform Resource Identification (URI) carrying the third NF, and/or a type of the third NF (NF type). The token request may further carry an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification association ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Subscription Identifier, GPSI), and/or a Permanent device Identifier (Permanent device Identifier, PEI). The token request may also carry other parameters required for authorization and token generation.
Optionally, the token request may further carry indication information, where the indication information is used to indicate that the first NF requests a token in a proxy subscription scenario, that is, to indicate that the NRF needs to determine whether the second NF has a right to receive a network function service provided by a third NF, and to indicate that the NRF needs to determine whether the first NF has a right to send a subscription request to the third NF, specifically, whether the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF.
Optionally, before S201, S200 is further included.
S200, the second NF sends NF information to the first NF, and the first NF receives the NF information from the second NF.
The NF information includes an identification of the second NF, such as an instance identification (instance ID) and/or a Uniform Resource Identification (URI) of the second NF. Optionally, the NF information further includes an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification relationship ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Public Subscription Identifier, GPSI), and/or a Permanent device Identifier (PEI). In addition, it should be noted that if the first NF already configures or stores the information of the second NF, S200 does not need to be executed.
Through S200, the first NF may obtain information of the second NF, and the identifier of the second NF carried in the token request in S201 may be derived from S200, or may be preconfigured or stored by the first NF.
S202, NRF generates a token based on the received token request.
The NRF first determines from the token request that the first NF requests a token in the proxy subscription scenario. Specifically, the NRF may be determined according to a service calling name of the token request, where the service calling name of the token request in the present application is different from the service calling name of the token request in the prior art; or, the NRF determines according to the indication information carried in the token request; or, the NRF determines according to the token request carrying the identifiers (instance ID and/or URI) of the two service requesters; or the NRF determines that the current first NF requests a token in the proxy subscription scenario according to other means.
When performing the authorization, the NRF may determine whether the first NF has an authority to proxy the second NF to subscribe to the network function service from the third NF, and determine whether the second NF has an authority to receive the network function service provided by the third NF. The method for determining the permission may be, for example, that the NRF may determine the permission according to an identifier of the first NF, an identifier of the second NF, an identifier and/or a type of a service provider (that is, a third NF) carried in the token request, and/or other information in the token request, in combination with a locally configured policy or authorization information.
The NRF generates a token (token) if the NRF determines that the second NF has the right to receive the network function service provided by the third NF and determines that the first NF has the right to proxy the second NF to subscribe the network function service to the third NF.
The generated token contains the identifications of the first NF and the second NF, and the specific NF identification may be an NF Instance ID, and/or a URI of the NF, and/or other forms of ID or address information capable of uniquely identifying the NF. The token may further include an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification Identifier), and/or a Subscription Permanent Identifier (SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (gprs), and/or a Permanent device Identifier (PEI), and/or other parameters required for authorization and token generation.
The identifiers of the first NF and the second NF in the token are contained in a subject container, and specifically may be an extended length of the subject container, the first half of the subject container fills the identifier of the first NF, and the second half of the subject container fills the identifier of the second NF; or the first half of the subject mail fills the identification of the second NF and the second half of the subject mail fills the identification of the first NF. Or newly defining a subject container, for example, as subject container-new, where the subject container fills in the identifier of the first NF, and the subject container-new fills in the identifier of the second NF; or the object container fills in the identification of the second NF, and the object container-new fills in the identification of the first NF. The application does not limit how the token carries the identifier of the first NF and the identifier of the second NF.
Other information in the Token can be contained in Token Claim, and the application does not limit how the Token carries the other information in the Token.
Optionally, the token may further carry indication information, where the indication information is used to indicate that the token is a token in a proxy subscription scenario, and for example, the indication information is used to indicate that the first NF proxies the second NF to subscribe to the network function service to the third NF.
After the token is generated, S203 is executed.
If the second NF is determined not to have the right to receive the network function service provided by the third NF, or the first NF is determined not to have the right to proxy the second NF to subscribe the network function service to the third NF, or the second NF is determined not to have the right to receive the network function service provided by the third NF, and the first NF is determined not to have the right to proxy the second NF to subscribe the network function service to the third NF, the flow is ended, or a message may be sent to the first NF to indicate the determination result.
S203, the NRF sends a token response to the first NF, and the first NF receives the token response from the NRF.
The token response is used to respond to the token request in S201. The token response carries the NRF generated token. The token is used to indicate that the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF and to indicate that the second NF has a right to receive the network function service provided by the third NF.
Through S201 to S203, the NRF can determine the authority of the proxy subscription, thereby improving the security of the proxy subscription.
After S203, the following steps may also be included.
S204, the first NF sends a subscription request to a third NF, and the third NF receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The subscription request includes the token, an instance identifier (instance ID) and/or a Uniform Resource Identifier (URI) of the first NF, and an instance identifier (instance ID) and/or a Uniform Resource Identifier (URI) of the second NF. The subscription request may also carry a network function service requesting subscription, a type of a service provider (service provider) and/or an identifier of the service provider (service provider), where the service provider is a third NF in this embodiment. For example, an instance identification (instance ID) and/or a Uniform Resource Identification (URI) carrying the third NF, and/or a type of the third NF (NF type). The Subscription request may further carry an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification association ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Subscription Identifier, GPSI), and/or a Permanent device Identifier (Permanent device Identifier, PEI).
Specifically, the first NF determines, according to the token response sent by the NRF, that the first NF has the right to proxy the second NF to subscribe to the network function service from the third NF, and then sends a subscription request to the third NF.
S205, the third NF verifies the token contained in the subscription request, if the verification is successful, S206 is executed; otherwise, if the token check fails, the third NF finishes the process, or replies a subscription response to the first NF, where the subscription response includes the subscription failure, or the token check failure information, or other information indicating the process failure.
Specifically, if the token verification is successful, the third NF determines that the second NF has the right to receive the network function service provided by the third NF, and determines that the first NF has the right to subscribe the network function service from the third NF by acting on the second NF.
Wherein the token check includes one or more of: and carrying out integrity check on the token, checking whether the token is used for indicating that the second NF has the authority of receiving the network function service provided by the third NF and checking the validity of the token. The verification fails when any one verification is unsuccessful, and the verification succeeds when all verifications are successful. Specifically, it is required to check whether the subscription request includes the identifier of the third NF. It is also necessary to check whether the identity and/or type of the service provider (service provider) contained in audioclaim in the token is the same as the identity and/or type of the third NF. It may also be checked whether the third NF is capable of providing the network function service in the subscription request. For example, the network function services that the third NF can provide include service 1, service 2, and service 3, but the token indicates that the authorized service is service 4, the verification fails. The token has a validity period, and when the token is within the validity period, the token has validity, and when the token exceeds the validity period, the token is invalid. The verification is successful only if the token is within the validity period. It may also be checked whether the information contained in the token is identical to the corresponding information in the subscription request.
The above description of verifying a token applies to the process of verifying a token throughout.
Optionally, the third NF may verify the token through the NRF. Specifically, the third NF sends a check request to the NRF after receiving the subscription request. The NRF receives a check request from the third NF, and checks a token included in the check request. The NRF replies the verification result to the third NF. If the verification is successful, the third NF performs S206 and S207. Otherwise, the third NF finishes the process, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token check failure information, or other information indicating a process failure. When the NRF checks the token, the NRF may check whether the token is consistent with the stored token or the token is consistent with the token included in the token response sent to the first NF, in addition to the above-described items of token checking. If the two are consistent, the verification is successful, otherwise, the verification fails. By consistent is meant that the information indicated by the token is the same.
The process of correcting the token by NRF may replace S205.
S206, the third NF sends an authorization notice to the second NF, and the second NF receives the authorization notice from the third NF.
The authorization notification carries an authorization result, and the authorization notification is used for indicating whether the second NF has a right to receive the network function service provided by the third NF. The second NF may save the authorization result in the authorization notification.
Alternatively, the authorization notification may also include a token. The second NF learns the authorization result through the token. That is, the second NF knows whether the second NF has the right to receive the network function service provided by the third NF according to the token, and can also know that the first NF has the right to proxy the second NF to subscribe the network function service to the third NF.
S207, the third NF sends a subscription response (subscribe response) to the first NF, and the first NF receives the subscription response from the third NF.
The subscription response may carry an authorization result for indicating that the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF.
Alternatively, if S206 is not executed, the following operations may be performed instead: the third NF may also carry an authorization result in the subscription response, where the authorization result includes: the first NF has the authority of acting the second NF to subscribe the network function service to the third NF, and whether the second NF has the authority of receiving the network function service provided by the third NF; or, the third NF carries a token with a successful check in the subscription response. And the first NF determines that the authorization is successful according to the token or the authorization result carried in the subscription response. Further, the first NF may also notify the second NF of the token or the authorization result. Of course, in the case of performing S206, these operations may also be included.
If the third NF verifies that the token is unsuccessful, the third NF may also send an authorization result indicating that the first NF does not have an authority to subscribe the network function service from the third NF by proxying the second NF to the third NF, or indicating that the second NF does not have an authority to receive the network function service provided by the third NF to the first NF. S206 is omitted in this case.
S206 and S207 have no strict execution order and may be executed in the order of exchange.
S208, the third NF provides the network function service for the second NF according to the subscribed network function service.
Specifically, when the subscription condition is satisfied, the third NF sends a notification (notify) to the second NF, where the notification includes the network function service provided by the third NF.
Optionally, since the first NF proxies the second NF to subscribe to the third NF, the third NF may also send a notification to the first NF, where the notification carries information such as modification or unsubscription of the service.
One of the authorization methods for proxy subscription may also be applicable to roaming scenarios. In a roaming scenario, each NF is located in two different Public Land Mobile Networks (PLMNs). The interaction between NFs is forwarded through the SCP serving them. And the token request sent by the first NF is forwarded to the NRF in the PLMN where the first NF is located by the NRF in the PLMN where the third NF is located. And the token response sent by the NRF in the PLMN where the third NF is located is forwarded to the first NF by the NRF in the PLMN where the first NF is located. The generation and authorization of the token is done by the NRF within the PLMN where the third NF is located. And under the condition that the third NF can check the token through the NRF, the token check is also completed by the NRF in the PLMN where the third NF is located. The other processing is the same as described in one of the authorization methods of the proxy subscription.
Based on the same inventive concept, the embodiment of the present application provides a second authorization method for proxy subscription. The main contents comprise: and the NRF generates two tokens aiming at the token requests respectively sent by the first NF and the second NF. For example representing the two tokens by a first token and a second token. The first token is requested by and sent by the NRF to the first NF. The second token is requested by the second NF and sent by the NRF to the second NF. The first token is used for indicating that the first NF has the authority of acting on the second NF to subscribe the network function service to the third NF; the second token is used to indicate that the second NF has the right to receive network function services provided by the third NF.
As shown in fig. 3, a possible flow of the second method for authorizing the proxy subscription is as follows.
S301, the first NF sends a notification message to the second NF, and the second NF receives the notification message from the first NF.
The notification message is used to indicate that the second NF requests a token. For example, the second NF is instructed to send a token request to the NRF to obtain a token.
The notification message may carry the following information:
an identification of the first NF, such as an instance ID and/or URI of the first NF. The notification also carries a type of the service provider (service provider) and/or an identifier of the service provider (service provider), where the service provider is a third NF in this embodiment. The notification also carries other parameters required for authorization and token generation.
Optionally, the Notification message further includes an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification association ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Public Subscription Identifier, GPSI), and/or a Permanent device Identifier (PEI).
S302, the second NF sends a token request to the NRF, and the NRF receives the token request from the second NF.
The token request is used for requesting to execute authorization, and the process of executing authorization comprises the following steps: and judging whether the second NF has the authority of receiving the network function service provided by the third NF. The token request carries an identifier of a service requester (service provider), i.e., an identifier of the second NF. Such as an instance identification (instance ID) and/or a Uniform Resource Identification (URI) carrying the second NF. The token request further carries a network function service requesting subscription, a type of a service provider (service provider) and/or an identifier and/or a type of the service provider (service provider), where the service provider is a third NF in this embodiment. The token request also carries other parameters required for authorization and token generation, please refer to the related description of the parameters included in the token request in S201, which is not described herein again.
S303, the first NF sends a token request to the NRF, which receives the token request from the first NF.
The token request is for requesting execution authorization. The process of performing authorization includes: and judging whether the first NF has the authority of sending the subscription request to the third NF, for example, whether the first NF has the authority of acting the second NF to subscribe the network function service to the third NF. The token request carries an identifier of a service requester (service provider), that is, an identifier of a first NF, and also carries an identifier of a second NF, and the token is an agent subscription scenario. For example, the instance identifier (instance ID) and/or Uniform Resource Identifier (URI) of the first NF, and the instance identifier (instance ID) and/or Uniform Resource Identifier (URI) of the second NF are carried. The token request also carries a network function service, a type of a service provider (service provider) and/or an identifier of the service provider (service provider), which is a third NF in this embodiment. The notification also carries other parameters required for authorization and token generation, please refer to the related description of the parameters included in the token request in S201, which is not described herein again.
For the convenience of distinguishing, the token request sent by the first NF to the NRF is marked as a first token request, and the token request sent by the second NF to the NRF is marked as a second token request.
Optionally, both the first token request and the second token request may further carry indication information, where the indication information is used to indicate a token in a scenario of requesting a proxy to subscribe.
There is no strict execution order between S302 and S303, and they may be exchanged.
The first token requests a call authority for acquiring a network function service provided by the third NF. For example, the first NF is requested to acquire whether the first NF has the right to send a subscription request to the third NF, or whether the first NF has the right to proxy the second NF to subscribe to the network function service from the third NF.
The second token request is for obtaining a call authority of a network function service provided by the third NF. For example, it is requested to acquire whether the second NF has a right to receive the network function service provided by the third NF.
Similar to the embodiment of fig. 2, optionally, S300 is further included before S301.
S300 is the same as S200.
S304, the NRF judges whether the first NF has the authority of acting the second NF to subscribe the network function service to the third NF or not based on the received first token request, and if so, generates a first token;
the NRF judges whether the second NF has the authority of receiving the network function service provided by the third NF or not based on the received second token request, and if so, generates a second token.
Optionally, the first token request received by the NRF from the first NF may further carry indication information, where the indication information is used to indicate that the first NF proxies the second NF to subscribe to the network function service from the third NF.
Optionally, the second token request received by the NRF from the second NF may further carry indication information, where the indication information is used to indicate that the first NF proxies the second NF to subscribe to the network function service from the third NF.
The NRF determines that the current first NF requests a token in the proxy subscription scenario. Specifically, the NRF may be determined according to a service call name of the first token request and/or the second token request, where the service call name of the token request is different from the service call name of the token request in the prior art; or the NRF determines according to the indication information carried in the first token request and/or the second token request; or the NRF determines that the current first NF requests a token in the proxy subscription scenario according to other means.
Specifically, the NRF may determine the permission by combining the locally configured policy or authorization information according to the identifier of the first NF, the identifier or the type of the service provider (i.e., the third NF) carried in the first token request, and/or other information in the first token request, that is, determine whether the first NF has the permission to proxy the second NF to subscribe to the network function service from the third NF. If the first NF is judged to have the authority of acting on the second NF to subscribe the network function service to the third NF, the NRF generates a first token.
The first token includes identifiers of the first NF and the second NF, and the specific NF identifier may be an NF Instance ID, and/or a URI of the NF, and/or other forms of ID or address information capable of uniquely identifying the NF. The token may further include an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification Identifier), and/or a Subscription Permanent Identifier (SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (gprs), and/or a Permanent device Identifier (PEI), and/or other parameters required for authorization and token generation.
The NRF may also determine, according to the identifier of the second NF, the identifier and/or the type of the service provider (i.e., the third NF) carried in the second token request, and/or other information in the second token request, in combination with a locally configured policy or authorization information, the authority, that is, determine whether the second NF has the authority to receive the network function service provided by the third NF. If the second NF is judged to have the authority of receiving the network function service provided by the third NF, the NRF generates a second token.
The second token includes an identifier of the second NF, where the specific NF identifier may be an NF Instance ID, and/or a URI of the NF, and/or other forms of ID or address information capable of uniquely identifying the NF. The token may further include an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification Identifier), and/or a Subscription Permanent Identifier (SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (gprs), and/or a Permanent device Identifier (PEI), and/or other parameters required for authorization and token generation.
Please refer to the relevant description of S202 how the above first token and the second token carry the identity of the NF and other information in the token.
NRF executes S305 after generating the first token and the second token.
If it is determined that the second NF does not have the right to receive the network function service provided by the third NF, or it is determined that the first NF does not have the right to subscribe the network function service to the third NF by proxying the second NF, or it is determined that the second NF does not have the right to receive the network function service provided by the third NF and it is determined that the first NF does not have the right to subscribe the network function service to the third NF by proxying the second NF, the NRF ends the flow, and the NRF may also send a message to the first NF to indicate the determination result.
S305, the NRF sends a token response to the first NF, which receives the token response from the NRF.
The token response carries a first token and a second token. Since the NRF knows that the first NF is subscribing to the network function service from the second NF to the third NF, it is sufficient for the NRF to send a token response to the first NF. The token response may also carry an identifier of the first NF and an identifier of the second NF.
Through S301 to S305, the NRF can determine the authority of the proxy subscription, thereby improving the security of the proxy subscription.
After S305, the following steps may also be included.
S306, the first NF sends a subscription request (subscribe request) to the third NF, and the third NF receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The subscription request includes a first token and a second token, and other parameters included in the subscription request refer to the relevant description of S204.
Specifically, the first NF determines, according to the token response sent by the NRF, that the first NF has the right to proxy the second NF to subscribe to the network function service from the third NF, and then sends a subscription request to the third NF.
S307, the third NF verifies the first token and the second token contained in the subscription request, and if the verification is successful, S308 is executed; otherwise, the third NF ends the process, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token check failure information, or other information indicating a process failure.
If the first token is successfully verified, determining that the first NF has the authority of acting the second NF to subscribe the network function service to the third NF; and if the second token is verified successfully, determining that the second NF has the authority of receiving the network function service provided by the third NF.
The token checking content and the token checking mode may refer to the description of the embodiment shown in fig. 2, and are not described herein again.
Similarly, optionally, the third NF may verify the token through the NRF. Specifically, after receiving the subscription request, the third NF sends a verification request to the NRF, and the NRF receives the verification request from the third NF and verifies the first token and the second token included in the verification request. The NRF replies the verification result to the third NF. If the verification is successful, the third NF executes S308, otherwise, the third NF ends the procedure, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token verification failure information, or other information indicating that the procedure fails.
The process of the third NF verifying the token through NRF may replace S307.
The descriptions of S308-S310 are the same as those of S206-S208, and are not repeated herein.
The second authorization method for proxy subscription can also be applied to roaming scenarios. In the roaming scenario, each NF is located on two different PLMNs. The interaction between NFs is forwarded through the SCP serving them. And the first token request sent by the first NF is forwarded to the NRF in the PLMN where the third NF is located by the NRF in the PLMN where the first NF is located. And the second token request sent by the second NF is forwarded to the NRF in the PLMN where the third NF is located by the NRF in the PLMN where the second NF is located. And the token response sent by the NRF in the PLMN where the third NF is located is forwarded to the first NF by the NRF in the PLMN where the first NF is located. The generation and authorization of the token is done by the NRF within the PLMN where the third NF is located. The token verification is also completed by the NRF in the PLMN where the third NF is located, in a manner that the third NF can verify the token through the NRF. The other processing procedures are the same as those described in the second method for authorizing the proxy subscription.
Based on the same inventive concept, the embodiment of the present application provides a third authorization method for proxy subscription. The third method of authorization of a proxy subscription described below is based on the interaction between three network functions. The three network functions include a first NF, a second NF, and a third NF.
As shown in fig. 4, a third process of the method for authorizing a proxy subscription provided in the embodiment of the present application is as follows.
S401, the first NF sends a subscription request (subscribe request) to the third NF, and the third NF receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The subscription request carries the identifier of the first NF and the identifier of the second NF, and please refer to the related description of S204 for other parameters included in the subscription request.
Optionally, S400 is further included before S401.
S400, the second NF sends NF information to the first NF, and the first NF receives the NF information from the second NF.
The NF information includes an identification of the second NF. Such as an instance identification (instance ID) and/or a Uniform Resource Identification (URI) of the second NF. If the first NF has already configured or stored the information of the second NF, S400 does not need to be performed.
Optionally, the NF information further includes an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification relationship ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Public Subscription Identifier, GPSI), and/or a Permanent device Identifier (PEI).
Through S400, the first NF can obtain information of the second NF, and the identifier of the second NF carried in the subscription request in S401 may originate from S400, or may be preconfigured or stored by the first NF.
S402, the third NF executes authorization based on the received subscription request.
The authorization operations performed include: and judging whether the first NF has the authority of acting on the second NF to subscribe the network function service to the third NF or not, and judging whether the second NF has the authority of receiving the network function service provided by the third NF or not.
The method for determining the permission may be, for example, that the third NF determines the permission according to information, such as the identifier of the first NF, the identifier of the second NF, and the type of the service provider, carried in the subscription request, in combination with a locally configured policy or authorization information.
If the third NF determines that the second NF has the right to receive the network function service provided by the third NF, S403 is executed, or if the third NF determines that the second NF has the right to receive the network function service provided by the third NF and the first NF has the right to proxy the second NF to subscribe the network function service to the third NF, S403 is executed.
If it is determined that the second NF does not have the right to receive the network function service provided by the third NF, or it is determined that the first NF does not have the right to subscribe the network function service to the third NF by proxying the second NF, or it is determined that the second NF does not have the right to receive the network function service provided by the third NF and it is determined that the first NF does not have the right to subscribe the network function service to the third NF by proxying the second NF, the third NF ends the flow, and the third NF may also send a message to the first NF to indicate the determination result.
S403, the third NF sends an authorization notice to the second NF, and the second NF receives the authorization notice from the third NF.
The authorization notification carries an authorization result, and the authorization notification is used for indicating that the second NF has the authority of receiving the network function service provided by the third NF. The second NF may save the authorization result in the authorization notification.
S404, the third NF sends a subscription response (subscribe response) to the first NF, and the first NF receives the subscription response from the third NF.
The subscription response may carry an authorization result for indicating that the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF.
Optionally, if S403 is not executed, the third NF may further carry an authorization result in the subscription response, where the authorization result includes: the first NF has a right to proxy the second NF to subscribe the network function service to the third NF, and whether the second NF has a right to receive the network function service provided by the third NF. And the first NF determines that the authorization is successful according to the authorization result carried in the subscription response. Further, the first NF may also notify the second NF of the authorization result. Of course, in the case where S403 is executed, these operations may also be included.
S403 and S404 do not have a strict execution order and can be executed in an exchange order.
S405, the third NF provides the network function service for the second NF according to the subscribed network function service.
Specifically, when the subscription condition is satisfied, the third NF sends a notification (notify) to the second NF, where the notification includes the network function service provided by the third NF.
Optionally, since the first NF proxies the second NF to subscribe to the third NF, the third NF may also send a notification to the first NF, where the notification carries information such as modification or unsubscription of the service.
The third authorization method for proxy subscription can also be applied to roaming scenarios. In a roaming scenario, each NF is located on two different PLMNs. The other processing procedures are the same as those described in the third method for authorizing the proxy subscription.
And after receiving the proxy subscription request, the third NF judges the authority, so that the safety in proxy subscription can be ensured.
Based on the same inventive concept, the embodiment of the application provides four authorization methods for proxy subscription, five authorization methods for proxy subscription and six authorization methods for proxy subscription. The fourth of the authorization methods for proxy subscription, the fifth of the authorization methods for proxy subscription, and the sixth of the authorization methods for proxy subscription described below are all based on interactions between five network functions. The five network functions include a first NF, a second NF, a third NF, NRF, and SCP.
The SCP is used for playing a role in forwarding service calls between the NFs, or the SCP can independently complete the authorization of requesting services, or the SCP can cooperate with the NRF to complete the authorization of requesting services.
As shown in fig. 5, a flow of a fourth method for authorizing a proxy subscription provided in the embodiment of the present application is as follows. The method ensures the safety of the proxy subscription through the token.
S501, the first NF sends a token request to the NRF, and the NRF receives the token request from the first NF.
This step is the same as S201, and the details can refer to S201, which is not described herein again.
Optionally, S500 is further included before S501.
S500, the second NF sends NF information to the first NF, and the first NF receives the NF information from the second NF.
The step is the same as S200, and the detailed description may refer to S200, which is not repeated herein.
S502, the NRF determines whether the second NF has the right to receive the network function service provided by the third NF based on the received token request.
The step is the same as S202, and the details can refer to S202, which are not described herein again.
S503, the NRF sends a token response to the first NF, and the first NF receives the token response from the NRF.
The step is the same as S203, and the details can refer to S203, which is not described herein again.
The descriptions of S501 to S503 are the same as those of S201 to S203, and reference may be made to the description about one of the authorization methods of the proxy subscription.
After S503, the following steps may be further included.
S504, the first NF sends a subscription request (subscribe request) to the SCP, and the SCP receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The subscription request includes the token, and other information included in the subscription request is referred to as relevant description in S204.
S505, the SCP checks the token contained in the subscription request, and if the check is successful, S508 is executed; otherwise, if the verification fails, the SCP ends the process, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token verification failure information, or other information indicating a process failure.
If the verification is successful, the SCP determines that the first NF has the authority of acting the second NF to subscribe the network function service to the third NF, and determines that the second NF has the authority of receiving the network function service provided by the third NF.
Wherein the verification comprises one or more of: and carrying out integrity check on the token, checking whether the token is used for indicating that the second NF has the authority of receiving the network function service provided by the third NF and checking the validity of the token. The verification fails when any one verification fails, and the verification succeeds when all verifications succeed. Specifically, it is required to check whether the subscription request includes the identifier of the third NF. It is further required to check whether the identifier and/or type of the service provider (service provider) included in the audio container in the token is the same as the identifier and/or type of the third NF queried by the SCP, specifically, the SCP may query the identifier of the third NF according to locally configured information, or query the identifier of the third NF according to information obtained from the NRF. It may also be checked whether the third NF is capable of providing the subscribed network function service. For example, the network function services that the third NF can provide include service 1, service 2, and service 3, but the token indicates that the authorized service is service 4, the verification fails. The token has a validity period, and when the token is within the validity period, the token has validity, and when the validity period is exceeded, the token is invalid. The check is successful only if the token is within the validity period. It may also be checked whether the information contained in the token is identical to the corresponding information in the subscription request.
Like one of the authorization methods for proxy subscription, the SCP may optionally also check the token through NRF. Specifically, after receiving the subscription request, the SCP sends a check request to the NRF, and the NRF receives the check request from the SCP and checks a token included in the check request. The NRF returns a check result to the SCP. If the verification is successful, the SCP executes S508; otherwise, the SCP ends the procedure, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token check failure message, or other message indicating that the procedure fails.
The process of correcting the token by NRF may replace S507.
S506, the SCP sends an authorization notice to the second NF, and the second NF receives the authorization notice from the SCP.
The authorization notification carries an authorization result, and the authorization notification is used for indicating that the second NF has a right to receive the network function service provided by the third NF. The second NF may save the authorization result in the authorization notification.
Alternatively, the authorization notification may also include a token. The second NF learns the authorization result through the token. That is, the second NF knows whether the second NF has the right to receive the network function service provided by the third NF according to the token, and can also know that the first NF has the right to proxy the second NF to subscribe the network function service to the third NF.
S507, the SCP sends a subscription request to the third NF, and the third NF receives the subscription request from the SCP.
The subscription request carries information except for the token carried in the subscription request received from the first NF, and may also carry a verification result. The check result is used to indicate whether the token check was successful. Or for indicating the authorization result, i.e. indicating whether the second NF has the right to receive the network function service provided by the third NF, and whether the first NF has the right to proxy the second NF to subscribe the network function service to the third NF.
There is no strict execution order between S506 and S507, and the order may be exchanged.
S508, the third NF returns a subscription response to the SCP, and the SCP receives the subscription response from the third NF.
S509, the SCP sends a subscription response to the first NF, and the first NF receives the subscription response from the SCP.
The subscription response may carry an authorization result, which is used to indicate whether the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF, and whether the second NF has a right to receive the network function service provided by the third NF. And if the SCP successfully verifies the token, the authorization result is yes, and if the SCP unsuccessfully verifies the token, the authorization result is no. The authorization result is that the first NF has the authority of acting the second NF to subscribe the network function service to the third NF, and/or the second NF has the authority of receiving the network function service provided by the third NF. And if the authorization result is negative, the first NF does not have the authority of acting the second NF to subscribe the network function service to the third NF, and/or the second NF does not have the authority of receiving the network function service provided by the third NF.
Alternatively, the subscription response may carry a token. In the case that the subscription response carries the token or the authorization result, the token or the authorization result may be further sent to the second NF through the first NF, and S506 is omitted.
And S510, the third NF provides the network function service for the second NF according to the subscribed network function service.
Specifically, when the subscription condition is satisfied, the third NF sends a notification (notify) to the second NF, where the notification includes the network function service provided by the third NF.
Optionally, because the first NF brokers the third NF to subscribe to the service, the third NF may further send a notification to the first NF through the SCP, where the notification carries information such as modification or unsubscription of the service. Specifically, the third NF sends a notification to the SCP, which forwards the notification to the first NF.
The fourth method of authorization for proxy subscription may also be applicable to roaming scenarios. In a roaming scenario, each NF is located on two different PLMNs. The interaction between NFs is forwarded through the SCP serving them. And the token request sent by the first NF is forwarded to the NRF in the PLMN where the first NF is located by the NRF in the PLMN where the third NF is located. And the response of the token sent by the NRF in the PLMN where the third NF is located is forwarded to the first NF by the NRF in the PLMN where the first NF is located. The generation and authorization of the token is done by the NRF within the PLMN where the third NF is located. The token check is also performed by the NRF in the PLMN where NF _ B is located in such a way that the third NF can check the token through the NRF. The verification of the token is done by the SCP serving the third NF. The other processes are the same as those described in the fourth embodiment of the authorization method of the proxy subscription.
Through the fourth authorization method of the proxy subscription, the authority is judged through the NRF in the system architecture of the SCP, and the SCP checks the token, so that the security of the proxy subscription is improved.
As shown in fig. 6, the flow of the fifth method for authorizing a proxy subscription provided in the embodiment of the present application is as follows. The method indicates the authority of the first NF and the third NF through the two tokens respectively so as to improve the security of the proxy subscription process.
S601, the first NF sends a notification message to the SCP, and the SCP receives the notification message from the first NF.
S602, the SCP forwards the notification message to the second NF, and the second NF receives the notification message from the SCP.
The notification message is used to indicate that the second NF requests a token. For example, the second NF is instructed to send a token request to the NRF to obtain a token. The notification message may carry the following information:
an identification of the first NF, such as an instance ID and/or URI of the first NF. The notification also carries a type of a service provider (service provider) and/or an identifier and/or a type of the service provider (service provider), where the service provider is the third NF in this embodiment. The notification also carries other parameters needed for authorization and token generation.
Optionally, the Notification message further includes an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification association ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Public Subscription Identifier, GPSI), and/or a Permanent device Identifier (PEI).
S603, the second NF sends a token request to the NRF, and the NRF receives the token request from the second NF.
The token request is used for requesting to execute authorization, and the process of executing authorization comprises the following steps: and judging whether the second NF has the authority of receiving the network function service provided by the third NF. The token request carries an identifier of a service requester (service provider), i.e., an identifier of the second NF. For example, carrying an identification of the second NF, such as an instance ID and/or URI of the second NF. The token request further carries a network function service requesting subscription, a type of a service provider (service provider) and/or an identifier and/or a type of the service provider (service provider), where the service provider is a third NF in this embodiment. The notification also carries other parameters required for authorization and token generation, please refer to the related description of the parameters included in the second token request in S201, which is not described herein again.
S604, the first NF sends a token request to the NRF, and the NRF receives the token request from the first NF.
The token request is for requesting execution authorization. The process of performing authorization includes: and judging whether the first NF has the authority of sending the subscription request to the third NF, for example, whether the first NF has the authority of acting the second NF to subscribe the network function service to the third NF. The token request carries an identifier of a service requester (service provider), that is, an identifier of a first NF, and also carries an identifier of a second NF, and the token is an agent subscription scenario. For example, the instance identifier (instance ID) and/or Uniform Resource Identifier (URI) of the first NF, and the instance identifier (instance ID) and/or Uniform Resource Identifier (URI) of the second NF are carried. The token request also carries a network function service, a type of a service provider (service provider) and/or an identifier and/or a type of a service provider (service provider), which is a third NF in this embodiment. The notification also carries other parameters required for authorization and token generation, please refer to the related description of the parameters included in the first token request in S201, which is not described herein again.
For the convenience of distinction, a token request sent by the first NF to the NRF is denoted as a first token request, and a token request sent by the second NF to the NRF is denoted as a second token request.
Optionally, both the first token request and the second token request may further carry indication information, where the indication information is used to indicate a token in a scenario of requesting a proxy to subscribe.
There is no strict execution order between S603 and S604, and they may be exchanged.
The first token request is for obtaining a call authority of a network function service provided by the third NF. For example, the first NF is requested to acquire whether the first NF has the right to send a subscription request to the third NF, or whether the first NF has the right to proxy the second NF to subscribe to the network function service from the third NF.
The second token request is for obtaining a call authority of a network function service provided by the third NF. For example, it is requested to acquire whether the second NF has a right to receive the network function service provided by the third NF.
Optionally, S600 is further included before S601.
S600 is the same as S200.
S605, the NRF judges whether the first NF has the authority of acting the second NF to subscribe the network function service to the third NF or not based on the received first token request, and if so, generates a first token;
the NRF judges whether the second NF has the authority of receiving the network function service provided by the third NF or not based on the received second token request, and if so, generates a second token.
Optionally, the first token request received by the NRF from the first NF may further carry indication information, where the indication information is used to indicate that the first NF proxies the second NF to subscribe to the network function service from the third NF.
Optionally, the second token request received by the NRF from the second NF may further carry indication information, where the indication information is used to indicate that the first NF proxies the second NF to subscribe to the network function service from the third NF.
The NRF determines that the current first NF requests a token in the proxy subscription scenario. Specifically, the NRF may be determined according to a service call name of the first token request and/or the second token request, where the service call name of the token request is different from the service call name of the token request in the prior art; or the NRF determines according to the indication information carried in the first token request and/or the second token request; or the NRF determines that the current first NF requests a token in the proxy subscription scenario according to other means.
Specifically, the NRF may determine the permission by combining a locally configured policy or authorization information according to the identifier of the first NF, the identifier or the type of the service provider (i.e., the third NF) carried in the first token request, and/or other information in the first token request, that is, determine whether the first NF has a permission to proxy the second NF to subscribe to the network function service from the third NF. If the first NF is judged to have the authority of acting on the second NF to subscribe the network function service to the third NF, the NRF generates a first token. The information contained in the first token please refer to the description in S304 regarding the first token containing information.
The NRF may also determine, according to information such as an identifier of the second NF and a type of a service provider (i.e., a third NF) carried in the second token request, the right in combination with a locally configured policy or authorization information, that is, determine whether the second NF has a right to receive a network function service provided by the third NF. If the second NF is judged to have the authority of receiving the network function service provided by the third NF, the NRF generates a second token. The information contained in the second token please refer to the description in S304 regarding that the second token contains information.
Please refer to the relevant description of S202 how the above first token and the second token carry the identity of the NF and other information in the token.
NRF performs S606 and S607 after generating the first token and the second token.
If it is determined that the second NF does not have the right to receive the network function service provided by the third NF, or it is determined that the first NF does not have the right to subscribe the network function service to the third NF by proxying the second NF, or it is determined that the second NF does not have the right to receive the network function service provided by the third NF and it is determined that the first NF does not have the right to subscribe the network function service to the third NF by proxying the second NF, the NRF ends the flow, and the NRF may also send a message to the first NF to indicate the determination result.
S606, the NRF sends a token response to the first NF, which receives the token response from the NRF.
For differentiation, it is noted as the first token response.
The first token response carries a first token and a second token. Since the NRF knows that the first NF proxies the second NF to subscribe to the network function service from the third NF, the NRF may send a token response to the first NF without replying to the third NF. The first token response may also carry an identifier of the first NF and an identifier of the second NF.
Through S601-S606, NRF can judge the authority of proxy subscription, and improve the security of proxy subscription.
After S606, the following steps may also be included.
The particular SCP holds the first token and the second token.
S607, the first NF sends a subscription request (subscribe request) to the SCP, and the SCP receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The subscription request includes the first token and the second token, and please refer to the relevant description of S204 for other parameters included in the subscription request.
S608, the SCP checks the token contained in the subscription request, if the check is successful, S610 is executed; otherwise, the third NF ends the process, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token check failure information, or other information indicating a process failure.
If the first token is verified successfully, determining that the first NF has the authority of acting the second NF to subscribe the network function service to the third NF; and if the second token is verified successfully, determining that the second NF has the authority of receiving the network function service provided by the third NF.
The contents and manner of token verification may be described with reference to the embodiment shown in fig. 5, and are not described herein again.
Similarly, optionally, the SCP may also check the token via NRF. Specifically, after receiving the subscription request, the SCP sends a check request to the NRF, and the NRF receives the check request from the SCP and checks a first token and a second token included in the check request. The NRF replies a check result to the SCP. If the verification is successful, the SCP executes S610, otherwise, the third NF ends the flow, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token verification failure information, or other information indicating that the flow fails.
The process of the SCP verifying the token through NRF may replace S608.
S609-S613 are the same as S506-S510, and are not described herein.
Through the fifth authorization method of the proxy subscription, the authority is judged through the NRF in the system architecture of the SCP to generate the first token and the second token, and the SCP checks the first token and the second token, so that the security of the proxy subscription is improved.
The fifth authorization method for proxy subscription may also be applicable to roaming scenarios. In a roaming scenario, each NF is located on two different PLMNs. And the token request sent by the first NF is forwarded to the NRF in the PLMN where the first NF is located by the NRF in the PLMN where the third NF is located. And the token response sent by the NRF in the PLMN where the third NF is located is forwarded to the first NF by the NRF in the PLMN where the first NF is located. The token is checked by the SCP serving the third NF, and the token check is also performed by the NRF in the PLMN where the third NF is located in a manner that the SCP can check the token through the NRF. Other processes are the same as those described in the fifth description of the authorization method of the proxy subscription.
As shown in fig. 7, a flow of the sixth method for authorizing the proxy subscription provided in the embodiment of the present application is as follows. The SCP does not transmit immediately when receiving the subscription request for representing proxy subscription, firstly consults the NRF whether the subscription request is authorized or judges whether the subscription request is authorized by the SCP, and decides whether to transmit the subscription request according to the authorization result. This helps to improve the security of the proxy subscription process.
S701, the first NF sends a subscription request to the SCP, and the SCP receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The parameters included in the subscription request refer to the relevant description of S204.
Optionally, before S701, S700 is further included.
S700, the second NF sends NF information to the first NF, and the first NF receives the NF information from the second NF.
This step is the same as S700, and the details can refer to S200, which is not described herein again.
S702, the SCP sends an authorization request to the NRF, and the NRF receives the authorization request from the SCP.
The authorization request is for consulting the NRF whether the second NF has a right to receive network function services provided by the third NF, and whether the first NF has a right to proxy the second NF to subscribe to the network function services from the third NF. The authorization request contains information referring to the token request in S201 that contains the relevant description of the parameters.
S703, NRF executes authorization based on the received authorization request.
When performing the authorization, the NRF may determine whether the first NF has an authority to proxy the second NF to subscribe to the network function service from the third NF, and determine whether the second NF has an authority to receive the network function service provided by the third NF. The method for determining the permission may be, for example, that the NRF may determine the permission according to an identifier of the first NF, an identifier of the second NF, an identifier and/or a type of the service provider, and/or other information in the authorization request, in combination with a locally configured policy or authorization information.
S704, the NRF sends an authorization response to the SCP, and the SCP receives the authorization response from the NRF.
The authorization response is used in response to the authorization request of S702. The authorization response carries an authorization result for judging authorization. For example, the authorization result is successful authorization, which indicates that the first NF has the right to proxy the second NF to subscribe the network function service to the third NF, and the second NF has the right to receive the network function service provided by the third NF.
Alternatively, S704 is executed only when the determined authorization result is successful in authorization. Otherwise, the NRF flow ends, or the NRF returns a response containing the authorization failure to the SCP.
Alternatively, S702 to S704 may be omitted, and authorization is determined by the SCP. After receiving the subscription request, the SCP determines, based on the subscription request, whether the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF, and whether the second NF has a right to receive the network function service provided by the third NF, to obtain an authorization result.
S705, the SCP judges whether to forward the subscription request or send a subscription refusal message according to the authorization response.
The SCP performs S706 when the result in the authorization response is that authorization is successful. And when the result in the authorization response is that the authorization is unsuccessful, the SCP sends a subscription refusing message to the first NF. The subscription denial message characterizes a denial of the first NF proxy that the second NF subscribe to network function services from the third NF.
S706, the SCP sends an authorization notice to the second NF, and the second NF receives the authorization notice from the SCP.
The authorization notification carries an authorization result, and the authorization result includes: the second NF has a right to receive the network function service provided by the third NF, and may further include the first NF having a right to broker the second NF to subscribe to the network function service from the third NF. The second NF may save the authorization result in the authorization notification.
S707, the SCP sends a subscription request to the third NF, and the third NF receives the subscription request from the SCP.
The subscription request carries information carried in the subscription request received from the first NF, and may also carry an authorization result. The authorization result is used to indicate whether the second NF has a right to receive the network function service provided by the third NF, and/or whether the first NF has a right to subscribe the network function service from the third NF by acting on the second NF.
There is no strict execution order between S706 and S707, and the order may be exchanged.
S708, the third NF returns a subscription response to the SCP, and the SCP receives the subscription response from the third NF.
S709, the SCP sends a subscription response to the first NF, and the first NF receives the subscription response from the SCP.
The subscription response may carry an authorization result for indicating whether the first NF has a right to proxy the second NF to subscribe to the network function service from the third NF.
S710, the third NF provides the network function service for the second NF according to the subscribed network function service.
Specifically, when the subscription condition is satisfied, the third NF sends a notification (notify) to the second NF, where the notification includes the network function service provided by the third NF.
Optionally, since the first NF brokers the third NF to subscribe to the service, the third NF may also send a notification to the first NF through the SCP, where the notification carries information such as modification or unsubscription of the service. Specifically, the third NF sends a notification to the SCP, which forwards the notification to the first NF.
The sixth method of authorization for proxy subscription may also be applicable to roaming scenarios. In a roaming scenario, each NF is located on two different PLMNs. The interaction between NFs is forwarded through the SCP serving them. The subscription request sent by the first NF is forwarded by the SCP serving the first NF to an SCP serving a third NF. And the subscription response sent by the SCP serving the third NF is sent to the first NF by the SCP serving the first NF. Authorization (i.e., determining the rights) is accomplished by the NRF within the PLMN where the third NF is located. The verification of the authorization (S705) is completed by the SCP serving the third NF, and the verification is completed by the SCP in the PLMN where the third NF is located, in the case that the authorization mode is determined by the SCP. The other processes are the same as those described in the sixth description of the authorization method of the proxy subscription.
The embodiments described below relate to interactions between a plurality of NFs, including a first NF, a third NF, and an NRF. Wherein, the first NF corresponds to the NF _ A, and the third NF corresponds to the NF _ B. The first NF subscribes to the service to a third NF, which then sends a service notification to the first NF. The network function service provided by a service provider or service provider (service provider) in this application may also be referred to as simply a service.
The seventh method of authorization for a proxy subscription described below is based on interactions between three network functions, including a first NF, NRF, and a third NF.
As shown in fig. 10, a flow of a seventh method for authorizing a proxy subscription provided in the embodiment of the present application is as follows.
S1001, the first NF sends a token request to the NRF, and the NRF receives the token request from the first NF.
The token request (token request) is used to request execution authorization. The process of performing authorization includes: and judging whether the first NF has the authority of sending the subscription request to the third NF.
The token request carries an identifier of a service requester (service provider), i.e., an identifier of the first NF. Such as an instance identification (instance ID) and/or a Uniform Resource Identification (URI) carrying the first NF. The token request may also carry a network function service, a type of a service provider (service provider), and/or an identifier of the service provider (service provider), which is a third NF in this embodiment. For example, an instance identification (instance ID) and/or a Uniform Resource Identification (URI) carrying the third NF, and/or a type of the third NF (NF type). The token request may further carry an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification association ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Public Subscription Identifier, GPSI), and/or a Permanent device Identifier (PEI). The token request may also carry other parameters required for authorization and token generation.
Optionally, the token request may further carry indication information, where the indication information is used to indicate that the first NF requests a token in a subscription scenario, that is, to indicate that the NRF needs to determine whether the first NF has an authority to send the subscription request to a third NF.
S1002, NRF generates a token based on the received token request.
The NRF first determines from the token request that the first NF requests a token in the subscription scenario. Specifically, the NRF may be determined according to the service call name of the token request; or, the NRF determines according to the indication information carried in the token request; alternatively, the NRF is determined from parameters (e.g., URI, event ID(s), etc.) carried in the token request; or the NRF determines that the current first NF requests a token in the subscription scenario according to other means.
When performing authorization, the NRF may determine the authorization according to the identifier of the first NF, the identifier and/or the type of the service provider (i.e., the third NF), and/or other information in the token request, in combination with the locally configured policy or the authorization information.
If the NRF judges that the first NF has the right of subscribing the network function service to the third NF, a token (token) is generated.
The generated token contains a first NF identification, and the specific NF identification may be an NF Instance ID, and/or a URI of the NF, and/or other forms of ID or address information capable of uniquely identifying the NF. The token may further comprise an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification association ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Public Subscription Identifier, GPSI), and/or a Permanent device Identifier (Permanent Equipment Identifier, PEI), and/or other parameters required for authorization and token generation.
The application does not limit how the token carries the identifier of the first NF and other information in the token.
Optionally, the token may further carry indication information, where the indication information is used to indicate that the token is a token in a subscription scenario, and for example, the indication information is used to indicate that the first NF subscribes to the network function service to the third NF.
After the token is generated, S1003 is executed.
If the first NF is determined not to have the right to subscribe the network function service to the third NF, the process is ended, or a message may be sent to the first NF to indicate the determination result.
S1003, the NRF sends a token response to the first NF, and the first NF receives the token response from the NRF.
The token response is used to respond to the token request in S1001. The token response carries the NRF generated token. The token is used to indicate that the first NF has the right to subscribe to network function services from a third NF.
Through S1001 to S1003, the NRF can determine the subscription authority, thereby improving the security of subscription.
After S1003, the following steps may be further included.
S1004, the first NF sends a subscription request (subscribe request) to the third NF, and the third NF receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The subscription request includes the token, an instance identifier (instance ID) of the first NF, and/or a Uniform Resource Identifier (URI). The subscription request may also carry a network function service, a type of a service provider (service provider), and/or an identifier of the service provider (service provider), which is a third NF in this embodiment. For example, an instance identification (instance ID) and/or a Uniform Resource Identification (URI) carrying the third NF, and/or a type of the third NF (NF type). The Subscription request may further carry an Event Identifier (Event ID (s)), and/or an Event List (Event List), and/or a Subscription Change Notification Uniform Resource Identifier (Subscription Change Notification Uniform Resource Identifier), and/or a Subscription Change Notification related Uniform Resource Identifier (Subscription Change Notification association ID), and/or a Subscription Permanent Identifier (Subscription Permanent Identifier, SUPI), and/or a Group Identifier (Group ID), and/or a general Public Subscription Identifier (Generic Public Subscription Identifier, GPSI), and/or a Permanent device Identifier (PEI).
Specifically, the first NF determines, according to the token response sent by the NRF, that the first NF has the right to subscribe to the network function service from the third NF, and then sends a subscription request to the third NF.
S1005, the third NF checks the token contained in the subscription request, if the check is successful, S1006 is executed; otherwise, if the token check fails, the third NF ends the process, or replies a subscription response to the first NF, where the subscription response includes the information of the subscription failure, the token check failure, or other information indicating the process failure.
Specifically, if the token verification is successful, the third NF determines that the first NF has a right to subscribe to the network function service from the third NF.
Wherein the token check includes one or more of: and carrying out integrity check on the token, checking whether the token is used for indicating that the first NF has the authority of subscribing the network function service to the third NF and checking the validity of the token. The verification fails when any one verification is unsuccessful, and the verification succeeds when all verifications are successful. Specifically, it is required to check whether the subscription request includes the identifier of the third NF. It is also necessary to check whether the identity and/or type of the service provider (service provider) contained in audioclaim in the token is the same as the identity and/or type of the third NF. It may also be checked whether the third NF is capable of providing the network function service in the subscription request. For example, the network function services that the third NF can provide include service 1, service 2, and service 3, but the token indicates that the authorized service is service 4, the verification fails. The token has a validity period, and when the token is within the validity period, the token has validity, and when the token exceeds the validity period, the token is invalid. The check is successful only if the token is within the validity period. It may also be checked whether the information contained in the token is identical to the corresponding information in the subscription request.
Optionally, the third NF may verify the token through the NRF. Specifically, the third NF sends a check request to the NRF after receiving the subscription request. The NRF receives a check request from the third NF, and checks a token included in the check request. The NRF replies the verification result to the third NF. If the verification is successful, the third NF performs S1006. Otherwise, the third NF finishes the process, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token check failure information, or other information indicating a process failure. When the NRF checks the token, the NRF may check whether the token is consistent with the stored token or the token is consistent with the token included in the token response sent to the first NF, in addition to the above-described items of token checking. If the two are consistent, the verification is successful, otherwise, the verification fails. By consistent is meant that the information indicated by the token is the same.
The process of correcting the token by NRF may replace S1005.
S1006, the third NF sends a subscription response (subscribe response) to the first NF, and the first NF receives the subscription response from the third NF.
The subscription response may carry an authorization result, which is used to indicate that the first NF has a right to subscribe the network function service to the third NF by acting on the second NF; or, the third NF carries a token with a successful check in the subscription response. And the first NF determines that the authorization is successful according to the token or the authorization result carried in the subscription response.
S1007 and the third NF provide the network function service to the first NF according to the subscribed network function service.
Specifically, when the subscription condition is satisfied, the third NF sends a notification (notify) to the first NF, where the notification includes the network function service provided by the third NF.
Optionally, the third NF may further send a notification to the first NF, where the notification carries information such as modification or unsubscription of the service.
The seventh authorization method for subscription may also be applicable to roaming scenarios. In a roaming scenario, each NF is located in two different Public Land Mobile Networks (PLMNs). The interaction between NFs is forwarded through the SCP serving them. And the token request sent by the first NF is forwarded to the NRF in the PLMN where the first NF is located by the NRF in the PLMN where the third NF is located. And the response of the token sent by the NRF in the PLMN where the third NF is located is forwarded to the first NF by the NRF in the PLMN where the first NF is located. The generation and authorization of the token is done by the NRF within the PLMN where the third NF is located. And under the condition that the third NF can check the token through the NRF, the token check is also completed by the NRF in the PLMN where the third NF is located. The other processing procedures are the same as described in one of the authorization methods of the proxy subscription.
Based on the same inventive concept, the embodiment of the present application provides eight methods for authorizing subscriptions. Eight of the subscription authorization methods described below are based on interactions between four network functions. The four network functions include a first NF, a third NF, NRF, and SCP. The network function service provided by a service provider or service provider (service provider) in this application may also be referred to as simply a service.
The SCP is used for playing a role in forwarding service calls between the NFs, or the SCP can independently complete the authorization of requesting services, or the SCP can cooperate with the NRF to complete the authorization of requesting services.
As shown in fig. 11, a flow of an eighth method for authorizing a subscription provided in the embodiment of the present application is as follows. The method guarantees the safety of subscription through the token.
S1101, the first NF sends a token request to the NRF, which receives the token request from the first NF.
The step is the same as S1001, and the detailed description can refer to S1001, which is not repeated herein.
S1102, NRF generates a token based on the received token request.
The step is the same as S1002, and the detailed description may refer to S1002, which is not repeated herein.
S1103, the NRF sends a token response to the first NF, and the first NF receives the token response from the NRF.
This step is the same as S1003, and the details can refer to S1003, which is not described herein again.
The descriptions of S1101 to S1103 are the same as those of S1001 to S1003, and reference may be made to the description about the seventh authorization method for proxy subscription.
After S1103, the following steps may also be included.
S1104, the first NF sends a subscription request (subscribe request) to the SCP, and the SCP receives the subscription request from the first NF.
The subscription request is for the first NF to request the second NF to subscribe to a network function service from the third NF. The subscription request includes the token, and other information included in the subscription request refers to the relevant description in S1004.
S1105, SCP checks the token contained in the subscription request, if the check is successful, S1106 is executed; otherwise, if the verification fails, the SCP ends the process, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token verification failure information, or other information indicating a process failure.
If the verification is successful, the SCP determines that the first NF has the authority of subscribing the network function service to the third NF.
Wherein the verification comprises one or more of: and carrying out integrity check on the token, checking whether the token is used for indicating that the first NF has the authority of subscribing the network function service to the third NF and checking the validity of the token. The verification fails when any one verification fails, and the verification succeeds when all verifications succeed. Specifically, it is required to check whether the subscription request includes the identifier of the third NF. It is further required to check whether the identifier and/or type of the service provider (service provider) included in the audio container in the token is the same as the identifier and/or type of the third NF queried by the SCP, specifically, the SCP may query the identifier of the third NF according to locally configured information, or query the identifier of the third NF according to information obtained from the NRF. It may also be checked whether the third NF is capable of providing the subscribed network function service. For example, the network function services that the third NF can provide include service 1, service 2, and service 3, but the token indicates that the authorized service is service 4, the verification fails. The token has a validity period, and when the token is within the validity period, the token has validity, and when the token exceeds the validity period, the token is invalid. The check is successful only if the token is within the validity period. It may also be checked whether the information contained in the token is identical to the corresponding information in the subscription request.
Like the seventh subscription authorization method, the SCP can optionally also check the token through NRF. Specifically, after receiving the subscription request, the SCP sends a check request to the NRF, and the NRF receives the check request from the SCP and checks a token included in the check request. The NRF returns the check result to the SCP. If the verification is successful, the SCP executes S1106; otherwise, the SCP ends the procedure, or replies a subscription response to the first NF, where the subscription response includes a subscription failure, or token check failure message, or other information indicating that the procedure fails.
A process of correcting the token by NRF may replace S1105.
S1106, the SCP sends a subscription request to the third NF, and the third NF receives the subscription request from the SCP.
The subscription request carries information carried in the subscription request received from the first NF, and may also carry a verification result. The check result is used to indicate whether the token check was successful. Or for indicating the result of the authorization, i.e. indicating whether the first NF has the right to subscribe to network function services from the third NF.
S1107, the third NF returns a subscription response to the SCP, and the SCP receives the subscription response from the third NF.
S1108, the SCP sends a subscription response to the first NF, and the first NF receives the subscription response from the SCP.
The subscription response may carry an authorization result for indicating whether the first NF has a right to subscribe to the network function service to the third NF. When the SCP successfully checks the token, the authorization result is yes; and when the SCP fails to verify the token, the authorization result is negative. And if so, the first NF has the authority of subscribing the network function service to the third NF. And if the authorization result is negative, the first NF does not have the authority of subscribing the network function service to the third NF.
Alternatively, the subscription response may carry a token.
S1109-S1110, the third NF provides the network function service for the first NF according to the subscribed network function service.
Specifically, when the subscription condition is satisfied, the third NF sends a notification (notify) to the first NF through the SCP, where the notification includes a network function service provided by the third NF.
Optionally, since the first NF subscribes to the service from the third NF, the third NF may also send a notification to the first NF through the SCP, where the notification carries information such as modification or unsubscription of the service. Specifically, the third NF sends a notification to the SCP, which forwards the notification to the first NF.
Eight of the authorization methods for subscription may also be applicable to roaming scenarios. In a roaming scenario, each NF is located on two different PLMNs. The interaction between NFs is forwarded through the SCP serving them. The token request sent by the first NF is forwarded to the NRF in the PLMN where the third NF is located by the NRF in the PLMN where the first NF is located. And the token response sent by the NRF in the PLMN where the third NF is located is forwarded to the first NF by the NRF in the PLMN where the first NF is located. The generation and authorization of the token is done by the NRF within the PLMN where the third NF is located. The token check is also performed by the NRF in the PLMN where NF _ B is located in such a way that the third NF can check the token through the NRF. The verification of the token is done by the SCP serving the third NF. The other processing procedures are the same as those described in the eighth of the subscription authorization method.
Through the eighth subscription authorization method, the authority is judged through the NRF in the system architecture of the SCP, and the SCP checks the token, so that the safety of proxy subscription is improved.
Based on the same inventive concept of the foregoing method embodiment, as shown in fig. 8, the embodiment of the present application further provides an authorization apparatus 800 for proxy subscription. The apparatus 800 comprises a receiving unit 801 and a processing unit 802, and further comprises a transmitting unit 803.
The apparatus 800 may be applied to an NRF, and may also be an NRF, and the apparatus 800 may perform operations performed by the NRF in the authorization method for each proxy subscription. Taking as an example one of the authorization methods of performing a proxy subscription, the receiving unit 801 is configured to receive a token request from the first network function NF, and the processing unit 802 is configured to generate a token based on the token request. Optionally, the receiving unit 801 is further configured to receive a check request from a third NF. The processing unit 802 is further configured to check the second token. The sending unit 803 is used for the NRF to send messages to other functions.
The apparatus 800 may also be applied to the first NF, and the apparatus 800 may perform operations performed by the first NF in the authorization method for each proxy subscription. Taking one of the authorization methods of executing the proxy subscription as an example, the sending unit 803 is configured to send a token request to a network function storage function NRF, where the token request is used to request the NRF to generate a token. A receiving unit 801, configured to receive a token from the NRF.
The apparatus 800 may also be applied to a third NF, and the apparatus 800 may perform operations performed by the third NF in the authorization methods for the respective proxy subscriptions. Taking one of the authorization methods for executing the proxy subscription as an example, the receiving unit 801 is configured to receive a subscription request from the first NF, where the subscription request carries a token. The processing unit 802 is configured to check the token included in the subscription request, and obtain a check result. If the verification is passed, the first NF has the authority of acting the second NF to subscribe the network function service to the third NF, and the second NF has the authority of receiving the network function service provided by the third NF; if the verification fails, the first NF does not have the authority for acting the second NF to subscribe the network function service to the third NF, and the second NF does not have the authority for receiving the network function service provided by the third NF. The sending unit 803 is configured to send a subscription response to the first NF, where the subscription response carries the check result.
Based on the same inventive concept as that of the foregoing method embodiment, as shown in fig. 9, an authorization apparatus 900 for proxy subscription is further provided in this application embodiment, where the authorization apparatus 900 for proxy subscription is used to implement operations executed by an NRF, a first NF, a second NF, a third NF, or an SCP in the authorization method for proxy subscription provided in the foregoing embodiment, for brief description, a schematic diagram of the entity apparatus of each function described above is illustrated by referring to fig. 9, and it can be understood that fig. 9 is only a schematic diagram, and it may be applied to various functions described above. The proxy subscription authorization apparatus 900 includes: a transceiver 901, a processor 902, and may further include a memory 903. The processor 902 is configured to invoke a set of programs, and when the programs are executed, the processor 902 is enabled to execute the operations executed by the NRF, the first NF, the second NF, the third NF, or the SCP in the authorization method for each proxy subscription provided in the above embodiments. The memory 903 is used to store programs executed by the processor 902. The above-mentioned function modules in fig. 8, the transmitting unit and the receiving unit may be implemented by the transceiver 901, and the processing unit may be implemented by the processor 902.
The processor 902 may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP.
The processor 902 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof.
The memory 903 may include a volatile memory (volatile memory), such as a random-access memory (RAM); the memory 903 may also include a non-volatile memory (non-volatile memory), such as a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); the memory 903 may also comprise a combination of memories of the kind described above.
In the methods provided in the above embodiments of the present application, some or all of the operations and functions performed by the described functional entities (or functions) may be implemented by a chip or an integrated circuit.
In order to implement the functions of the apparatus described in fig. 8 or fig. 9, an embodiment of the present application further provides a chip, which includes a processor and is configured to support the apparatus to implement the functions related to the method provided in the foregoing embodiment. In one possible design, the chip is connected to or includes a memory for storing the necessary program instructions and data for the device.
The embodiment of the application provides a computer storage medium, which stores a computer program, wherein the computer program comprises instructions for executing the method provided by the embodiment.
The present application provides a computer program product containing instructions, which when run on a computer, causes the computer to execute the method provided by the above embodiments.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications can be made in the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. Thus, if such modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to encompass such modifications and variations.

Claims (15)

1. A method for authorizing a proxy subscription, comprising:
a network function storage function, NRF, receiving a token request from a first network function, NF, the token request comprising an identification of the first NF and an identification of the second NF;
the NRF generating a first token based on the token request;
the NRF sends the first token to the first NF.
2. The method of claim 1, wherein the token request includes first indication information for indicating to the first NF to proxy that the second NF subscribes to a network function service from the third NF.
3. The method of any one of claims 1 or 2, wherein the first token includes an identification of the second NF.
4. The method of any of claims 1 or 2, wherein the first token includes the second indication information to indicate to the first NF to proxy the second NF to subscribe to a network function service from the third NF.
5. A method for authorizing a proxy subscription, comprising:
a first network function, NF, sending a token request to a network function storage function, NRF, the token request comprising an identification of the first NF and an identification of the second NF;
the first NF receives a token from the NRF.
6. The method of claim 5, wherein the token request includes first indication information indicating that the first NF is proxying the second NF to subscribe to network function services from the third NF.
7. The method of claim 5 or 6, wherein the token comprises an identification of the second NF.
8. The method of any of claims 5-7, wherein the token comprises second indication information for indicating that the first NF proxies the second NF to subscribe to a network function service from the third NF.
9. The method of any one of claims 5 to 8, further comprising:
and the first NF sends a subscription request to the third NF, wherein the subscription request carries the token.
10. The method of claim 9, wherein the method further comprises:
the first NF receives a subscription response from the third NF, wherein the subscription response carries the token or the authorization result, and the authorization result comprises: the second NF has a right to receive the network function service provided by the third NF, and the first NF has a right to proxy the second NF to subscribe the network function service to the third NF.
11. The method of any one of claims 5 to 10, further comprising:
and the first NF receives a notice from the third NF, wherein the notice carries the token or the authorization result, and the authorization result comprises that the first NF has the authority of acting the second NF to subscribe the network function service to the third NF and that the second NF has the authority of receiving the network function service provided by the third NF.
12. A method for authorizing a proxy subscription, comprising:
a third network function NF receives a subscription request from the first NF, wherein the subscription request carries a token;
the third NF checks the token contained in the subscription request to obtain a check result;
and the third NF sends a subscription response to the first NF, wherein the subscription response carries the verification result.
13. A method for authorizing a proxy subscription, comprising:
the service communication proxy SCP checks the communication between the different network functions.
14. A proxy subscription system, comprising:
a network function storage function NRF for performing the method according to any of claims 1-4;
a first network function, NF, to send a token request to a network function storage function, NRF, the token request comprising an identification of the first NF and an identification of the second NF.
15. An apparatus for authorizing a proxy subscription, comprising:
a processor, coupled to the memory, for invoking a program in the memory and executing the program to implement the method of any of claims 1-13.
CN202210945552.4A 2019-04-29 2019-09-19 Proxy subscription authorization method and device Pending CN115361183A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201910356654 2019-04-29
CN2019103566540 2019-04-29
CN201910888767.5A CN111865888B (en) 2019-04-29 2019-09-19 Proxy subscription authorization method and device

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201910888767.5A Division CN111865888B (en) 2019-04-29 2019-09-19 Proxy subscription authorization method and device

Publications (1)

Publication Number Publication Date
CN115361183A true CN115361183A (en) 2022-11-18

Family

ID=72970606

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201910888767.5A Active CN111865888B (en) 2019-04-29 2019-09-19 Proxy subscription authorization method and device
CN202210945552.4A Pending CN115361183A (en) 2019-04-29 2019-09-19 Proxy subscription authorization method and device

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201910888767.5A Active CN111865888B (en) 2019-04-29 2019-09-19 Proxy subscription authorization method and device

Country Status (2)

Country Link
CN (2) CN111865888B (en)
WO (1) WO2020220783A1 (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4287557A4 (en) * 2021-02-21 2024-03-06 Huawei Tech Co Ltd Service authorization method, system, and communication device
CN113111339B (en) * 2021-05-13 2023-12-19 数字广东网络建设有限公司 Access control method, device, equipment and medium for application service
CN115623576A (en) * 2021-07-13 2023-01-17 华为技术有限公司 Data synchronization method, device and system
CN115915137A (en) * 2021-08-09 2023-04-04 华为技术有限公司 Network function service authorization method and device
WO2023092504A1 (en) * 2021-11-26 2023-06-01 Oppo广东移动通信有限公司 Subscription control method and apparatus, and computer device and storage medium
CN114867003A (en) * 2022-06-07 2022-08-05 中国电信股份有限公司 Cross-network request method, system, device, equipment and storage medium

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101867590B (en) * 2009-04-14 2013-04-24 华为技术有限公司 Subscription method based on session initiation protocol, and device thereof
CN103685139B (en) * 2012-08-30 2018-07-13 中兴通讯股份有限公司 Certificate Authority processing method and processing device
CN108206803B (en) * 2016-12-16 2021-02-05 腾讯科技(深圳)有限公司 Service agency processing method and device
CN108632216B (en) * 2017-03-20 2020-10-16 电信科学技术研究院 Network function authorization method, device, readable storage medium and entity equipment
CN108632312B (en) * 2017-03-20 2020-01-17 ***通信有限公司研究院 Network function information interaction method and device
US11039381B2 (en) * 2017-03-21 2021-06-15 Telefonaktiebolaget Lm Ericsson (Publ) SMF selection based on supported DNN
CN109274512B (en) * 2017-07-17 2021-12-07 中兴通讯股份有限公司 Management method and device for proxy call service control function
CN109587187A (en) * 2017-09-28 2019-04-05 华为技术有限公司 For calling the methods, devices and systems of network function service
CN109688586B (en) * 2017-10-19 2021-12-07 中兴通讯股份有限公司 Network function authentication method and device and computer readable storage medium
US10671462B2 (en) * 2018-07-24 2020-06-02 Cisco Technology, Inc. System and method for message management across a network

Also Published As

Publication number Publication date
WO2020220783A1 (en) 2020-11-05
CN111865888B (en) 2022-08-19
CN111865888A (en) 2020-10-30

Similar Documents

Publication Publication Date Title
CN111865888B (en) Proxy subscription authorization method and device
US11844014B2 (en) Service authorization for indirect communication in a communication system
CN111937421B (en) Method and device for subscribing service
CN111031571B (en) Network slice access control method and device
JP7027558B2 (en) Authorization revocation method and equipment
CN111565404B (en) Data distribution method and device
CN116601986A (en) Method, system and computer readable medium for message authentication in a fifth generation (5G) communication network
CN112073919B (en) Communication method and device for multicast broadcast service, electronic equipment and storage medium
EP3962136A1 (en) Management of access tokens in communication networks
CN117715238A (en) Session establishment method and device
FI129916B (en) Authorization of network request
WO2020220919A1 (en) Authorization method and device for proxy subscription
US20230049810A1 (en) Data information obtaining method and apparatus
CN113498060B (en) Method, device, equipment and storage medium for controlling network slice authentication
CN117121438A (en) Methods, systems, and computer readable media for delegated authorization at Secure Edge Protection Proxy (SEPP)
CN112492592A (en) Authorization method under multiple NRF scenes
WO2021176131A1 (en) Enhanced authorization in communication networks
WO2010121645A1 (en) Priority service invocation and revocation
CN112752352B (en) Method and equipment for determining I-SMF (intermediate session management function)
CN116097691A (en) Service request handling
US20230030315A1 (en) Network Security
CN115915137A (en) Network function service authorization method and device
EP3852339A1 (en) Enabling quality of service for trusted 3rd party network functions in core networks
US20230379677A1 (en) Handling events in a network
EP4092982A1 (en) Authentication of network request

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination