WO2022000155A1 - Access control of service based management framework - Google Patents

Access control of service based management framework Download PDF

Info

Publication number
WO2022000155A1
WO2022000155A1 PCT/CN2020/098706 CN2020098706W WO2022000155A1 WO 2022000155 A1 WO2022000155 A1 WO 2022000155A1 CN 2020098706 W CN2020098706 W CN 2020098706W WO 2022000155 A1 WO2022000155 A1 WO 2022000155A1
Authority
WO
WIPO (PCT)
Prior art keywords
access control
identity information
authentication
authorization
information
Prior art date
Application number
PCT/CN2020/098706
Other languages
English (en)
French (fr)
Inventor
Jing PING
Iris ADAM
Anatoly ANDRIANOV
Uwe Rauschenbach
Original Assignee
Nokia Shanghai Bell Co., Ltd.
Nokia Solutions And Networks Oy
Nokia Technologies Oy
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 Nokia Shanghai Bell Co., Ltd., Nokia Solutions And Networks Oy, Nokia Technologies Oy filed Critical Nokia Shanghai Bell Co., Ltd.
Priority to EP20942683.2A priority Critical patent/EP4173226A4/en
Priority to CN202080102534.9A priority patent/CN116134857A/zh
Priority to PCT/CN2020/098706 priority patent/WO2022000155A1/en
Publication of WO2022000155A1 publication Critical patent/WO2022000155A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent

Definitions

  • Embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to device, method, apparatus and computer readable storage medium of access control of service-based management framework.
  • SBMA Service-Based Management Architecture
  • IRP integration reference point
  • SBMA Zero touch network and Service Management
  • 3GPP related management system could be one or more management domain (s) of ZSM framework.
  • the different management domains may belong to different administrative domains.
  • Access control including identification, authentication, authorization, and audit
  • MnS management service
  • ZSM Third Generation Partnership Project
  • 3GPP Third Generation Partnership Project
  • ZSM requires that the ZSM framework reference architecture shall allow authorization of service access by authenticated service consumers and recommends robust mutual authentication between management service producer and consumer, and access control on management service.
  • 3GPP recommends the network slice management interface that is exposed to communication service providers to be securely protected to prevent unauthorized access.
  • example embodiments of the present disclosure provide a solution of access control of service-based management framework.
  • a first device comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the first device at least to, in accordance with a determination that a second device has been authenticated in a login process of the second device, transmit the identity information of the second device to a third device; receive, from the third device, an authorization grant of an access control for the second device to at least one fourth device, the authorization grant being generated at least based on access control polices for the second device, the access control polices being determined based on the identity information and a set of respective domains associated with the at least one fourth device; generate, based on the identity information and the authorization grant, an authorization verifying indication for the second device to access the at least one fourth device; and transmit the authorization verifying indication to the second device.
  • a third device comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the third device at least to, receive, from a first device, identity information of a second device; determine access control polices for the second device based on the identity information and a set of respective domains associated with the at least one fourth device; generate an authorization grant of an access control for the second device to the at least one fourth device at least based on the access control polices; and transmitting the authorization grant to the first device.
  • a method comprises in accordance with a determination that a second device has been authenticated in a login process of the second device, transmitting the identity information of the second device to a third device; receiving, from the third device, an authorization grant of an access control for the second device to at least one fourth device, the authorization grant being generated at least based on access control polices for the second device, the access control polices being determined based on the identity information and a set of respective domains associated with the at least one fourth device; ; generating, based on the identity information and the authorization grant, an authorization verifying indication for the second device to access the at least one fourth device; and transmitting the authorization verifying indication to the second device.
  • a method comprises receiving, from a first device, identity information of a second device; determining access control polices for the second device based on the identity information and a set of respective domains associated with the at least one fourth device; generating an authorization grant of an access control for the second device to the at least one fourth device at least based on the access control polices; and transmitting the authorization grant to the first device.
  • an apparatus comprises means for in accordance with a determination that a second device has been authenticated in a login process of the second device, transmitting the identity information of the second device to a third device; means for receiving, from the third device, an authorization grant of an access control for the second device to at least one fourth device, the authorization grant being generated at least based on access control polices for the second device, the access control polices being determined based on the identity information and a set of respective domains associated with the at least one fourth device; means for generating, based on the identity information and the authorization grant, an authorization verifying indication for the second device to access the at least one fourth device; and means for transmitting the authorization verifying indication to the second device.
  • an apparatus comprises means for receiving, from a first device, identity information of a second device; means for determining access control polices for the second device based on the identity information and a set of respective domains associated with the at least one fourth device; means for generating an authorization grant of an access control for the second device to the at least one fourth device at least based on the access control polices; and means for transmitting the authorization grant to the first device.
  • a computer readable medium having a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method according to the third aspect.
  • a computer readable medium having a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method according to the fourth aspect.
  • FIG. 1 illustrates an example environment in which example embodiments of the present disclosure can be implemented
  • FIG. 2 illustrates an example function blocks to support SBMA Access control according to some example embodiments of the present disclosure
  • FIG. 3 shows a signaling chart illustrating a process of access control of service based management framework according to some example embodiments of the present disclosure
  • FIG. 4 shows a signaling chart illustrating a process of access control of service-based management framework according to some example embodiments of the present disclosure
  • FIG. 5 shows a flowchart of an example method of access control of service-based management framework according to some example embodiments of the present disclosure
  • FIG. 6 shows a flowchart of an example method of access control of service-based management framework according to some example embodiments of the present disclosure
  • FIG. 7 shows a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure.
  • FIG. 8 shows a block diagram of an example computer readable medium in accordance with some embodiments of the present disclosure.
  • references in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an example embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • circuitry may refer to one or more or all of the following:
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • the term “communication network” refers to a network following any suitable communication standards, such as fifth generation (5G) systems, Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on.
  • 5G fifth generation
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • WCDMA Wideband Code Division Multiple Access
  • HSPA High-Speed Packet Access
  • NB-IoT Narrow Band Internet of Things
  • the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the future fifth generation (5G) new radio (NR) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • suitable generation communication protocols including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the future fifth generation (5G) new radio (NR) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the
  • the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom.
  • the network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR Next Generation NodeB (gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology.
  • BS base station
  • AP access point
  • NodeB or NB node B
  • eNodeB or eNB evolved NodeB
  • gNB Next Generation NodeB
  • RRU Remote Radio Unit
  • RH radio header
  • RRH remote radio head
  • relay a
  • a RAN split architecture comprises a gNB-CU (Centralized unit, hosting RRC, SDAP and PDCP) controlling a plurality of gNB-DUs (Distributed unit, hosting RLC, MAC and PHY) .
  • a relay node may correspond to DU part of the IAB node.
  • terminal device refers to any end device that may be capable of wireless communication.
  • a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) .
  • UE user equipment
  • SS Subscriber Station
  • MS Mobile Station
  • AT Access Terminal
  • the terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/
  • the terminal device may also correspond to Mobile Termination (MT) part of the integrated access and backhaul (IAB) node (a.k.a. a relay node) .
  • MT Mobile Termination
  • IAB integrated access and backhaul
  • the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
  • a user equipment apparatus such as a cell phone or tablet computer or laptop computer or desktop computer or mobile IoT device or fixed IoT device
  • This user equipment apparatus can, for example, be furnished with corresponding capabilities as described in connection with the fixed and/or the wireless network node (s) , as appropriate.
  • the user equipment apparatus may be the user equipment and/or or a control device, such as a chipset or processor, configured to control the user equipment when installed therein. Examples of such functionalities include the bootstrapping server function and/or the home subscriber server, which may be implemented in the user equipment apparatus by providing the user equipment apparatus with software configured to cause the user equipment apparatus to perform from the point of view of these functions/nodes.
  • SBMA service Based Management Architecture
  • IRP integration reference point
  • SBMA Zero touch network and Service Management
  • 3GPP related management system could be one or more management domain (s) of ZSM framework.
  • the different management domains may belong to different administrative domains.
  • Access control including identification, authentication, authorization, and audit
  • MnS management service
  • ZSM Third Generation Partnership Project
  • 3GPP Third Generation Partnership Project
  • ZSM requires that the ZSM framework reference architecture shall allow authorization of service access by authenticated service consumers and recommends robust mutual authentication between management service producer and consumer, and access control on management service.
  • 3GPP recommends the network slice management interface that is exposed to communication service providers to be securely protected to prevent unauthorized access.
  • AAA Authentication, Authorization and Auditing
  • ZSM framework is built on multiple administrative domains. There are different levels of trust between domains. Generally, it’s zero trust between domains at the beginning. Further the trust relationship could be dynamically changed along the change in each management domain. Access control solutions (including identification and authentication, authorization and auditing) should adapt the change of trust relationship between ZSM management domains, as well as between ZSM management domain (s) and external entities.
  • ZSM framework e.g. it integrates management domains based on different technologies, for different industries with various security requirements; it supports many types of interaction, e.g. Machine to machine, Human to Machine, Humane on behalf of Machine, etc.
  • ZSM services offer machine-consumable interfaces (to e.g. management function, network function, application, mobile device, etc. ) . They may also allow interfacing with human users (e.g. representing tenant, operator, 3rd party partner, vendor, end user, etc. ) using e.g. a GUI, web portal or application, etc.
  • ZSM framework enables resource sharing as well as dedicated (physical/logical) resource for specific tenant. Therefore, using ZSM (or alike) framework for E2E Service management and orchestration could be very complex and unpredictable, while authentication, authorization and audit are required to be flexible, dynamic and adaptive.
  • TLS Transport Layer Security
  • OAuth local policy based authorization without concrete solution.
  • TLS may be good solution to authenticate MnS producer (server) by the consumer (client) , but it is almost impossible to rely TLS to authenticate the MnS consumer (client) because the MnS consumer is always in different management and network domain than the producer.
  • management point view it is hard to pre-configure consumer’s root certificate on each producer as the MnS consumer can be dynamically changed.
  • IP address or FQDN of the client in the client request is same to subject or subject Alternative of the client certificate especially if they’re in different network domains.
  • MnS consumer is always in the different domain than the producer, this is block issue to rely on TLS for MnS consumer authentication.
  • AAF Application Auth Framework
  • ONAP Open Network Automation Platform
  • OAuth based authorization solution to protect Application Programming Interface (API)
  • ZSM ZSM or alike framework
  • the embodiments of the present invention propose a novel framework for SBMA access control across multiple management domains including cross-domain authentication, authorization and audit functions, as well as domain specific authentication and authorization functions.
  • the framework enables mutual and adaptive authentication between any type of MnS consumer and producer in different scenarios, granular and adaptive authorization based on business logic and specific context, audit based on data collected from multiple domains, and also allow to integrate with existing domain or central AAA framework.
  • FIG. 1 shows an example environment 100 in which embodiments of the present disclosure can be implemented.
  • ACF access control function
  • the ACF 130 may comprise an Authentication Administrative Function (ANAF) 131 (hereafter may also be referred to as a first device 131) and an Authorization Administrative Function (ARAF) 132 (hereafter may also be referred to as a third device 132) .
  • ANAF Authentication Administrative Function
  • ARAF Authorization Administrative Function
  • FIG. 1 The environment 100 may include any suitable number of ANAF 131 and ARAF 132.
  • the environment 100 may also comprise a Management Service Consumer (MnSC) 110 (hereafter may also be referred to as a second device 110) and a Management Service Provider (MnSP) 120 (hereafter may also be referred to as a fourth device 120) .
  • MnSC Management Service Consumer
  • MnSP Management Service Provider
  • FIG. 1 the number of MnSC and MnSP shown in FIG. 1 is given for the purpose of illustration without suggesting any limitations.
  • the environment 100 may include any suitable number of MnSC and MnSP in one or multiple management domains or from external entity.
  • the environment 100 may also comprise an access control enforcement point 140.
  • the MnSC 110 and the MnSP 120 may interact with the access control enforcement point 140 and may interact with the ACF 130 via the access control enforcement point 140, respectively.
  • the access control enforcement point 140 can be implemented as an Integration Fabric (IF) or an Exposure Governance Management Function (EGMF) .
  • IF Integration Fabric
  • EGMF Exposure Governance Management Function
  • the ANAF 131 may support authentication functions associated with the MnSC 110 and one or more MnSP 120 in one or multiple management domains, such as identity management, credential management, and authentication policy management, etc., while the ARAF 132 may support authorization functions associated with the MnSC 110 and one or more MnSP 120 in one or multiple management domains, such as access control policy management. In this way, an access control between the MnSC 110 and the MnSP 120 can be achieved.
  • the ANAF 131 and ARAF 132 may also be considered as an integrated function, i.e. the ACF 130.
  • the ACF 130 may support all functions of the ANAF 131 and ARAF 132.
  • the ACF 130 may also be considered to integrated to the access control enforcement point 140.
  • FIG. 2 illustrates an example function blocks to support SBMA Access control in a ZSM architecture according to some example embodiments of the present disclosure.
  • the architecture 200 may comprise End-To End (E2E) Management Domain (MnD) 210 and a Management Domain (MnD) 230.
  • the Management Function (MnF) of E2E MnD 210 and the MnF of MnD 230 may interact with the Cross-Domain Integration Fabric (CDIF) 220 with their Domain Integration Fabric (DIF) 211 and 231, respectively.
  • CDIF Cross-Domain Integration Fabric
  • DIF Domain Integration Fabric
  • the Domain Authentication Administrative Function (DANAF) 212 and the Domain Authorization Administrative Function (DARAF) 213 in the E2E MnD 210 may interact with the DIF 211, while the DANAF 232 and the DARAF 233 in the MnD 230 may interact with the DIF 231.
  • the DANAF 212 and 232 may considered as an embodiment of ANAF 131 shown in FIG. 1 and the DARAF 213 and 233 may considered as an embodiment of ARAF 132 shown in FIG. 1.
  • the Cross-Domain Authentication Administrative Function (CDANAF) 241 and the Cross-Domain Authorization Administrative Function (CDARAF) 242 may interact with the CDIF 220.
  • the Cross-Domain Authentication Administrative Function (CDANAF) 241 may interact with DANAF via CDIF and DIF
  • the Cross-Domain Authorization Administrative Function (CDARAF) 242 may interact with DARAF via CDIF and DIF.
  • the CDANAF 241 may considered as an embodiment of ANAF 131 shown in FIG. 1 and the CDARAF 242 may considered as an embodiment of ARAF 132 shown in FIG. 1.
  • the CDANAF 241 and DANAF 212 and 232 may support the following functions: identity management, including identity lifecycle management of various type of MnSC and MnSP; credential management, including credential lifecycle management of various type of credentials; authentication policy management (e.g. create, delete, update, etc. ) for MnSC and MnSP; generating and issue authentication assertion/token to MnSC after validated the MnSC’s identity and credential; integrate into existing AAA or Single Sign On (SSO) solution; interacting with Integration Fabric (IF) , analytics and intelligence function for dynamic identity and authentication policy management, therefore support context based and adaptive authentication; and synchronizing and mapping identity between CDANAF 241 and DANAF 212 and 232. Furthermore, the CDANAF 241 may generate consolidated authentication policies across multiple domains.
  • identity management including identity lifecycle management of various type of MnSC and MnSP
  • credential management including credential lifecycle management of various type of credentials
  • authentication policy management e.g. create, delete, update, etc.
  • the authentication policies may include following information elements as examples: Authentication factor: knowledge (what do I know) , ownership (what do I have) , personal attributes (who am I) , single factor, multi-factors; Authentication mode: local authentication (on MnF provided MnS) , domain authentication, common authentication, SSO, etc.; authentication protocol: TLS, SAML2.0, OpenID, basic user/password, Kerberos and Context adaptive information: e.g. in which context what anthemion factor need to be applied, etc.
  • CDARAF 242 and DARAF 213 and 233 may support the following functions: access control policy management (create, delete, update) for MnSC and MnSP; interacting with policy management service for consistency of access policies, especially for conflict detection and resolving; interacting with SLA management to adjust access control policy based on SLA; interacting with integration fabric, analytics and intelligence function for dynamic policy adaption; either Discretionary Access Control (DAC) or Mandatory Access Control (MAC) according to best practice or policy. For example, apply DAC for dedicated resources, and MAC for shared resources; and synchronizing and mapping access control policies between CDARAF 242 and DARAF 213 and 233. Furthermore, the CDANAF 242 may generate consolidated authentication policies across multiple domains.
  • the CDIF 220 and DIF 211 and 231 in the architecture 200 may interact with CDANAF 241/DANAF 212 and 232/CDARAF 242/DARAF 213 and 233 to register new MnSC 110 (e.g. ZSM framework consumer, MnF inside ZSM framework, etc. ) in ZSM access control system and interact with CDANAF 241/DANAF 212 and 232/CDARAF 242/DARAF 213 and 233 to register new MnS in ZSM access control system.
  • the CDIF 220 and DIF 211 and 231 may also synchronize the change of MnS (e.g. add/delete/update) with CDANAF 241/DANAF 212 and 232/CDARAF 242/DARAF 213 and 233.
  • the CDIF 220 and DIF 211 and 231 may be access control (authentication and authorization) enforcement point and may record security log in data service for records every registration, login and access request and result.
  • the architecture 200 may also comprise a common audit function 243, which may interact with the CDIF 220 and generate security report for specific domain, specific service, specific tenant, etc., based on security logs collected from domain/cross domain data service.
  • a common audit function 243 may interact with the CDIF 220 and generate security report for specific domain, specific service, specific tenant, etc., based on security logs collected from domain/cross domain data service.
  • FIGs. 3-4 show schematic processes for the access control of service-based management framework.
  • the process 300 will be described with reference to FIG. 3.
  • the process 300 may involve the MnSP 120, ARAF 131 and ANAF 132 as illustrated in FIG. 1.
  • the process 300 may also involve Integration Fabric (IF) 301, which may be considered as the access control enforcement point 140 shown in FIG. 1, or CDIF 220 or DIF 211 and 231 shown in FIG. 2. It is to be understood that the IF 301 can be replaced by other interacting functions, entities or modules in other framework or system.
  • IF Integration Fabric
  • the MnSP 120 may send 305 a registration request to the IF 301 to register MnS to IF 301.
  • the request may include service type, security level of the service, domain of the service, authentication mechanism supported by the MnS producer, etc.
  • the IF 301 may send 310 the registration information of the MnSP 120 to ANAF 131, to register the MnS in authentication system.
  • the ANAF 131 may create 315 a new record for the MnS.
  • the ANAF 131 may also assign an authentication group for the MnSP 120.
  • the ANAF 131 may determine service type, security level of the service, domain of the service, authentication mechanism supported by the MnS producer from the registration information of the MnSP 120.
  • the ANAF 131 determine authentication policies for the MnSP 120 based on the service type, security level of the service, domain of the service, authentication mechanism supported by the MnS producer from the registration information of the MnSP 120.
  • the ANAF 131 may assign the MnSP 120 to an authentication group. For example, if the ANAF 131 determines there is an existing authentication group configured with a set of authentication policies matching the requirements related to the registration information of the MnSP 120, the ANAF 131 may assign the existing authentication group to the MnSP 120, and apply the configured set of authentication policies to the MnSP 120.
  • the ANAF 131 may create a new authentication group for the MnSP 120 and configure the corresponding authentication policies based on the requirements related to the registration information of the MnSP 120.
  • the ANAF 131 may further send 320 the information related to the MnSP 120 to the ARAF 132.
  • the ARAF 132 may determine the classification of the MnS based on the information related to the MnSP 120.
  • the ARAF 132 may update 325 access control polices based on the classification of the MnS and classification/clearance of a subject of the access control policy. For example, the ARAF 132 may add the MnS into an existing access control policy.
  • the IF 301 may record the registration procedures of the MnSP 120 in database.
  • the process 400 may involve the MnSP 120, IF 301, ARAF 131, ANAF 132, and MnSC 110 as illustrated in FIG. 1.
  • the MnSC 110 may send 402 a registration request to the IF 301 of the MnSP 120.
  • the registration request may include consumer type, consumer domain, security level of consumer, authentication mechanism supported by the consumer, etc.
  • the IF 301 may send 404 the registration information of the MnSC 110 to ANAF 131, to register the MnSC 110 in authentication system.
  • the ANAF 131 may create 406 an identity for the MnSC 110.
  • the ANAF 131 may also records the identity information of the MnSC 110, as well as preferred authentication mechanism of the MnSC 110 in identity repository.
  • the identity information may comprise the domain of MnSC 110, the security level of MnSC 110 and the type of the MnSC 110, etc.
  • the ANAF 131 may determine authentication policies according its own capability and security context of the MnSC 110 and supported technology by the MnSC 110 and one or more MnSPs of one or more management domains, if there are more than one MnSPs have been registered. Furthermore, the ANAF 131 may also obtain some preliminary information for the MnSC 110 from ARAF 132. The ARAF 132 may assign related access control policies to the MnSC 110 based on the classification (e.g. security level, applied industry, region, security status, etc. ) of MnSs from one or more management domains registered on the IF 301 and classification/clearance of the MnSC 110 (e.g. SLA, industry, region. etc. ) , which may be obtained from the identity information of the MnSC 110
  • the ANAF 131 may send 408 the created identity, agreed authentication mechanism and the preliminary information to the IF 301.
  • the IF 301 may further send 410 the created identity, as well as agreed authentication mechanism to the MnSC 110.
  • the MnSC 110 may login on IF 301 of the MnSP to create new account in authentication system of the MnSP and manage access policies for the account.
  • the IF 301 may record the registration, login and access procedures of the MnSC in database.
  • the MnSC 110 may log in 412 IF 301 with identity and credential in agreed authentication mechanism (s) , which are obtained in the registration process.
  • the IF 301 as authentication enforcement point, may interact with ANAF 131, to authenticate 416 the MnSC 110 based on agreed authentication policy, as well as the security context of the identity of the MnSC 110 (e.g. time, place, security status of the identity, etc. ) .
  • the “security context” herein in the login process may be associated with a current status of the MnSC 110, which may be different from the status when the MnSC 110 is registered at the ANAF 131.
  • the ANAF 131 may send 418 an indication of the authentication status of the MnSC 110 to the ARAF 132 and synchronize the identity information of the MnSC 110 with authorization system.
  • the ARAF 132 may assign related access control policies to the MnSC 110 based on the classification (e.g. security level, applied industry, region, security status, etc. ) of MnSs from one or more management domains registered on the IF 301 and classification/clearance of the MnSC 110 (e.g. SLA, industry, region. etc. ) , as well as security context of the consumer (e.g. time, location, security status, mission/reason, etc. ) , which may be obtained from the identity information of the MnSC 110.
  • classification e.g. security level, applied industry, region, security status, etc.
  • security context of the consumer e.g. time, location, security status, mission/reason, etc.
  • the ARAF 132 may generate 420 an authorization grant of the access control for the MnSC 110 and/or access point of MnS list exposed to the MnSC 110.
  • the ARAF 132 may send 422 the authorization grant to the ANAF 131 and the ANAF 131 may generate 424 an authorization verifying indication comprise at least one of token and assertion based on authentication and authorization result.
  • the ANAF 131 may send 426 the generated token /assertion to the IF 301 and the IF 301 may send the token/assertion generated by ANAF 131 and/or access point of MnS list exposed to the MnSC 110 to the MnSC 110 and probably exposes allowed MnSs (may include SAP, operation, resource, etc. ) to the MnSC 110.
  • the MnSC 110 may access 430 the MnS of the MnSP 120 with access request including token/assertion.
  • the token/assertion may be comprised in an access request to the MnS.
  • the MnSP 120 may validate 432 the token/assertion and proceed the request. Then the MnSP 120 may send 434 the access result to the MnSC 110.
  • the IF 301 or MnSP 120 may record login and access procedures of the MnSC 110 in database.
  • security audit may be performed periodically or on demand.
  • an authorized auditing service consumer may send request to a MnSP to audit a MnSC.
  • the audit function of the MnSP may retrieve data related to the MnSC from data base, analyzes the data, generates a report and returns the report to the auditing service consumer.
  • the security policy may be updated dynamically.
  • the IF may discover changes of MnSP or MnSC, and syncs the changes with ANAF 131 or ARAF 132.
  • the ANAF 131 and ARAF 132 may update identity repository, authentication policy and access control policies accordingly, and may terminate the ongoing access sessions of the MnSC or MnSP.
  • the ANAF 131 and ARAF 132 may update identity status, authentication policies and access control policies according to security status change of the MnSC and MnSP received from Analytics or intelligence function, or access control policy change from ARAF of other domain, security policy change from MnSC or MnSP, etc., and may terminate the ongoing access sessions of the MnSC or MnSP.
  • the MnSC can be human consumer, digital portal, management function, network function, application, etc.
  • the IF can be cross-domain integration fabric or domain integration fabric, or exposure governance management function, management service registration function, etc.
  • the ANAF and the ANRF can be independent function blocks or combined with each other, or combined with other function block, such as IF.
  • MnD 230 In a case where a MnD 230 is registered to ZSM framework as MnSC, mutual trust has been established between DIF 231, DANAF 232 and DARAF 233, as well as between CDIF 220, CDANAF 241 and CDARAF 242, and MnF trusts DIF 231, DIF 231, DANAF 232 and DARAF 233 trust CDIF 220, CDANAF 241 and CDARAF 242, DIF 231 of a MnD 230 registers the MnD 230 to CDIF 220 after the MnD 230 being deployed, the request may include MnD type, MnD authentication mechanism, MnD security level, etc.
  • the CDIF 220 calls CDANAF 241 (including identity management) to register the MnD 230 in the access control system of ZSM framework.
  • the CDANAF 241 creates primary identity for the MnD 230, and records the identity information, as well as preferred authentication mechanism of the MnD 230 in common identity repository. In some example embodiments, the CDANAF 241 may determine authentication policies according its own capability and security context of the MnD 230 and supported technology by the MnD 230.
  • the CDIF 220 returns primary identity, as well as agreed authentication mechanism to DIF 231 of the MnD 230.
  • the DIF 231 of the MnD 230 records the primary identity and authentication mechanism, and optional address of CDANAF 241, in domain identity repository or other domain data service
  • the DIF 231of the MnD 230 logs in the CDIF 220 with the primary identity, agreed authentication mechanism and credential, the CDIF 220 redirects the request or calls CDANAF 241 to validate the DIF 231.
  • the mechanism to manage and exchange the credential of each identity is dependent on authentication mechanism and credential storage and access technology.
  • the CDANAF 241 validates the identity and credential of the DIF 231 based on current security context of the DIF 231 /MnD 230, and issues authentication assertion/token for the DIF 231 after successfully validate the DIF 231.
  • CDANAF 241 /CDIF 220 syncs the identity information with CDARAF 242.
  • the CDARAF 242 assigns related access control policies to the new MnD 230 based on the classification (e.g. security level, applied industry, region, security status, etc. ) of MnSs registered on the CDIF 220 and classification/clearance of the MnD 220 (e.g security level, security status, SLA, etc. ) . It is to be understood that Mandatory Access Control (MAC) is applied in this scenario.
  • the CDARAF 242 may interact with DARAF 232 to get granular access control policies, then generate permission based on the access control policies, and return to CDANAF/CDIF
  • the CDANAF/CDIF 220 generate assertion/token based on permission, and returns authentication assertion/token and/or allowed MnS list to the DIF 231.
  • the DIF 231 of the MnD 230 may create account for existing MnF of the MnD 230 in case the MnF needs to access MnS exposed on CDIF 22 or expose its MnS on CDIF 220.
  • the DIF 231 calls CDANAF 241 and CDARAF 242 services directly (or proxy through CDIF 220) to create new account and manage the access policies for the MnF together with DARAF 233.
  • DAC Discretionary Access Control
  • DIF 231 After a new MnF deployed in the MnD 230, it registers to DIF 231.
  • the DIF 231 interacts with DANAF 232 to create an identity for the MnF, together with DARAF 233, assign access control policies to the MnF for accessing domain MnSs (including DIF services) according to clearance/classification of the MnF.
  • the DIF 231/DANAF 232 can call CDANAF 241 and CDARAF 242 services to create account and assign access policies for the MnF together with DARAF 233, after that the MnF can register itself to CDIF 220, and can also access MnSs registered on CDIF 220 and exposed to the MnF after authentication and authorization.
  • the DIF 231 could register the MnF to CDIF 220 on behalf of the MnF. It is to be understood that registering to domain fabric is allowed to any MnF in the MnD by default. Then CDIF 220/DIF 231 records every registration, login and access request and result for MnFs of the MnD 230 in common/domain data service.
  • DANAF/CDANAF/DARAF/CDARAF which may be part of IF, or independent MnFs.
  • Part of DANAF/CDANAF/DARAF/CDARAF may be deployed with data service producer (e.g. identity repository) , part of them may be deployed with policy service producer, part of them can be deployed with DIF/CDIF, etc.
  • the MnFs of the MnD could be hidden behind the DIF of the MnD. All access from/to CDIF or other domain MnFs will be proxy by DIF of the MnD. In this case, no need to create sperate account for the MnFs in CDANAF.
  • a MnD 230 is registered to ZSM framework as producer.
  • the precondition of this scenario may comprise the MnD 230 has been registered to ZSM framework as consumer, and created account for each MnF needs to expose MnS on CDIF 220, and assigned basic permissions to MnF, e.g. register MnS, etc.; MnF has been logged in DIF 231 and DIF 231 or MnF has been logged in CDIF 220.
  • the MnSP registers MnS to DIF 231, at least service access point (SAP) of the MnS need to be provided.
  • SAP service access point
  • the DIF 231 calls DANAF 232 to register the MnS in authentication system.
  • the DANAF 232 could create a new record for the MnS, the SAP of the MnS should be recorded.
  • the DANAF 232 may put the MnS into an existing group (e.g. based on service type, security level of the service, producer of the service, authentication mechanism supported by the MnS producer, etc. ) , and apply the group policy on the MnS or create a new group for the MnS, and assign authentication policies to the group according to e.g. security level of the service (may impact authentication factor) , technology supported by the MnSP (may impact authentication protocol and factor) and authentication preference.
  • security level of the service may impact authentication factor
  • technology supported by the MnSP may impact authentication protocol and factor
  • the DANAF 232 syncs the new MnS information with DARAF 233.
  • the DARAF 233 may add the MnS into existing access control policies according to the classification of the MnS and classification/clearance of the subject of an access control policy. If the MnS need to be exposed to CDIF 220, the MnSP registers the MnS to CDIF 220, at least SAP of the MnS need to be provided.
  • the CDIF 220 may call common CDANAF 241 to register the MnS in common authentication system.
  • the CDANAF 241 could create a new record for the MnS, the SAP of the MnS should be recorded. Then the CDANAF 241 may put the MnS into an existing group (e.g. based on service type, security level of the service, domain of the service, producer of the service, authentication mechanism supported by the MnS producer, etc. ) , and apply the group policy on the MnS or create a new group for the MnS, and assign authentication policies to the group according to e.g. security level of the service (may impact authentication factor) , technology supported by the CDANAF 241 (may impact authentication protocol and factor) and authentication preference.
  • security level of the service may impact authentication factor
  • technology supported by the CDANAF 241 may impact authentication protocol and factor
  • the CDANAF 241 syncs the new MnS information with CDARAF 242.
  • the CDARAF 242 may add the MnS into existing access control policies according to the classification of the MnS and classification/clearance of the subject of an access control policy.
  • the CDIF 220/DIF 231 records every registration, login and access request and result for MnFs of the MnD 230 in common/domain data service.
  • MnSP may be used to represent MnD or MnF or service producer regardless which concrete component initialized the MnS registration to integration fabric.
  • access control for a ZSM framework consumer who consumes MnSs across multiple management domains may comprise the trust relationship between MnDs of ZSM framework and CDIF 220 has been established and the MnSs will be accessed by the ZSM framework consumer which is registered to CDIF 220.
  • ZSM framework consumer registers to ZSM framework, CDIF 220 (interact with BSS or Customer care system) signs online contract with the consumer and creates record for the consumer (formal or trial tenant/customer) .
  • the negotiated SLA which may include authentication mechanism, is included in the record.
  • a tenant/customer might sign contract with ZSM framework owner (Operator) in advance and the tenant/customer has been created in BSS system already, and ZSM framework administrator may register the tenant/customer to CDIF 220 of ZSM framework on behalf of the consumer.
  • ZSM framework owner OEM
  • ZSM framework administrator may register the tenant/customer to CDIF 220 of ZSM framework on behalf of the consumer.
  • the CDIF 220 calls CDANAF 241 to register the consumer in the access control system of ZSM framework.
  • the CDANAF 241 creates primary identity for the ZSM consumer, and records the identity information, as well as preferred authentication mechanism of the consumer in common identity repository.
  • the CDIF 220 returns primary identity, as well as agreed authentication mechanism to the consumer.
  • the authentication mechanism is decided by CDANAF 241 according to its own capability, security context of the consumer and supported technology by the consumer, as well as security context of MnSP (s) and supported technology (e.g. type of token, assertion, etc. ) by the producers which would provide services to satisfy SLA of the consumer.
  • the CDIF 220 (together with CDANAF 241 and CDARAF 242) needs to go through all MnSP (s) in one or more MnDs and finally figure out common authentication technologies fit to all MnSPs and also supported by the consumer.
  • the ZSM framework consumer logs in ZSM framework with identity and credential in agreed authentication mechanism.
  • the CDIF 220 as authentication enforcement point, interacts with CDANAF 241, to authenticate the consumer based on agreed authentication policy, as well as other security context of the identity (e.g. time, place, security status of the identity, etc. ) .
  • the mechanism to manage and exchange the credential of the consumer is dependent on authentication mechanism.
  • the CDIF 220/CDANAF 241 syncs the identity information with CDARAF 242.
  • the CDARAF 242 assigns related access control policies to the consumer based on the classification (e.g. security level, applied industry, region, security status, etc. ) of MnSs registered on the CDIF 220 and classification/clearance of the consumer (e.g. SLA, industry, region. etc. ) , as well as security context of the consumer (e.g. time, location, security status, mission/reason, etc. ) , and generate permission based on the access control policies, and return to CDIF 220/CDANAF 241.
  • classification e.g. security level, applied industry, region, security status, etc.
  • classification/clearance of the consumer e.g. SLA, industry, region. etc.
  • security context of the consumer e.g. time, location, security status, mission/reason, etc.
  • the CDARAF 242 may interact with DARAF 233 for get granular access control policies.
  • the CDIF 220 returns token/assertion generated by CDANAF 241 based on permission to the ZSM framework consumer.
  • the CDIF 220 exposes allowed MnSs (may include SAP, operation, resource, etc. ) to the consumer according to permisson.
  • the CDIF 220 (together with CDANAF 241 and CDARAF 242) may return a single assertion/token to the consumer after successfully authentication or return different assertion/token for different MnS producers if the consumer has capability to support that.
  • the ZSM framework consumer accesses MnS exposed to them, the token/assertion shall be included in the access request. If CDIF is exposed to the consumer, the CDIF validates the token/assertion and invokes the MnSs and forwards the result to the consumer. Alternatively, if endpoint of MnS is exposed, the MnF of the MnS shall have capability to validate the token/assertion either based on pre-configured information, or by checking with CDANAF.
  • the CDIF/MnF may double check access control policies assigned to the consumer and context of the consumer with CDARAF before process the request.
  • a ZSM consumer could create new account and manage the access policies for the account after authentication.
  • Discretionary Access Control (DAC) is applied in this scenario which allows ZSM framework customer to manage access policies for its own accounts in the scope of the MnSs could be accessed by the customer.
  • the CDIF records every registration, login and access request and result for the ZSM framework consumer in common data service.
  • the precondition of this scenario may comprise an E2E service MnD 210 and other MnDs 230 supporting E2E service deployment registered to CDIF 220.
  • the ZSM framework consumer logs in ZSM framework with identity and credential.
  • the CDIF 220 interacts with CDANAF 241 to authenticate the consumer based on agreed authentication policy, as well as other security context of the consumer. After authentication, the CDIF 220/CDANAF 241 gets related permission based on access control policies of the consumer from CDARAF 242.
  • the CDIF 220 returns token/assertion generated by CDANAF 241 based on permssion to the ZSM framework consumer.
  • the CDIF 220 exposes allowed MnSs (may include SAP, operation, resource, etc. ) based on permission to the consumer.
  • the ZSM framework consumer accesses an E2E service MnS (assume directly with address of the E2E MnS) exposed to them, the token/assertion shall be included in the access request.
  • the E2E service MnF maps the E2E service request to one or several other requests on MnSs exposed on CDIF 220.
  • the E2E service MnF logs in CDIF 220 with its identity and credential if no authenticated session exists.
  • the CDIF 220 interacts with CDANAF 241 to authenticate the MnF based on agreed authentication policy, as well as other security context of the MnF.
  • the CDIF 220 After authentication, the CDIF 220 checks access control policies of the MnF and returns token/assertion to the E2E service MnF. In addition, the CDIF 220 exposes allowed MnSs (may include SAP, operation, resource, etc. ) to the MnF.
  • the E2E service MnF accesses MnSs required to support the service requirement of the E2E service, the token/assertion returned to the E2E service MnF should be included in the access request.
  • the domain MnF producing MnS in the target MnD validates the token/assertion of the E2E service MnF and processes the request.
  • the domain MnF breakdowns the request to one or more domain MnS requests.
  • the domain MnF logs in DIF if there’s no authentication session existed.
  • the DIF interact with DANAF to authenticate the domain MnF based on domain specific authentication policy, as well as other security context of the MnF.
  • the DIF checks access control policies assigned to the MnF with DARAF and returns token/assertion to the MnF.
  • the DIF exposes allowed MnSs (may include SAP, operation, resource, etc. ) to the MnF.
  • the DARAF may authenticate the MnF by itself or forward the request to CDIF for federation authentication. In the latter case, the DARAF needs to map federation id to local id of the MnF.
  • the domain MnF (MnF-1) accesses another domain MnF (MnF-2) for the required MnSs with token/assertion got from the DIF.
  • the called MnF (MnF-2) validates the token/assertion, proceeds the request and return result to the calling MnF (MnF-1) .
  • the domain MnF (MnF-1) handling request from E2E service MnD returns result to the E2E service MnF.
  • the E2E service MnF returns result to the E2E service MnS consumer.
  • the CDIF records every registration, login and access request and result for the E2E service consumer, and all interactions between E2E service MnD and other MnDs in common data service.
  • the DIF records every registration, login and access request and result for the MnFs of the MnD in domain data service.
  • FIG. 5 shows a flowchart of an example method 500 of access control of service-based management framework according to some example embodiments of the present disclosure.
  • the method 500 can be implemented at the ANAF 110 as shown in FIG. 1.
  • the method 500 will be described with reference to FIG. 1.
  • the ANAF transmits the identity information of the management service consumer to an ARAF, if the ANAF determines the management service consumer has been authenticated in a login process of the management service consumer.
  • the ANAF receives, from the ARAF, an authorization grant of an access control for the management service consumer to at least one management service producer.
  • the authorization grant may be generated at least based on the identity information and access control polices for the management service consumer, the access control polices being determined based on the identity information and a set of respective domains associated with the at least one management service producer.
  • the ANAF generate, based on the identity information and the authorization grant, an authorization verifying indication for the management service consumer to access the at least one management service producer.
  • the ANAF transmits the authorization verifying indication to the management service consumer.
  • FIG. 6 shows a flowchart of an example method 600 of access control of service-based management framework according to some example embodiments of the present disclosure.
  • the method 600 can be implemented at the ARAF 120 as shown in FIG. 1.
  • the method 600 will be described with reference to FIG. 1.
  • the ARAF receives, from a ANAF, identity information of a management service consumer
  • the ARAF determines access control polices for the management service consumer based on identity information and a set of respective domains of at least one management service producer.
  • the ARAF generates an authorization grant of an access control for the management service consumer to the at least one management service producer at least based on the access control polices.
  • the ARAF transmits the authorization grant to the ANAF.
  • an apparatus capable of performing the method 500 may comprise means for performing the respective steps of the method 500.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus comprises means for in accordance with a determination that a second device has been authenticated in a login process of the second device, transmitting the identity information of the second device to a third device; means for receiving, from the third device, an authorization grant of an access control for the second device to at least one fourth device, the authorization grant being generated at least based on access control polices for the second device, the access control polices being determined based on the identity information and a set of respective domains associated with the at least one fourth device; ; means for generating, based on the identity information and the authorization grant, an authorization verifying indication for the second device to access the at least one fourth device; and means for transmitting the authorization verifying indication to the second device.
  • an apparatus capable of performing the method 600 may comprise means for performing the respective steps of the method 600.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus comprises means for receiving, from a first device, identity information of a second device; means for determining access control polices for the second device based on the identity information and a set of respective domains associated with the at least one fourth device; means for generating an authorization grant of an access control for the second device to the at least one fourth device at least based on the access control polices; and means for transmitting the authorization grant to the first device.
  • FIG. 7 is a simplified block diagram of a device 700 that is suitable for implementing embodiments of the present disclosure.
  • the device 700 may be provided to implement the communication device, for example the ANAF 110 and the ARAF 120 as shown in FIG. 1.
  • the device 700 includes one or more processors 710, one or more memories 740 coupled to the processor 710, and one or more transmitters and/or receivers (TX/RX) 740 coupled to the processor 710.
  • TX/RX transmitters and/or receivers
  • the TX/RX 740 is for bidirectional communications.
  • the TX/RX 740 has at least one antenna to facilitate communication.
  • the communication interface may represent any interface that is necessary for communication with other network elements.
  • the processor 710 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.
  • the device 700 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.
  • the memory 720 may include one or more non-volatile memories and one or more volatile memories.
  • the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 724, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , and other magnetic storage and/or optical storage.
  • the volatile memories include, but are not limited to, a random access memory (RAM) 722 and other volatile memories that will not last in the power-down duration.
  • a computer program 730 includes computer executable instructions that are executed by the associated processor 710.
  • the program 730 may be stored in the ROM 720.
  • the processor 710 may perform any suitable actions and processing by loading the program 730 into the RAM 720.
  • the embodiments of the present disclosure may be implemented by means of the program 730 so that the device 700 may perform any process of the disclosure as discussed with reference to FIGs. 2 to 6.
  • the embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
  • the program 730 may be tangibly contained in a computer readable medium which may be included in the device 700 (such as in the memory 720) or other storage devices that are accessible by the device 700.
  • the device 700 may load the program 730 from the computer readable medium to the RAM 722 for execution.
  • the computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.
  • FIG. 8. shows an example of the computer readable medium 800 in form of CD or DVD.
  • the computer readable medium has the program 730 stored thereon.
  • various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, device, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
  • the present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium.
  • the computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the methods 500 and 600 as described above with reference to FIGs. 5-6.
  • program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types.
  • the functionality of the program modules may be combined or split between program modules as desired in various embodiments.
  • Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.
  • Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing device, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented.
  • the program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
  • the computer program codes or related data may be carried by any suitable carrier to enable the device, device or processor to perform various processes and operations as described above.
  • Examples of the carrier include a signal, computer readable medium, and the like.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
