Methods, devices and storage medium for data access control

Abstract

Embodiments of the present disclosure provide methods, devices, and storage medium for data access control. In a method, a communication device receives a request for accessing Network Configuration Protocol (NETCONF) data. The communication device determines one or more access rules for a target user associated with the received request. Then, the communication device determines a target access rule from the one or more access rules based on information about respective priority of the one or more access rules. Based on the target access rule, the communication device determines an access right of the target user for accessing the NETCONF data.

Description

METHODS, DEVICES AND STORAGE MEDIUM FOR DATA ACCESS CONTROLTECHNICAL FIELD

[0001] The non-limiting and embodiments of the present disclosure generally relate to the technical field of telecommunications, and specifically to methods, devices, and storage medium for data access control.BACKGROUND

[0002] This section introduces aspects that may facilitate a better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0003] Network Configuration Protocol (NETCONF) is a network management protocol developed and standardized by Institute of Electrical and Electronics Engineers (IETF) . It was developed in the NETCONF working group and published in December 2006 as Request for Comments (RFC) 4741 and later revised in June 2011 and published as RFC 6241. The NETCONF protocol specification is an Internet Standards Track document. NETCONF provides mechanisms to install, manipulate, and delete configurations of network devices. NETCONF operations are implemented on top of a simple Remote Procedure Call (RPC) layer. The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding for configuration data as well as protocol messages. The protocol messages are exchanged on top of a secure transport protocol. The standardization of network configuration interfaces for use with NETCONF or Representational State Transfer Configuration Protocol (RESTCONF) protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability.SUMMARY

[0004] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] Network Configuration Access Control Model (NACM) is a standard mechanism to restrict NETCONF or RESTCONF protocol-based access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol-based operations and content.  However, the use of NACM is complex and error-prone, which would bring trouble to the users, increase user workloads, and bring security risks.

[0006] To overcome or mitigate at least one of the above-mentioned problems or other problems or provide a useful solution, embodiments of the present disclosure propose methods, devices, and storage medium for data access control.

[0007] In a first aspect of the present disclosure, there is provided a method implemented at a communication device. In the method, the communication device receives a request for accessing Network Configuration Protocol (NETCONF) data. The communication device determines one or more access rules for a target user associated with the received request. Then, the communication device determines a target access rule from the one or more access rules based on information about respective priority of the one or more access rules. Based on the target access rule, the communication device determines an access right of the target user for accessing the NETCONF data.

[0008] In an embodiment, the communication device may generate access control data associated with the NETCONF data. The access control data may include the one or more access rules and the information about the respective priority of the one or more access rules.

[0009] In an embodiment, the access control data may have respective priority attributes for the one or more access rules, and the priority attributes indicate the information about the respective priority of the one or more access rules.

[0010] In an embodiment, the communication device may receive a configuration for adding a priority attribute for an access rule. The access control data may be generated based on the received configuration.

[0011] In an embodiment, the access control data may be based on a network configuration access control model.

[0012] In an embodiment, the information about the respective priority of the one or more access rules may comprise at least one of a default priority level, a defined priority level, or a priority weight for the one or more access rules.

[0013] In an embodiment, the one or more access rules may comprise a first plurality of access rules associated with the target user, and the first plurality of access rules has respective first priority levels. In an embodiment, the communication device may determine the target access rule from the first plurality of access rules based on a comparison among the respective first priority levels of the first plurality of access rules.

[0014] In an embodiment, the communication device may determine a second plurality of  access rules from the first plurality of access rules, the second plurality of access rules having a same first priority level and respective priority weights. Then, the communication device may determine respective second priority levels for the second plurality of access rules by applying the respective priority weights of the second plurality of access rules to the first priority level. Further, the communication device may determine the target access rule from the second plurality of access rules based on a comparison among the respective second priority levels of the second plurality of access rules.

[0015] In a second aspect of the present disclosure, there is provided a method implemented at a communication device. In the method, the communication device generates access control data associated with Network Configuration Protocol (NETCONF) data. The access control data includes a plurality of lists of access rules, and the plurality of lists of access rules are mapped to a plurality of operator roles of users. The communication device receives a request for accessing the NETCONF data. Based on at least one target list of access rules from the plurality of lists of access rules, the communication device determines an access right of a target user for accessing the NETCONF data. The at least one target list of access rules is mapped to at least one operator role of the target user, and the target user is associated with the received request.

[0016] In an embodiment, the communication device may receive a login request associated with the target user. The communication device may determine the at least one operator role of the target user. Then, the communication device may associate the target user with the at least one target list of access rules, based on the mapping between the at least one target list of access rules and the at least one operator role of the target user.

[0017] In an embodiment, the communication device may receive a logoff request associated with the target user. The communication device may disassociate the target user with the at least one target list of access rules.

[0018] In an embodiment, the communication device may create a plurality of groups of users for the plurality of operator roles. Then, the communication device may create the plurality of lists of access rules associated with the plurality of groups of users. The access control data may include the plurality of lists of access rules and the plurality of groups of users.

[0019] In an embodiment, the communication device may determine, based on the at least one operator role of the target user, at least one group of users from the plurality of groups of users, wherein the at least one group of users is associated with the at least one target list of access rules. Then, the communication device may add the target user to the at least one group of users.

