EP4173226A1

EP4173226A1 - Access control of service based management framework

Info

Publication number: EP4173226A1
Application number: EP20942683.2A
Authority: EP
Inventors: Jing PING; Iris ADAM; Anatoly ANDRIANOV; Uwe Rauschenbach
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2020-06-29
Filing date: 2020-06-29
Publication date: 2023-05-03
Also published as: EP4173226A4; WO2022000155A1; CN116134857A

Abstract

Embodiments of the present disclosure relate to device, method, apparatus and computer readable storage medium of access control of service-based management framework. The 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. In this way, an AAA solution for the service-based management framework can be achieved.

Description

ACCESS CONTROL OF SERVICE BASED MANAGEMENT FRAMEWORK

FIELD

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.

BACKGROUND

Service-Based Management Architecture (SBMA) was introduced to support service and network management automation. Comparing to traditional integration reference point (IRP) based architecture, SBMA is more flexible, scalable and extendable. Especially the Zero touch network and Service Management (ZSM) framework enables integration and coordination between multiple management domains to support zero-touch service management and orchestration. 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) for protecting management service (MnS) provided by ZSM or Third Generation Partnership Project (3GPP) defined management system and management system itself are essential for service and network management and orchestration, some requirements, guidance and solutions has been defined. For example, 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. Furthermore, 3GPP recommends the network slice management interface that is exposed to communication service providers to be securely protected to prevent unauthorized access.
SUMMARY
In general, example embodiments of the present disclosure provide a solution of access control of service-based management framework.
In a first aspect, there is provided a first device. The first 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 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.
In a second aspect, there is provided a third device. The 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.
In a third aspect, there is provided a method. The 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.
In a fourth aspect, there is provided a method. The 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.
In a fifth aspect, there is provided 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.
In a sixth aspect, there is provided 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.
In a seventh aspect, there is provided 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.
In an eighth aspect, there is provided 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.
Other features and advantages of the embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of embodiments of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the disclosure are presented in the sense of examples and their advantages are explained in greater detail below, with reference to the accompanying drawings, where
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; and
FIG. 8 shows a block diagram of an example computer readable medium in accordance with some embodiments of the present disclosure.
Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.
In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.
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.
It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish functionalities of various elements. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.
As used in this application, the term “circuitry” may refer to one or more or all of the following:
(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and
(b) combinations of hardware circuits and software, such as (as applicable) :
(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and
(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and
(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term 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. The term 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.
As used herein, 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. Furthermore, 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. 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 scope of the present disclosure to only the aforementioned system.
As used herein, 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. 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.
The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, 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) . 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/or industrial wireless networks, and the like. 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) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
Although functionalities described herein can be performed, in various example embodiments, in a fixed and/or a wireless network node, in other example embodiments, functionalities may be implemented in 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.
As mentioned above, service Based Management Architecture (SBMA) was introduced to support service and network management automation. Comparing to traditional integration reference point (IRP) based architecture, SBMA is more flexible, scalable and extendable. Especially the Zero touch network and Service Management (ZSM) framework enables integration and coordination between multiple management domains to support zero-touch service management and orchestration. 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) for protecting management service (MnS) provided by ZSM or Third Generation Partnership Project (3GPP) management system and the management system itself are essential for service, some requirements, guidance and solutions has been defined. For example, 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. Furthermore, 3GPP recommends the network slice management interface that is exposed to communication service providers to be securely protected to prevent unauthorized access.
Authentication, Authorization and Auditing (AAA) are essential for management and orchestration frameworks, but AAA solution has not been developed for ZSM framework and 3GPP SBMA so far.
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.
In addition, diversity is a typical character of 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.
Some approaches have been proposed to solve the AAA problem. For example, Transport Layer Security (TLS) based mutual authentication, and OAuth or local policy based authorization without concrete solution. However, 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. In management point view, it is hard to pre-configure consumer’s root certificate on each producer as the MnS consumer can be dynamically changed. In technical view, it is difficult to make sure 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. In reality, MnS consumer is always in the different domain than the producer, this is block issue to rely on TLS for MnS consumer authentication.
Application Auth Framework (AAF) used in ONAP (Open Network Automation Platform) to protect ONAP applications, and OAuth based authorization solution to protect Application Programming Interface (API) are centralized and static access control framework, which are focused on one management domain with limited client type and may not satisfy requirement of flexible and dynamic SBMA access control across multiple management domains for ZSM or alike framework. Furthermore, none of the solutions as mentioned above considers the security audit.
As described above, the proposed approaches fail to solve the AAA problem between the MnS consumer and producer in multiple management domains. Therefore, 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. As shown in FIG. 1, an access control function (ACF) 130 is introduced to the environment 100. 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) . It is to be understood that the number of ANAF 131 and ARAF 132 shown in FIG. 1 is given for the purpose of illustration without suggesting any limitations. The environment 100 may include any suitable number of ANAF 131 and ARAF 132.
Furthermore, 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) . It is to be understood that 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) .
In general, 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.
It is to be understood that 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.
In order to better understand the solution of the present disclosure, hereinafter the newly introduced function will be described in detail in conjunction with the ZSM architecture. 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.
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.
Furthermore, 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, and 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.
Specifically, 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.
In some example embodiments, 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.
Furthermore, 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.
Principle and implementations of the present disclosure will be described in detail below with reference to FIGs. 3-4, which show schematic processes for the access control of service-based management framework. For the purpose of discussion, 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.
In a registration process 300 shown in FIG. 3, 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.
Then the IF 301 may send 310 the registration information of the MnSP 120 to ANAF 131, to register the MnS in authentication system. According to the requirements of the MnSP 120, 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.
In some example embodiments, 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.
Alternatively, 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.
As another option, if the ANAF 131 determines there is no an existing authentication group matching the requirements related to the registration information of 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.
Then 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. Then 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.
Furthermore, the IF 301 may record the registration procedures of the MnSP 120 in database.
Hereinafter the process 400 will be described with reference to FIG. 4. The process 400 may involve the MnSP 120, IF 301, ARAF 131, ANAF 132, and MnSC 110 as illustrated in FIG. 1.
In a registration process, 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.
Then 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. Furthermore, 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.
In some example embodiments, 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
Then 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.
In addition, with the created identity, 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.
Hereinafter the login process of the MnSC 110 will be further described with reference to FIG. 4. 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. ) .
It is to be understood that 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.
After the MnSC 110 is authenticated, 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.
Then 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.
Based on the assigned access control policies, 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.
Then 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.
After obtaining the token /assertion, 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. In addition, the IF 301 or MnSP 120 may record login and access procedures of the MnSC 110 in database.
Besides the processes described above with reference to FIGs. 3 and 4, there are some postconditions for access control of service-based management framework. First, security audit may be performed periodically or on demand. For example, 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.
Second, the security policy may be updated dynamically. For example, 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.
It is to be understood that 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.
With reference to the example framework 200 shown in FIG. 2, the interaction and operation of the functions may be further described in detail in different scenarios.
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.
Then 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. In some example embodiments, the mechanism to manage and exchange the credential of each identity is dependent on authentication mechanism and credential storage and access technology.
Then 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.
In addition, the 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
Then 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. It is to be understood that Discretionary Access Control (DAC) is applied in this scenario which allows domain administrator to manage access policies for domain MnFs in the scope of the MnSs could be accessed by the MnD 230.
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.
Optionally, 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. Alternatively, 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.
In this scenario, assuming secure connection is always built in all interactions mentioned above. To simplify the solution, the authentication done by MnF is not covered in this invention. Therefore, the authentication and authorization are always enforced at CDIF or DIF based on token/assertion issued by DANAF/CDANAF. 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.
Based on design and security consideration of a MnD, 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.
In another scenario, 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.
In the scenario where the MnD 230 has been registered to ZSM framework as consumer, The MnSP registers MnS to DIF 231, at least service access point (SAP) of the MnS need to be provided. The DIF 231 calls DANAF 232 to register the MnS in authentication system.
According to requirements of the MnSP, 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.
Then 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.
According to requirements of the MnSP, 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.
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.
In this scenario, assuming secure connection is always built in all interactions mentioned above. Furthermore, to simplify, MnSP may be used to represent MnD or MnF or service producer regardless which concrete component initialized the MnS registration to integration fabric.
In a further scenario, access control for a ZSM framework consumer who consumes MnSs across multiple management domains. The precondition of this scenario 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.
In this scenario, 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.
As alternative, 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.
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. After authentication, 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.
In this scenario, 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. In addition, 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.
With primary identity, 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.
In this scenario, all interactions between ZSM consumer and ZSM framework components, as well as between components of ZSM framework, are secured with confidentiality and integrity protection. According to least privilege principle, the default permission of any objects and operations for a new identity is denying. Multiple cross-domain integration fabrics may be deployed to support different management domains based on performance and security requirements.
In a further scenario, Access control for a ZSM framework consumer who consumes E2E service MnS, and E2E service MnF consumes MnSs across multiple management domains to build E2E service for the consumer. 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. In addition, 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.
After having validated the token/assertion, 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.
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. Then the DIF checks access control policies assigned to the MnF with DARAF and returns token/assertion to the MnF. In addition, 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) .
After proceeding all mapped requests with other domain MnFs, the domain MnF (MnF-1) handling request from E2E service MnD returns result to the E2E service MnF. After proceeding all mapped requests with CDIF and MnFs in other MnDs, 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. For the purpose of discussion, the method 500 will be described with reference to FIG. 1.
At 510, 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.
At 520, 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.
At 530, 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.
At 540, 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. For the purpose of discussion, the method 600 will be described with reference to FIG. 1.
At 610, the ARAF receives, from a ANAF, identity information of a management service consumer;
At 620, 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.
At 630, 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.
At 640, the ARAF transmits the authorization grant to the ANAF.
In some example embodiments, an apparatus capable of performing the method 500 (for example, implemented at the ANAF 110) may comprise means for performing the respective steps of the method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.
In some example embodiments, 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.
In some example embodiments, an apparatus capable of performing the method 600 (for example, implemented at the ARAF 120) may comprise means for performing the respective steps of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.
In some example embodiments, 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. As shown, 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.
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. Examples of 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. Examples of 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.
In some embodiments, 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.
Generally, 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. Generally, 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.
In the context of the present disclosure, 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.
Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.
Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

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.
The first device of Claim 1, wherein the first device is further caused to:

determine a list of services allowed for the second device based on the authorization grant; and

transmit the list of services to the second device.
The first device of Claim 1, wherein the first device is further caused to:

in response to receiving, from the second device, registration information of the second device, determine identity information of the second device based on the registration information;

obtain an authentication mechanism supported by the second device from the registration information;

determine an authentication policy for the second device to be authenticated at the first device based on the authentication mechanism supported by the second device, the authentication mechanism, authentication capabilities of the first device and a further authentication mechanism supported by the set of respective domains associated with the at least one fourth device; and

transmit the identity information and the authentication policy to the second device.
The first device of Claim 3, wherein the first device is further caused to:

transmit the identity information of the second device to the third device; and

in response to receiving preliminary information associated with the access control for the second device, transmit the preliminary information to the second device, the preliminary information comprising at least one of the preliminary access control polices and a preliminary list of services allowed for the second device.
The first device of Claim 1, wherein the first device is further caused to:

in response to receiving a login request from the second device in the login process, determine the identity information of the second device;

determine a security context of the second device;

obtain, based on the identity information, an authentication policy for the second device to be authenticated at the first device; and

determine an authentication status of the second device based on the security context and the authentication policy.
The first device of Claim 1, wherein the first device is further caused to:

in response to receiving, from the at least one fourth device, further registration information of the at least one fourth device, create respective further identity information of the at least one fourth device based on the further registration information; and

