WO2013022319A2

WO2013022319A2 - Method for authenticating authority to command of server, method for requesting authority authentication, and device for same

Info

Publication number: WO2013022319A2
Application number: PCT/KR2012/006408
Authority: WO
Inventors: 박승규; 김성윤
Original assignee: 엘지전자 주식회사
Priority date: 2011-08-10
Filing date: 2012-08-10
Publication date: 2013-02-14
Also published as: WO2013022319A3; WO2013022317A3; WO2013022317A2

Abstract

Disclosed is a method for authenticating from a terminal authority to a device management (DM) command of a server with respect to nodes of a DM tree that are saved on the terminal, and the method comprises the steps of: receiving the command with respect to the nodes; retrieving from the server an access control list (ACL) value of the node; and determining whether the server has authority to the command, based on information on a authenticated group that is described on the ACL value of the nodes, and on the server that belongs to the authority group, wherein the authority group is one of a plurality of authority groups to which authority to at least one command from a plurality of commands is allocated, and the server that belongs to the authority group can have authority to the at least one command that is allocated to the authority group.

Description

Authorization authentication method, authorization request method, and device for the command on the server

The present invention relates to a method for authenticating authority for a node of a server and an apparatus therefor, and more particularly, to a method for a terminal authenticating authority of a server and a terminal performing the same.

In general, Device Management (DM) technology is a technology that allows a device management server to change the configuration of a device by remotely controlling values of variables or objects stored in a specific device in an effective manner. The device management technology is being developed as an international standard based on SynchML Data Synchronisation, which was written by the SyncML Initiative (Synchronization Markup Language) Forum at the Open Mobile Alliance (OMA), and is already being developed by other standards bodies and operators worldwide. It is accepted as the management technology standard. The OMA device management technology is a standard that supports the most diverse functions compared to other device management technologies. The device management protocol standard, the device management document presentation standard, a binding protocol and a transport protocol, and a device management tree And a standard for a device management node, a standard for a device description framework (DDF), a standard for notification, and the like.

This device management is performed by the device management server (DMS) sending a command for a management object (MO) existing inside the device to the device, and the device management client (DMC) of the device performs the command. Can be. The DMC corresponds to an entity mounted in the device and receiving from the DMS. The MO is logically connected to a management tree (or tree) existing within the device or a node of the tree. Accordingly, the device management server may control a MO, or a tree or node associated with the MO, that is the target of the command through a command to the MO. The MO generally exists in a database of the device, and the device management server may access the MO through the URI of the tree or node to instruct a management command.

Hereinafter, the background art related to the present invention will be described.

장치 관리(Device Management)Device Management

Device Management (DM) refers to managing device configuration and other managed objects of devices from the perspective of various Management Authorities. Device management includes sequential updates of constantly persisting information in devices, retrieval of management information from devices, and processing of events and alarms generated by devices, but which sets initial configuration information within devices. Management of the Device configuration and other managed objects of Devices from the point of view of the various Management Authorities.Device Management includes, but is not restricted to setting initial configuration information in Devices, subsequent updates of persistent information in Devices , retrieval of management information from Devices and processing events and alarms generated by Devices.)

관리 트리(Management Tree)Management Tree

The management tree is an interface for the management server to interact with the DM client, such as by storing values in or retrieving values from the management tree and by manipulating the attributes of the management tree, such as an access control list (ACL). The interface by which the management server interacts with the client, eg by storing and retrieving values from it and by manipulating the properties of it, for example the access control lists.) In this specification, a management tree interacts with a device management tree or a DM tree. It may be referred to interchangeably.

MO(관리 객체; Management Object)Management Object (MO)

A management object is a subtree of a management tree that is intended to be a set of nodes (sometimes alone) that are related to each other in some way. For example, ./DevInfo nodes may form a managed object. A Management Object is a subtree of the Management Tree which is intended to be a (possibly singleton) collection of Nodes which are related in some way.For example, the ./DevInfo Nodes form a Management Object.A simple Management Object may consist of one single Node.)

DM Server 또는 DMS(Device Management Server)DM Server or Device Management Server (DMS)

The DM server or DMS may be a conceptual software component in a device management infrastructure that conforms to the OMA Device Management Enabler static conformance requirements specified for the DM server or the DMS. The DM server or the DMS may serve as an endpoint of a DM client-server protocol and a DM server-server interface. (An abstract software component in a deployed Device Management infrastructure that conforms to the OMA Device Management Enabler static conformance requirements specified for DM Servers.It serves as an end-point of the DM Client-Server Protocols and DM Server-Server Interface).

In addition, in the present specification, the DM server or the DMS may be provided mounted in an apparatus, a device, a computer, etc. having a communication module, a processor module, and the like, and thus may be implemented as one device.

DM Client 또는 DMC(Device Management Client)DM Client or Device Management Client

The DM client or DMC may be a conceptual software component in device implementation that conforms to the OMA Device Management Enabler static conformance requirements specified for the DM client or the DMC. have. The DM server or the DMS may serve as an endpoint of a DM client-server protocol. (An abstract software component in a Device implementation that conforms to the OMA Device Management Enabler static conformance requirements specified for DM Clients.It serves as an end-point of the DM Client-Server Protocols.).

In addition, in the present specification, the DM client or the DMC may be provided as mounted in a device targeted for the DM having a communication module, a processor module, and the like, and thus may be implemented as one device.

ACL(Access Control List)ACL (Access Control List)

An ACL refers to a list of identifiers and access rights associated with each identifier.

노드(Node)Node

A node is a single element in the management tree. There can be two types of nodes in the management tree: interior nodes and leaf nodes. A node is a single element in a Management Tree.There can be two kinds of Nodes in a Management Tree: Interior Nodes and Leaf Nodes. The Format property of a Node provides information about whether a Node is a leaf or an Interior Node.).

인테리어 노드(Interior Node)Interior Node

An interior node may have child nodes, while an interior node may not have a value assigned to the node, that is, a node value. A Node that may have child Nodes, but cannot store any value.The Format property of an Interior Node is node.

리프 노드(Leaf Node)Leaf Node

Leaf nodes cannot have child nodes, but instead can have node values. A Node that can store a value, but cannot have child Nodes.The Format property of a Leaf Node is not node.

Therefore, all parent nodes must be interior nodes.

영구 노드(Permanent Node)Permanent Node

Persistent nodes are nodes whose DDF attribute scope is set to Permanent. If the node is not a permanent node, it is a dynamic node. A Node is permanent if the DDF property Scope is set to Permanent.If a Node is not permanent, it is dynamic.A permanent Node can never be deleted by the server.)

동적 노드(Dynamic Node)Dynamic Node

A node is dynamic if the DDF property Scope is set to Dynamic, or if the Scope property is is a node in which the DDF property scope is set to Dynamic or the DDF property scope is not specified. unspecified).

서버 식별자(Sever Identifier)Server Identifier

The server identifier refers to the OMA DM internal name for the DM server. The OMA DM internal name for a DM Server.A DM Server is associated with an existing Server Identifier in a device through OMA DM account.

ACL 속성 및 ACL 값ACL attributes and ACL values

All terminals managed by the DM (device management) protocol have one DM tree starting with a root node, and the DM protocol performs management commands to the terminals by manipulating each node of the DM tree. . For example, in order to install the downloaded software on the terminal, if a node called install matching the software is executed, the corresponding software can be installed. Each node can represent simple information such as numbers, or it can represent complex data such as picture data or log data. A node can also represent a single command, such as run, download, or the like.

Each node has a property that provides meta information about the node. One of these attributes is the runtime attribute, which is the attribute that can be used until the node is created and destroyed in the DM tree. These runtime attributes include ACL, Format, Name, Size, Title, TStamp, Type, and VerNo.