[0020] In an embodiment, the communication device may delete the target user from the at least one group of users.

[0021] In an embodiment, the communication device may cause the plurality of lists of access rules to be stored in association with the plurality of groups of users in a data base.

[0022] In an embodiment, the communication device may obtain the at least one operator role of the target user from at least one of: a local configuration associated with the target user, or an authentication and authorization server.

[0023] In an embodiment, the access control data is based on a network configuration access control model.

[0024] In a third aspect of the present disclosure, there is provided a communication device. The communication device comprises a reception unit configured to receive a request for accessing NETCONF data. The communication device further comprises a first rule determination unit configured to determine one or more access rules for a target user associated with the received request. Moreover, the communication device comprises a second rule determination unit configured to determine a target access rule from the one or more access rules based on information about respective priority of the one or more access rules. Furthermore, the communication device comprises an access control unit configured to determine, based on the target access rule, an access right of the target user for accessing the NETCONF data. The communication device may further comprise units for implementing the method according to the first aspect.

[0025] In a fourth aspect of the present disclosure, there is provided a communication device. The communication device comprises a rule generation unit configured to generate access control data associated with NETCONF data, the access control data including a plurality of lists of access rules, the plurality of lists of access rules being mapped to a plurality of operator roles of users. The communication device further comprises a reception unit configured to receive a request for accessing the NETCONF data. Furthermore, the communication device comprises an access control unit configured to determine, based on at least one target list of access rules from the plurality of lists of access rules, an access right of a target user for accessing the NETCONF data. The at least one target list of access rules is mapped to at least one operator role of the target user, and the target user is associated with the received request. The communication device may further comprise units for implementing the method according to the second aspect.

[0026] In a fifth aspect of the present disclosure, there is provided a communication device. The communication device comprises a processor and a memory coupled to the processor, the memory containing instructions executable by the processor, whereby the communication device is operative to perform the method according to the first or second aspect.

[0027] In a sixth aspect of the present disclosure, there is provided an apparatus. the apparatus  comprises means for performing the method according to the first or second aspect.

[0028] in a seventh aspect of the disclosure, there is provided a computer-readable storage medium having instructions stored thereon, the instructions, which, when executed by at least one processor of a device, cause the device to perform the method according to the first or second aspect.

[0029] With some embodiments of the present disclosure, if a user requests for an access to NETCONF data, a target access rule is determined from one or more access rules for the user based on information about respective priority of the one or more access rules. With some other embodiments of the present disclosure, an access right of a user is determined based on mapping between one or more operator roles of the user and one or more lists of access rules. In this way, various issues caused by rule conflicts may be avoided effectively and efficiently.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Through the more detailed description of some embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein the same reference generally refers to the same components in the embodiments of the present disclosure.

[0031] FIG. 1 is a diagram showing an example communication environment in which embodiments of the present disclosure can be implemented.

[0032] FIG. 2 is a diagram showing a flowchart of an example method for data access control based on a priority definition scheme in accordance with some embodiments of the present disclosure.

[0033] FIG. 3 is a diagram showing an example process for using priority in NACM-based access rules in accordance with some embodiments of the present disclosure.

[0034] FIG. 4 is a diagram showing a flowchart of an example method for data access control based on a role mapping scheme in accordance with some embodiments of the present disclosure.

[0035] FIG. 5A is a diagram showing an example process of associating a user with one or more lists of access rules in according with some embodiments of the present disclosure.

[0036] FIG. 5B is a diagram showing another example process of associating a user with one or more lists of access rules in according with some embodiments of the present disclosure.

[0037] FIG. 6 is a diagram showing a flowchart of an example process of monitoring event frequency in accordance with some embodiments of the present disclosure.

[0038] FIG. 7 is a diagram showing function units of a communication device in accordance  with some embodiments of the present disclosure.

[0039] FIG. 8 is a diagram showing function units of a communication device in accordance with some other embodiments of the present disclosure.

[0040] FIG. 9 is a block diagram showing a communication device in accordance with some other embodiments of the present disclosure.

[0041] FIG. 10 is a block diagram showing a computer readable storage medium in accordance with some embodiments.DETAILED DESCRIPTION

[0042] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0043] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0044] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features  and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.

[0045] As used herein, the terms "first" , "second" and so forth refer to different elements. The singular forms "a" and "an" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises" , "comprising" , "has" , "having" , "includes" and / or "including" as used herein, specify the presence of stated features, elements, and / or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. The term "based on" is to be read as "based at least in part on" . The term "one embodiment" and "an embodiment" are to be read as "at least one embodiment" . The term "another embodiment" is to be read as "at least one other embodiment" . Other definitions, explicit and implicit, may be included below.

[0046] As described above, NACM is a standard mechanism for NETCONF or RESTCONF protocol-based access control. NACM is a YANG model of NETCONF. An example model structure of NACM is show as below.

[0047] The configuration of NACM requires XML based RPC. Data is written into the NETCONF data base to restrict user access to NETCONF data. An RPC example is as follows, where an NACM group called "limited" is created and there is a user "test_limit" in this group:

[0048] The following is another RPC example where a rule-list named "limited-acl" is created:

[0049] As shown, the rule-list "limited-acl" has two rules, where one is to allow the read operation on the data of the model "ntp-router" , and the other is to prohibit the write operation on the data of the model "ntp-router" . The group "limited" applies these rules (e.g., this group can read, but cannot write to model "ntp-router" data) . This means that the user "test_limit" applies these rules as the user "test_limit" is added to group "limited" . For use of NACM, a lot of the above configurations are required, which is obviously complicated and workload consuming. Therefore, the NACM usage is complex.

[0050] In addition, the use of NACM is error prone. A user can reference multiple rules, and these rules may conflict with each other. For example, a first rule-list is as follows:

[0051] According to this rule-list, the write operation on the data of the model "ntp-router" is denied. Further, there is a second rule-list as follows:

[0052] According to the second rule-list, the write operation on all models is permitted. In this  case, the first and second rule-lists conflict with each other. Thus, the write operation on the data of the model "ntp-router" cannot be configured or used.

[0053] NACM is very flexible. Many different user groups and rule-lists may be created. Therefore, confliction between different rules is possible. For example, as shown in the above RPC examples, the first RPC prohibits the user "test_limit" from accessing the data of the model "ntp-router" , and the second RPC allows the user "test_limit" to access data for all models. The results of these two rules are in conflict. Due to such confliction, data access services may not be configured and used.

[0054] The consequences of defining rules based on NACM are unknown and may cause a server or device to lose access management control. Although these errors can be found during use, this still adds a lot of work to the user. Moreover, NACM is a security-related function. If something goes wrong, it will bring security risks.

[0055] One approach to resolve the confliction between the rules is "first matched first takes effect" . In this approach, the rule-list entries are processed in an order until an entry matching the requested operation is found. It is uncertain which rule will be found. Such rule searching may depend on a data structure for creating the rule-list. For example, the rules may be organized based on a forward list, a reverse list, and even hash tables for higher efficiency. Thus, some rules conflict, the searching result may be uncertain.

[0056] Such rule searching is uncertain for rule (or that rule has no priority) . This method is very dependent on the implementation level, for example, if the rule at the implementation level can be organized according to the forward list, the reverse list, and even in order to pursue efficiency hash tables can be used, so that if the rule conflicts, the result is uncertain. For example, in the case that "rule1" and "rule2" conflict, if a forward list lookup is used, one (e.g., "rule1" ) of "rule1" and "rule2" will take effect; if a reverse list lookup is used, the other one (e.g., "rule2" ) of "rule1" and "rule2" will take effect. If a hash lookup is used, the rule that takes effect will even be changed each time.

[0057] The device configuration recovery may also have some issues. For example, in the case that "rule1" and "rule2" conflict, after the device stores the configuration and restarts, it is uncertain whether "rule1" or "rule2" will take effect. This is because it is uncertain which rule will be put on the first place in the internal data structure due to timing reason. As a result, the device may behave differently after each restart.

[0058] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. Some embodiments of the present disclosure propose a priority definition scheme for access rules (also called rules) of users. With this priority definition scheme, if a user  requests for an access to NETCONF data, a target access rule is determined from one or more access rules for the user based on information about respective priority of the one or more access rules. Based on the information about priority of the respective access rules, a rule with higher priority may take effect. As such, by defining the priority of different rules, the error-prone issues as described above may be resolved. In this way, various issues caused by rule conflicts may be avoided effectively and efficiently.

[0059] In addition, some other embodiments of the present disclosure propose a role mapping scheme for access rules of users. With this role mapping scheme, access control data associated with NETCONF data is generated to include a plurality of lists of access rules that are mapped to a plurality of operator roles (also referred to as roles) of users. After receiving a user request for an access to NETCONF data, an access right of a target user is determined based on at least one target list of access rules that is mapped to at least one operator role of the target user. By mapping an operator role (or user role) of a user to the corresponding list (s) of access rules, manual configurations may be replaced with automatic mapping, thereby reducing user workloads and the possibility of errors.

[0060] Some example implementations will be described below with reference to the accompanying drawings.

[0061] FIG. 1 illustrates an example communication environment 100 in which embodiments of the present disclosure can be implemented.

[0062] The communication environment 100, which may be a part of a communication system, comprises a communication device 110 which may operate as a router, a switch, a server or other communication devices. The communication device 110 can perform access management for data stored in a data base 120. In some embodiments, the stored data may comprise NETCONF data. The communication device 110 and the data base 120 may be deployed in a separate or integrated way. For example, the data base 120 may be integrated into or be a part of the communication device 110.

[0063] The communication environment 100 may further comprise an authentication and authorization server 130 which may be a Terminal Access Controller Access-Control System (TACACS) server or a Remote Authentication Dial in User Service (RADIUS) server. The authentication and authorization server 130 may be responsible for authentication and authorization for users.

[0064] Furthermore, the communication environment 100 may comprise a client device 140 which may be any end device. An example of the client device 140 may comprise, but be not limited to, a mobile phone, a desktop computer, a laptop computer, a netbook, a tablet, a media  computer, a multimedia tablet, a personal communication system (PCS) device, a personal navigation device, a personal digital assistants (PDA) , an audio / video players, a digital camera / camcorder, a positioning device, a television receiver, a radio receiver, an e-book device, a gaming device, or any combination thereof. In the communication environment 100, a user 140 may use the client device 150 to access the NETCONF data stored in the data based 120 via a network 160.

