WO2013022319A2 - Procédé d'authentification d'une autorité à commander un serveur, procédé de demande d'authentification de l'autorité, et dispositif pour celui-ci - Google Patents

Procédé d'authentification d'une autorité à commander un serveur, procédé de demande d'authentification de l'autorité, et dispositif pour celui-ci Download PDF

Info

Publication number
WO2013022319A2
WO2013022319A2 PCT/KR2012/006408 KR2012006408W WO2013022319A2 WO 2013022319 A2 WO2013022319 A2 WO 2013022319A2 KR 2012006408 W KR2012006408 W KR 2012006408W WO 2013022319 A2 WO2013022319 A2 WO 2013022319A2
Authority
WO
WIPO (PCT)
Prior art keywords
command
authority
node
acl
group
Prior art date
Application number
PCT/KR2012/006408
Other languages
English (en)
Korean (ko)
Other versions
WO2013022319A3 (fr
Inventor
박승규
김성윤
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2013022319A2 publication Critical patent/WO2013022319A2/fr
Publication of WO2013022319A3 publication Critical patent/WO2013022319A3/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • 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.
  • 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.
  • 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.
  • DDF device description framework
  • 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.
  • 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.
  • Device Management 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.
  • 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.
  • 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).
  • ACL access control list
  • a management tree interacts with a device management tree or a DM tree. It may be referred to interchangeably.
  • 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.
  • ./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.
  • the ./DevInfo Nodes form a Management Object.
  • a simple Management Object may consist of one single Node.
  • DMS Device Management Server
  • 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).
  • 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.
  • 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.).
  • 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
  • An ACL refers to a list of identifiers and access rights associated with each identifier.
  • 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.).
  • 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.
  • the Format property of an Interior Node is node.
  • Leaf nodes cannot have child nodes, but instead can have node values.
  • the Format property of a Leaf Node is not 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.)
  • 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).
  • the server identifier refers to the OMA DM internal name for the DM server.
  • a DM Server is associated with an existing Server Identifier in a device through OMA DM account.
  • 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. .
  • the DM protocol performs management commands to the terminals by manipulating each node of the DM tree.
  • the DM protocol performs management commands to the terminals by manipulating each node of the DM tree.
  • the DM protocol performs management commands to the terminals by manipulating each node of the DM tree.
  • 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.
  • runtime attributes include ACL, Format, Name, Size, Title, TStamp, Type, and VerNo.
  • ACL Access Control List
  • 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.
  • ACL means the permissions that a particular DM server is granted to a particular node.
  • 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.
  • such an ACL may be provided as an ACL property and an ACL value assigned to the ACL property.
  • an ACL value may be interchangeably referred to as ACL information or information about an ACL.
  • ACL information may be interchangeably referred to as ACL information or information about an ACL.
  • 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.
  • the DM server uses the Get command to get the ACL value.
  • 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.
  • Replace permission means permission to replace ACL values of all child nodes.
  • the node has Get permission, it means the authority to get the value of the node.
  • the parent node To get an ACL, the parent node must have Get permission.
  • a node has Replace permission, it means that the value of that node can be replaced.
  • the parent node must have Replace permission.
  • the created 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.
  • 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.
  • 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
  • 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 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.
  • 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.
  • FIG. 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).
  • DMS DM server
  • Each DM command writes the address of the node targeted by the DM command in the ⁇ Target> element.
  • 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 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.
  • 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 S140 Authentication is Approved
  • the DMC executes the command and sends a result code.
  • Step S150 Authentication Failed
  • the DMC does not execute the command and sends an error code.
  • 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.
  • ACLs are described at the command-level.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the conventional DM protocol has a problem that all nodes have an ACL attribute regardless of the characteristics of the MO.
  • 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.
  • 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.
  • a subset of said plurality of rights groups may be assigned rights for at least one same command.
  • 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.
  • 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.
  • the authority group 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.
  • one authority group of the plurality of authority groups may be assigned authority for all commands assigned to another authority group.
  • the authority for the command assigned to each of the plurality of authority groups may vary according to the type of the node.
  • the The method may further include modifying an ACL value of the node to a new ACL value based on the authority group information.
  • 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.
  • 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.
  • a subset of said plurality of rights groups may be assigned rights for at least one same command.
  • 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.
  • 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.
  • the authority group 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.
  • one authority group of the plurality of authority groups may be assigned authority for all commands assigned to another authority group.
  • the authority for the command assigned to each of the plurality of authority groups may vary according to the type of the node.
  • 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.
  • 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.
  • ACL access control list
  • 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.
  • a server configured to request authorization authentication for a DM command for a node of a Device Management (DM) tree stored in a terminal, and to generate a command for the node.
  • a configured processor 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.
  • ACL access control list
  • 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 authority group may be configured to perform authority authentication for each node to effectively express the ACL value.
  • authority group 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.
  • 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.
  • the ACL value can be obtained from the parent node or ancestor node having the ACL attribute without a separate search process.
  • the ACL value can be searched only for nodes having an ACL attribute, without having to search the ACL values of all nodes.
  • FIG. 1 is a view showing an authentication process for a DM command according to the prior art
  • FIG. 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
  • FIG. 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
  • FIG. 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
  • FIG. 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
  • FIG. 6 is a diagram showing an example in which selective authority group setting control is applied according to an embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating a method of performing a specific command according to an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating an example of a MO tree
  • FIG. 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.
  • FIG. 13 is a block diagram of an apparatus for implementing an embodiment of the present invention.
  • 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.
  • MO management object
  • an apparatus may be used interchangeably with a terminal
  • 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).
  • DM device management
  • 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.
  • 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.
  • 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.
  • the present invention proposes a terminal management group and management authority assigned to each group as shown in Table 2 below.
  • Table 2 below.
  • the groups of administrative rights proposed in Table 2 there is a dependency between the commands allowed for each group.
  • 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.
  • the types of commands (or allowed command rights) that can be executed for each group and for each target are shown in Table 3 below.
  • 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.
  • 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.
  • each of the plurality of authority groups may be assigned authority for at least one command.
  • a permission group eg, a W group
  • 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.
  • 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
  • the commands assigned to each permission group may be set to have a dependency relationship with each other.
  • the ACL value for expressing command privileges for each node can be shortened or simplified.
  • 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.
  • the command authority group may be arbitrarily classified without considering the dependency between the commands.
  • 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.
  • RE DMS1
  • E Exec
  • 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 above form may also be expressed in other ways within the scope of the present invention.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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).
  • 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.
  • the target node can be determined through the URI.
  • the terminal can retrieve the ACL value of the specific node (S502).
  • 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.
  • 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.
  • the process proceeds to S505; otherwise, the process proceeds to S504.
  • 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.
  • 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.
  • 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).
  • 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).
  • DMS1 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.
  • the second embodiment of the present invention proposes a method that can control the level of access control more efficiently.
  • 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.
  • FIG. 7A illustrates a process of obtaining an ACL value
  • FIG. 7B illustrates a process of modifying an ACL value.
  • 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.
  • a process corresponding to S701 may be performed to confirm (authenticate) whether the DMS has authority for the Delete command for the specific node.
  • the process of obtaining (reading) the ACL value may be performed when the DMS sends a command (Get) to read the ACL value.
  • the terminal may determine whether the specific node has an ACL attribute.
  • the terminal may determine whether the specific node has an ACL attribute.
  • 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.
  • the ACL value is obtained through ACL inheritance in S703.
  • the ACL value is inherited from the closest or nearest node to the particular node having the ACL attribute.
  • 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.
  • 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.
  • the terminal or the DM client 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.
  • the terminal or the DM client may receive a command for changing the ACL value of the specific node from the DMS.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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 (".”)
  • the FUMO "./FUMO"
  • SCOMO SCOMO
  • 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.
  • MOID Management Object Identifier
  • Rule 1 The root node (".") Of the DM tree must have an ACL attribute.
  • 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.
  • the ACL value is obtained through ACL inheritance.
  • 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.
  • the ACL attribute ownership information may be stored in a DDF or a separate MO.
  • 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.
  • 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.
  • 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.
  • ACLMO that is, ACLMO
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. .
  • ACL access control list
  • 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.
  • R group and A group among R group, A group and W group are assigned authority for Get command.
  • 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.
  • 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.
  • the first command depends on the second command.
  • one authority group of the plurality of authority groups may be assigned authority for all commands assigned to another authority group.
  • 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.
  • 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.
  • the terminal 10 may be configured to perform a DM command for a node of a device management (DM) tree of a server.
  • 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.
  • 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.
  • DDF device description framework
  • MO management object
  • the processor 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.
  • 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.
  • the server 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.
  • ID an identifier
  • 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.
  • 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.
  • 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.
  • 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.
  • the ACL value when expressed by using the authority group and the independent authority group, the ACL value may be represented more effectively.
  • 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.
  • a node having an ACL attribute is preselected in a specific manner, and a non-empty ACL value is assigned to the selected node.
  • 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.
  • Embodiments of the invention may be used in a device management system, in a server, terminal, client device or other device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Computing Systems (AREA)
  • Small-Scale Networks (AREA)
  • Storage Device Security (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne un procédé permettant d'authentifier à partir d'un terminal une autorité sur une commande de gestion de dispositif (DM) d'un serveur par rapport à des nœuds d'une arborescence DM qui sont enregistrés sur le terminal. Le procédé consiste à recevoir la commande par rapport aux nœuds ; à récupérer depuis le serveur une valeur de liste de commandes d'accès (ACL) du nœud ; et à déterminer si le serveur a autorité sur la commande, sur la base d'informations sur un groupe authentifié qui est décrit sur la valeur ACL des nœuds, et sur le serveur qui appartient au groupe d'autorité, ce dernier faisant partie de plusieurs groupes d'autorité auxquels une autorité sur au moins une commande d'une pluralité de commandes est affectée, et le serveur qui appartient au groupe d'autorité peut avoir une autorité sur la ou les commandes affectées au groupe d'autorité.
PCT/KR2012/006408 2011-08-10 2012-08-10 Procédé d'authentification d'une autorité à commander un serveur, procédé de demande d'authentification de l'autorité, et dispositif pour celui-ci WO2013022319A2 (fr)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201161522229P 2011-08-10 2011-08-10
US61/522,229 2011-08-10
US201161562437P 2011-11-21 2011-11-21
US61/562,437 2011-11-21
US201261586846P 2012-01-16 2012-01-16
US61/586,846 2012-01-16
US201261665318P 2012-06-28 2012-06-28
US61/665,318 2012-06-28

Publications (2)

Publication Number Publication Date
WO2013022319A2 true WO2013022319A2 (fr) 2013-02-14
WO2013022319A3 WO2013022319A3 (fr) 2013-04-04

Family

ID=47669115

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/KR2012/006406 WO2013022317A2 (fr) 2011-08-10 2012-08-10 Procédé permettant d'exécuter une commande d'un serveur et appareil associé
PCT/KR2012/006408 WO2013022319A2 (fr) 2011-08-10 2012-08-10 Procédé d'authentification d'une autorité à commander un serveur, procédé de demande d'authentification de l'autorité, et dispositif pour celui-ci

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/006406 WO2013022317A2 (fr) 2011-08-10 2012-08-10 Procédé permettant d'exécuter une commande d'un serveur et appareil associé

Country Status (1)

Country Link
WO (2) WO2013022317A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014193166A1 (fr) * 2013-05-28 2014-12-04 엘지전자 주식회사 Passerelle et son procédé de commande

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050096047A (ko) * 2004-03-29 2005-10-05 유한회사 알파데이터링크시스템 사용자 계정 및 스케쥴링에 의한 디바이스 접근권한 제어장치 및 그 방법
US20060184530A1 (en) * 2005-02-11 2006-08-17 Samsung Electronics Co., Ltd. System and method for user access control to content in a network
WO2010043175A1 (fr) * 2008-10-14 2010-04-22 华为技术有限公司 Procédé et dispositif de gestion de terminal selon la commande des droits
WO2010055901A1 (fr) * 2008-11-14 2010-05-20 日本電気株式会社 Système, procédé et programme de traitement d'informations

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003280990A (ja) * 2002-03-22 2003-10-03 Ricoh Co Ltd 文書処理装置及び文書を管理するためのコンピュータプログラム
KR100731272B1 (ko) * 2005-05-20 2007-06-21 노키아 코포레이션 이동 통신 장치들을 위한 장치 관리 트리를 설정할 수 있는객체들을 정의하는 방법 및 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050096047A (ko) * 2004-03-29 2005-10-05 유한회사 알파데이터링크시스템 사용자 계정 및 스케쥴링에 의한 디바이스 접근권한 제어장치 및 그 방법
US20060184530A1 (en) * 2005-02-11 2006-08-17 Samsung Electronics Co., Ltd. System and method for user access control to content in a network
WO2010043175A1 (fr) * 2008-10-14 2010-04-22 华为技术有限公司 Procédé et dispositif de gestion de terminal selon la commande des droits
WO2010055901A1 (fr) * 2008-11-14 2010-05-20 日本電気株式会社 Système, procédé et programme de traitement d'informations

Also Published As

Publication number Publication date
WO2013022319A3 (fr) 2013-04-04
WO2013022317A3 (fr) 2013-06-20
WO2013022317A2 (fr) 2013-02-14

Similar Documents

Publication Publication Date Title
WO2012134080A2 (fr) Procédé et appareil pour la séparation afin de mettre à niveau un logiciel à distance dans une communication m2m
WO2013025085A2 (fr) Appareil et procédé permettant de prendre en charge un nuage de famille dans un système informatique en nuage
WO2016126021A1 (fr) Procédé et appareil de traitement de requête pour l'arrêt de réception de notification dans un système de communication sans fil
CN108768948B (zh) 一种访问权限管理方法、服务器及计算机可读存储介质
WO2016068548A1 (fr) Procédé de traitement d'un message de notification dans un système de communication sans fil et appareil associé
WO2016064235A2 (fr) Procédé de gestion d'une ressource enfant d'un membre d'un groupe dans un système de communication sans fil, et dispositif associé
WO2013176499A2 (fr) Procédé de contrôle et d'exécution d'une règle de politique et carte euicc
WO2016013200A1 (fr) Système de traitement d'informations, et procédé de gestion de ressources réseau
WO2013065915A1 (fr) Procédé d'interfonctionnement de confiance entre une région de confiance et une région non de confiance, procédé, serveur et terminal pour commander le téléchargement d'applications de confiance, et système de commande les appliquant
WO2021071032A1 (fr) Procédé et appareil de contrôle d'accès au dispositif pour l'internet des objets
JP5340041B2 (ja) アクセス制御システム、アクセス制御方法、及びプログラム
WO2016171401A1 (fr) Procédé et dispositif pour le partage d'un document à édition coopérative
WO2018101565A1 (fr) Structure de gestion de sécurité dans un environnement de virtualisation de réseau
WO2020167095A1 (fr) Procédé et appareil permettant d'enregistrer des entités de fonction de domaine de fournisseur d'api sur une entité de fonction de noyau capif
WO2016126023A1 (fr) Appareil de diffusion et procédé d'authentification de données de diffusion
EP2826014A1 (fr) Appareil et procédé permettant de garantir la confidentialité dans un système de partage de contenus
WO2012124999A2 (fr) Procédé de fourniture de ressources par un terminal, et procédé d'acquisition de ressources par un serveur
WO2013183944A1 (fr) Appareil et procédé de transmission et de réception de fichiers dans un dispositif universel
WO2013022319A2 (fr) Procédé d'authentification d'une autorité à commander un serveur, procédé de demande d'authentification de l'autorité, et dispositif pour celui-ci
WO2017082506A1 (fr) Procédé de traitement d'une demande d'arrêt de réception de notification dans un système de communication sans fil, et dispositif associé
WO2019194412A1 (fr) Appareil de réseau et son procédé de commande
WO2015002436A1 (fr) Procédé et appareil permettant d'optimiser un trajet de données dans un système de communications mobiles
WO2014035092A1 (fr) Procédé de gestion de fichier partagé et dispositif d'authentification d'abonné l'utilisant
JP2011180772A (ja) 機器管理システム、機器管理装置、及び機器設定方法
WO2012108678A2 (fr) Appareil et procédé de réglage de disposition relative à un partage de document

Legal Events

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

Ref document number: 12822677

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12822677

Country of ref document: EP

Kind code of ref document: A2