ACL (Access Control List) is an essential function that both terminal and server should implement in DM 1.3 protocol. An ACL specifies DM commands that a specific DM server can execute on a particular node, and any DM commands that are not specified cannot be performed. In other words, ACL means the permissions that a particular DM server is granted to a particular node. In the DM protocol, ACLs are assigned to the server identifier of the DM server, not URIs, IP addresses, or DM server certificates. This server identifier is used as an identifier to authenticate the DM server in the DM protocol. In addition, such an ACL may be provided as an ACL property and an ACL value assigned to the ACL property. Meanwhile, in the present specification, an ACL value may be interchangeably referred to as ACL information or information about an ACL. In the DM 1.3 protocol, all nodes are defined to have ACL attributes, and all nodes with ACL attributes are defined to have either empty or non-empty ACL values.

ACLs have unique properties that differ from other run-time properties, and this unique representative property is ACL inheritance. ACL inheritance is the concept that when a node in the DM tree does not have an ACL value, the ACL value for that node is taken from the ACL value of the parent node. If the parent node also does not have an ACL value, the ACL value is taken from the parent node of that parent node. Since the DM protocol specifies that the root node, the top node of the DM tree, must have an ACL value, the ACL value is necessarily inherited. Since this ACL inheritance is not performed for individual DM commands, but for the entire ACL value, the ACL inheritance from the parent node is made only when the ACL value is empty. In other words, if the ACL value of a node specifies only the Add permission, the Get permission that is not specified is not inherited.

In the DM protocol, the root node has "Add = ^* & Get = ^* " as the default value for ACL, where " ^* " is a wild card, which means any DM server. The DM server uses the Get command to get the ACL value. The Get command for "./NodeA/Node1?prop=ACL" gets the ACL value of ./NodeA/Node1. In addition, to change the ACL value, use the Replace command. If you change the value to "Add = DMS1 & Delete = DMS1 & Get = DMS1" by executing the Replace command on "./NodeA/Node1?prop=ACL", the ACL value is changed. Will change. In the DM protocol, it is not possible to change individual ACL entries, but to change the entire ACL value. Permissions for getting and modifying ACL values are also defined based on ACLs, with slightly different permissions for inter- and leaf nodes.

-Interior node If the node has Get and Replace permission, it has the authority to get and replace the ACL value of the node respectively. In addition, Replace permission means permission to replace ACL values of all child nodes.

-Leaf Node If the node has Get permission, it means the authority to get the value of the node. To get an ACL, the parent node must have Get permission.

Likewise, if a node has Replace permission, it means that the value of that node can be replaced. To replace an ACL, the parent node must have Replace permission.

If you have Replace permission on an interior node, this means that you can replace the ACL values of all the child nodes, as well as the interior node. Thus, if you have Replace permission on the root node, you can have any permission on any node in the DM tree. However, having the Replace permission on a parent node does not imply a specific permission, such as Get, on a child node, and the permission, such as Get, must be specified directly on the child node. Therefore, the ACL value should be modified before executing the command. Finally, the ACL value of all the nodes on the way to the node to be modified will be modified to modify the ACL value of the child node. This is inconvenient. In the DM protocol, when the parent or ancestor node has Replace permission, the DM protocol allows modification of the ACL value of the node without modifying the ACL value of the intermediate node.

When the DM server creates a new node through the Add command, the created node generally does not have an ACL value, so all permissions are inherited from the parent. However, if the created node is an interior node and the parent node does not have Replace permission, it is necessary to have sufficient authority to manage the node by setting the ACL value at the same time.

The syntax for representing ACL values is defined in [DM-TND]. An example of an ACL value is "Get = DMS1 & Replace = DMS1 & Delete = DMS2". Where DMS1 and DMS2 are server identifiers of the DM Server, and Get, Replace, and Delete are DM commands. Therefore, DMS1 can perform Get and Replace commands for the node, and DMS2 can perform Delete commands. Here, Get = DMS1, Replace = DMS1, and Delete = DMS2 are ACL-entry, respectively, and represent individual command authority of the DM server. In other words, an ACL value is a set of individual ACL-entries, and each node's ACL value may include at least one ACL entry.

DDF(Device Description Framework)Device Description Framework (DDF)

A DDF is a description of how to describe the management syntax and semantics for a particular device type. The DDF provides information on the MO, management function, and DM tree structure of the terminal.

DM 1.3 인증DM 1.3 certification

In DM 1.3, authentication is performed based on ACLs. DM authentication is done separately for each DM command. If the DM server sends a plurality of DM commands, the DM client (hereinafter referred to as DMC) performs authentication before executing individual commands, and as a result, only authorized DM commands are executed. In the present specification, an ACL value, which is information about an ACL, may be stored and provided in an ACL attribute, or may be stored and provided elsewhere (eg, a specific node in a DM tree). If it is stored somewhere other than an ACL attribute, the procedure for retrieving the ACL value may be different.

1 illustrates an authentication process for a DM command, which will be described in detail with respect to each step.

Step S110: The DMC receives a command targeting Node 1 from the DMS

The DMC receives a command for node 1 from a DM server (hereinafter referred to as DMS). Each DM command writes the address of the node targeted by the DM command in the <Target> element. Here, it is assumed that the command transmitted from the DMS is a DM command targeting node 1.

Step S120: The DMC retrieves the ACL value to authenticate the command

DMC gets the ACL value to perform authentication. The ACL value describes which DMS can execute which command and is required for authentication. In most cases, get the ACL value of node1.

The exception is that the authority to change (or replace) the ACL value of the leaf node is determined from the ACL of the parent node, so the ACL value of the parent node must be obtained. That is, node 1 is a leaf node, and in order to change the ACL value of node 1, it is determined as the ACL of the parent node of node 1, not node 1. In addition, to change the ACL value of the interior node, the authority only needs to be authorized in either the node or its parent node. Therefore, if node 1 is an interior node and wants to change the ACL value of node 1, the node 1 needs to have the corresponding authority. If you do not have one, you may have the privileges on the parent node of node 1. Therefore, the ACL of node 1 is taken first, and the ACL of the parent node of node 1 is used secondarily.

Step S130: Does the ACL value include an ACL entry 'command' = 'server ID'?

DMC checks the imported ACL value to see if the command is allowed. This can be done by checking that an ACL-entry named 'Command' = 'ServerID' is included in the ACL value. For example, if the DMS wants to execute the command Get, node1 must have an ACL-entry of Get = DMS. In exceptional cases, wildcards allow commands, which may indicate that all DMSs allow Get commands, such as Get = ^* .

Step S140: Authentication is Approved

If the command from the DMS is approved, the DMC executes the command and sends a result code.

Step S150: Authentication Failed

If the command of the DMS is not accepted, the DMC does not execute the command and sends an error code.

In the DM protocol, ACL values are described at the command-level. That is, if the DMS1 has the authority to execute the Get, Replace, Add command, the ACL value for expressing this is "Get = DMS1 & Replace = DMS1 & Add = DMS1". DMS1 cannot execute Exec or Delete command that is not described in ACL value. The first problem with how to describe ACL values at this command-level is that the ACL values for specifying permissions are too long. Since the DM protocol allows one terminal to be managed by a plurality of DMSs, an ACL value may be described for the plurality of DMSs. Therefore, when DMS1 and DMS2 have all rights to a specific interior node, the ACL value becomes "Get = DMS1 & Replace = DMS1 & Add = DMS1 & Delete = DMS1 & Get = DMS2 & Replace = DMS2 & Add = DMS2 & Delete = DMS2".

Another problem with the way ACLs are described at the command-level is to ignore dependencies between DM commands. As an example, assume that DMS1 only has Replace permission to change the node value of a leaf node. This is represented by the ACL value, resulting in "Replace = DMS1". Since DMS1 doesn't have Get permission, it can't get the node value of a node whose value can be changed. This is incorrectly a misconfiguration, and if you have the Replace privilege on a leaf node, of course you also have a Get privilege. In other words, if you have authority over a particular DM command, you should also be able to have authority over other DM commands that are essential for the performance of that specific DM command. However, because ACLs are described at the command-level, these dependencies cannot be automatically included.