[0065] It is to be understood that the numbers and types of devices are illustrated in FIG. 1 only for the purpose of illustration without suggesting any limitations. The communication environment 100 may include any number and any other types of devices for implementing embodiments of the present disclosure. For example, the communication environment 100 may comprise more than one communication device 110 which may share the data stored in the data base 120 which may be deployed in Cloud.

[0066] For data access control or management, a plurality of access rules may be created by a system administrator to restrict users to access the NETCONF data stored in the data based 120. These access rules may be included in access control data which may be based on a NACM. According to some embodiments of the present disclosure, information about priority of the access rules is introduced for the data access control. Using such information, the access rule with the higher priority may be selected to use, thereby avoiding rule conflicts effectively and efficiently. Some embodiments in this regard will be describe below with reference to FIGS. 2 and 3.

[0067] FIG. 2 shows a flowchart of an example method 200 for data access control based on a priority definition scheme in accordance with some embodiments of the present disclosure. The method 200 can be implemented by the communication device 110 in FIG. 1. For the purpose of discussion, the method 200 will be described for the perspective of the communication device 110 with reference to FIG. 1.

[0068] At block 210, the communication device 110 receives a request for accessing NETCONF data. Herein, this request will also be referred to as a data access request. The request may be made by the user 150 using the client device 140. In some embodiments, the request may be a NETCONF RPC.

[0069] At block 220, the communication device 110 determines one or more access rules for a target user associated with the received request. For example, if the data access request is from the user 150, the communication device 110 may determine the access rule (s) that can be used for the user 150 (as the target user) .

[0070] At block 230, based on information about respective priority of the one or more access  rules determined for the target user, the communication device 110 determines a target access rule from the one or more access rules.

[0071] At block 240, based on the target access rule, the communication device 110 determines an access right of the target user for accessing the NETCONF data.

[0072] In some embodiments, such information may be added in access control data associated with the NETCONF data. The access control data may be based on a NACM or other data model. In an example, the communication device 110 may generate the access control data that includes the one or more access for the target user as well as the information about the respective priority of the one or more access rules. In an example, the access control data may be maintained in the data base 120 as shown in FIG. 1.

[0073] In some embodiments, priority attributes for the access rules may be introduced which indicate the information about the respective priority of the access rules. Based on the introduced priority attributes, each rule may have priority information. In an example, the access control data may have respective priority attributes for the one or more access rules for the target user and other access rules that can be used for other users, and the priority attributes. By way of example, in the embodiments where the access control data is based on a NACM or a NACM model, a NACM model may be extended to have the priority attribute.

[0074] Taking a NACM YANG model as an example model used for the access control data, the NACM YANG model may be extended to add a "priority" subfield to a "rule" element as follows.

[0075] In the expanded NACM structure as shown above, the subfield “priority” with a data type “uint32” is added for the rule-list.

[0076] The addition of the priority attribute may be configured, for example, by a system administrator. In some embodiments, the communication device 110 may receive a configuration for adding a priority attribute for an access rule. Based on the configuration, the communication device 110 may generate the access control data including the priority attributes for the access  rules.

[0077] This configuration for adding a priority attribute for an access rule may be created by a system administrator. The configuration may be received in a NETCONF protocol message. In an example, in the case that the access control data is generated based on a NACM module, “augment” statements may be used to create an extension model. The configuration may be based on such an extension model. An example of such an extension model is as follows.

[0078] As shown, the extension model using the “augment” statements defines a leaf “priority” with the data type “uint32” to indicate the priority of an access rule. It is to be noted that the use of "augment" statements for creating as an extension model is only illustrative but not limited. Other approaches for extending the NACM model are also possible. For example, the standard  NACM model may be modified to include the priority attributes for the access rule. Accordingly, based on the information about the priority of the access rules indicated by the priority attribute, an access rule with higher priority may be determined from the one or more access rules for the target user (e.g., the user 150) .

[0079] The information about the priority of the access rules may comprise any type of information related to priority. In some embodiments, the information may comprise a default and / or defined priority level of the access rules. The defined priority level may comprise an explicitly defined priority of the rule be specified by the system administrator. If no priority is explicitly defined, the default priority level may take effect for each rule. For example, all created access rules may initially have a default priority level, such as 255. If a defined priority level is specified for an access rule, the priority level for that access rule may be updated to the defined priority level.

[0080] In some embodiments, in the case that a plurality of access rules (referred to as a first plurality of access rules) are determined to be associated with the target user, the communication device 110 may determine the target access rule from the first plurality of access rules based on a comparison among respective priority levels (referred to as first priority levels) of the first plurality of access rules. In an example, to find the target access rule, the communication device 110 may iterate over all the access rules in a way that makes the access rule with the highest (explicitly defined) priority to take effect.

[0081] In another example, the communication device 110 may not iterate over all the access rules, but search for the target access rule based on the descending order of the priority levels in a predefined sets of priority levels. For example, a set of priority levels may be predefined for the access rules. In this example, the communication device 110 may first search for an access rule with the highest priority levels in the predefined sets of priority levels. If no such an access rule is found, the communication device 110 may search for an access rule with the second highest priority level in the predefined set of priority levels, and so on, util one or more access rules are found.

