WO2014207554A2 - Method and apparatus for providing database access authorization - Google Patents

Method and apparatus for providing database access authorization Download PDF

Info

Publication number
WO2014207554A2
WO2014207554A2 PCT/IB2014/001529 IB2014001529W WO2014207554A2 WO 2014207554 A2 WO2014207554 A2 WO 2014207554A2 IB 2014001529 W IB2014001529 W IB 2014001529W WO 2014207554 A2 WO2014207554 A2 WO 2014207554A2
Authority
WO
WIPO (PCT)
Prior art keywords
access
request
data
control information
token
Prior art date
Application number
PCT/IB2014/001529
Other languages
French (fr)
Other versions
WO2014207554A3 (en
Inventor
Zhiyuan Hu
Qunying SUN
Zhigang Luo
Yonggen Wan
Original Assignee
Alcatel Lucent
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 Alcatel Lucent filed Critical Alcatel Lucent
Publication of WO2014207554A2 publication Critical patent/WO2014207554A2/en
Publication of WO2014207554A3 publication Critical patent/WO2014207554A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing 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/2141Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • This invention relates to the field of databases, especially to the technology of providing validation of database access authorization.
  • Fig. 1 illustrates the architecture of NoSQL database.
  • Client may be an user equipment (UE) or a 3 rd party application.
  • the NoSQL database system comprises USERDATA nodes: USERDATA_1, USERDATA_2, USERDATA_3, and a multiple-level of METADATA nodes: METADATA_1, METADATA_2, METAD ATA_3 , S UPER_METAD ATA . It shall be understood for the person skilled in the art that the number of each parts and of the levels are only for the purpose of illustration.
  • a single file may be split into blocks and the blocks are distributed in clusters.
  • cluster management there are two types of cluster management to support the embodiment of NoSQL databases. They are USERDATA node, which stores the data block(s) of the files; and METADATA node, which stores the metadata, with enumeration of data block(s) and a list of USERDATA in the cluster under the control of it, as shown in Fig. 1.
  • a METADATA node manages one or more USERDATA node. There may be several levels of METADATA node, i.e., SUPERJVIETADATA node and METADATA node.
  • METADATA node checks access permissions (e.g., read, write and delete) to those files according to the security policies after authenticating the user or 3rd party application.
  • access permissions e.g., read, write and delete
  • the object of the present invention is to provide a solution which provides authorizing validation of requests to access data to NoSQL databases or similar databases.
  • a security mechanism of validation of data access is provided to the NoSOL database or similar database by enforcing the authorizing validation of data access at an external data management layer or the relative application layer, which thereby enables declining any access of an unauthorized client.
  • a method for managing the data access comprises the following steps:
  • said method further comprises:
  • a method for providing data accesses comprises the following steps:
  • a data management apparatus for managing the data access which comprises:
  • a determining device for determining one or more data block locations based on the storage location(s);
  • an authentication device (202) for authenticating the request based on the storage location(s) and the access authorization
  • an authorization generating device (203) for generating a corresponding access authorization control information based on the determination that the authentication request is successful, the corresponding access authorization control information being based on the storage location(s) and access authorization when authentication is successful;
  • a data storage apparatus for providing data accesses comprising:
  • a second validation device (303) for validating the request for data access according to the access authorization control information extracted from the request for data access;
  • a access operating device for executing the corresponding access operations for the data block(s) to be accessed according to their storage location(s) and the access permission when validation is successful.
  • a database system for providing data access comprises one or more data management apparatus according to the third aspect of the invention and one or more data storage apparatus according to the fourth aspect of the invention.
  • the existing NoSQL databases or similar databases have two entities, METADATA Node and USERDATA Node. USERDATA could not do authorizing validation for data accesses from users, so that access control is not possible.
  • METADATA Node validates the request for storage location(s) and access authorization of users and generates a token and an access token validation code. Also, it sends access authorization control information, containing access token and access token validation code, to Client.
  • access authorization control information containing access token and access token validation code
  • Fig. 1 shows the architecture of NoSQL database.
  • Fig. 2 shows a application scenarios, based on an embodiment of this invention.
  • FIG. 3 shows the flow charts of the methods of providing authorizing validation for databases, based on an embodiment of this invention.
  • FIG. 4 shows the schematic diagram of a method that used to provide authorizing validation for database, based on an embodiment of this invention.
  • FIG. 5 shows schematic diagram of a device that provides authorizing validation for databases, based on an embodiment of this invention.
  • FIG. 6 shows schematic diagram of a device that provides authorizing validation for databases, based on another embodiment of this invention.
  • Fig. 2 shows an exemplary application scenario according to the present invention, which comprises Client UCD_Clientl, a METADATA node and an USERDATA node of a NoSQL database system or similar database system, wherein the METADATA node comprises a database management apparatus METDATA_1 and the USERDATA node comprises two data storage apparatuses USERDATA_1 and USERDATA_2.
  • FIG. 3 shows a flow chart of the method of providing authorization for access databases, based on an embodiment according to this invention. According to Fig. 3, also in connection with Fig. 2, detailed descriptions would be given as follow:
  • step S301 Clientl sends a request for storage location(s) and access authorization to the data management apparatus 2 for requesting the storage location(s) and access permission of data block(s) to be accessed, which is described by two examples as follow:
  • Example 1 is an user equipment (UE).
  • UE user equipment
  • Request_Authorization (user_name/user_id, user_credential, metadata_node_name, file_name/ file_id, ...)
  • Request_Authorization is the request for storage location(s) and access authorization.
  • user_name is the name of user
  • user_id is ID of user
  • user_credential is the authentication certificate of user, and may be a secret key or certificate of user;
  • metadata_node_name is the name for data management apparatus to which the request is to be send
  • file_name is the name of the file to be accessed
  • file_id is ID of the file to be accessed
  • Example 2 Clientl is a 3rd party application.
  • the format of request for storage location(s) and access authorization that 3rd party application sends to the data management apparatus is exemplary shown as follow:
  • Request_Authorization (application_name/application_id, application_credential, metadata_node_name, file_name/ file_id, user_authorization_grant, ) [0064] Wherein, Request_Authorization is the request for storage location.
  • application_name is the name of the 3rd application
  • application_id is ID of the 3rd applications
  • application_credential the authentication certificate of the 3rd application, and may be application secret key or certificate;
  • metadata_node_name is the name for data management apparatus to which the request is to be send.
  • file_name is the name of the file to be accessed
  • file_id is the ID of the file to be accessed
  • user_authorization_grant includes but not limited to Authorization Grant defined in RFC6749
  • step S302 the data management apparatus 2 authenticates the request based on the request for the storage location(s) and the access authorization, and generates a corresponding access authorization control information based on the determination that the authentication request is successful, the corresponding access authorization control information being based on the request for storage location(s) and access authorization.
  • the access authorization control information contains the access token, ID of the access token and the access token validation code.
  • the data management apparatus 2 may determine the storage location(s) of data block(s) to be accessed based on the request for storage location and access authorization either prior to or after the determination that the authentication of the request is successful.
  • Example 3 the access authorization control information has following format:
  • Access_Token ⁇ Token ID, Token, Token_UCD ⁇
  • Access_Token is access authorization control information
  • Token is a access token
  • Token ID is ID of access token
  • Token_UCD is access token validation code
  • the data management apparatus 2 generates the access token according to the information such as ID of file owner, IDs of data block(s), expiring information of authentication and information of data accesses method, and its format is exemplary shown as follow:
  • Token ⁇ ownerlD, [,applicationID] blockID, expirationln, access_methods ⁇
  • ownerlD is the ID of file owner
  • blockID is the ID of data block
  • expirationIN is the expiring information of authentication
  • access_method is the information of data accesses method, including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
  • applicationID is ID of application, and is optional. If a third-party application is to access the user information, applicationID is needed.
  • the data management apparatus 2 obtains access token validation code by hashing the generated access token, ID of the access token and USERDATA_key of data storage apparatus which store the data block(s) to be accessed.
  • the format of access token validation code is exemplary shown as follow:
  • Token_UCD HMAC (Token ID, Token, US ERD ATA_key )
  • USERDATA_key is the key of storage apparatus.
  • the data management apparatus 2 sends key of storage apparatus to the corresponding data storage apparatus.
  • all data storage apparatus belonging to one data management apparatus 2 share the same key of storage apparatus.
  • a plurality of data storage apparatus may have different keys of storage apparatus.
  • the key of storage apparatus could be fixed or, preferably, updated periodically according to UCD providers' policy.
  • step S303 the data management apparatus 2 sends authorization response to Client 1, which contains storage location(s) of data block(s) to be accessed and the generated corresponding access authorization control information, to Client 1.
  • Client 1 contains storage location(s) of data block(s) to be accessed and the generated corresponding access authorization control information, to Client 1.
  • the process of sending access authorization control information is explained by two examples as follows:
  • Example 4 Client 1 is a UE:
  • the data management apparatus 2 sends authorization response, which contains storage location(s) of data block(s) to be accessed and the corresponding access authorization control information, to Client 1.
  • authorization response contains storage location(s) of data block(s) to be accessed and the corresponding access authorization control information, to Client 1.
  • the format of authorization response is exemplary shown as follows:
  • Response_Authorization is the authorization response
  • list_of_blockIDs is the list of IDs of the data block(s) to be accessed
  • blocks_locations is storage location(s) of data block(s) to be accessed
  • Access_Token is the access authorization control information.
  • Example5 Client 1 is a 3rd party application:
  • the data management apparatus 2 sends an authorization response, which contains storage location(s) of data block(s) to be accessed and the corresponding access authorization control information, to Client 1.
  • the authorization response has following format:
  • Response_Authorization is the authorization response
  • list_of_blockIDs is the ID list of the data block(s) to be accessed
  • blocks_locations is storage location(s) information of data block(s) to be accessed
  • Access_Token is the access authorization control information.
  • refresh_token is optional and may be Refresh Token defined in RFC6794 .
  • step S304 after receiving authorization response from the data management apparatus 2, Client 1 sends a request for data access to the data storage apparatus 3 for requesting to access data block(s).
  • This request for data access contains storage location(s) and access authorization control information of the data block(s) to be accessed, extracted from the authorization response from data management apparatus 2. It is illustrated by the following examples:
  • Example 6 the format of request for data access sent by Clientl is exemplary shown as follows::
  • Request_Resource (ucd_client_name/ucd_client_id, blockID, Access_Token, 8) [00110] Wherein, Request_Resource is request for data access;
  • Ucd_client_name is the name of Client, wherein Client may be either an user or a 3 rd party application;
  • Ucd_client_id is the ID of Client, wherein Client may be either an user or a 3 rd party application;
  • BlockID is ID of the data block(s) to be accessed
  • Access_Toen is the corresponding access authorization control information.
  • step S305 after receiving the request for data access from Client 1, the data storage apparatus 3 obtains the storage location(s), access authorization control information and access permission of data block(s) to be accessed, from the request for data access.
  • step S306 the data storage apparatus 3 validate the request for data access from Client 1 according to the access authorization control information. The process of validation is explained by the following examples:
  • Example 7 in the above step S302, the data management apparatus 2 generates access authorization control information for the request for storage location(s) and access authorization from Client 1, which contains the access token, ID of the access token and first access token validation code obtained by hashing the access token, ID of the access token and the USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored.
  • the format of the first access token validation code is exemplary shown as follow:
  • Token_UCD HMAC (Token ID, Token, US ERD ATA_key )
  • Token_UCD is the first access token validation code
  • Token is the access token generated for the data management apparatus 2;
  • Token ID is ID of access token
  • USERDATA_key is the storage key for data storage apparatus
  • step S306 the data storage apparatus 3 obtains second access token validation code by using the same hash algorithm to hash the access token, ID of access token contained in the request for validation and the storage key apparatus USERDATA_key of data storage apparatus.
  • the format of second validation authorization code is exemplary shown as follow:
  • Token_UCD' HMAC (Token ID, Token, US ERD ATA_key ) [00125] wherein, Token_UCD' is the second access token validation code;
  • Token is the access token contained in the request for validation
  • Token ID is ID of access token
  • USERDATA_key is the storage key for the data storage apparatus
  • the validation of the validating request could be done by comparing the first access token validation code Token_UCD and second access token validation code Token_UCD' . If they are same, it could be determined that the validation is successful.
  • step S306 the data storage apparatus 3 could also verify whether the database management apparatus, from which the access token is issued, is trusted. Since only the date storage apparatus 3 and the database management apparatus, from which the access token is issued, share the key USERDATA_key with each other, if the data storage apparatus verifies the access authorization control information based on the shared key USERDATA_key, it could be determined that the database management apparatus is trusted. And, for example, the request for data access contains the identification of the data management apparatus that issues the access authorization control information, and the data storage apparatus 3 could extract the identification of the data management apparatus and compared it with a list of trusted data management apparatus. If it is found in the list, the validation is successful.
  • the data storage apparatus 3 executes the access operation to the data block(s) to be accessed according to storage location(s) of data block(s) and the corresponding access permission obtained from the access authorization control information from Client 1.
  • Those operations comprise, but not limited to, the operation of create, read, update, delete, delete, write, copy, replace, etc.
  • the request for data access from Client only includes Token ID of access token.
  • the data storage apparatus 3 sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the access permission corresponding to the Token ID.
  • the database management device 2 searches the corresponding access permission according to Token ID, then sends the searched access permission to the data storage apparatus 3.
  • step S302 the data management apparatus 2 generates access authorization control information and encrypt it with the key and the related encryption algorithm, which are known by itself and the data storage apparatus 3 under its management , then sends the authorization response containing the encrypted access authorization control information to Client 1.
  • step S305 the data storage apparatus 3 extracts the encrypted access authorization control information from the request for data access from Client 1, then decrypts it with the known key and related decryption algorithm so as to obtain the decrypted access authorization control information.
  • the transportations between Client 1 and data management apparatus 2 and between Client 1 and data storage apparatus 3 are all based on the TLS protocol.
  • Fig.4 shows a schematic diagram of a method that used to provide validation for access to the database, based on a preferred embodiment of this invention. According to Fig. 4, in connection with Fig. 2 and 3, the detailed descriptions about this preferred embodiment would be given as follow:
  • Step S401 to S405 are same as those of S301 to S305 as shown in the above embodiments described according to Fig.3.
  • the content of S301 to S305 are involved herein by reference.
  • step S406 the data storage apparatus 3 sends a request for validation to the data management apparatus 2 in order to request for validating the request for data access from Client 1.
  • the request for validation contains the obtained access authorization control information;
  • step S407 the data management apparatus 2 validate the request for validation after receiving it from the data storage apparatus 3. The process of validation is explained by the following example:
  • ExamplelO in step S402, the data management apparatus 2 generates access authorization control information for the request for storage location(s) and access authorization from Client 1, which contains the access token, ID of the access token and first access token validation code obtained by hashing the access token, ID of the access token and the storage key USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored.
  • the format of the first access token validation code is exemplary shown as follow:
  • Token_UCD HMAC (Token ID, Token, US ERD ATA_key )
  • Token_UCD is the first access token validation code(the 1st authorizing validation code);
  • Token is the access token generated by the data management apparatus 2;
  • Token ID is ID of the access token
  • USERDATA_key is the storage key for the data storage apparatus
  • step S407 the data management apparatus 2 obtains the second access token validation code by using the same hash algorithm to hash the access token, ID of access token contained in request for validation and the storage key USERDATA_key of data storage apparatus.
  • the format of second validation authorization code is exemplary shown as follow:
  • Token_UCD' HMAC (Token ID, Token, US ERD ATA_key )
  • Token_UCD' is second access token validation code
  • Token is the access token contained in the request for validation
  • Token ID is ID of the access token
  • USERDATA_key is the storage key for the data storage apparatus
  • the validation could be done by comparing the first access token validation code Token_UCD and the second access token validation code Token_UCD'. If they are same, it could be determined that the validation is successful.
  • step S408 the data management apparatus 2 sends message of successful validation to the data storage apparatus based on the determination that the validation of validating request is successful.
  • the data storage apparatus 3 when receiving message of successful validation from the data management apparatus 2, the data storage apparatus 3 could execute the access operations to the data block(s) to be accessed according to the storage location(s) of data block(s) and the corresponding access permission sent from Client 1. Those operations including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
  • the request for data access from Client only includes Token ID of access token.
  • the data storage apparatus 3 sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the access permission corresponding to the Token ID.
  • step S411 after receiving the request for access permission from the data storage apparatus 3, the database management device 2 searches the corresponding access permission according to Token ID, then sends the searched access permission to the data storage apparatus 3.
  • FIG. 5 shows a schematic diagram of system of providing authorization for access database according to an embodiment of the present invention, wherein the system comprise Client 1, the database management apparatus and the data storage apparatus. According to Fig. 5, also in connection with Fig. 2, the detailed description of embodiment would be given as follow:
  • step S301 Client 1 sends a request for storage location(s) and access authorization to the data management apparatus 2 for requesting the storage location(s) and access permission of data block(s) to be accessed, which is described by two examples as follow:
  • Clientl is an user equipment (UE).
  • UE user equipment
  • the format of request for storage location(s) and access authorization that UE sends to the data management apparatus is exemplary shown as follow:
  • Request_Authorization (user_name/user_id, user_credential, metadata_node_name, file_name/ file_id, 8)
  • Request_Authorization is the request for storage location(s) and access authorization.
  • user_name is the name of user
  • user_id is ID of user
  • user_credential is the authentication certificate of user, and may be a secret key or certificate of user;
  • metadata_node_name is the name for data management apparatus to which the request is to be send
  • file_name is the name of the file to be accessed
  • file_id is ID of the file to be accessed;
  • Clientl is 3rd party application.
  • the format of request for storage location(s) and access authorization that 3rd party application sends to the data management apparatus is exemplary shown as follow:
  • Request_Authorization is the request for storage location.
  • application_name is the name of the 3rd application
  • application_id is ID of the 3rd applications
  • application_credential the authentication certificate of the 3rd application, and may be application secret key or certificate;
  • metadata_node_name is the name for data management apparatus to which the request is to be send.
  • file_name is the name of the file to be accessed
  • file_id is the ID of the file to be accessed
  • user_authorization_grant includes but not limited to Authorization Grant defined in RFC6749
  • the authorization generating device 203 After the authentication is successful, the authorization generating device 203 generates a corresponding access authorization control information for the request for storage location(s) and access authorization.
  • the access authorization control information contains the access token, ID of the access token and the access token validation code.
  • the determination device (not shown) of data management apparatus 2 may determine the storage location(s) of data block(s) to be accessed based on the request for storage location and access authorization either prior to or after the determination that the authentication of the request is successful.
  • Access authorization control information has following format:
  • Access_Token ⁇ Token ID, Token, Token_UCD ⁇
  • Access_Token is access authorization control information
  • Token is a access token
  • Token ID is ID of the access token
  • Token_UCD is access token validation code
  • the authorization generating device 203 generates the access token according to the information such as ID of file owner, IDs of data block(s), expiring information of authentication and information of data accesses method, and its format is exemplary shown as follow:
  • Token ⁇ ownerlD, [,applicationID] blockID, expirationln, access_methods ⁇ [00194] Wherein, ownerlD is the ID of file owner;
  • blockID is the ID of data block
  • expirationIN is the expiring information of authentication
  • access_method is the information of data accesses method, including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
  • applicationID is ID of application, and is optional. If a third-party application is to access the user information, applicationID is needed
  • the authorization generating device 203 generates access token validation code by hashing the generated access token, ID of the access token and USERDATA_key of data storage apparatus which store the data block(s) to be accessed.
  • the format of access token validation code is exemplary shown as follow:
  • Token_UCD HMAC (Token ID, Token, US ERD ATA_key )
  • USERDATA_key is the key of storage apparatus.
  • the data management apparatus 2 sends the key of storage apparatus to the corresponding data storage apparatus.
  • all data storage apparatus belonging to one data management apparatus 2 share the same key of storage apparatus.
  • a plurality of data storage apparatus may have different keys of storage apparatus.
  • the key of storage apparatus could be fixed or, preferably, updated periodically according to UCD providers' policy.
  • the first responding device 204 of data management apparatus 2 sends authorization response, which contains storage location(s) of data block(s) to be accessed by Client 1 and the generated corresponding access authorization control information, to Client 1.
  • authorization response contains storage location(s) of data block(s) to be accessed by Client 1 and the generated corresponding access authorization control information, to Client 1.
  • Example 14 Client 1 is an UE:
  • the first responding device 204 sends an authorization response, which contains storage location(s) of data block(s) to be accessed from Client 1 and the corresponding access authorization control information, to Client 1.
  • the format of authorization response is exemplary shown as follows:
  • Response_Authorization is the authorization response
  • list_of_blockIDs is the list of IDs of the data block(s) to be accessed
  • blocks_locations is storage location(s) of data block(s) to be accessed
  • Access_Token is the access authorization control information.
  • Example 15 is a 3rd party application:
  • the first responding device 204 sends authorization response, which contains storage location(s) of data block(s) to be accessed and the corresponding access authorization control information, to Client 1.
  • the authorization response has following format:
  • list_of_blockIDs is the ID list of the data block(s) to be accessed
  • blocks_locations is storage location(s) information of data block(s) to be accessed
  • Access_Toen is access authorization control information.
  • refresh_token is optional and may be Refresh Token defined in RFC6794.
  • Client 1 After receiving authorization response from the data management apparatus 2, Client 1 sends a request for data access to the data storage apparatus 3 for requesting to access data block(s).
  • This request for data access contains storage location(s) and access authorization control information extracted from the authorization response from the data management apparatus 2. It is illustrated by the following examples:
  • Example 16 the format of request for data access sent by Clientl is exemplary shown as follows:
  • Request_Resource (ucd_client_name/ucd_client_id, blockID, Access_Token, %)
  • Request_Resource is request for data access
  • Ucd_client_name is the name of Client, wherein Client may be either the user or a 3 rd party application;
  • Ucd_client_id is the ID of Client, wherein Client may be either an user or a 3 rd party application;
  • BlockID is ID of the data block(s) to be accessed;
  • Access_Toen is the corresponding access authorization control information.
  • the obtaining device 302 obtains the storage location(s), access authorization control information and access permission of data block(s) to be accessed, from the request for data access.
  • the second validation device 303 of data storage apparatus 3 validate the request for data access from Client 1 according to the obtained access authorization control information.
  • the process of validation is explained by the following examples:
  • Example 17 in the data management apparatus 2, the authorization generating device 203 generates access authorization control information for request for storage location(s) and access authorization from Client 1, which contains the access token and first access token validation code obtained by hashing the access token, ID of the access token and first access token validation code obtained by hashing the access token, ID of the access token and the USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored.
  • the format of the first access token validation code is exemplary shown as follow:
  • Token_UCD HMAC (Token ID, Token, US ERD ATA_key )
  • Token_UCD is the first access token validation code
  • Token is the access token generated for the data management apparatus 2;
  • Token ID is ID of access token
  • USERDATA_key is the storage key for data storage apparatus
  • the second validation device 303 obtains the second access token validation code by using the same hash algorithm to hash the access token, ID of access token contained in request for validation and the key of storage apparatus USERDATA_key of data storage apparatus.
  • the format of second validation authorization code is exemplary shown as follow:
  • Token_UCD' HMAC (Token ID, Token, US ERD ATA_key )
  • Token_UCD' is the second access token validation code
  • Token is the access token contained in the request for validation
  • Token ID is ID of access token
  • USERDATA_key is the storage key for the data storage apparatus
  • the validation could be done by comparing the first access token validation code Token_UCD and the second access token validation code Token_UCD' . If they are same, it could be determined that the validation is successful.
  • Example 18 in the data storage apparatus 3, the second validation device 303 could also verify whether the database management apparatus, from which the access token is issued, is trusted. Since only the date storage apparatus 3 and the database management apparatus, from which the access token is issued, share the key USERDATA_key with each other, if the data storage apparatus verifies the access authorization control information based on the shared key USERDATA_key, it could be determined that the database management apparatus is trusted.. And, for example, the request for data access contains the identification of the data management apparatus that issues the access authorization control information, and the data storage apparatus 3 could extract the identification of the data management apparatus and compared it with a list of trusted data management apparatus. If it is found in the list, the validation is successful.
  • the access operating device 304 executes the access operation to the data block(s) to be accessed according to storage location(s) of data block(s) and the corresponding access permission obtained from the access authorization control information from Client 1.
  • Those operations comprise, but not limited to, the operation of create, read, update, delete, delete, write, copy, replace, etc. to the date blocks.
  • the request for data access from Client only includes Token ID of access token.
  • the permission requesting module 3021 (not shown) of obtaining device 302 sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the access permission corresponding to the Token ID.
  • the permission querying device 209 searches the corresponding access permission according to Token ID. Then, the third responding device 210(not shown) sends the searched access permission to the data storage apparatus 3.
  • the authorization generating device 203 comprises an authorization generating module 2031 (not shown) and an encryption module 2032(not shown).
  • the authorization generating module 2031 generates access authorization control information and the encryption module 2032 then encrypts it with the key and the related encryption algorithm, which are known by itself and the data storage apparatus 3 under its management, and the related encryption algorithm. Then, the first responding device 204 sends the authorization response containing the encrypted access authorization control information to Client 1.
  • the obtaining device 302 extracts the encrypted access authorization control information from the request for data access from Clientl, then decrypts it with the known key and related decryption algorithm so as to obtain the decrypted access authorization control information.
  • the transportations between Clientl and the data management apparatus 2 and between Client 1 and the data storage apparatus 3 are all based on the TLS protocol.
  • FIG. 6 shows a schematic diagram of system of providing authorization for access database, based on another preferred embodiment of this invention. According to Fig. 6, in connection with Fig. 2 and 5, the detailed descriptions about this preferred embodiment would be given as follow:
  • the operations of the determining device(not shown), the first receiving device 201 ', authentication device 202', authorization generating device 203', first responding device 204' of data management apparatus 2 and the fourth receiving device 301 ', obtaining device 302' of data storage apparatus 3 are same as those of the first receiving device 201, authentication device 202, authorization generating device 203, first responding device 204 of data management apparatus 2 and fourth receiving device 301, obtaining device 302 of data storage apparatus 3 as shown in the above embodiments described according to Fig. 5.
  • first receiving device 201 authentication device 202, authorization generating device 203, first responding device 204 of data management apparatus 2 and fourth receiving device 301, obtaining device 302 of data storage apparatus 3 are involved herein by reference.
  • the validation requesting module 3031 of second validation device 303 sends a request for validation to the data management apparatus 2 in order to request for validating the request for data access from Client 1.
  • the request for validation contains the obtained access authorization control information;
  • the first validation device 206' validates the request for validation.
  • the process of validation is exemplary explained by the following example:
  • ExamplelO in the data management apparatus 2, the authorization generating device 203 generates access authorization control information for request for storage location(s) and access authorization from Client 1, which contains the access token, ID of the access token and the first access token validation code obtained by hashing the access token, ID of the access token and the storage key USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored.
  • the format of the first access token validation code is exemplary shown as follow:
  • Token_UCD HMAC (Token ID, Token, US ERD ATA_key )
  • Token_UCD is first access token validation code(the 1st authorizing validation code);
  • Token is the access token generated by the data management apparatus 2;
  • Token ID is ID of access token
  • USERDATA_key is the storage key for data storage apparatus
  • the first validation device 206' obtains the second access token validation code by using the same hash algorithm to hash the access token, ID of the access token contained in request for validation and the storage key USERDATA_key of data storage apparatus.
  • the format of second validation authorization code is exemplary shown as follow:
  • Token_UCD' HMAC (Token ID, Token, US ERD ATA_key )
  • Token_UCD' is the second access token validation code
  • Token is the access token contained in the request for validation
  • Token ID is ID of the access token
  • USERDATA_key is the storage key for the data storage apparatus
  • the first validation device 206' validates the request for validation by comparing the first access token Token_UCD and the second access token validation code Token_UCD' . If they are same, it could be determined that the validation is successful. [00267] In the data management apparatus 2, based on the determination of the first validation device 206' that the validation of request for validation is successful, the second responding device 207' sends a message of successful validation to the data storage apparatus 3.
  • the access operating device 304' could execute the access operations to the data block(s) to be accessed according to storage location(s) of data block(s) and the corresponding access permission sent by Client 1. Those operations including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
  • the request for data access from Client only includes Token ID of access token.
  • the permission requesting module 3021 '(not shown) of the obtaining device 302' sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the corresponding access permission.
  • the permission querying device 209 '(not shown) search the corresponding access permission according Token ID. Then, the third responding device 210'(not shown) sends the searched access permission back to the data storage apparatus 3.
  • the present invention can be implemented in software and/or a combination of software and hardware, for example, the invention can be implemented by using an Application Specific Integrated Circuit (ASIC), a general purpose computer or any other similar hardware equipment.
  • ASIC Application Specific Integrated Circuit
  • the software program of this invention can be executed by a processor to accomplish the aforesaid steps or functions.
  • the software program (including the relevant data structure) of the invention can be stored in a computer readable recording medium, for example, RAM memory, magneto-optical drive or floppy disk and similar devices.
  • some steps or functions of the invention can be realized by using hardware, for example, a circuit that cooperates with the processor to perform various steps or functions.
  • part of the invention can be applied as a computer program product, such as a computer program instruction, when the instruction is executed by the computer, the method and/or technical solution according to this invention may be called or provided through an operation of the computer.
  • the program instruction for calling the method of the invention may possibly be stored in a fixed or movable recording medium, and/or be transmitted via broadcasting or other signal carrier mediums, and/or be stored in the operation memory of a computer device that is running according to said program instruction.
  • said device comprises a memory for storing computer program instructions and a processor for executing program instructions, this device is triggered to operate the methods and/or technical solutions based on the aforesaid embodiments of the invention when the computer program instructions are executed by said processor.

Abstract

Methods and apparatus provide a solution which provides authorizing validation of requests to access data to databases. In particular, according to the present invention, a METADATA Node 2 validates the request for storage location(s) and access authorization of users and generates a token and an access token validation code. Also, it sends access authorization control information, containing access token and access token validation code, to Client. As a result, when Client send request for data access to USERDATA Node 2, USERDATA Node 2 could enforce access authorization for the request for data access according to the access authorization control information in request for data access. Therefore, the problem of existing NoSQL databases or similar databases could not provide authorizing validation for request for data access is solved, and the security of database is improved.

Description

METHOD AND APPARATUS FOR PROVIDING DATABASE ACCESS
AUTHORIZATION
FIELD OF THE INVENTION
[0001] This invention relates to the field of databases, especially to the technology of providing validation of database access authorization.
DESCRIPTION OF THE RELATED ART
[0002] Most existing databases, like NoSQL databases, have little built-in security. Even though some security mechanisms such as authentication and authorization are enforced on data management layer like metadata management, no access authorization is passed to and enforced on physical data storage.
[0003] Existing relational database security is not applicable for NoSQL databases. As NoSQL databases lack a schema, access authorization cannot be enforced separately on a table, column or row.
[0004] Fig. 1 illustrates the architecture of NoSQL database. As shown in Fig. 1, it is illustrated Client and NoSQL Database system, wherein, Client may be an user equipment (UE) or a 3rd party application. The NoSQL database system comprises USERDATA nodes: USERDATA_1, USERDATA_2, USERDATA_3, and a multiple-level of METADATA nodes: METADATA_1, METADATA_2, METAD ATA_3 , S UPER_METAD ATA . It shall be understood for the person skilled in the art that the number of each parts and of the levels are only for the purpose of illustration.
[0005] In the NoSQL database system, a single file may be split into blocks and the blocks are distributed in clusters. Generally, there are two types of cluster management to support the embodiment of NoSQL databases. They are USERDATA node, which stores the data block(s) of the files; and METADATA node, which stores the metadata, with enumeration of data block(s) and a list of USERDATA in the cluster under the control of it, as shown in Fig. 1. A METADATA node manages one or more USERDATA node. There may be several levels of METADATA node, i.e., SUPERJVIETADATA node and METADATA node. When an user or an 3rd party application accesses a file on NoSQL database, it looks for the locations of data block(s) which compose of the file on a METADATA node then access the data block(s) on USERDATA. Users or 3rd party applications can directly access USERDATA node for data block(s) if they already know the locations of data block(s).
[0006] When users or 3rd party applications request file access on a METADATA node, METADATA node checks access permissions (e.g., read, write and delete) to those files according to the security policies after authenticating the user or 3rd party application.
[0007] However, when it comes to the subsequent data block accesses on the USERDATA node, the decision of authorization is not available to USERDATA node and hence the access control cannot be enforced. It is impossible for the USERDATA node to check access permission and make decision independently since USERDATA node only manages those data blocks without having concepts of the files. Moreover, some NoSQL database implementation such as Google BigTable does not enforce any access control on access to its database. It is possible for an unauthorized client to access a data block as long as it knows the block location or block ID.
SUMMARY OF THE INVENTION [0008] The object of the present invention is to provide a solution which provides authorizing validation of requests to access data to NoSQL databases or similar databases. In particular, a security mechanism of validation of data access is provided to the NoSOL database or similar database by enforcing the authorizing validation of data access at an external data management layer or the relative application layer, which thereby enables declining any access of an unauthorized client.
[0009] According to the first embodiment of the invention, a method for managing the data access is provided, wherein, the method comprises the following steps:
[0010] - receiving a request for storage location(s) and access authorization from a Client, which is used to request for one or more data block(s) to be accessed and the corresponding access authorization information;
[0011] - determining one or more data block locations based on the storage location(s);
[0012] - authenticating the request based on the request for storage location(s) and the access authorization;
[0013] - generating the corresponding access authorization control information based on the determination that the authentication request is successful, the corresponding access authorization control information being based on the request for storage location(s) and access authorization; and
[0014] - sending the one or more data block locations and the corresponding access authorization control information to the Client based on the determination that the authentication request is successful.
[0015] Preferably, said method further comprises:
[0016] - receiving a request for validation from a data storage apparatus;
[0017] - validating the request for validation according to the access authorization control information extracted from said request for validation;
[0018] - sending a message of successful validation to said data storage apparatus when the validation is successful.
[0019]
[0020] According to a second embodiment of the invention, a method for providing data accesses is provided, wherein, said method comprises the following steps:
[0021] - receiving a requests for data access from a client, which contains one or more data block locations to be accessed and the corresponding access authorization control information;
[0022] - obtaining the one or more data block locations, the access authorization control information and the access permission from the request for data access from the client;
[0023] - validating the request for data access according to the access authorization control information extracted from the request for data access;
[0024] - executing the corresponding access operations for the data block(s) to be accessed according to their storage location(s) and the access permission when validation is successful.
[0025] According to the third embodiment of the invention, a data management apparatus for managing the data access is provided, which comprises:
[0026] a first receiving device (201) for receiving a request for storage location(s) and access authorization from a client, which is used to request for one or more data block(s) to be accessed and the corresponding access authorization information;
[0027] a determining device for determining one or more data block locations based on the storage location(s);
[0028] an authentication device (202) for authenticating the request based on the storage location(s) and the access authorization; [0029] an authorization generating device (203) for generating a corresponding access authorization control information based on the determination that the authentication request is successful, the corresponding access authorization control information being based on the storage location(s) and access authorization when authentication is successful;
[0030] a first responding device (204) for sending the one or more data block locations and the corresponding access authorization control information to the Client based on the determination that the authentication is successful .
[0031] According to the fourth embodiment of the invention, a data storage apparatus for providing data accesses is provided, wherein, said data storage apparatus comprises:
[0032] a fourth receiving device (301) for receiving a requests for data access from a client, which contains one or more data block locations to be accessed, the corresponding access authorization control information ;
[0033] a obtaining device (302) for obtaining the one or more data block locations, the access authorization control information and the access permission from the request for data access from the client;
[0034] a second validation device (303) for validating the request for data access according to the access authorization control information extracted from the request for data access;
[0035] a access operating device (304) for executing the corresponding access operations for the data block(s) to be accessed according to their storage location(s) and the access permission when validation is successful.
[0036]
[0037] According to invention fifth embodiment, a database system for providing data access is provided, wherein, said system comprises one or more data management apparatus according to the third aspect of the invention and one or more data storage apparatus according to the fourth aspect of the invention.
[0038] The existing NoSQL databases or similar databases have two entities, METADATA Node and USERDATA Node. USERDATA could not do authorizing validation for data accesses from users, so that access control is not possible. In particular, METADATA Node validates the request for storage location(s) and access authorization of users and generates a token and an access token validation code. Also, it sends access authorization control information, containing access token and access token validation code, to Client. As a result, when Client send request for data access to USERDATA Node, USERDATA Node could enforce access authorization for the request for data access according to the access authorization control information in request for data access. Therefore, the problem that the existing NoSQL databases or similar databases could not provide authorizing validation for request for data access is solved, and the security of database is improved.
[0039]
BRIEF DESCRIPTION OF THE DRAWINGS
[0040] Other features, purposes and advantages of the invention will become more explicit by means of reading the detailed statement of the non-restrictive embodiments made with reference to the accompanying drawings.
[0041] Fig. 1 shows the architecture of NoSQL database.
[0042] Fig. 2 shows a application scenarios, based on an embodiment of this invention.
[0043] Fig. 3 shows the flow charts of the methods of providing authorizing validation for databases, based on an embodiment of this invention.
[0044] Fig. 4 shows the schematic diagram of a method that used to provide authorizing validation for database, based on an embodiment of this invention.
[0045] Fig. 5 shows schematic diagram of a device that provides authorizing validation for databases, based on an embodiment of this invention.
[0046] Fig. 6 shows schematic diagram of a device that provides authorizing validation for databases, based on another embodiment of this invention.
[0047] The same or similar reference signs in the drawings represent the same or similar component parts.
DETAILED DESCRIPTION OF THE INVENTION
[0048] Further description of this invention would be given as follow by reference of the drawings.
[0049] Fig. 2 shows an exemplary application scenario according to the present invention, which comprises Client UCD_Clientl, a METADATA node and an USERDATA node of a NoSQL database system or similar database system, wherein the METADATA node comprises a database management apparatus METDATA_1 and the USERDATA node comprises two data storage apparatuses USERDATA_1 and USERDATA_2.
[0050] Fig. 3 shows a flow chart of the method of providing authorization for access databases, based on an embodiment according to this invention. According to Fig. 3, also in connection with Fig. 2, detailed descriptions would be given as follow:
[0051] In step S301, Clientl sends a request for storage location(s) and access authorization to the data management apparatus 2 for requesting the storage location(s) and access permission of data block(s) to be accessed, which is described by two examples as follow:
[0052] Example 1, Clientl is an user equipment (UE).
[0053] In this example, the format of the request for storage location(s) and access authorization that UE sends to the data management apparatus is exemplary shown as follow: [0054] Request_Authorization (user_name/user_id, user_credential, metadata_node_name, file_name/ file_id, ...)
[0055] Wherein, Request_Authorization is the request for storage location(s) and access authorization.
[0056] user_name is the name of user;
[0057] user_id is ID of user;
[0058] user_credential is the authentication certificate of user, and may be a secret key or certificate of user;
[0059] metadata_node_name is the name for data management apparatus to which the request is to be send;
[0060] file_name is the name of the file to be accessed;
[0061] file_id is ID of the file to be accessed;
[0062] Example 2, Clientl is a 3rd party application. In this embodiment, the format of request for storage location(s) and access authorization that 3rd party application sends to the data management apparatus is exemplary shown as follow:
[0063] Request_Authorization(application_name/application_id, application_credential, metadata_node_name, file_name/ file_id, user_authorization_grant, ) [0064] Wherein, Request_Authorization is the request for storage location.
[0065] application_name is the name of the 3rd application;
[0066] application_id is ID of the 3rd applications;
[0067] application_credential the authentication certificate of the 3rd application, and may be application secret key or certificate;
[0068] metadata_node_name is the name for data management apparatus to which the request is to be send.
[0069] file_name is the name of the file to be accessed;
[0070] file_id is the ID of the file to be accessed;
[0071] user_authorization_grant includes but not limited to Authorization Grant defined in RFC6749
[0072] In step S302, the data management apparatus 2 authenticates the request based on the request for the storage location(s) and the access authorization, and generates a corresponding access authorization control information based on the determination that the authentication request is successful, the corresponding access authorization control information being based on the request for storage location(s) and access authorization. The access authorization control information contains the access token, ID of the access token and the access token validation code.
[0073] And, the data management apparatus 2 may determine the storage location(s) of data block(s) to be accessed based on the request for storage location and access authorization either prior to or after the determination that the authentication of the request is successful.
[0074] It should be understood by the person skilled in the art that various existing technologies of authentication are applicable to this invention, and should fall within the protection scope of this invention. One example to describe the process of generating access authorization control information would be given as follow:
[0075] Example 3, the access authorization control information has following format:
[0076] Access_Token = { Token ID, Token, Token_UCD }
[0077] wherein, Access_Token is access authorization control information;
[0078] Token is a access token;
[0079] Token ID is ID of access token;
[0080] Token_UCD is access token validation code;
[0081] The data management apparatus 2 generates the access token according to the information such as ID of file owner, IDs of data block(s), expiring information of authentication and information of data accesses method, and its format is exemplary shown as follow:
[0082] Token = {ownerlD, [,applicationID] blockID, expirationln, access_methods}
[0083] Wherein, ownerlD is the ID of file owner;
[0084] blockID is the ID of data block;
[0085] expirationIN is the expiring information of authentication,
[0086] access_method is the information of data accesses method, including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
[0087] applicationID is ID of application, and is optional. If a third-party application is to access the user information, applicationID is needed.
[0088] Then, the data management apparatus 2 obtains access token validation code by hashing the generated access token, ID of the access token and USERDATA_key of data storage apparatus which store the data block(s) to be accessed. The format of access token validation code is exemplary shown as follow:
[0089] Token_UCD=HMAC (Token ID, Token, US ERD ATA_key ) [0090] USERDATA_key is the key of storage apparatus. The data management apparatus 2 sends key of storage apparatus to the corresponding data storage apparatus. Generally, all data storage apparatus belonging to one data management apparatus 2 share the same key of storage apparatus. Preferably, a plurality of data storage apparatus may have different keys of storage apparatus. The key of storage apparatus could be fixed or, preferably, updated periodically according to UCD providers' policy.
[0091] In step S303, the data management apparatus 2 sends authorization response to Client 1, which contains storage location(s) of data block(s) to be accessed and the generated corresponding access authorization control information, to Client 1. The process of sending access authorization control information is explained by two examples as follows:
[0092] Example 4, Client 1 is a UE:
[0093] The data management apparatus 2 sends authorization response, which contains storage location(s) of data block(s) to be accessed and the corresponding access authorization control information, to Client 1. The format of authorization response is exemplary shown as follows:
[0094] Response_Authorization(user_name/user_id,list_of_blockIDs/block_locations,
Access_Token, )
[0095] Wherein, Response_Authorization is the authorization response;
[0096] list_of_blockIDs is the list of IDs of the data block(s) to be accessed;
[0097] blocks_locations is storage location(s) of data block(s) to be accessed;
[0098] Access_Token is the access authorization control information.
[0099] Example5, Client 1 is a 3rd party application:
[00100] The data management apparatus 2 sends an authorization response, which contains storage location(s) of data block(s) to be accessed and the corresponding access authorization control information, to Client 1. The authorization response has following format:
[00101] Response_Authorization(application_name/application_id,
list_of_blockIDs/block_locations, Access_Token[, refresh_token], )
[00102] Wherein, Response_Authorization is the authorization response;
[00103] list_of_blockIDs is the ID list of the data block(s) to be accessed;
[00104] blocks_locations is storage location(s) information of data block(s) to be accessed;
[00105] Access_Token is the access authorization control information.
[00106] refresh_token is optional and may be Refresh Token defined in RFC6794 .
[00107] In step S304, after receiving authorization response from the data management apparatus 2, Client 1 sends a request for data access to the data storage apparatus 3 for requesting to access data block(s). This request for data access contains storage location(s) and access authorization control information of the data block(s) to be accessed, extracted from the authorization response from data management apparatus 2. It is illustrated by the following examples:
[00108] Example 6, the format of request for data access sent by Clientl is exemplary shown as follows::
[00109] Request_Resource (ucd_client_name/ucd_client_id, blockID, Access_Token, ...) [00110] Wherein, Request_Resource is request for data access;
[00111] Ucd_client_name is the name of Client, wherein Client may be either an user or a 3 rd party application;
[00112] Ucd_client_id is the ID of Client, wherein Client may be either an user or a 3 rd party application;
[00113] BlockID is ID of the data block(s) to be accessed;
[00114] Access_Toen is the corresponding access authorization control information.
[00115] In step S305, after receiving the request for data access from Client 1, the data storage apparatus 3 obtains the storage location(s), access authorization control information and access permission of data block(s) to be accessed, from the request for data access. [00116] In step S306, the data storage apparatus 3 validate the request for data access from Client 1 according to the access authorization control information. The process of validation is explained by the following examples:
[00117] Example 7, in the above step S302, the data management apparatus 2 generates access authorization control information for the request for storage location(s) and access authorization from Client 1, which contains the access token, ID of the access token and first access token validation code obtained by hashing the access token, ID of the access token and the USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored. The format of the first access token validation code is exemplary shown as follow:
[00118] Token_UCD= HMAC (Token ID, Token, US ERD ATA_key )
[00119] Wherein, Token_UCD is the first access token validation code;
[00120] Token is the access token generated for the data management apparatus 2;
[00121] Token ID is ID of access token;
[00122] USERDATA_key is the storage key for data storage apparatus;
[00123] In step S306, the data storage apparatus 3 obtains second access token validation code by using the same hash algorithm to hash the access token, ID of access token contained in the request for validation and the storage key apparatus USERDATA_key of data storage apparatus. The format of second validation authorization code is exemplary shown as follow:
[00124] Token_UCD' = HMAC (Token ID, Token, US ERD ATA_key ) [00125] wherein, Token_UCD' is the second access token validation code;
[00126] Token is the access token contained in the request for validation;
[00127] Token ID is ID of access token;
[00128] USERDATA_key is the storage key for the data storage apparatus;
[00129] Finally, the validation of the validating request could be done by comparing the first access token validation code Token_UCD and second access token validation code Token_UCD' . If they are same, it could be determined that the validation is successful.
[00130] Example 8, in step S306, the data storage apparatus 3 could also verify whether the database management apparatus, from which the access token is issued, is trusted. Since only the date storage apparatus 3 and the database management apparatus, from which the access token is issued, share the key USERDATA_key with each other, if the data storage apparatus verifies the access authorization control information based on the shared key USERDATA_key, it could be determined that the database management apparatus is trusted. And, for example, the request for data access contains the identification of the data management apparatus that issues the access authorization control information, and the data storage apparatus 3 could extract the identification of the data management apparatus and compared it with a list of trusted data management apparatus. If it is found in the list, the validation is successful.
[00131] Finally, in S307, the data storage apparatus 3 executes the access operation to the data block(s) to be accessed according to storage location(s) of data block(s) and the corresponding access permission obtained from the access authorization control information from Client 1. Those operations comprise, but not limited to, the operation of create, read, update, delete, delete, write, copy, replace, etc.
[00132] In one preferred embodiment, the request for data access from Client only includes Token ID of access token. In step S308 (not shown), the data storage apparatus 3 sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the access permission corresponding to the Token ID. [00133] In step S309(not shown), after receiving the request for access permission, the database management device 2 searches the corresponding access permission according to Token ID, then sends the searched access permission to the data storage apparatus 3.
[00134] In another preferred embodiment, in step S302, the data management apparatus 2 generates access authorization control information and encrypt it with the key and the related encryption algorithm, which are known by itself and the data storage apparatus 3 under its management , then sends the authorization response containing the encrypted access authorization control information to Client 1.
[00135] And, in step S305, the data storage apparatus 3 extracts the encrypted access authorization control information from the request for data access from Client 1, then decrypts it with the known key and related decryption algorithm so as to obtain the decrypted access authorization control information.
[00136] In another preferred embodiment, to secure the transportation, the transportations between Client 1 and data management apparatus 2 and between Client 1 and data storage apparatus 3 are all based on the TLS protocol.
[00137] Fig.4 shows a schematic diagram of a method that used to provide validation for access to the database, based on a preferred embodiment of this invention. According to Fig. 4, in connection with Fig. 2 and 3, the detailed descriptions about this preferred embodiment would be given as follow:
[00138] Wherein, the processes of Step S401 to S405 are same as those of S301 to S305 as shown in the above embodiments described according to Fig.3. For the sake of brevity, the content of S301 to S305 are involved herein by reference.
[00139] In step S406, the data storage apparatus 3 sends a request for validation to the data management apparatus 2 in order to request for validating the request for data access from Client 1. The request for validation contains the obtained access authorization control information; [00140] In step S407, the data management apparatus 2 validate the request for validation after receiving it from the data storage apparatus 3. The process of validation is explained by the following example:
[00141] ExamplelO, in step S402, the data management apparatus 2 generates access authorization control information for the request for storage location(s) and access authorization from Client 1, which contains the access token, ID of the access token and first access token validation code obtained by hashing the access token, ID of the access token and the storage key USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored. The format of the first access token validation code is exemplary shown as follow:
[00142] Token_UCD= HMAC (Token ID, Token, US ERD ATA_key )
[00143] Wherein, Token_UCD is the first access token validation code(the 1st authorizing validation code);
[00144] Token is the access token generated by the data management apparatus 2;
[00145] Token ID is ID of the access token;
[00146] USERDATA_key is the storage key for the data storage apparatus;
[00147] In step S407, the data management apparatus 2 obtains the second access token validation code by using the same hash algorithm to hash the access token, ID of access token contained in request for validation and the storage key USERDATA_key of data storage apparatus. The format of second validation authorization code is exemplary shown as follow:
[00148] Token_UCD' = HMAC (Token ID, Token, US ERD ATA_key )
[00149] wherein, Token_UCD' is second access token validation code;
[00150] Token is the access token contained in the request for validation;
[00151] Token ID is ID of the access token;
[00152] USERDATA_key is the storage key for the data storage apparatus;
[00153] Finally, the validation could be done by comparing the first access token validation code Token_UCD and the second access token validation code Token_UCD'. If they are same, it could be determined that the validation is successful.
[00154]
[00155] In step S408(not shown), the data management apparatus 2 sends message of successful validation to the data storage apparatus based on the determination that the validation of validating request is successful.
[00156] In S409(not shown), when receiving message of successful validation from the data management apparatus 2, the data storage apparatus 3 could execute the access operations to the data block(s) to be accessed according to the storage location(s) of data block(s) and the corresponding access permission sent from Client 1. Those operations including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
[00157] In one preferred embodiment, the request for data access from Client only includes Token ID of access token. In step S410(not shown), the data storage apparatus 3 sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the access permission corresponding to the Token ID.
[00158] In step S411(not shown), after receiving the request for access permission from the data storage apparatus 3, the database management device 2 searches the corresponding access permission according to Token ID, then sends the searched access permission to the data storage apparatus 3.
[00159] Please note that the above reference sign is just for illustration and shall not be understood to be any limitation to the special order of respective steps. [00160] Fig. 5 shows a schematic diagram of system of providing authorization for access database according to an embodiment of the present invention, wherein the system comprise Client 1, the database management apparatus and the data storage apparatus. According to Fig. 5, also in connection with Fig. 2, the detailed description of embodiment would be given as follow:
[00161] In step S301, Client 1 sends a request for storage location(s) and access authorization to the data management apparatus 2 for requesting the storage location(s) and access permission of data block(s) to be accessed, which is described by two examples as follow:
[00162] Example 11, Clientl is an user equipment (UE). In this embodiment, the format of request for storage location(s) and access authorization that UE sends to the data management apparatus is exemplary shown as follow:
[00163] Request_Authorization (user_name/user_id, user_credential, metadata_node_name, file_name/ file_id, ...)
[00164] Wherein, Request_Authorization is the request for storage location(s) and access authorization.
[00165] user_name is the name of user;
[00166] user_id is ID of user;
[00167] user_credential is the authentication certificate of user, and may be a secret key or certificate of user;
[00168] metadata_node_name is the name for data management apparatus to which the request is to be send;
[00169] file_name is the name of the file to be accessed;
[00170] file_id is ID of the file to be accessed; [00171] Example 12, Clientl is 3rd party application. In this embodiment, the format of request for storage location(s) and access authorization that 3rd party application sends to the data management apparatus is exemplary shown as follow:
[00172] Request_Authorization(application_name/application_id,application_credential, metadata_node_name, file_name/ file_id, user_authorization_grant, )
[00173] Wherein, Request_Authorization is the request for storage location.
[00174] application_name is the name of the 3rd application;
[00175] application_id is ID of the 3rd applications;
[00176] application_credential the authentication certificate of the 3rd application, and may be application secret key or certificate;
[00177] metadata_node_name is the name for data management apparatus to which the request is to be send.
[00178] file_name is the name of the file to be accessed;
[00179] file_id is the ID of the file to be accessed;
[00180] user_authorization_grant includes but not limited to Authorization Grant defined in RFC6749
[00181] In the data management apparatus 2, after the first receiving device 201 receiving the request for storage location(s) and access authorization from Client 1, authentication device 202 authenticates the request for storage location(s) and access authorization. [00182] After the authentication is successful, the authorization generating device 203 generates a corresponding access authorization control information for the request for storage location(s) and access authorization. The access authorization control information contains the access token, ID of the access token and the access token validation code.
[00183] And, the determination device (not shown) of data management apparatus 2 may determine the storage location(s) of data block(s) to be accessed based on the request for storage location and access authorization either prior to or after the determination that the authentication of the request is successful.
[00184] It should be understood by the person skilled in the art that various existing technologies of authentication are applicable to this invention, and should fall within the protection scope of this invention.
[00185] The process of generating access authorization control information would be described by a example as follows:
[00186] Example 13, access authorization control information has following format:
[00187] Access_Token = {Token ID, Token, Token_UCD}
[00188] wherein, Access_Token is access authorization control information;
[00189] Token is a access token;
[00190] Token ID is ID of the access token
[00191] Token_UCD is access token validation code;
[00192] Then, the authorization generating device 203 generates the access token according to the information such as ID of file owner, IDs of data block(s), expiring information of authentication and information of data accesses method, and its format is exemplary shown as follow:
[00193] Token = {ownerlD, [,applicationID] blockID, expirationln, access_methods} [00194] Wherein, ownerlD is the ID of file owner;
[00195] blockID is the ID of data block;
[00196] expirationIN is the expiring information of authentication,
[00197] access_method is the information of data accesses method, including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
[00198] applicationID is ID of application, and is optional. If a third-party application is to access the user information, applicationID is needed
[00199] wherein, the authorization generating device 203 generates access token validation code by hashing the generated access token, ID of the access token and USERDATA_key of data storage apparatus which store the data block(s) to be accessed. The format of access token validation code is exemplary shown as follow:
[00200] Token_UCD=HMAC (Token ID, Token, US ERD ATA_key ) [00201] USERDATA_key is the key of storage apparatus. The data management apparatus 2 sends the key of storage apparatus to the corresponding data storage apparatus. Generally, all data storage apparatus belonging to one data management apparatus 2 share the same key of storage apparatus. Preferably, a plurality of data storage apparatus may have different keys of storage apparatus. The key of storage apparatus could be fixed or, preferably, updated periodically according to UCD providers' policy.
[00202] Then, the first responding device 204 of data management apparatus 2 sends authorization response, which contains storage location(s) of data block(s) to be accessed by Client 1 and the generated corresponding access authorization control information, to Client 1. The process of sending access authorization control information is explained by two examples as follows:
[00203] Example 14, Client 1 is an UE:
[00204] The first responding device 204 sends an authorization response, which contains storage location(s) of data block(s) to be accessed from Client 1 and the corresponding access authorization control information, to Client 1. The format of authorization response is exemplary shown as follows:
[00205] Response_Authorization(user_name/user_id, list_of_blockIDs/block_locations, Access_Token, )
[00206] Wherein, Response_Authorization is the authorization response;
[00207] list_of_blockIDs is the list of IDs of the data block(s) to be accessed;
[00208] blocks_locations is storage location(s) of data block(s) to be accessed;
[00209] Access_Token is the access authorization control information.
[00210] Example 15, Client 1 is a 3rd party application:
[00211] The first responding device 204 sends authorization response, which contains storage location(s) of data block(s) to be accessed and the corresponding access authorization control information, to Client 1. The authorization response has following format:
[00212] Response_Authorization (application_name/application _id, list_of_blockIDs/block_locations, Access_Token[, refresh_token], )
[00213] wherein, Response_Authorization isauthorization response;
[00214] list_of_blockIDs is the ID list of the data block(s) to be accessed;
[00215] blocks_locations is storage location(s) information of data block(s) to be accessed;
[00216] Access_Toen is access authorization control information.
[00217] refresh_token is optional and may be Refresh Token defined in RFC6794.
[00218] After receiving authorization response from the data management apparatus 2, Client 1 sends a request for data access to the data storage apparatus 3 for requesting to access data block(s). This request for data access contains storage location(s) and access authorization control information extracted from the authorization response from the data management apparatus 2. It is illustrated by the following examples:
[00219] Example 16, the format of request for data access sent by Clientl is exemplary shown as follows:
[00220] Request_Resource (ucd_client_name/ucd_client_id, blockID, Access_Token, ...) [00221] Wherein,
[00222] Request_Resource is request for data access;
[00223] Ucd_client_name is the name of Client, wherein Client may be either the user or a 3rd party application;;
[00224] Ucd_client_id is the ID of Client, wherein Client may be either an user or a 3rd party application;
[00225] BlockID is ID of the data block(s) to be accessed; [00226] Access_Toen is the corresponding access authorization control information.
[00227] In the data storage apparatus 3 , after the fourth receiving device 301 receiving the request for data access from Client 1, the obtaining device 302 obtains the storage location(s), access authorization control information and access permission of data block(s) to be accessed, from the request for data access.
[00228] Thereafter, the second validation device 303 of data storage apparatus 3 validate the request for data access from Client 1 according to the obtained access authorization control information. The process of validation is explained by the following examples:
[00229] Example 17, in the data management apparatus 2, the authorization generating device 203 generates access authorization control information for request for storage location(s) and access authorization from Client 1, which contains the access token and first access token validation code obtained by hashing the access token, ID of the access token and first access token validation code obtained by hashing the access token, ID of the access token and the USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored. The format of the first access token validation code is exemplary shown as follow:
[00230] Token_UCD= HMAC (Token ID, Token, US ERD ATA_key )
[00231]
[00232] Wherein, Token_UCD is the first access token validation code;
[00233] Token is the access token generated for the data management apparatus 2;
[00234] Token ID is ID of access token;
[00235] USERDATA_key is the storage key for data storage apparatus;
[00236] In the data storage apparatus 3, the second validation device 303 obtains the second access token validation code by using the same hash algorithm to hash the access token, ID of access token contained in request for validation and the key of storage apparatus USERDATA_key of data storage apparatus. The format of second validation authorization code is exemplary shown as follow:
[00237] Token_UCD' = HMAC (Token ID, Token, US ERD ATA_key )
[00238] wherein, Token_UCD' is the second access token validation code;
[00239] Token is the access token contained in the request for validation;
[00240] Token ID is ID of access token;
[00241] USERDATA_key is the storage key for the data storage apparatus;
[00242] Finally, the validation could be done by comparing the first access token validation code Token_UCD and the second access token validation code Token_UCD' . If they are same, it could be determined that the validation is successful.
[00243] Example 18, in the data storage apparatus 3, the second validation device 303 could also verify whether the database management apparatus, from which the access token is issued, is trusted. Since only the date storage apparatus 3 and the database management apparatus, from which the access token is issued, share the key USERDATA_key with each other, if the data storage apparatus verifies the access authorization control information based on the shared key USERDATA_key, it could be determined that the database management apparatus is trusted.. And, for example, the request for data access contains the identification of the data management apparatus that issues the access authorization control information, and the data storage apparatus 3 could extract the identification of the data management apparatus and compared it with a list of trusted data management apparatus. If it is found in the list, the validation is successful.
[00244] Finally, in the data storage apparatus 3, the access operating device 304 executes the access operation to the data block(s) to be accessed according to storage location(s) of data block(s) and the corresponding access permission obtained from the access authorization control information from Client 1. Those operations comprise, but not limited to, the operation of create, read, update, delete, delete, write, copy, replace, etc. to the date blocks.
[00245] In one preferred embodiment, the request for data access from Client only includes Token ID of access token. In the data storage apparatus 3, the permission requesting module 3021 (not shown) of obtaining device 302 sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the access permission corresponding to the Token ID.
[00246] In the data management apparatus 2, after the third receiving device 208 (not shown) receiving the request for access permission, the permission querying device 209 (not shown) searches the corresponding access permission according to Token ID. Then, the third responding device 210(not shown) sends the searched access permission to the data storage apparatus 3.
[00247] In another preferred embodiment, in the data management apparatus 2, the authorization generating device 203 comprises an authorization generating module 2031 (not shown) and an encryption module 2032(not shown). The authorization generating module 2031 generates access authorization control information and the encryption module 2032 then encrypts it with the key and the related encryption algorithm, which are known by itself and the data storage apparatus 3 under its management, and the related encryption algorithm. Then, the first responding device 204 sends the authorization response containing the encrypted access authorization control information to Client 1.
[00248] And, in the data storage apparatus 3, the obtaining device 302 extracts the encrypted access authorization control information from the request for data access from Clientl, then decrypts it with the known key and related decryption algorithm so as to obtain the decrypted access authorization control information.
[00249] In another preferred embodiment, to secure the transportation, the transportations between Clientl and the data management apparatus 2 and between Client 1 and the data storage apparatus 3 are all based on the TLS protocol.
[00250] Fig. 6 shows a schematic diagram of system of providing authorization for access database, based on another preferred embodiment of this invention. According to Fig. 6, in connection with Fig. 2 and 5, the detailed descriptions about this preferred embodiment would be given as follow:
[00251] Wherein, the operations of the determining device(not shown), the first receiving device 201 ', authentication device 202', authorization generating device 203', first responding device 204' of data management apparatus 2 and the fourth receiving device 301 ', obtaining device 302' of data storage apparatus 3 are same as those of the first receiving device 201, authentication device 202, authorization generating device 203, first responding device 204 of data management apparatus 2 and fourth receiving device 301, obtaining device 302 of data storage apparatus 3 as shown in the above embodiments described according to Fig. 5. For the sake of brevity, the content related to the operation of first receiving device 201, authentication device 202, authorization generating device 203, first responding device 204 of data management apparatus 2 and fourth receiving device 301, obtaining device 302 of data storage apparatus 3 are involved herein by reference.
[00252] As shown in Fig. 6, in data storage apparatus 3, the validation requesting module 3031 of second validation device 303 sends a request for validation to the data management apparatus 2 in order to request for validating the request for data access from Client 1. The request for validation contains the obtained access authorization control information; [00253] In data management apparatus 2, after the second receiving device 205' receiving it from the data storage apparatus 3, the first validation device 206' validates the request for validation. The process of validation is exemplary explained by the following example:
[00254] ExamplelO, in the data management apparatus 2, the authorization generating device 203 generates access authorization control information for request for storage location(s) and access authorization from Client 1, which contains the access token, ID of the access token and the first access token validation code obtained by hashing the access token, ID of the access token and the storage key USERDATA_key of data storage apparatus in which the data block(s) to be accessed are stored. The format of the first access token validation code is exemplary shown as follow:
[00255] Token_UCD= HMAC (Token ID, Token, US ERD ATA_key )
[00256] Wherein, Token_UCD is first access token validation code(the 1st authorizing validation code);
[00257] Token is the access token generated by the data management apparatus 2;
[00258] Token ID is ID of access token;
[00259] USERDATA_key is the storage key for data storage apparatus;
[00260] Thereby, the first validation device 206' obtains the second access token validation code by using the same hash algorithm to hash the access token, ID of the access token contained in request for validation and the storage key USERDATA_key of data storage apparatus. The format of second validation authorization code is exemplary shown as follow:
[00261] Token_UCD' = HMAC (Token ID, Token, US ERD ATA_key )
[00262] wherein, Token_UCD' is the second access token validation code;
[00263] Token is the access token contained in the request for validation;
[00264] Token ID is ID of the access token;
[00265] USERDATA_key is the storage key for the data storage apparatus;
[00266] Finally, the first validation device 206' validates the request for validation by comparing the first access token Token_UCD and the second access token validation code Token_UCD' . If they are same, it could be determined that the validation is successful. [00267] In the data management apparatus 2, based on the determination of the first validation device 206' that the validation of request for validation is successful, the second responding device 207' sends a message of successful validation to the data storage apparatus 3.
[00268] In data storage apparatus 3, when the validation receiving module 3032' receiving message of successful validation from the data management apparatus 2, the access operating device 304' could execute the access operations to the data block(s) to be accessed according to storage location(s) of data block(s) and the corresponding access permission sent by Client 1. Those operations including but not limited to create, read, update, delete, delete, write, copy, replace, etc.
[00269] In one preferred embodiment, the request for data access from Client only includes Token ID of access token. In data storage apparatus 3, the permission requesting module 3021 '(not shown) of the obtaining device 302' sends a request for access permission to the data management apparatus 2, wherein the request for access permission contains the Token ID and is used for requesting the corresponding access permission.
[00270] In the data management apparatus 2, after the third receiving device 208 '(not shown) receiving the request for access permission, the permission querying device 209 '(not shown) search the corresponding access permission according Token ID. Then, the third responding device 210'(not shown) sends the searched access permission back to the data storage apparatus 3.
[00271] It needs to note that the present invention can be implemented in software and/or a combination of software and hardware, for example, the invention can be implemented by using an Application Specific Integrated Circuit (ASIC), a general purpose computer or any other similar hardware equipment. In one embodiment, the software program of this invention can be executed by a processor to accomplish the aforesaid steps or functions. Likewise, the software program (including the relevant data structure) of the invention can be stored in a computer readable recording medium, for example, RAM memory, magneto-optical drive or floppy disk and similar devices. In addition, some steps or functions of the invention can be realized by using hardware, for example, a circuit that cooperates with the processor to perform various steps or functions. [00272] In addition, part of the invention can be applied as a computer program product, such as a computer program instruction, when the instruction is executed by the computer, the method and/or technical solution according to this invention may be called or provided through an operation of the computer. However, the program instruction for calling the method of the invention may possibly be stored in a fixed or movable recording medium, and/or be transmitted via broadcasting or other signal carrier mediums, and/or be stored in the operation memory of a computer device that is running according to said program instruction. Here, there is one device included according to an embodiment of the invention, said device comprises a memory for storing computer program instructions and a processor for executing program instructions, this device is triggered to operate the methods and/or technical solutions based on the aforesaid embodiments of the invention when the computer program instructions are executed by said processor.
[00273] To those skilled in the art, apparently the present invention is not limited to the details of the aforementioned exemplary embodiments, moreover, under the premise of not deviating from the spirit or fundamental characteristics of the invention, this invention can be accomplished in other specific forms. Therefore, the embodiments should be considered exemplary and non-restrictive no matter from which point, the scope of the invention is defined by the appended claims instead of the above description, and aims at covering the meanings of the equivalent components falling into the claims and all changes within the scope in this invention. Any reference sign in the claims shall not be deemed as limiting the concerned claims. Besides, apparently the word "comprise/include" does not exclude other components or steps, singular numbers does not exclude complex numbers, the plurality of components or means mentioned in device claims may also be accomplished by one component or means through software or hardware, the wording like first and second are only used to represent names rather than any specific order.

Claims

What is claimed:
1. A method for managing data access, wherein, the method comprises:
- receiving a request for storage location(s) and access authorization from a Client, which is used to request for one or more data block(s) to be accessed and the corresponding access authorization information;
- determining one or more data block locations based on the storage location(s);
- authenticating the request based on the request for storage location(s) and the access authorization;
- generating a corresponding access authorization control information based on the determination that the authentication is successful, the corresponding access authorization control information being based on the request for storage location(s) and access authorization ; and
- sending the one or more data block locations and the corresponding access authorization control information to the Client based on the determination that the authentication request is successful.
2. The method according to claim 1, wherein, said method further comprises:
- receiving a request for validation from a data storage apparatus;
- validating the request for validation according to the access authorization control information extracted from said request for validation;
- sending a message of successful validation to said data storage apparatus when the validation is successful.
3. The method according to claim 1 or 2, wherein said step of generating access authorization control information comprises:
- generating the corresponding access authorization control information based on the determination that the authentication request is successful, the corresponding access authorization control information being based on the storage location(s) and access authorization;
- encrypting the generated access authorization control information, so as to obtain the encrypted access authorization control information.
Wherein, said step of sending the one or more data block locations and the access authorization control information to the Client includes:
- sending the storage location(s) of the requested data block(s) and the corresponding encrypted access authorization control information to said Client.
4. The method according to anyone of claims 1 to 3, wherein, the method further comprises:
- receiving a request for access permission from a data storage apparatus, which contains the Token ID of access authorization, the request is for requesting the access permission corresponding to the Token ID;
- searching the corresponding access permission according to the Token ID contained in the request for access permission;
- sending the access permission to the data storage apparatus.
5. A method for providing data accesses, wherein, said method comprises the following steps:
- receiving a requests for data access from a client, which contains one or more data block locations to be accessed and the corresponding access authorization control information;
- obtaining the one or more data block locations, the access authorization control information and the access permission from the request for data access from the client;
- validating the request for data access according to the access authorization control information extracted from the request for data access;
- executing the corresponding access operations for the data block(s) to be accessed according to their storage location(s) and the access permission when validation is successful.
6. The method according to claim 5, wherein, said step of validating the request for data access comprises:
- sending a validation request, which contains the access authorization control information extracted from the request for data access, to the database management apparatus;
- receiving the message of successful validation from the data management apparatus ;
wherein, said step of executing the corresponding access operations comprises:
- executing the corresponding access operations for the data block(s) to be accessed according to their storage location(s) and access authorization control information from request for data access after receiving the message of successful validation from data management apparatus.
7. The method according to claim 5 or 6, wherein said access authorization control information contains the token ID of access authorization, and the step of obtaining the access permission further comprises:
- sending a request for access permission to the data management apparatus, wherein, the request contains the token ID;
- receiving a response, containing the access permission corresponding to the token ID, from the data management apparatus.
8. A data management apparatus for managing the data access, which comprises:
a first receiving device (201) for receiving a request for storage location(s) and access authorization from a Client, which is used to request for one or more data block(s) to be accessed and the corresponding access authorization information;
a determining device for determining one or more data block locations based on the storage location(s);
an authentication device (202) for authenticating the request based on the storage location(s) and the access authorization;
an authorization generating device (203) for generating a corresponding access authorization control information based on the determination that the authentication is successful, the corresponding access authorization control information being based on the storage location(s) and access authorization;
a first responding device (204) for sending the one or more data block locations and the corresponding access authorization control information to the Client based on the determination that the authentication is successful.
9. The data management apparatus according to claim 9, which further comprises: a second receiving device (205') for receiving a request for validation from a data storage apparatus;
a first validation device (206') for validating the request for validation according to the access authorization control information extracted from said request for validation;
a second responding device (20V) for sending a message of successful validation to said data storage apparatus when the validation is successful.
10. The data management apparatus according to claim 8 or 9, wherein said authorization generating device (203) comprises:
an authorization generating module (2031) for generating the corresponding access authorization control information based on the determination that the authentication request is successful, the corresponding access authorization control information being based on the storage location(s) and access authorization;
an encryption module (2032) encrypting the generated access authorization control information, so as to obtain the encrypted access authorization control information.
Wherein, said first responding device (204) is adapted to send the storage location(s) of the requested data block(s) and the corresponding encrypted access authorization control information to said Client.
11. The data management apparatus according to anyone of claims 8 to 9, wherein, the data management apparatus further comprises:
a third receiving device (208, 208') for receiving a request for access permission from a data storage apparatus, which contains the token ID of access authorization, the request is for requesting the access permission corresponding to the token ID;
a permission querying device (209, 209') for searching the corresponding access permission according to the token ID contained in the request for access permission;
a third responding device (210, 210') for sending the access permission to the data storage apparatus.
12. A data storage apparatus for providing data accesses, wherein, said data storage apparatus comprises:
a fourth receiving device (301, 30 ) for receiving a requests for data access from a client, which contains one or more data block locations to be accessed, the corresponding access authorization control information;
a obtaining device (302, 302') for obtaining the one or more data block locations, the access authorization control information and the access permission from the request for data access from the client;
a second validation device (303, 303') for validating the request for data access according to the access authorization control information extracted from the request for data access;
access operating device (304, 304') for executing the corresponding access operations for the data block(s) to be accessed according to their storage location(s) and the access permission when validation is successful.
13. The data storage apparatus according to claim 12, wherein, said second validation device (303') comprises: a validation requesting module (303 ) for sending a validation request, which contains the access authorization control information extracted from the request for data access, to the database management apparatus( data management apparatus);
a validation receiving module (3032') for receiving the message of successful validation from the data management apparatus;
wherein, said access operating device (304') is adapted to executing the corresponding access operations for the data block(s) to be accessed according to their storage location(s) and access authorization control information from request for data access after receiving the message of successful validation from data management apparatus.
14. The data storage apparatus according to claim 12 or 13, wherein said access authorization control information contains the token ID of access authorization, and the data storage apparatus further comprises:
a permission requesting module (3021, 302 ) for sending a request for access permission to the data management apparatus, wherein, the request contains the token ID;
a permission receiving module (3022, 3022') for receiving a response, containing the access permission corresponding to the token ID, from the data management apparatus.
15. A database system for providing data access, wherein, said system comprises one or more data management apparatus according to any one of claims 8 to 11 and one or more data storage apparatus according to any one of claims 12 to 14.
PCT/IB2014/001529 2013-06-02 2014-05-30 Method and apparatus for providing database access authorization WO2014207554A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310217403.7 2013-06-02
CN201310217403.7A CN104216907B (en) 2013-06-02 2013-06-02 It is a kind of for providing the method, apparatus and system of Access and control strategy of database

Publications (2)

Publication Number Publication Date
WO2014207554A2 true WO2014207554A2 (en) 2014-12-31
WO2014207554A3 WO2014207554A3 (en) 2015-03-26

Family

ID=51790788

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2014/001529 WO2014207554A2 (en) 2013-06-02 2014-05-30 Method and apparatus for providing database access authorization

Country Status (2)

Country Link
CN (1) CN104216907B (en)
WO (1) WO2014207554A2 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3356964A4 (en) * 2015-09-28 2018-08-08 Bluetalon, Inc. Policy enforcement system
US10291602B1 (en) 2017-04-12 2019-05-14 BlueTalon, Inc. Yarn rest API protection
US10491635B2 (en) 2017-06-30 2019-11-26 BlueTalon, Inc. Access policies based on HDFS extended attributes
US10803190B2 (en) 2017-02-10 2020-10-13 BlueTalon, Inc. Authentication based on client access limitation
US10972506B2 (en) 2015-12-10 2021-04-06 Microsoft Technology Licensing, Llc Policy enforcement for compute nodes
CN113919000A (en) * 2021-12-16 2022-01-11 北京交研智慧科技有限公司 User database management method and device

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106034104B (en) * 2015-03-07 2021-02-12 华为技术有限公司 Verification method, device and system for network application access
CN105069370B (en) * 2015-07-22 2018-01-30 北京京东尚科信息技术有限公司 Database automatic authorization access method
CN106685901B (en) * 2015-11-10 2020-06-02 华为技术有限公司 Method for processing cross-domain data, first server and second server
KR20170077328A (en) * 2015-12-28 2017-07-06 현대자동차주식회사 System and method for management of vehicle
CN107317787A (en) * 2016-04-26 2017-11-03 北京京东尚科信息技术有限公司 Service credit method, equipment and system
CN106250778B (en) * 2016-07-27 2019-02-15 新乡学院 A kind of data security protection method of business management software
WO2018126380A1 (en) * 2017-01-05 2018-07-12 深圳市前海中康汇融信息技术有限公司 Database access control system
CN107241357A (en) * 2017-07-27 2017-10-10 郑州云海信息技术有限公司 User access control method and apparatus in cloud computing system
CN107656722B (en) * 2017-07-31 2019-03-12 平安科技(深圳)有限公司 Data manipulation method, device and computer readable storage medium
CN110309213B (en) * 2018-03-28 2023-10-13 腾讯科技(深圳)有限公司 Database access control method, device, system, medium and equipment
CN112567708A (en) * 2018-07-19 2021-03-26 马士基集装箱工业公司 Secure remote access to refrigeration control system
CN109831435B (en) * 2019-01-31 2021-06-01 广州银云信息科技有限公司 Database operation method, system, proxy server and storage medium
CN110324333B (en) * 2019-06-29 2021-12-28 北京启迪区块链科技发展有限公司 Data processing method, device, terminal and storage medium
CN112311716B (en) * 2019-07-24 2023-04-21 顺丰科技有限公司 Data access control method, device and server based on openstack
CN110598445B (en) * 2019-09-12 2022-05-20 金蝶蝶金云计算有限公司 Database access control method, system and related equipment
CN112527897A (en) * 2020-12-01 2021-03-19 深圳市鹰硕技术有限公司 Data processing method and system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044373A (en) * 1997-09-29 2000-03-28 International Business Machines Corporation Object-oriented access control method and system for military and commercial file systems
JP4852938B2 (en) * 2005-09-02 2012-01-11 富士ゼロックス株式会社 Data server, data management method and program
CN102571771B (en) * 2011-12-23 2014-06-04 华中科技大学 Safety authentication method of cloud storage system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3356964A4 (en) * 2015-09-28 2018-08-08 Bluetalon, Inc. Policy enforcement system
US10277633B2 (en) 2015-09-28 2019-04-30 BlueTalon, Inc. Policy enforcement system
US10965714B2 (en) 2015-09-28 2021-03-30 Microsoft Technology Licensing, Llc Policy enforcement system
US10972506B2 (en) 2015-12-10 2021-04-06 Microsoft Technology Licensing, Llc Policy enforcement for compute nodes
US10803190B2 (en) 2017-02-10 2020-10-13 BlueTalon, Inc. Authentication based on client access limitation
US10291602B1 (en) 2017-04-12 2019-05-14 BlueTalon, Inc. Yarn rest API protection
US10491635B2 (en) 2017-06-30 2019-11-26 BlueTalon, Inc. Access policies based on HDFS extended attributes
CN113919000A (en) * 2021-12-16 2022-01-11 北京交研智慧科技有限公司 User database management method and device
CN113919000B (en) * 2021-12-16 2022-03-29 北京交研智慧科技有限公司 User database management method and device

Also Published As

Publication number Publication date
CN104216907B (en) 2018-12-18
CN104216907A (en) 2014-12-17
WO2014207554A3 (en) 2015-03-26

Similar Documents

Publication Publication Date Title
WO2014207554A2 (en) Method and apparatus for providing database access authorization
US20220207159A1 (en) Systems and methods for privacy management using a digital ledger
US10735202B2 (en) Anonymous consent and data sharing on a blockchain
CN111783075B (en) Authority management method, device and medium based on secret key and electronic equipment
WO2019214211A1 (en) Block chain-based user data authorization method and apparatus, and medium and computing device
US9646161B2 (en) Relational database fingerprinting method and system
US9495555B2 (en) Client computer for querying a database stored on a server via a network
US8856530B2 (en) Data storage incorporating cryptographically enhanced data protection
US7827403B2 (en) Method and apparatus for encrypting and decrypting data in a database table
KR101371608B1 (en) Database Management System and Encrypting Method thereof
US11290446B2 (en) Access to data stored in a cloud
EP4002758A1 (en) Security token validation
US10911538B2 (en) Management of and persistent storage for nodes in a secure cluster
US11595398B1 (en) Access control for named domain networking
US11757877B1 (en) Decentralized application authentication
US11943345B2 (en) Key management method and related device
US9137014B2 (en) Systems and methods for controlling electronic document use
RU2475839C2 (en) Cryptographic management of access to documents
KR20120054839A (en) Method and apparatus for controlling access to data based on layer
JP7367692B2 (en) Apparatus, request apparatus, method, and program
Fakhar et al. Comparative analysis on security mechanisms in cloud
US20230418953A1 (en) Secure high scale cryptographic computation through delegated key access
Sampoornam et al. Attribute-Based Access Control for Secure Cloud Storage Structure
CN113821823A (en) Trusted data exchange sharing method, memory and processor

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: 14787246

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 14787246

Country of ref document: EP

Kind code of ref document: A2