Another problem is that a server that has permission to modify ACL values, and who can have any permission, needs to modify the ACL value once more to gain certain privileges. This is inefficient because it requires additional work to obtain privileges. For example, if an interior node has Replace permission, all sub-trees of the interior node can be replaced with another sub-tree, and the ACL value of the node can be changed. In other words, if you only have the Replace permission, the DMS can change the ACL value at will, and thus have any permission. However, even if you have the Replace privilege, it has no effect unless you manually add the necessary privileges to perform the Replace privilege. This is cumbersome in that even DMS with Replace permission can get permission only by modifying ACL value explicitly. For example, the ACL value "Replace = DMS1" of an interior node means that DMS1 can have any privileges on that interior node and its sub-trees, but to perform a Get command, the ACL value "Replace" = DMS1 & Get = DMS1 ".

In addition, node-level authorization control is applied in DM 1.3. Node-level authority control means that the access rights of the DMS can be set differently for each node. That is, the DMS can control the authority by separately setting the desired ACL value for each node. This is possible because every node has an ACL attribute. In exceptional cases, the ACL management authority of a leaf node can be set only at the interior node which is the parent, and thus the ACL management authority of the leaf nodes in siblings must be the same. The problem is that the DM protocol does not require this fine level of privilege control, which is node-level privilege control. That is, depending on the management object (MO), some MOs require only MO-level privilege control, some MOs require node-level privilege control, and some MOs negotiate a compromised privilege control level between the two. in need. However, the DM protocol consistently supports node-level authorization control by allowing every node to have an ACL attribute, which has the complexity of setting an ACL value to all nodes by default. The DM protocol attempts to solve some of this complexity through inheritance. In other words, nodes that do not have ACL values set can inherit ACL values from their parent nodes through inheritance, but the problem is that they basically support only node-level permission control. There is a hassle to go up and find the non-empty ACL value.

The fact that all nodes have ACL attributes is also a problem when deleting a DMS account. If the DMS account is deleted due to un-bootstrapping, etc., all the nodes in the DM tree must be searched and deleted before deleting the DMS account. Since this also includes the ACL value, you need to check the ACL value of all nodes and delete all ACL-entries that contain the server identifier of the DMS that you want to delete. This causes a heavy load every time a DMS account is deleted.

As described above, in the conventional DM protocol, the ACL value is described at the command-level, and the ACL value becomes excessively long, and other DM commands that are essential for performing the DM command in the ACL value are not described. There is a problem that can not be performed. In addition, the conventional DM protocol has a problem that all nodes have an ACL attribute regardless of the characteristics of the MO.

Technical problems to be achieved by the present invention are not limited to the above-mentioned technical problems, and other technical problems not mentioned above are apparent to those skilled in the art from the following detailed description. Can be understood.

According to an embodiment of the present invention, a method for performing authorization authentication for a DM command of a server with respect to a node of a device management (DM) tree stored in the terminal at the terminal is disclosed. Receiving a command for the node from the server; Retrieving an access control list (ACL) value for authorization authentication of the command of the server; And determining whether the server that sent the command belongs to the permission group for the command, based on the permission group included in the retrieved ACL value and the permission group information indicating a server belonging to the permission group. The authority group is one of a plurality of authority groups to which authority for at least one of a plurality of commands is assigned, and a server belonging to the authority group has authority to at least one command assigned to the authority group. Can be.

Advantageously, a subset of said plurality of rights groups may be assigned rights for at least one same command.

Preferably, each of the plurality of permission groups may be assigned a permission for commands selected by at least one command randomly selected from among a plurality of commands or any combination of the plurality of commands.

Preferably, each of the plurality of permission groups may be assigned a permission for at least one command selected according to a dependency relationship between the plurality of commands.

Preferably, when the authority group is assigned authority for a first command, the authority group may also be assigned authority for a second command that is essential for performing the first command.

Preferably, one authority group of the plurality of authority groups may be assigned authority for all commands assigned to another authority group.

Preferably, the authority for the command assigned to each of the plurality of authority groups may vary according to the type of the node.

Preferably, if the command for the node from the server is a command for modifying the ACL value of the node, if it is determined that the server that sent the command has authority for the command for modifying the ACL value, the The method may further include modifying an ACL value of the node to a new ACL value based on the authority group information.

In accordance with another embodiment of the present invention, a terminal configured to perform authorization authentication for a DM command of a server for a node of a device management (DM) tree is disclosed, and the command for the node from the server is disclosed. A communication module configured to receive; And retrieving an access control list (ACL) value required for authorization of the command of the server, and based on the authority group included in the retrieved ACL value and authority group information indicating a server belonging to the authority group. And a processor module configured to check whether the server that sent the command belongs to a permission group for the command, wherein the permission group includes a plurality of rights to which rights for at least one of a plurality of commands are assigned. One of the groups, and the server belonging to the authority group may have authority for at least one command assigned to the authority group.

Preferably, when the command for the node from the server is a command for modifying the ACL value of the node, if it is determined that the server has authority for the command for modifying the ACL value, the processor module is The ACL value of the node may be configured to be modified to a new ACL value based on the authority group information.

According to another embodiment of the present invention, a method for requesting authorization of a DM command of a server to a node of a device management (DM) tree stored in a terminal in a server is disclosed. The terminal causes the terminal to retrieve an access control list (ACL) value required for authorization of the command of the server, thereby indicating an authorization group included in the retrieved ACL value and a server belonging to the authorization group. Determining whether the server that sent the command belongs to a permission group for the command based on the information, wherein the permission group includes a plurality of commands to which permission for at least one of a plurality of commands is assigned; One of the authority groups and a server belonging to the authority group may have authority for at least one command assigned to the authority group.

In accordance with another embodiment of the present invention, a server configured to request authorization authentication for a DM command for a node of a Device Management (DM) tree stored in a terminal is disclosed, and to generate a command for the node. A configured processor module; And a communication module configured to transmit a command to the node to a terminal, wherein the command causes the terminal to retrieve an access control list (ACL) value required for authorization of the command of the server, On the basis of the authority group included in the retrieved ACL value and the authority group information indicating the server belonging to the authority group, it is determined whether the server that has sent the command belongs to the authority group for the command. One of a plurality of authority groups to which authority for at least one of a plurality of commands is assigned, and a server belonging to the authority group may have authority for at least one command assigned to the authority group.

The problem solving methods are only a part of embodiments of the present invention, and various embodiments reflecting the technical features of the present invention are based on the detailed description of the present invention described below by those skilled in the art. Can be derived and understood.

According to an embodiment of the present invention, the authority group may be configured to perform authority authentication for each node to effectively express the ACL value. In addition, by configuring the authority group in consideration of dependencies among the commands to be assigned to the authority group, authority for all commands necessary to perform a specific DM command may be assigned.

According to an embodiment of the present invention, it is possible to reduce the overload of the protocol by performing a flexible form of authority control by avoiding node-level authority control. In addition, even if the parent node or ancestor node of the corresponding node is not sequentially searched for inheritance of the ACL value, the ACL value can be obtained from the parent node or ancestor node having the ACL attribute without a separate search process. In addition, when deleting the account of the DMS, the ACL value can be searched only for nodes having an ACL attribute, without having to search the ACL values of all nodes.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included as part of the detailed description in order to provide a thorough understanding of the present invention, provide an embodiment of the present invention and together with the description, illustrate the technical idea of the present invention.

1 is a view showing an authentication process for a DM command according to the prior art;

2 is a diagram illustrating a syntax for expressing an ACL value based on a permission group according to an embodiment of the present invention;

3 is a diagram illustrating an example of expressing an ACL value of each node using an authority group according to an embodiment of the present invention;

4 is a flowchart illustrating a method for authenticating authority for a command of a server in a terminal through an authority group according to an embodiment of the present invention;

5 is a flowchart illustrating a method for authenticating authority for a command of a server in a terminal through an authority group according to an embodiment of the present invention;

6 is a diagram showing an example in which selective authority group setting control is applied according to an embodiment of the present invention;