PCT/CN2020/098706 2020-06-29 2020-06-29 Access control of service based management framework WO2022000155A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP20942683.2A EP4173226A4 (en) 2020-06-29 2020-06-29 ACCESS CONTROL OF A SERVICE BASED MANAGEMENT FRAMEWORK
CN202080102534.9A CN116134857A (zh) 2020-06-29 2020-06-29 基于服务的管理框架的接入控制
PCT/CN2020/098706 WO2022000155A1 (en) 2020-06-29 2020-06-29 Access control of service based management framework

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/098706 WO2022000155A1 (en) 2020-06-29 2020-06-29 Access control of service based management framework

Publications (1)

Publication Number Publication Date
WO2022000155A1 true WO2022000155A1 (en) 2022-01-06

Family

ID=79317771

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/098706 WO2022000155A1 (en) 2020-06-29 2020-06-29 Access control of service based management framework

Country Status (3)

Country Link
EP (1) EP4173226A4 (zh)
CN (1) CN116134857A (zh)
WO (1) WO2022000155A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023167571A1 (en) * 2022-03-04 2023-09-07 Samsung Electronics Co., Ltd. Method and system for management services authorization
CN117278329A (zh) * 2023-11-21 2023-12-22 大连凌一科技发展有限公司 一种基于零信任网关的应用资源动态控制访问方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103828412A (zh) * 2011-09-27 2014-05-28 高通股份有限公司 用于远程配置无线设备的方法和系统
CN105187426A (zh) * 2015-09-06 2015-12-23 北京京东尚科信息技术有限公司 用于基于认证信息实现跨域访问的方法和系统
US20160381001A1 (en) * 2015-06-24 2016-12-29 Lecloud Computing Co., Ltd. Method and apparatus for identity authentication between systems
CN107592969A (zh) * 2015-06-09 2018-01-16 英特尔公司 用于在受约束的环境中访问控制列表处理的系统、装置和方法
CN109936547A (zh) * 2017-12-18 2019-06-25 阿里巴巴集团控股有限公司 身份认证方法、系统及计算设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105659558B (zh) * 2013-09-20 2018-08-31 甲骨文国际公司 计算机实现的方法、授权服务器以及计算机可读存储器
US10645583B2 (en) * 2018-02-15 2020-05-05 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103828412A (zh) * 2011-09-27 2014-05-28 高通股份有限公司 用于远程配置无线设备的方法和系统
CN107592969A (zh) * 2015-06-09 2018-01-16 英特尔公司 用于在受约束的环境中访问控制列表处理的系统、装置和方法
US20160381001A1 (en) * 2015-06-24 2016-12-29 Lecloud Computing Co., Ltd. Method and apparatus for identity authentication between systems
CN105187426A (zh) * 2015-09-06 2015-12-23 北京京东尚科信息技术有限公司 用于基于认证信息实现跨域访问的方法和系统
CN109936547A (zh) * 2017-12-18 2019-06-25 阿里巴巴集团控股有限公司 身份认证方法、系统及计算设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4173226A4 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023167571A1 (en) * 2022-03-04 2023-09-07 Samsung Electronics Co., Ltd. Method and system for management services authorization
CN117278329A (zh) * 2023-11-21 2023-12-22 大连凌一科技发展有限公司 一种基于零信任网关的应用资源动态控制访问方法
CN117278329B (zh) * 2023-11-21 2024-01-16 大连凌一科技发展有限公司 一种基于零信任网关的应用资源动态控制访问方法