[0082] In addition to a default or defined priority level for the access rules, or as an alternative, the information about the priority of the access rules may comprise a priority weight for the access rules. In an example, the priority weight may be related to a requested action or operation for data access which is involved in an access rule. For example, each action or operation may have a priority weight. If the defined priority levels of more than one access rules are the same, or if no priority level are defined for these access rules, then the default priority level is used for these access rules, the priority weights for the access rules may be used to determine their final priority levels.

[0083] In some embodiments, the communication device 110 may determine a plurality of access rules (referred to as a second plurality of access rules) from the first plurality of access rules associated with the target user. The second plurality of access rules may have a same first priority level and respective priority weights. In this case, the communication device 110 may apply the respective priority weights of the second plurality of access rules to the first priority level to determine respective second priority levels for the second plurality of access rules. Based on a comparison among the respective second priority levels of the second plurality of access rules, the communication device 110 may determine the target access rule from the second plurality of access rules.

[0084] FIG. 3 shows an example process 300 for using priority in NACM-based access rules in accordance with some embodiments of the present disclosure. The process 300 can be implemented by the communication device 110 in FIG. 1. For the purpose of discussion, the method 200 will be described for the perspective of the communication device 110 with reference to FIG. 1. In this example, the request from a target user for accessing the NETCONF is a NETCONF RPC.

[0085] As shown in FIG. 3, in the process 300, at block 310, the communication device 110 receives a NETCONF RPC. At block 320, the communication device 110 collects all access rules for a user (as a target user) who requests this NETCONF RPC. At block 330, the communication device 110 determines priority levels of the collected access rules. If priority levels are not explicitly defined for some access rules, the default priority level may be used for these access rules. At block 340, the communication device 110 compares the priority levels of the collected access rules. At block 350, the communication device 110 determines whether only one access rule with the highest priority level is found. If yes, the process 300 proceeds to block 360 where the access rule with the highest priority level is used.

[0086] If more than one access rules have the highest priority, the process 300 proceeds to block 370 where the new priority level is recalculated by adding the priority weights of these access rules which may be related to the actions or operations of the data access. For example, the NACM model may support two actions, namely "permit" and "deny" . The priority weights for these two actions may be defined as follows:

[0087] ● “permit” : 100%, which is multiplied by 1 based on the defined (or default) priority.

[0088] ● “deny” : 200%, which is multiplied by 2 based on the defined (or default) priority.

[0089] In this example, different priority weights related to different actions may be added on top of the priority levels of the access rules to get the new priority levels for these access rules. At block 380, the communication device 110 uses the access rule with the new highest priority  level. Based on information about the priority of the access rules, rule conflicts may be avoided effectively and efficiently.

[0090] In some embodiments, in addition to the use of the priority of the access rules, or as an alternative, different operator roles of users may be defined and mapped to different lists of access rules (also called rule lists) . Some embodiments in this regard will be described below with refence to FIGS. 4 to 6.

[0091] FIG. 4 shows a flowchart of an example method 400 for data access control a role mapping scheme in accordance with some other embodiments of the present disclosure. The method 400 can be implemented by the communication device 110 in FIG. 1. For the purpose of discussion, the method 400 will be described for the perspective of the communication device 110 with reference to FIG. 1.

[0092] At block 410, the communication device 110 generates access control data associated with NETCONF data. The access control data, which may be based on a NACM and maintained in the data base 120, includes a plurality of lists of access rules, and the plurality of lists of access rules are mapped to a plurality of operator roles of users. One list of access rules may be mapped to more than one operator role, and more than one list of access rules may be mapped to one operator role.

[0093] The operator role may be defined in any criterion which may depend on the system deployment. Examples of the operator role may comprise a system administrator, a technical support, a debugger, and / or the like. The "role" indicates a responsibility, a job and / or an available service of a user. For example, the “system administrator” role (denoted by “SystemAdministrator” ) is responsible for system management. The “technical support” role (denoted by “TechSupport” ) is responsible for customer support.

[0094] The mapping between the operator roles and the lists of access rules may be dynamically defined, configured, or added, for example, by a system administrator in the access control data. Alternatively, or in addition, the mapping may be fixed or embedded in the access control data.

[0095] In an example, for mapping different operator roles to different lists of access rules, default lists of access rules may be created for different roles. For example, the following default access rules based on "role" may be created:

[0096] ● SystemAdministrator has full access permission, that is, can read, write, and execute.

[0097] ● TechSupport can read and execute, but cannot write.

[0098] The mapping of the lists of access rules and the operator roles may be included in the  access control data in any suitable way. In some embodiments, the communication device 110 may create a plurality of groups of users for the plurality of operator roles and then create the plurality of lists of access rules associated with the plurality of groups of users. In these embodiments, the access control data may include the plurality of lists of access rules and the plurality of groups of users. In an example, one or more groups of users may be created for one operator roles, and one group of users may be associated with more than one operator role. Alternatively, or in addition, one or more lists of access rules may be created for one group of users, and more than one group of users may share one list of access rules.

[0099] In some embodiments, the communication device 110 may cause the plurality of lists of access rules to be stored in association with the plurality of groups of users in the data base 120. In an example, in the case that the data base 120 is integrated into or is a part of the communication device 110, the communication device 110 may store, in the data base 120, the plurality of lists of access rules in association with the plurality of groups of users. In another example, if the data base 120 is separately deployed in Cloud, the communication device 110 may transmit the plurality of lists of access rules and the plurality of groups of users to the data base 120 such that the data base 120 store the plurality of lists of access rules in association with the plurality of groups of users.