7 is a flowchart illustrating a method of performing a specific command according to an embodiment of the present invention;

8 is a diagram illustrating an example of a MO tree;

9 is a diagram illustrating an example of applying selective authority group setting control for a specific MO according to an embodiment of the present invention;

FIG. 10 is a view showing a modified DDF of a specific MO for notifying a server of information regarding selective authority group setting according to an embodiment of the present invention; FIG.

11 is a diagram illustrating a proposed MO for notifying a server of information about an optional authority group setting according to an embodiment of the present invention;

FIG. 12 is a diagram illustrating an example for notifying a server of information on selective authority group setting using the MO of FIG. 11; FIG.

13 is a block diagram of an apparatus for implementing an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The following detailed description includes specific details in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art appreciates that the present invention may be practiced without these specific details.

In some instances, well-known structures and devices may be omitted or shown in block diagram form centering on the core functions of the structures and devices in order to avoid obscuring the concepts of the present invention. In addition, the same components will be described with the same reference numerals throughout the present specification.

The present invention relates to a device management client and a device management server or a device management procedure for performing device management for a specific management object (MO), and more particularly, each node of the MO of the device management server. It is to manage the authority for.

In the present specification, an apparatus may be used interchangeably with a terminal, and a DM command may be used interchangeably with a command, a DM server with a DMS or a server, and a DM client with a DMC or a terminal.

The present invention proposes an efficient authority authentication method and authority control method suitable for device management (DM).

제 1 실시예: 권한 그룹을 통한 권한 제어 및 인증 방법First Embodiment: Authorization Control and Authentication Method Through Authorization Group

The DM protocol provides a total of five DM commands. Each DM command is used to manipulate the DM tree, and its meaning depends on whether the DM command is targeting leaf nodes, interior nodes, or node attributes. Meaning of each DM command by object is as follows. The DM command does not have to be the following and other DM commands may be used.

Table 1

Get
Leaf node	Get the node value
Interior node	Get the list of child nodes
Property	Get the property value
Exec
Leaf node	Execute the node
Interior node	Execute the node
Property	N / A
Add
Interior node	Add a leaf node to the interior node, Add a sub-tree to the interior node
Leaf node, Property	N / A
Delete
Leaf node	Delete the leaf node
Interior node	Delete the interior node and the entire sub-tree
Property	N / A
Replace
Leaf node	Replace the node value
Interior node	Replace the entire sub-tree
Property	Replace the property value

The existing DM protocol described ACL values at the DM command-level and performed authorization. However, this method has various problems described above, and in order to solve this problem, the present invention introduces a right group concept and performs right authentication.

To create an authority group, first, consider the dependencies between the DM commands. A dependency relationship between DM commands means that if you have authority over one command, you also need authority over another command. For example, a DMS that has a Replace privilege on a leaf node will also need a Get privilege, so the Replace privilege depends on the Get privilege. Thus, privileges for these dependent commands can be configured to be assigned to one privilege group.

In addition to the dependencies between these DM commands, it is necessary to group the management authority based on the terminal management scenario. In the case of terminal management using the DM protocol, some groups have only read permission on the DM tree, and are intended only to check the current status of the terminal, such as checking the software installed on the terminal, rather than changing the terminal status. Can be. Another group cannot modify the currently installed software, but may have permission to add new software. Another group may have permission to modify existing content. This management authority grouping should be determined based on the terminal management scenario using the DM protocol.

As such, in grouping the management rights, at least one of the dependency relationship between the DM commands and the terminal management scenario may be considered. In view of these limitations, the present invention proposes a terminal management group and management authority assigned to each group as shown in Table 2 below. Of course, it is apparent to those skilled in the art that groups other than the group in Table 2 may be used.

TABLE 2

R (Read) group
DMS belonging to this group can read data from the node. Command authority that DMS in this group can execute is as follows.
Leaf node	Get
Interior node	Get
Property	Get
A (Add) group
DMS belonging to this group inherit all the command privileges of the R group. In addition, DMS belonging to this group can add data to the node, but cannot modify existing data. Additional command privileges that the DMS in this group can execute are:
Interior node	Add
Leaf node, Property	none
W (Write) group
DMS belonging to this group inherits all command privileges of group A. Also, DMS belonging to this group can modify existing data. Additional command privileges that the DMS in this group can execute are:
Leaf node	Replace, Delete
Interior node	Replace, Delete
Property	Replace (if applicable, some node attributes are static and do not allow Replace command)

In the groups of administrative rights proposed in Table 2, there is a dependency between the commands allowed for each group. In addition, the groups of management authority proposed in Table 2 depend on each other, and the group described later includes the management authority of the preceding group. Therefore, the DMS belonging to the R group can read data from the node, and the DMS belonging to the A group has the authority to create a new node in addition to the authority belonging to the R group. However, DMS belonging to group A does not have the authority to modify an existing node. The DMS belonging to the W group has all rights of group A, and additionally has the authority to modify data of an existing node. Based on this authority group, the types of commands (or allowed command rights) that can be executed for each group and for each target (leaf node, interior node, or property) are shown in Table 3 below.

TABLE 3

group	Command for leaf nodes	Command for interior node	Command for attribute
R	Get	Get	Get
A	Get	Get, Add	Get
W	Get, Replace, Delete	Get, Add, Delete, Replace	Get, Replace

In other words, a subset of the plurality of authority groups R, A, and W or two or more authority groups of the plurality of authority groups may be assigned authority for at least one same command. In Table 3, the entire set of the plurality of permission groups is all assigned the Get permission, but in other embodiments, only some of the entire permission groups may be assigned the permission for at least one same command. In addition, each of the plurality of authority groups may be assigned authority for at least one command. In addition, when a permission group (eg, a W group) is assigned a permission for a first command (eg, Replace), the one permission group is assigned to a second command (Get or Add), which is essential for performing the first command. Authority may be assigned.

The types of commands listed in Table 3 above may change depending on the types of commands supported by the DM protocol. For example, the following command configuration is also possible. In the following Table 4, the PUT command is the sum of Add and Replace in Table 3 above. If the PUT command targets an existing resource, it has the meaning corresponding to the Replace command. It can be said to have the meaning corresponding to Add. Table 4 below illustrates a privilege group in which a Put command is added instead of Add and Replace.

Table 4

group	Command for leaf nodes	Command for interior node	Command for attribute
R	Get	Get	Get
A	Get	Get, Put (URI for Put refers to a non-existing resource)	Get
W	Get, Delete, Put	Get, Delete, Put (URI for Put refers to an existing or non-existing resource)	Get, Put

As illustrated in Tables 2 to 4, the commands assigned to each permission group may be set to have a dependency relationship with each other. For example, according to the conventional DM protocol, the ACL value for allocating authority corresponding to group A of Table 3 to DMS1 for the interior node is expressed as "Get = DMS1 & Add = DMS1", but the DM protocol proposed by the present invention It can be expressed as "A = DMS1".

By classifying privilege groups according to this dependency, the ACL value for expressing command privileges for each node can be shortened or simplified. In addition, when grouping the authority group according to this dependency, the specific command authority is granted to the node, but the authority for other commands necessary to execute the specific command is not granted to the node, and thus cannot perform other necessary commands. It can solve the contradiction.

On the other hand, the command authority group may be arbitrarily classified without considering the dependency between the commands.

Table 5

group	Command for leaf nodes	Command for interior node	Command for attribute
One	Get	Get, Add	Get
2	Get, Delete	Get, Delete	Get
3	Get, Exec	Get	Get

In the example of Table 5, groups 1 to 3 have been assigned permissions for the Get + Add, Get + Delete, and Get + Exec commands, respectively. According to the conventional DM protocol, the ACL value for allocating the authority corresponding to the two groups in Table 5 to DMS1 for the leaf node is expressed as "Get = DMS1 & Delete = DMS1". According to the DM protocol proposed by the present invention, "2 = DMS1 ". Table 5 illustrates three cases in which two of the commands are combined, but more combinations are possible, and classifying the permission groups through any combination of these commands can effectively express the ACL value. There is an advantage.