Also Published As

Publication number Publication date
EP4173226A4 (en) 2024-03-06
EP4173226A1 (en) 2023-05-03
CN116134857A (zh) 2023-05-16

Similar Documents

Publication Publication Date Title
US11470085B2 (en) Service and security enhancement of communication services
US11706617B2 (en) Authenticating radio access network components using distributed ledger technology
US10333927B2 (en) Simulated SSO functionality by means of multiple authentication procedures and out-of-band communications
US10540507B2 (en) Verified device identity providing context to application
US20130227658A1 (en) Openid/local openid security
CN107070843A (zh) 一种用户设备以及在用户设备中的方法
Naik et al. A secure mobile cloud identity: Criteria for effective identity and access management standards
US11337065B1 (en) Fifth generation (5G) edge application authentication
US12068879B2 (en) Smart device provisioning
US20230362199A1 (en) Mechanism for dynamic authorization
WO2022000155A1 (en) Access control of service based management framework
US20190007311A1 (en) Device, Apparatus, Method and Computer Programs for a Network Gateway, Server, Server Apparatus, Server Method, System, Router, Mobile Device, Vehicular Gateway and Cloud Server
WO2021219385A1 (en) Securely identifying network function
EP4075722A1 (en) Security enhancement on inter-network communication
WO2021160386A1 (en) Authorization service for providing access control
WO2021174439A1 (en) Allocation resource of network slice
US20230239679A1 (en) Facilitation of security for electronic subscriber identity module for 5g or other next generation network
US20220360586A1 (en) Apparatus, methods, and computer programs
US20240056506A1 (en) Network function validation
US20230361989A1 (en) Apparatus, methods, and computer programs
US20230413052A1 (en) Access token revocation in security management
WO2024037215A1 (zh) 通信方法及装置
WO2023070340A1 (en) Network repository function policy control for different public land mobile networks
US20240314557A1 (en) Network repository function services access authorization
US11847205B1 (en) Trusted 5G network function virtualization of virtual network function elements embedded on a system-on-chip

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20942683

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020942683

Country of ref document: EP

Effective date: 20230130