[0100] In some other embodiments, a “role” attribute may be added for a list of access rules. The operations and actions for adding the priority attribute to the access rule as described above with reference to FIGS. 2 and 3 are likewise applicable for adding the role attribute to the list of access rules. For the purpose of simplification, the details will be omitted.

[0101] At block 420, the communication device 110 receives a request for accessing the NETCONF data. In an example, the request may be a NETCONF RPC. In response to the received request, at block 430, the communication device 110 determines an access right of a target user for accessing the NETCONF data, based on at least one target list of access rules among the plurality of lists of access rules. The at least one target list of access rules is mapped to at least one operator role of the target user. The target user is associated with the received request and, for example, may be a user making the request. The target user may have one or more operator roles which may be mapped to one or more target lists of access rules.

[0102] In this way, based on the role attribute of a user, the user may have an expected access right. Thus, the complex and error-prone NACM configurations may be avoided. Further, human labor may be replaced with automation, thereby reducing the workload and the possibility of errors.

[0103] The association of the target user and the at least one target list of access rules may be created or generated in any suitable way. In some embodiments, the association may be created  during a login procedure of the target user. In an example, the communication device 110 may receive a login request associated with the target user. Then, the communication device 110 may determine the at least one operator role of the target user. Based on the mapping between the at least one target list of access rules and the at least one operator role of the target user, the communication device 110 may associate the target user with the at least one target list of access rules.

[0104] In the embodiments where the access control data includes the plurality of lists of access rules and the plurality of groups of users associated with the plurality of lists of access rules, to associate the target user with the at least one target list of access rules, the communication device 110 may determine at least one group of users from the plurality of groups of users based on the at least one operator role of the target user. The at least one group of users is associated with the at least one target list of access rules. Then, the communication device 110 may add the target user to the at least one group of users. As such, the target user may be associated with the at least one target list of access rules.

[0105] The at least one operator role of the target user may be obtained by the communication device 110 from a local configuration associated with the target user. For example, the operator role of the target user may be locally set statically. An example process of setting an operator role of a user locally will be described below with reference to FIG. 5A.

[0106] FIG. 5A shows an example process 500 of associating a user with one or more lists of access rules in according with some embodiments of the present disclosure.

[0107] In the process 500 as shown in FIG. 5A, at 502, the communication device 110 creates one or more groups of users for every role. At 504, the communication device 110 creates one or more lists of access rules for every group of users. At 506, the communication device 110 stores the groups of users and the lists of rules in the data base 120 which may be integrated into or be a part of the communication device 110. At 508, the communication device 110 receives a login request of a user. At 510, the communication device 110 gets one or more roles for the user from a local configuration. At 512, the communication device 110 finds one or more groups of users based on one or more roles of the user. At 514, the communication device 110 adds the user to the one or more groups of users that are stored in the data base 120.

[0108] In addition to obtaining the at least one operator role of the target user from the local configuration, or as an alternative, the communication device 110 may obtain obtaining the at least one operator role of the target user from the authentication and authorization server 130 as shown in FIG. 1. In an example, two modes may be supported, including locally setting one or more operator roles of a user statically, and / or obtaining the role dynamically from the authentication and authorization server 130 such as a TACACS or RADIUS server. An example  process of getting an operator role of a user from the authentication and authorization server 130 will be described below with reference to FIG. 5B.

[0109] FIG. 5B shows another example process 520 of associating a user with one or more lists of access rules in according with some embodiments of the present disclosure.

[0110] The operations and actions of the communication device 110 at 522, 524, 526 and 528 in the process 520 as shown in FIG. 5B are similar to the operations and actions of the communication device 110 at 502, 504, 506 and 508 in the process 500 as shown in FIG. 5A. For the purpose of simplification, the details will be omitted. Different from the process 500 as shown in FIG. 5A, in the process 520, after the communication device 110 receives a login request of a user, at 530, the communication device 110 requests authentication and authorization of the user from the authentication and authorization server 130 which may be a TACACS or RADIUS server. At 532, the authentication and authorization server 130 replies one or more roles of the user. At 534, the communication device 110 finds one or more groups of users based on one or more roles of the user. At 536, the communication device 110 adds the user to the one or more groups of users that are stored in the data base 120.

[0111] After a user has a "role" (obtained either from a local static configuration or through a TACACS or RADIUS server) , it may be determined which list (s) of access rules are associated with the user and need to be used for the user.

[0112] In some embodiments, the association between the target user and the at least one target list of access rules may be canceled. In an example, this cancelling may be implemented during a logoff procedure of the target user.

[0113] For example, after the communication device 110 receives a logoff request associated with the target user, the communication device 110 may disassociate the target user with the at least one target list of access rules. In the embodiments where the target user is added to a group of users that is associated with the at least one target list of access rules, the communication device 110 may deleting the target user from the group of users to disassociate the target user with the at least one target list of access rules.

[0114] FIG. 6 shows another example process 600 of disassociating a user with one or more lists of access rules in according with some embodiments of the present disclosure.

[0115] In the process 600 as shown in FIG. 6, at 602, the communication device 110 receives a logoff request of a user. At 604, the communication device 110 finds one or more groups of users based on one or more roles of the user. At 606, the communication device 110 deletes the user from the one or more groups of users. As such, the user may be disassociated with the or more lists of access rules that are associated with the found one or more groups of users.