We've introduced some privilege groups above, and if the DMS doesn't belong to any privilege group for a particular node, the DMS can't execute any commands on that node.

DM commands not mentioned in the authority groups illustrated above are treated as separate independent right groups. A typical independent authority is the authority for the Exec command, which is assigned to the DMS separately from the three authority groups. This is because the Exec privilege is hardly dependent on any other privileges (Get, Replace, Delete, Add). Table 6 below illustrates independent authority groups.

Table 6

group	Command for leaf nodes	Command for interior node	Command for attribute
E	Exec	Exec	N / A

For example, if the DMS1 belongs to the R group as "R = DMS1", it may be expressed as "RE = DMS1" that the DMS1 additionally has an E (Exec) right. In addition, those belonging to the W group may be expressed as "W = DMS1", and those in which DMS1 additionally has the E authority may be expressed as "WE = DMS1". That is, independent authority is assigned separately from the three authority groups described above.

Authorization groups illustrated in Tables 2 to 4 are divided into three groups of R, A, and W, and are expressed in the form of ACL values and assigned to nodes. That is, if a DMS1 has an authority granted to group A for an interior node and DMS2 has an authority granted to a group W, the ACL value of the node becomes "A = DMS1 & W = DMS2". This means that DMS1 has Get, Add permission on the data of the interior node and Get permission on the property of the interior node. In addition, DMS2 has Get, Add, Delete, Replace permission on the data of the interior node and Get, Replace permission on the property of the interior node. Displaying ACL values based on permission groups can be a very efficient way to express ACL values shortly. As an example, the existing DM 1.3 representation of ACL value equal to "A = DMS1 & W = DMS2" is quite long as "Get = DMS1 & Add = DMS1 & Get = DMS2 & Add = DMS2 & Replace = DMS2 & Delete = DMS2".

The method of expressing an ACL value based on the authority group proposed in the present invention follows the format of FIG. 2 similar to the format defined in [DM-TND].

The DM server identifier must appear only once in the ACL value and cannot be duplicated. If it overlaps with "R = DMS1 & W = DMS1", it is assumed that the scope of authority belongs to a larger authority group. The above form may also be expressed in other ways within the scope of the present invention.

ACL values were previously set to "Get = * & Add = *" so that all servers could add sub-trees as needed for the root node of the DM tree. Using the authority group proposed by the present invention, it can be expressed as "A = ^* " for the root node of the DM tree.

ACL inheritance in the same manner as in DM 1.3 can be applied to the present invention. In other words, for a node with an empty ACL value, the ACL value of that parent node is inherited, and if the ACL value of the parent node is also empty, the ACL of the first node whose ACL value is not empty is sequentially raised to the parent node of that parent node. The value is inherited. In DM 1.3, at least the ACL value must be defined for the root node of the DM tree. Therefore, even if the ACL value is empty for a node, if it is found to move up to the parent node in the DM tree, the ACL value will be found. You lose.

3 shows an example of expressing an ACL value using a permission group according to an embodiment of the present invention. A brief representation of SCOMO is given in part. Here, the node (/ SCOMO / Download / SW1 / PkgID) whose ACL value is not displayed has an ACL value of "R = ^* & WE = DMS1" inherited from its parent node SW1.

4 is a flowchart illustrating a method for authenticating authority for a command of a server in a terminal through an authority group according to an embodiment of the present invention. The terminal may receive a command for a specific node from the server (S410). The terminal may search for an ACL value required to authenticate the authority for the command of the server (S420). In most cases, the ACL value of the node may be obtained. However, as described in S120 of FIG. 1, the ACL value of the parent node of the node may be used (that is, inheritance). The terminal may determine whether the server has the authority for the command based on the authority group described in the ACL value and the information about the server belonging to the authority group (S430, S440). As described above, the ACL value of a node according to an embodiment of the present invention may describe information about an authorization group and a server belonging thereto (eg, W = DMS1). Accordingly, the terminal determines whether the server that transmits the command (hereinafter referred to as a "command originating server") is included in a specific authority group, and more specifically, the server identifier of the command originating server is the ACL value. It may be determined whether it is assigned to the authority group described in S430. For example, in the ACL value "W = DMS1", DMS1 is assigned to the W permission group. If the server identifier of the command originating server is not assigned to any authority group, it means that the command originating server does not have any authority, and the authentication ends in failure (S450-2). However, if an authority group is assigned to a server identifier of the command originating server, the terminal determines whether the command from the command originating server belongs to a command allowed in a specific authority group to which the command originating server belongs in the ACL value. It may be determined (S440). In other words, it may be determined whether the authority for the command from the command originating server is assigned to the authority group to which the command originating server belongs. If the determination result of S440 corresponds to "Yes (Y)", the authentication of the server is determined to be successful (S450-1). It is determined that the authentication for the server corresponding to the determination result of S440 as "no" (N) has failed (S450-2). In addition, the terminal may inform the server of the determination result of S440.

5 is a flowchart illustrating a method for authenticating a right to a command of a server in a terminal through a right group according to an embodiment of the present invention. 5 illustrates the overall authentication procedure, which will be described below in detail for each process.

The terminal may receive a command targeting a specific node from the DMS1 (S501). The terminal receives a command targeting a specific node from the DMS1. In the case of the Get command, since it is usually referred to in the same manner as "Get URI", the target node can be determined through the URI. Then, the terminal can retrieve the ACL value of the specific node (S502). In this case, the terminal may search for the ACL value of the parent node of the specific node, the description thereof is the same as described in S120 of FIG. Then, the terminal can determine whether the command from the DMS1 is a command that can be authenticated by the authority group (S503). Commands to get, add, and modify data of a node correspond to commands that can be authenticated by an authority group. The remaining commands correspond to commands that can be authenticated by independent privilege groups. In S503, if the command from the DMS1 can be authenticated by the authority group, the process proceeds to S505; otherwise, the process proceeds to S504.

In S504, the terminal may determine whether the DMS1 has the independent authority required to execute the command through the ACL value obtained in S502. For example, if the command sent by the DMS1 is an Exec, the ACL value checks whether the DMS1 has the same independent authority as the command Exec. If the DMS1 has the authority assigned to the E group like the ACL value " RE = DMS1 ", authentication is successful (S510), otherwise authentication ends with failure (S511).

In step S505, the terminal may determine whether the command sent by the DMS1 is a command for reading data. A representative example of a command to read such data is Get. If the command sent by the DMS1 reads data, the method proceeds to S507. Otherwise, the method proceeds to S506.

In step S506, the terminal may determine whether the command sent by the DMS1 is a command for adding new data. A typical example of a command to add such data is Add. If the command sent by the DMS1 is a command for adding new data, the method proceeds to S508. Otherwise, the method proceeds to S509.

In S507, since the command sent by the DMS1 is a command for reading data, authentication succeeds even if the DMS1 belongs to any of the R / A / W groups. The ACL value obtained in S502 may determine whether the DMS1 belongs to the R / A / W group. If the DMS1 belongs to one authority group of the R / A / W group, authentication is completed successfully (S510). Otherwise, authentication ends in failure (S511).

In S508, since the command sent by the DMS1 is a command for adding new data, authentication succeeds even if the DMS1 belongs to any of the A / W groups. The UE may determine whether the DMS1 belongs to the A / W group through the ACL value obtained in S502. If the DMS1 belongs to one authority group of the A / W group, authentication is completed successfully (S510). Otherwise, authentication ends in failure (S511).

In S509, since the determination result of the previous step S506 is "N", the command sent by the DMS1 corresponds to a command for modifying data. Therefore, DMS1 may belong to the W group to have authority for the command. The ACL value obtained in S502 may determine whether DMS1 belongs to the W group. If DMS1 belongs to the W group, authentication is successfully completed (S510). Otherwise, authentication ends in failure (S511).