transmit the respective further identity information to the third device.
The first device of Claim 6, wherein the first device is further caused to:

obtain, from the further registration information, a property of the at least one fourth device comprising at least one of:

respective types of services provided by the at least one fourth device;

a security level of the at least one fourth device;

a security level of the services;

domain information of the services; and

further authentication mechanisms supported by the at least one fourth device; and

determine respective authentication policies for the at least one fourth device based on the property.
The first device of Claim 1, wherein the first device is further caused to:

in accordance with a determination of a status change of at least one of the at least one fourth device and the second device, update at least one of the following:

a security state of the second device;

a security state of the at least one fourth device; and

an authentication policy configured for the second device;

an authentication policy configured for the at least one fourth device.
The first device of Claim 8, wherein the first device is further caused to:

determine whether there is an ongoing access session between the second device and the at least one fourth device; and

in accordance with a determination that there is the ongoing access session, trigger a termination of the ongoing access session.
The first device of Claim 1, wherein the first device comprises an authentication function, the second device comprises a management service consumer, the third device comprises an authorization function and the at least one fourth device comprises a management service provider.
A third 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 third device at least to:

receive, from a first device, identity information of a second device after the second device has been authenticated in a login process of the second device;

determine access control polices for the second device based on 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

transmit the authorization grant to the first device.
The third device of Claim 11, wherein the third device is further caused to:

receive the identity information of the second device from the first device after the second device has been registered at the first device;

determine preliminary information associated with the access control for the second device based on the identity information and the set of respective domains associated with the at least one fourth device, the preliminary information comprising at least one of the preliminary access control polices and a preliminary list of services allowed for the second device; and

transmit the preliminary information to the first device.
The third device of Claim 11, wherein the third device is further caused to:

receive, from the first device, respective further identity information of the at least one fourth device; and