[0116] It is to be understood that the proposed priority definition scheme and role mapping scheme may be applied for data access management or control separately or in combination. The communication device 110 may use either the priority definition scheme or the role mapping scheme or use both the priority definition scheme and the role mapping scheme.

[0117] FIG. 7 shows function units of a communication device 700 in accordance with some embodiments of the present disclosure.

[0118] As shown in FIG. 7, the communication device 700 comprises a reception unit 710 configured to receive a request for accessing NETCONF data. The communication device 700 further comprises a first rule determination unit 720 configured to determine one or more access rules for a target user associated with the received request. Moreover, the communication device 700 comprises a second rule determination unit 730 configured to determine a target access rule from the one or more access rules based on information about respective priority of the one or more access rules. Furthermore, the communication device 700 comprises an access control unit 740 configured to determine, based on the target access rule, an access right of the target user for accessing the NETCONF data.

[0119] In some embodiments, the communication device 700 may further comprise units for implementing actions or operations related to the terminal device according to any of the above-mentioned embodiments described with reference to FIGS. 2 to 3.

[0120] FIG. 8 shows function units of a communication device 800 in accordance with some embodiments of the present disclosure.

[0121] As shown in FIG. 8, the communication device 800 comprises a rule generation unit 810 configured to generate access control data associated with NETCONF data, the access control data including a plurality of lists of access rules, the plurality of lists of access rules being mapped to a plurality of operator roles of users. The communication device 800 further comprises a reception unit 820 configured to receive a request for accessing the NETCONF data. Furthermore, the communication device 800 comprises an access control unit 830 configured to determine, based on at least one target list of access rules from the plurality of lists of access rules, an access right of a target user for accessing the NETCONF data. The at least one target list of access rules is mapped to at least one operator role of the target user, and the target user is associated with the received request.

[0122] In some embodiments, the terminal device 800 may further comprise units for implementing actions or operations related to the terminal device according to any of the above-mentioned embodiments described with reference to FIGS. 4 to 6.

[0123] All operations and features related to the communication device 110 as described above  with reference to FIGS. 1 to 6 are likewise applicable to the communication devices 700 and 800 and have similar effects. For the purpose of simplification, the details will be omitted.

[0124] The term unit may have conventional meaning in the field of electronics, electrical devices and / or electronic devices and may include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

[0125] FIG. 9 shows a communication device 900 in accordance with some embodiments of the present disclosure.

[0126] As shown in FIG. 9, the communication device 900 may comprise a processor 905 and a memory 910. The memory 910 may contain instructions 915 executable by the processor 905, whereby the communication device 900 may be operative to implement actions or operations according to any of the above-mentioned embodiments described with reference to FIGS. 1 to 6.

[0127] In some embodiments, the communication device 900 may be operative to: receive a request for accessing NETCONF data; determine one or more access rules for a target user associated with the received request; determine a target access rule from the one or more access rules based on information about respective priority of the one or more access rules; and determine, based on the target access rule, an access right of the target user for accessing the NETCONF data.

[0128] In some embodiments, the communication device 900 may be operative to: generate access control data associated with NETCONF data, the access control data including a plurality of lists of access rules, the plurality of lists of access rules being mapped to a plurality of operator roles of users; receive a request for accessing the NETCONF data; and determine, based on at least one target list of access rules from the plurality of lists of access rules, an access right of a target user for accessing the NETCONF data, where the at least one target list of access rules is mapped to at least one operator role of the target user and the target user is associated with the received request.

[0129] The processor 905 may be any kind of processing component, such as one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs) , special-purpose digital logic, and the like. The memory 910 may be any kind of storage component, such as read-only memory (ROM) , random-access memory, cache memory, flash memory devices, optical storage devices, etc.

[0130] FIG. 10 shows a computer readable storage medium 1000 in accordance with some embodiments.

[0131] As shown in FIG. 10, the computer readable storage medium 1000 comprising instructions 1015 which when executed by a processor of a device, cause the device to perform any above-mentioned embodiments described with reference to FIGS. 1 to 6.

[0132] The computer readable storage medium 1000 may be configured to include memory such as RAM, ROM, programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, or flash drives.

[0133] In some embodiments, an apparatus capable of performing the method 200 or 400 may comprise means for performing the respective operations of the method 200 or 400. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0134] Although the communication devices described herein may include the illustrated combination of hardware components, other embodiments may comprise communication devices with different combinations of components. It is to be understood that these communication devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, communication devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0135] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those  particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the communication device, but are enjoyed by the communication device as a whole, and / or by end users and a wireless network generally.

[0136] ABBREVIATIONS

[0137] NETCONF    Network Configuration Protocol

[0138] NACM       Network Configuration Access Control Model

[0139] RPC        Remote Procedure Call

[0140] XML        Extensible Markup Language

Claims