S510 is a case where authentication is successful, and in this case, the terminal may perform a command from DMS1. S511 is a case where authentication fails, in this case, the terminal does not perform a command from DMS1. The authentication method described with reference to FIG. 5 may be implemented in other manners using the concept of an authority group and an independent authority group proposed in the embodiment of the present invention.

제 2 실시예: 선택적인 권한 설정 레벨 제어 방법Second Embodiment: Method for Selective Authorization Level Control

The second embodiment of the present invention proposes a method that can control the level of access control more efficiently. As mentioned earlier, in the past, the privilege control level was inefficient at the node-level. To solve this, make sure that all nodes do not have ACL attributes, and that only selected nodes have ACL attributes according to a particular method, and nodes without ACL attributes have their ACL attributes inherited through inheritance from their parent or ancestor nodes. Make a decision. Figure 6 illustrates this example, where the darkened node is the node specified to have an ACL attribute. Unspecified nodes cannot have ACL attributes, so ACL values cannot be set. Also, nodes with ACL attributes must have a non-empty ACL value.

In the second embodiment of the present invention, it is proposed that only a designated or selected node can have an ACL attribute, and a process of getting and replacing an ACL value will be described with reference to FIG. 7.

FIG. 7A illustrates a process of obtaining an ACL value, and FIG. 7B illustrates a process of modifying an ACL value. First, referring to FIG. 7 (a), in S701, a terminal or a DMC is requested to read or get an ACL value of a specific node. This process corresponding to S701 is performed when the DMS sends a command to the terminal or the DMC because the ACL value is required to authenticate the command. In other words, for example, when the DMS sends a Delete command for the specific node, a process corresponding to S701 may be performed to confirm (authenticate) whether the DMS has authority for the Delete command for the specific node. . In addition, the process of obtaining (reading) the ACL value may be performed when the DMS sends a command (Get) to read the ACL value.

In S702, the terminal may determine whether the specific node has an ACL attribute. In the conventional DM technology, since all nodes are set to have an ACL attribute, there is no need to perform a process as in S702. However, in the embodiment of the present invention related to FIG. 7, only some selected nodes are configured to have an ACL attribute. need. If the specific node has an ACL attribute, go to S704 to read the ACL value of the specific node. Otherwise, ACL inheritance of the particular node is determined by ACL inheritance.

Therefore, since the specific node does not have an ACL attribute because the specific node does not have an ACL attribute, the ACL value is obtained through ACL inheritance in S703. Among the ancestor nodes, the ACL value is inherited from the closest or nearest node to the particular node having the ACL attribute. Here, the "ancestor node" is a term widely used in the DM field, and the ancestor nodes of the specific node include a parent node of the specific node and a root node of the DM tree (ie, a parent node of the specific node). And between the root node of the DM tree). That is, it refers to all nodes located above and higher level of the specific node in the DM tree.

As mentioned earlier, only nodes with ACL attributes can have non-empty ACL values. Accordingly, in the specific node, the ACL value may be inherited from the node having the first ACL attribute in the direction of the root node of the DM tree to which the specific node belongs.

In the embodiment of the present invention, since a node having an ACL attribute is determined in advance, the terminal or the DM client does not need to climb up the parent node in sequence, and moves directly to a ancestor node that can inherit the ACL value. You can get the value. This can greatly reduce the process of obtaining an ACL value through ACL inheritance in the past. ACL inheritance is guaranteed because at least the root node of the DM tree must have an ACL attribute and an ACL value. Accordingly, since the specific node has an ACL value through ACL inheritance, the ACL value of the specific node is read in S704.

The process of replacing the ACL value described in FIG. 7 (b) is as follows. It is assumed here that the DMC that sent the command has permission to modify the ACL value. In S711, the terminal or the DM client may receive a command for changing the ACL value of the specific node from the DMS. In S712, the terminal may determine whether the specific node has an ACL attribute. If the specific node does not have an ACL attribute, it moves to S715 because the ACL value cannot be modified.

If it is determined in step S712 that the specific node has an ACL attribute, in step S713 the terminal determines whether the ACL value in the command sent by the DMS is a valid value, that is, whether the ACL value is not empty and is a correct value. You can judge. The correct ACL value means to conform to the ACL expression format described in FIG.

If it is determined in step S713 that the ACL value of the specific node is a valid value, in step S714 the terminal modifies the existing ACL value of the specific node with the ACL value sent by the DMS. Otherwise, the command of the DMS ends in failure, and the terminal may transmit an error code to the DMS.

According to the permission setting level control method, the ACL attribute is assigned only to a node requiring a separate permission setting, thereby efficiently controlling the level of access control. Further, according to the permission level control method, the process of inheriting the ACL value is greatly shortened, and even when deleting a DM account, only a node selected to have an ACL attribute is searched without having to search all nodes. It is much more efficient because you only need to delete (acl-entry).

Referring to FIG. 7 (a), the DMC obtains an ACL value. Therefore, if the DMS belongs to an R group or a group having a wider authority than the R node to which the authority for the Get command is assigned for a specific node that wants to obtain an ACL value, the DMS may send a Get command to the DMC to obtain the ACL value. When the DMS gets the ACL value, it can see what privileges the DMS, including itself, has for that node. At this time, it may be determined by referring to Tables 2 to 6 in order to confirm the authority granted to the other DMS. For example, if the DMS1 belongs to the W group for a specific interior node, the DMS1 may cause the DMC to perform commands of Get, Add, Delete, and Replace to the specific interior node.