determine a set of candidate classifications of respective services of the at least one fourth device based on the respective further identity information.
The third device of Claim 13, wherein the third device is caused to determine the access control polices by:

obtaining an security context of the second device;

determining a classification of the the second device based on the identity information; and

determining the access control policies based on the set of candidate classifications of the respective services of the at least one fourth device, the classification of the the second device and the security context.
The third device of Claim 11, wherein the third device is further caused to:

in accordance with a determination of a status change of at least one of the at least one fourth device and the second device, update the access control polices for the second device.
The third device of Claim 11, wherein the first device comprises an authentication functions, the second device comprises a management service consumer, the third device comprises an authorization functions and the at least one fourth device comprises a management service provider.
A method comprising:

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.
The method of Claim 17, further comprising:

determining a list of services allowed for the second device based on the authorization grant; and

transmitting the list of services to the second device.
The method of Claim 17, further comprising:

in response to receiving, from the second device, registration information of the second device, determining identity information of the second device based on the registration information;

obtaining an authentication mechanism supported by the second device from the registration information;

determining an authentication policy for the second device to be authenticated at the first device based on the authentication mechanism supported by the second device, , authentication capabilities of the first device and a further authentication mechanism supported by the set of respective domains associated with the at least one fourth device; and

transmitting the identity information and the authentication policy to the second device.
The method of Claim 19, further comprising:

transmitting the identity information of the second device to the third device; and

in response to receiving preliminary information associated with the access control for the second device, transmitting the preliminary information to the second device, the preliminary information comprising at least one of the preliminary access control polices and a preliminary list of services allowed for the second device.
The method of Claim 17, further comprising:

in response to receiving a login request from the second device in the login process, determining the identity information of the second device;

obtaining a security context of the second device;

obtaining, based on the identity information, an authentication policy for the second device to be authenticated at the first device; and

determining an authentication status of the second device based on the security context and the authentication policy.
The method of Claim 17, further comprising:

in response to receiving, from the at least one fourth device, further registration information of the at least one fourth device, creating a further record of respective further identity information of the at least one fourth device based on the further registration information; and

transmitting the respective further identity information to the third device.
The method of Claim 22, further comprising:

obtaining, from the further registration information, a property of the at least one fourth device comprising at least one of:

respective types of services provided by the at least one fourth device;

a security level of the at least one fourth device;

a security level of the services;

domain information of the services; and

a further authentication mechanism supported by the at least one fourth device; and

determining respective authentication policies for the at least one fourth device based on the property.
The method of Claim 17, further comprising:

in accordance with a determination of a status change of at least one of the at least one fourth device and the second device, updating at least one of the following:

a security state of the second device;

a security state of the at least one fourth device;

an authentication policy configured for the second device; and

an authentication policy configured for the at least one fourth device.
The method of Claim 24, further comprising:

determining whether there is an ongoing access session between the second device and the at least one fourth device; and

in accordance with a determination that there is the ongoing access session, triggering a termination of the ongoing access session.
The method of Claim 17, wherein the first device comprises an authentication function, the second device comprises a management service consumer, the third device comprises an authorization function and the at least one fourth device comprises a management service provider.
A method comprising:

receiving, from a first device, identity information of a second device after the second device has been authenticated in a login process of the second device;

determining access control polices for the second device based on 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.
The method of Claim 27, further comprising:

receiving the identity of the second device from the first device after the second device has been registered at the first device;

determining preliminary information associated with the access control for the second device based on the identity information and the set of respective domains associated with the at least one fourth device, the preliminary information comprising at least one of the preliminary access control polices and a preliminary list of services allowed for the second device; and

transmitting the preliminary information to the first device.
The method of Claim 28, further comprising:

receiving, from the first device, respective further identity information of the at least one fourth device; and

determining a set of candidate classifications of respective services of the at least one fourth device based on the respective further identity information.
The method of Claim 28, wherein determining the access control polices comprises:

obtaining an identity of the second device from the identity information and an security context of the second device;

determining a classification of the the second device based on the identity information; and

determining the access control policies based on the set of candidate classifications of the respective services of the at least one fourth device, the classification of the the second device and the security context.
The method of Claim 27, further comprising:

in accordance with a determination of a status change of at least one of the at least one fourth device and the second device, updating the access control polices for the second device.
The method of Claim 27, wherein the first device comprises an authentication functions, the second device comprises a management service consumer, the third device comprises an authorization functions and the at least one fourth device comprises a management service provider.
An apparatus comprising:

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, a 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 comprising:

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 non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 17-26.
A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 27-32.