1.A method (200) implemented at a communication device (110) , the method (200) comprising:receiving (210) a request for accessing Network Configuration Protocol, NETCONF, data;determining (220) one or more access rules for a target user (150) associated with the received request;determining (230) a target access rule from the one or more access rules based on information about respective priority of the one or more access rules; anddetermining (240) , based on the target access rule, an access right of the target user (150) for accessing the NETCONF data.2.The method (200) of claim 1, further comprising:generating access control data associated with the NETCONF data, the access control data including the one or more access rules and the information about the respective priority of the one or more access rules.3.The method (200) of claim 2, wherein the access control data has respective priority attributes for the one or more access rules, and the priority attributes indicate the information about the respective priority of the one or more access rules.4.The method (200) of claim 3, further comprising:receiving a configuration for adding a priority attribute for an access rule,wherein the access control data is generated based on the received configuration.5.The method (200) of any of claims 2-4, wherein the access control data is based on a network configuration access control model.6.The method (200) of any of claims 1-5, wherein the information about the respective  priority of the one or more access rules comprises at least one of a default priority level, a defined priority level, or a priority weight for the one or more access rules.7.The method (200) of any of claims 1-6, whereinthe one or more access rules comprises a first plurality of access rules associated with the target user, and the first plurality of access rules has respective first priority levels, anddetermining (230) the target access rule from the one or more access rules comprises:determining the target access rule from the first plurality of access rules based on a comparison among the respective first priority levels of the first plurality of access rules.8.The method (200) of claim 7, wherein determining the target access rule from the first plurality of access rules comprises:determining a second plurality of access rules from the first plurality of access rules, the second plurality of access rules having a same first priority level and respective priority weights;determining respective second priority levels for the second plurality of access rules by applying the respective priority weights of the second plurality of access rules to the first priority level; anddetermining the target access rule from the second plurality of access rules based on a comparison among the respective second priority levels of the second plurality of access rules.9.A method (400) implemented at a communication device (110) , the method (400) comprising:generating (410) access control data associated with Network Configuration Protocol, NETCONF, data, the access control data including a plurality of lists of access rules, the plurality of lists of access rules being mapped to a plurality of operator roles of users;receiving (420) a request for accessing the NETCONF data; anddetermining, based on at least one target list of access rules from the plurality of lists of access rules, an access right of a target user (150) for accessing the NETCONF data, wherein the at least one target list of access rules is mapped to at least one operator role of the target user (150) and the target user (150) is associated with the received request.10.The method (400) of claim 9, further comprising:receiving a login request associated with the target user;determining the at least one operator role of the target user; andassociating the target user (150) with the at least one target list of access rules, based on the mapping between the at least one target list of access rules and the at least one operator role of the target user.11.The method (400) of claim 10, further comprising:receiving a logoff request associated with the target user; anddisassociating the target user (150) with the at least one target list of access rules.12.The method (400) of claim 10 or 11, wherein generating the access control data comprises:creating a plurality of groups of users for the plurality of operator roles; andcreating the plurality of lists of access rules associated with the plurality of groups of users,wherein the access control data includes the plurality of lists of access rules and the plurality of groups of users.13.The method (400) of claim 12, wherein associating the target user (150) with the at least one target list of access rules comprises:determining, based on the at least one operator role of the target user, at least one group of users from the plurality of groups of users, wherein the at least one group of users is associated with the at least one target list of access rules; andadding the target user (150) to the at least one group of users.14.The method (400) of claim 13, wherein disassociating the target user (150) with the at least one list of access rules comprises:deleting the target user (150) from the at least one group of users.15.The method (400) of any of claims 12-14, further comprising:causing the plurality of lists of access rules to be stored in association with the plurality of groups of users in a data base (120) .16.The method (400) of any of claims 10-15, wherein determining the at least one operator role of the target user (150) comprises:obtaining the at least one operator role of the target user (150) from at least one of:a local configuration associated with the target user, oran authentication and authorization server (130) .17.The method (400) of any of claims 9-16, wherein the access control data is based on a network configuration access control model.18.A communication device (110, 900) , comprising:a processor (905) ; anda memory (910) , the memory (910) containing instructions (915) executable by the processor (905) , whereby the communication device (110, 900) is operative to:receive (210) a request for accessing NETCONF data;determine (220) one or more access rules for a target user (150) associated with the received request;determine (230) a target access rule from the one or more access rules based on information about respective priority of the one or access rules; anddetermine (240) , based on the target access rule, an access right of the target user (150) for accessing the NETCONF data.19.The communication device (110, 900) of claim 18, wherein the communication device (110, 900) is further operative to implement the method (200) according to any of claims 2-8.20.A communication device (110, 900) , comprising:a processor (905) ; anda memory (910) , the memory (910) containing instructions (915) executable by the processor (905) , whereby the communication device (110, 900) is operative to:generate (410) access control data associated with NETCONF data, the access control data including a plurality of lists of access rules, the plurality of lists of access rules being mapped to a plurality of operator roles of users;receive (420) a request for accessing the NETCONF data; anddetermine (430) , based on at least one target list of access rules from the plurality of list of access rules, an access right of a target user (150) for accessing the NETCONF data, wherein the at least one target list of access rules is mapped to at least one operator role of the target user (150) and the target user (150) is associated with the received request.21.The communication device (110, 900) of claim 20, wherein the communication device (110, 900) is further operative to implement the method (400) according to any of claims 10-17.22.A computer-readable storage medium (1000) having instructions (915) stored thereon, the instructions (915) , which when executed by at least one processor of a device, causing the at least one processor to perform the method (200) according to any of claim 1-8 or the method (400) according to any of claims 9-17.

Images