Hereinafter, how to select a node having an ACL attribute will be described in detail. The DM protocol assumes that the terminal has a DM tree in order to manage the terminal. The DM tree is composed of several MOs such as FUMO [FUMO], SCOMO [SCOMO], DiagMon [DiagMon], and the like. The topmost node in the DM tree is called the root note ("."), And the FUMO ("./FUMO"), SCOMO ("./SCOMO"), and DiagMon ("./DiagMon" beneath the root node. The nodes in the ") are called MO root nodes. The MO root node usually refers to the highest node in each MO, and is distinguished from the general node by assigning a specific Management Object Identifier (MOID). That is, urn: oma: mo: oma-fumo: 1.0 is assigned as MOID to the MO root node of FUMO. The rules for selecting nodes for allocating ACL attributes in such a DM tree are as follows.

Rule 1: The root node (".") Of the DM tree must have an ACL attribute. The root node of the DM tree is usually assigned an ACL value of "A = ^* ".

Rule 2: The MO root node (the node to which the MOID is assigned) must have an ACL attribute.

Rule three

3-1: A node that starts from the MO root node and needs to have different access rights from the MO root node to child nodes of the MO root node has an ACL attribute.

3-2: Move to the next lower level (child nodes of the child node of the MO root node), among the nodes of that level that need to have access rights different from those of the parent node have ACL attributes.

3-3: Moving down one level, repeat steps 3-2 until you reach the last level (leaf node).

If the parent node does not have an ACL attribute, the ACL value is obtained through ACL inheritance.

9 illustrates an example of selecting a node having an ACL attribute by applying the above method to FUMO [FUMO]. Selecting a node having an ACL attribute by the above method may be performed at the stage of developing the MO standard, or may be made by negotiation between the terminal manufacturer and the communication operator in the process of mounting the MO on the terminal. Once a node with an ACL attribute is selected for each MO, the DMS must know which node has an ACL attribute. Information about a node having an ACL attribute among the nodes of the DM tree is referred to herein as "ACL attribute ownership information". Such ACL attribute ownership information may be delivered through the Device Description Framework (DDF), or may be delivered by configuring a separate MO that stores the corresponding information. In other words, the ACL attribute ownership information may be stored in a DDF or a separate MO. On the other hand, the DMS only knows which node has an ACL attribute and cannot dynamically create or delete an ACL attribute. That is, the DMS cannot delete an ACL attribute from a node having an ACL attribute, and cannot create a new ACL attribute on a node having no ACL attribute.

DDF describes management syntax and semantics supported by a specific terminal. It indicates which MO supports the terminal and which management function is included in which MO if the specific MO is supported. . DDF is usually expressed in XML format and provides static information for management syntax and semantics, making it a good place to describe which nodes have ACL attributes. FIG. 10 illustrates that the DDF of the FUMO is partially changed, so that only the root node of the FUMO has an ACL attribute as shown in FIG. 9. Referring to the DDF of the FUMO of FIG. 10, an <ACLProperty> element is added as true only to the root node of the FUMO. This means that only nodes with a true value of the <ACLProperty> element have ACL attributes. Such a DDF may be stored in a DMS or a DMC and may be downloaded via a URI.

In addition to using the DDF as described above, node information having an ACL attribute may be delivered to the DMS in the form of an MO (that is, ACLMO) as shown in FIG. 11. Description of each node in FIG. 11 is as follows. The node "ACLMO / <x> / MOID" represents the MOID of a particular MO. The node "ACLMO / <x> / ACLNode" stores information related to the node having an ACL attribute here for the MO referred to as MOID stored in the node value of node "ACLMO / <x> / MOID". The node "ACLMO / <x> / ACLNode / <x> / URI" is a URI in the form of a URI for the MO referred to as MOID stored in the node value of node "ACLMO / <x> / MOID". It is stored here.

FIG. 12 shows an actual ACLMO example of providing node information having ACL attributes for SCOMO and FUMO using the ACLMO of FIG. 11. The DMS can read the information by sending a Get command in the actual ACLMO example. However, the DMS cannot change the data of the actual ACLMO example. This method of using ACLMO has an advantage of transmitting node information having an ACL attribute to the DMS without having to modify the syntax of the DDF.

13 is a block diagram of an apparatus for implementing an embodiment of the present invention. The server and the terminal are configured to include a communication module and a processor module, respectively, and the communication module and the processor module are merely examples of the server and the terminal, and more modules may be added.

According to another embodiment of the present invention, the terminal 10 may be configured to perform authorization authentication for a command of the server 20. The terminal is a communication module 11 configured to receive a command for a node from the server and a processor module 12 configured to retrieve an access control list (ACL) value required for authorization of the command of the server. It may include. The node that is the target of the command of the server may or may not have an ACL value. If the node does not have an ACL value, it is necessary to get the ACL value from the ancestor node of the node through inheritance of the ACL value. In other words, the processor module may be configured to retrieve the ACL value required for authorization of the command of the server, that is, the ACL value of the ancestor node of the node through the ACL value or inheritance of the node.

Further, the processor module determines whether the server 20 that sent the command belongs to the authority group for the command based on the authority group included in the retrieved ACL value and the authority group information indicating the server belonging to the authority group. It may be configured to check whether or not. The processor module 12 may determine whether the server that sent the command has the authority for the command based on whether the server that sent the command belongs to the authority group for the command. In addition, if it is determined that the server that sent the command has the authority to the command, the processor module 12 may perform the command on the node.

The server 20 may instruct or transmit a command for a node of the MO to the terminal 10. The server includes a processor module 22 configured to generate a command for the node; And a communication module 21 configured to transmit a command for the node to the terminal. The command causes the terminal to retrieve an access control list (ACL) value required for authorization of the command of the server, and belongs to an authority group and the authority group included in the ACL value of the node. Based on the authority group information indicating the server, it may be determined whether the server belongs to the authority group. If it is determined that the server 20 belongs to the authority group for the command, that is, if it is determined that the server 20 has authority for the command, the terminal may perform the command on the node. .

The authority group is one of a plurality of authority groups to which authority for at least one of a plurality of commands is assigned, and a server belonging to the authority group may have authority for at least one command assigned to the authority group. have. The description of the rights group is described in more detail in the context described in connection with Tables 2-6.

A subset of the plurality of rights groups may be assigned rights for at least one same command. For example, R group and A group among R group, A group and W group are assigned authority for Get command. In addition, each of the plurality of authority groups may be assigned authority to commands selected by at least one command arbitrarily selected from among a plurality of commands or any combination of the plurality of commands.

In addition, each of the plurality of authority groups may be assigned authority for at least one command selected according to a dependency relationship between the plurality of commands. For example, in order to perform the Add command, since the Get command is necessary, the Add command is dependent on the Get command, and thus, the group A may be assigned permission for the Get command in addition to the Add command. In other words, if the authority group is assigned authority for the first command, the authority group may also be assigned authority for the second command that is necessary for performing the first command. Here, applying the foregoing description, it can be seen that the first command depends on the second command.

In addition, one authority group of the plurality of authority groups may be assigned authority for all commands assigned to another authority group. For example, the W group may be assigned authority for all commands assigned to the A group. This is because all the commands assigned to group A are necessary to carry out all the commands assigned to group W, which is included in the above dependency on each command.

Also, the authority for the command assigned to each of the plurality of authority groups is different depending on the type of the node. It has been described above that the node includes an interior node and a leaf node. As shown in Tables 3 to 5, it can be confirmed that the authority is different depending on the type of each node.

According to another embodiment of the present invention, the terminal 10 may be configured to perform a DM command for a node of a device management (DM) tree of a server. Here, the node may be configured to have a non-empty ACL value with an ACL attribute and to have no ACL value with no ACL attribute. The terminal includes a communication module (11) configured to receive a DM command for the node from the server; And determining whether the node has an ACL attribute and, if the node does not have an ACL attribute, determines a node that can inherit an ACL value to the node based on ACL attribute ownership information, and inherits from the determined node. It may include a processor module 12 configured to bring the ACL value of the determined node through. Nodes of the DM tree are selectively configured to have an ACL attribute, and the ACL attribute ownership information may include information about a node having an ACL attribute among the nodes of the DM tree.

The processor module is a node capable of inheriting an ACL value to the node, and determines a ancestor node having an ACL attribute closest to the node in the DM tree by using information about a selected node having the ACL attribute. It can be configured to.

The ACL attribute ownership information may indicate that an ACL attribute has been selectively assigned to some nodes of all nodes, and the ACL attribute ownership information may include a node that needs to be assigned a different authority from a parent node among the nodes of the DM tree. It can indicate that it has an ACL attribute. In addition, the ACL attribute ownership information indicates that a root node of the DM tree and a root node of a Management Object (MO) of the DM tree must have an ACL attribute, and it is a child of the root node of the MO. Nodes in the level that need to be assigned different permissions than the parent node may indicate that they have ACL attributes. The ACL attribute ownership information may be stored in a device description framework (DDF) of the terminal or a separate management object (MO) of the terminal.

Further, when a DM command for deleting an account of the server is received, the processor has an ACL attribute in the DM tree based on ACL attribute ownership information or using information about a selected node having the ACL attribute. May be configured to delete an ACL entry associated with the identifier of the server from an ACL value of the existing node. Meanwhile, the DM command for deleting the account of the server may be generated by the terminal itself according to a condition set in the terminal.

The server may delete the DM account using the Delete command. Before the server deletes the DM account, the server conventionally allows the terminal or the DM client in the terminal to check all nodes of the DM tree one by one to see if there is an identifier (ID) of the server to be deleted in the ACL value. However, in one embodiment of the present invention, an ACL attribute is selectively assigned to a node in the DM tree, and a node having the ACL attribute is set to have a non-empty ACL value, and this information is stored as ACL attribute ownership information. Only nodes with can check if there is an identifier (ID) of the server to be deleted in the ACL value. Accordingly, the server causes the terminal or the DM client in the terminal to perform the check only on nodes having an ACL attribute based on the ACL attribute ownership information to delete the ACL value associated with the ID of the server to be deleted. For example, if the DM account deletion command for DMS1 is, if the ACL value of node A is "Get = DMS1 & Replace = DMS1 & Get = DMS2", the ACL entry associated with the DMS1, that is, "Get = DMS1 & Replace = DMS1", is deleted from the ACL value. Thus, the ACL value of Node A is "Get = DMS2".

The present invention has been proposed to solve the problem of DM 1.3. Through embodiments of the present invention, an authorization group is configured to perform authorization authentication, and the authorization group may be configured in consideration of a dependency relationship between DM commands or arbitrarily. In consideration of the dependency between DM commands, the lower authority group has a wider scope of authority, and may be configured to include the authority of the upper authority group. That is, the authority for the commands assigned to the lower authority group depends on the authority for the commands assigned to the upper authority group, and since it is included, the dependency between DM commands can be considered. For example, in order for a DMS to have Replace permission on a particular leaf node, it must belong to the W group, and since the W group naturally includes all the rights of the R group, it also automatically has the Get permission.

In addition, according to an embodiment of the present invention, when the ACL value is expressed by using the authority group and the independent authority group, the ACL value may be represented more effectively. In DM 1.3, the authority for all commands of the DM server (SvrA) on the leaf node is expressed by the ACL value "Get = SvrA & Delete = SvrA & Replace = SvrA & Exec = SvrA". This is much more efficient since it can be simply abbreviated to "WE = SvrA" when expressed using the rights group of the present invention. Also, if the ACL value is expressed in DM 1.3 for a plurality of DMSs (SvrA and SvrB), "Get = SvrA & Add = SvrA & Delete = SvrA & Replace = SvrA & Exec = SvrA & Get = SvrB & Add = SvrB & Delete = SvrB & Replace = SvrB & Exec = SvrB" Although expressed as follows, it can be expressed simply and briefly as "WE = SvrA & WE = SvrB" when expressed using an authority group according to the present invention.

In addition, in DM 1.x, all nodes have ACL attributes, so node-level permission control has been applied uniformly. However, such detailed authority control is unnecessary in actual device management (DM), resulting in protocol overload. If a node is selected by the method proposed in the present invention and an ACL attribute is assigned to only the selected node, the authority control level can be controlled, thereby enabling the terminal to be managed more efficiently. That is, an MO such as FUMO [FUMO] needs to assign an ACL attribute only to the root node of the MO, and in the case of SCOMO [SCOMO], selects a node and assigns an ACL attribute as shown in FIG. 6.

DM 1.x also used an empty ACL value for ACL inheritance. In other words, if the ACL value is empty, the method inherits the ACL value from the parent node. If the parent parent node's ACL value is also empty, it must go up to its parent node and find the ancestor node with the non-empty ACL value. This is inefficient because you have to go up to the parent node one after the other for ACL inheritance. Using the present invention, a node having an ACL attribute is preselected in a specific manner, and a non-empty ACL value is assigned to the selected node. In addition, the information about the selected node having such an ACL attribute may be delivered to the DMS through a separate MO such as DDF or ACLMO. DMC can inherit ACL values much more efficiently because it can go directly to the node that has the ACL attribute and get the ACL value instead of following the parent node in turn for ACL inheritance.

When the DM account of a specific DMS is deleted, all the nodes of the DM tree should be found and deleted the ACL-entry associated with the DMS to be deleted. This is because DM 1.3 allowed all nodes to have ACL attributes. According to the present invention, selecting a node having an ACL attribute in a specific manner is much more effective because the deletion of the ACL-entry only needs to be performed on the node selected to have the ACL attribute. For example, in the case of FUMO [FUMO], since the ACL attribute needs to be assigned only to the root node of the MO, there is an advantage that the target node can be greatly reduced from 11 to one.

The detailed description of the preferred embodiments of the invention disclosed as described above is provided to enable those skilled in the art to implement and practice the invention. Although the above has been described with reference to preferred embodiments of the present invention, those skilled in the art will variously modify and change the present invention without departing from the spirit and scope of the invention as set forth in the claims below. I can understand that you can. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Embodiments of the invention may be used in a device management system, in a server, terminal, client device or other device.

Claims

A method for performing authorization authentication for a DM command of a server to a node of a device management (DM) tree stored in the terminal, in the terminal,

Receiving a command for the node from the server;

Retrieving an access control list (ACL) value for authorization authentication of the command of the server; And

Determining whether the server that sent the command belongs to the permission group for the command based on the permission group included in the retrieved ACL value and the permission group information indicating a server belonging to the permission group;

The authority group is one of a plurality of authority groups to which authority for at least one of a plurality of commands is assigned, and a server belonging to the authority group has authority for at least one command assigned to the authority group, Authentication method for the command.
The method of claim 1, wherein a subset of the plurality of rights groups is assigned rights for at least one same command.
The method of claim 1, wherein each of the plurality of permission groups is assigned a permission for commands selected with at least one command randomly selected from among a plurality of commands or any combination of the plurality of commands.
The method of claim 1, wherein each of the plurality of permission groups is assigned a permission for at least one command selected according to a dependency between the plurality of commands.
The method of claim 1, wherein if the authority group is assigned authority for a first command, the authority group is also assigned authority for a second command that is necessary to perform the first command. .
The method of claim 1, wherein one of the plurality of permission groups is assigned a permission for all commands assigned to another permission group.
The method of claim 1, wherein the authority for the command assigned to each of the plurality of authority groups is different depending on the type of the node.
The method of claim 1, wherein the command for a node from the server is a command for modifying an ACL value of the node.

If it is determined that the server originating the command has authority to the command for modifying the ACL value, modifying the ACL value of the node to a new ACL value based on the authority group information. Authorization authentication method.
A terminal configured to perform authorization authentication for a DM command of a server to a node of a device management (DM) tree.

A communication module configured to receive a command for the node from the server; And

Retrieving an access control list (ACL) value required for authorization of the command of the server, and based on authorization group included in the retrieved ACL value and authorization group information indicating a server belonging to the authorization group, A processor module configured to check whether the server that sent the command belongs to a permission group for the command,

The authority group is one of a plurality of authority groups to which authority for at least one of a plurality of commands is assigned, and a server belonging to the authority group has authority for at least one command assigned to the authority group, Terminal.
10. The terminal of claim 9, wherein a subset of the plurality of rights groups is assigned rights for at least one same command.
10. The terminal of claim 9, wherein each of the plurality of permission groups is assigned rights for commands selected with at least one command randomly selected from among a plurality of commands or any combination of the plurality of commands.
10. The terminal of claim 9, wherein each of the plurality of permission groups is assigned a permission for at least one command selected according to a dependency between a plurality of commands.
10. The terminal of claim 9, wherein, if the authority group is assigned authority for a first command, the authority group is also assigned authority for a second command that is essential for performing the first command.
The terminal of claim 9, wherein one of the plurality of authority groups is assigned authority for all commands assigned to another authority group.
The terminal of claim 9, wherein a right to a command assigned to each of the plurality of rights groups is different according to a type of the node.
10. The method of claim 9 wherein the command for a node from the server is a command for modifying an ACL value of the node.

And if it is determined that the server has authority to the command for modifying the ACL value, the processor module is configured to modify the ACL value of the node to a new ACL value based on the authority group information.
A method for requesting authorization of a DM command of a server from a server to a node of a device management (DM) tree stored in a terminal, the method comprising:

The terminal causes the terminal to retrieve an access control list (ACL) value required for authorization of the command of the server, thereby indicating an authorization group included in the retrieved ACL value and a server belonging to the authorization group. Determining whether the server that sent the command belongs to an authority group for the command based on the information;

The authority group is one of a plurality of authority groups to which authority for at least one of a plurality of commands is assigned, and a server belonging to the authority group has authority for at least one command assigned to the authority group, How to request authorization for a command.
A server configured to request authorization of a DM command for a node of a device management (DM) tree stored in a terminal.

A processor module configured to generate instructions for the node; And

Including a communication module configured to transmit a command for the node to the terminal,

The command causes the terminal to retrieve an access control list (ACL) value required for authorization of the command of the server, and indicates an authorization group included in the retrieved ACL value and a server belonging to the authorization group. Determine whether the server that sent the command belongs to a permission group for the command based on the permission group information,

The authority group is one of a plurality of authority groups to which authority for at least one of a plurality of commands is assigned, and a server belonging to the authority group has authority for at least one command assigned to the authority group, server.