CN110692223B

CN110692223B - Method, apparatus and system for controlling user access to a data storage system

Info

Publication number: CN110692223B
Application number: CN201780091469.2A
Authority: CN
Inventors: 保罗·克莱夫·卡斯韦尔; 西蒙·詹姆斯·查普尔; 法布里斯·克劳德·奥利弗·赫利克
Original assignee: Hitachi Data System Corp
Current assignee: Hitachi Data System Corp
Priority date: 2017-07-14
Filing date: 2017-07-14
Publication date: 2022-01-21
Anticipated expiration: 2037-07-14
Also published as: EP3652653A4; US20200004442A1; JP6894985B2; WO2019013818A1; US11036401B2; EP3652653A1; JP2020521213A; CN110692223A

Abstract

Methods, apparatus and systems control user access to a data storage system that includes a node providing data storage resources that store user accessible primary data structures and user accessible secondary data structures that are stored based on respective associated primary data structures, wherein for each secondary data structure, the data storage system stores data structure metadata indicating a parent data storage resource and an owner data storage resource of the respective secondary data structure. Upon receiving a user request to access a particular secondary data structure, determining a corresponding owner data storage resource of the particular secondary data structure, and determining whether to allow the user access to the particular secondary data structure based on an access control validation process that includes determining whether to allow the user access to the determined owner data storage resource of the particular secondary data structure.

Description

Method, apparatus and system for controlling user access to a data storage system

Technical Field

The present disclosure relates to methods, apparatus and systems for controlling user access to a data storage system, including one or more nodes providing a plurality of data storage resources, particularly in accordance with Role Based Access Control (RBAC).

Background

Backup systems for computers are well known. Backup systems provide redundant storage of data to enable a computer to be restored to a previous state after an event has occurred that results in the loss of data on the computer. As will be appreciated by those skilled in the art, data stored on a computer can be very valuable, and data loss can lead to serious economic difficulties.

Banks, stock brokerages, and other companies typically store large amounts of data on computers. These data are crucial to the daily operation of such enterprises. For example, it is readily understood that to facilitate conventional banking transactions, a bank account record, typically stored in a computer, is required.

Events such as fires, earthquakes, theft, and hard disk failures can result in loss of valuable computer data. If a unique copy of corporate data is stored on the affected computer, the loss may be permanent and may have catastrophic consequences.

However, if the data has been previously backed up, the data may be restored so that the daily operations of the enterprise may continue with minimal interruption. Therefore, a backup of the data stored on the computer is considered necessary and has generally become a routine task.

Backup systems typically include a repository (repository) and software that drives the repository. The software is configured to copy all or a portion of the data from the computer onto the media of the repository. Various different types of storage libraries are widely used. Local backup drives and digital virtual machines (DVD or DVD ROMO repositories) are typically used where data storage requirements are small, while tape storage or large disk drives are used on computers or in networks where data storage requirements are large.

The networking of computers temporarily simplifies the backup process by providing a central data storage location for multiple computers. That is, several client computers are typically connected to a server, and all data used by the client computers is stored by the server at a central location. Thus, to adequately protect data used by all client computers, only a single server needs to be backed up.

However, the ever increasing data storage capacity of client computers, and the increasing number of clients on a network, it is ultimately becoming more practical to store the large amounts of data required by client computers on the client computers themselves rather than on servers where bandwidth limitations will limit access to the data by the client computers. Thus, the problem of having to back up multiple client computers is again faced.

Government organizations have also enacted additional legal and regulatory requirements through regulation, and even local city and state regulations have mandated times and types of data that need to be archived and stored. For example, financial data may need to be archived and stored for seven years per day, while legal data may be archived and stored for five years per week. Thus, in modern networks, it is possible to backup data from multiple clients or even locations on a client computer on a selected one of multiple different repositories located at multiple different locations.

Conventional backup solutions have attempted to address some of these problems by providing information technology managers (IT managers) with the ability to manually set policies for the storage of particular data at particular locations on particular repositories designed for long term storage at very fine levels of granularity (granularity levels). Unfortunately, this process is very cumbersome and is highly impractical once it is recognized how many types of data are on any given client, the number of regulations on each type of data, how often the data must be archived, and the optimal archive location based on the data required.

IT managers therefore wish to have an integrated data management system with a central command module that can establish data sources in the data path to the storage repository through policies in a visual manner that enables the system view to also be viewed at a granular level.

Additionally, role-based access control (RBAC) is referred to as an access control scheme in which user access is controlled (i.e., access is controlled, including allowing or denying access to data structures and/or data resources based on a permission verification or access authorization process).

For example, US2008/0022370a1 relates to a system and method for Role Based Access Control (RBAC) in a content management system, wherein storage resources are assigned a level of protection. Storage resources of the same protection level share the same access control policy. Permissions granted to various roles are defined based on privilege groups and protection levels. The permissions of roles can be determined dynamically at runtime. Furthermore, as new storage resources are added, they may be assigned to pre-existing levels of protection. Thus, the new storage resource can automatically inherit the various permissions and roles attached to the protection level.

Further, US2008/0120302a1 relates to role-based resource level access control (RBAC) for storage management. The resource identification information is stored in association with role identification information for each of the plurality of roles and the operation identification information in a role-based access database for the network storage system. The operation identification information identifies one or more authorized operations for each of the plurality of roles, and the resource identification information identifies a particular resource maintained by the network storage system. The role identification information, data indicating one or more authorized operations for at least one role, and resource-specific identification information in the role-based access database are used to determine whether to allow or deny a request from a network storage client to access a resource maintained by the network storage system.

Disclosure of Invention

It is an object to provide a user access control mechanism in a data storage system of multiple storage resources that is highly flexible and efficient in configuring different allowed levels and user types or access permissions for user access, and to provide a reliable and efficient way of performing access control in a data storage system, in particular in a data storage system managing a primary data structure and secondary data structures related to the primary data structure, for data protection purposes, in particular preferably on a Role Based Access Control (RBAC) basis.

A method is presented for controlling user access to a data storage system comprising one or more nodes providing a plurality of data storage resources. Furthermore, a data storage system and a computer program product are proposed. The dependent claims relate to preferred exemplary embodiments.

According to some aspects, a method for controlling user access to a data storage system comprising one or more nodes providing a plurality of data storage resources is presented.

In some exemplary aspects, the plurality of data storage resources may store one or more primary data structures accessible by a user and/or one or more secondary data structures accessible by a user. Some or each secondary data structure may be stored based on the respective associated primary data structure.

In some exemplary aspects, for some or each secondary data structure, the data storage system may store data structure metadata indicating the parent and owner data storage resources of the respective secondary data structure. Here, the parent data storage resource of the respective secondary data structure is preferably the data storage resource storing the respective secondary data structure, and/or the owner data storage resource of the respective secondary data structure is preferably the data storage resource storing the respective associated primary data structure of the respective secondary data structure.

In some exemplary aspects, the data storage system may further store access control information indicating, for each of the one or more user accounts (and/or for each of the one or more user roles, each user account being associated with at least one user role), at least one set of resources of one or more data storage resources to which users associated with the respective user account (and/or their associated user role) are permitted user access.

According to some aspects, the method may comprise: receiving a user request to access a particular secondary data structure of the one or more secondary data structures stored on the respective parent data storage resource; determining, based on the data structure metadata stored for the particular secondary data structure, a corresponding owner data storage resource for the particular secondary data structure; and determining whether to allow access to the particular secondary data structure by a user of the user account (and/or user role) associated with the user request based on an access control validation process.

In some exemplary aspects, the access control validation process may include determining whether a user of a user account (and/or user role) associated with the user request is permitted access to the determined owner data storage resource of the particular secondary data structure based on the access control information.

In some exemplary aspects, the method may further comprise: access to a particular secondary data structure of the one or more secondary data structures based on (or in accordance with) the received user request if the access control validation process determines that access to the particular secondary data structure is allowed for a user of the user account (and/or user role) associated with the user request, and/or access to the particular secondary data structure of the one or more secondary data structures based on (or in accordance with) the received user request if the access control validation process determines that access to the particular secondary data structure is not allowed for a user of the user account (and/or user role) associated with the user request.

In some exemplary aspects, the data storage system may further include a user interface controller configured to receive a user request.

In some exemplary aspects, the data storage system may further comprise one or more resource handling controllers, wherein each resource handling controller may preferably be configured to manage user access to one or more data storage resources of the data storage system.

Preferably, the user interface controller is configured to communicate with one or more or all of the one or more resource handling controllers, for example for sending access requests to one or more or all of the one or more resource handling controllers. In some exemplary aspects, the resource handling controllers may be configured to communicate directly with each other and/or indirectly via user interface controllers.

For example, if a user logs in to access a primary data structure stored on a particular data storage resource, such as during a user session, the user's user access request for the primary data structure may be received at the user interface controller to be forwarded or communicated (or typically sent as a corresponding user request that may or may not modify the originally received request) from the user interface controller to a corresponding resource handling controller that manages the particular data storage resource storing the corresponding primary data structure.

Alternatively, while the user interface controller may still be responsible for establishing the session at the start of the session (e.g., including processing for user authentication and/or user authorization), subsequent user requests may be sent directly to the respective resource processing controller that manages the particular data storage resources that store the respective primary data structures.

Also, for example, if a user logs in to access a primary data structure stored on a particular data storage resource, e.g., during a user session, but may thereafter attempt to access a secondary data structure associated with a corresponding primary data structure stored on another data storage resource (which may or may not be managed by a different resource handling controller), the user access request to the secondary data structure by the user may be received at the user interface controller to be forwarded or transmitted (or generally sent as a corresponding user request, which may or may not modify the originally received request) from the user interface controller to the corresponding resource handling controller managing the particular data storage resource storing the corresponding secondary data structure.

Alternatively, while the user interface controller may still be responsible for establishing the session at the beginning of the session (e.g., including processing for user authentication and/or user authorization), subsequent user requests for the respective secondary data structures may be sent directly to the respective resource handling controller managing the particular data storage resource storing the respective primary data structure and/or the respective resource handling controller managing the particular data storage resource storing the respective secondary data structure.

For example, if a user request for a respective secondary data structure is received at a resource handling controller managing a particular data storage resource storing a respective associated primary data structure, in the event that the respective resource handling controller managing the particular data storage resource storing the respective secondary data structure is a different resource handling controller, the received request may be forwarded or transmitted (or typically sent as a corresponding user request which may or may not modify the originally received request) from the respective resource handling controller managing the particular data storage resource storing the respective primary data structure to the respective resource handling controller managing the particular data storage resource storing the respective associated secondary data structure.

In some aspects, the method may further comprise: performing an authorization process after a session is started (e.g., when a user of a user account (and/or user role) associated with the user request initiates a communication connection with the user interface controller), the authorization process preferably obtaining a user access control profile (profile) indicating at least one set of resources of one or more data storage resources to which the user associated with the respective user account (and/or user role) is granted user access, e.g., based on the access control information; and/or a payload indicating a user access control profile for the user associated with the respective user account (and/or user role) is preferably created by the user interface controller and/or by the authorization module or authorization device.

The payload may comprise the corresponding user access control profile information in an encoded and/or compressed format or as added information, e.g. as additional or alternative header information.

In some aspects, the method may further comprise: upon receiving a user request to access a particular secondary data structure at a user interface controller, the created payload is caused to be included (e.g., added, encoded, appended, or inserted) into the user's user request associated with the corresponding user account (and/or user role).

In some aspects, the method may further comprise: a user request including the created payload is sent from the user interface controller to a resource handling controller that manages access to parent data storage resources of a particular secondary data structure.

In some aspects, each resource handling controller may be further configured to manage data structure metadata related to secondary data structures stored on the one or more data storage resources managed by the respective resource handling controller.

For example, a resource handling controller may manage and store data structure metadata in a metadata storage portion of the respective resource handling controller relating to secondary data structures stored on one or more data storage resources managed by the respective resource handling controller.

Alternatively, the resource handling controller may illustratively store data structure metadata relating to secondary data structures stored on one or more data storage resources managed by the respective resource handling controller to the respective data storage resources managed by the respective resource handling controller. For example, the resource handling controller may illustratively store data structure metadata associated with a particular secondary data structure to a data storage resource that stores the corresponding secondary data structure, e.g., by storing the data structure metadata associated with the particular secondary data structure on the corresponding data storage resource along with or as part of the particular secondary data structure.

In some aspects, the method may further comprise: a user request including the created payload is received at a resource processing controller that manages access to a parent data storage resource of a particular secondary data structure. Preferably, the determining of the respective owner data storage resource of the particular secondary data structure and/or the determining of whether to allow access to the particular secondary data structure by a user of the user account (and/or user role) associated with the user request is performed by a resource handling controller managing access to a parent data storage resource of the particular secondary data structure, preferably based on data structure metadata managed by the respective resource handling controller and a payload comprised in the received user request.

In some aspects, determining whether to allow access to a particular secondary data structure by a user of a user account (and/or user role) associated with the user request may also be based on the determination: a determination is made based on the access control information whether a user of a user account (and/or user role) associated with the user request is granted access to a parent data storage resource of the particular secondary data structure.

In some exemplary aspects, the method may further comprise: accessing a particular secondary data structure of the one or more secondary data structures based on (or in accordance with) the received user request if the access control verification process determines that a user of the user account (and/or user role) associated with the user request is allowed access to the particular secondary data structure and/or that a user of the user account (and/or user role) associated with the user request is granted access to a parent data storage structure of the particular secondary data structure; and/or deny access to a particular secondary data structure of the one or more secondary data structures based on (or in accordance with) the received data request if the access control validation process determines that a user of the user account (and/or user role) associated with the user request is not permitted access to the particular secondary data structure and/or that a user of the user account (and/or user role) associated with the user request is not permitted access to a parent data storage structure of the particular secondary data structure.

In some exemplary aspects, a user of a user account (and/or user role) associated with a user request may be determined to allow (grant) access to a particular secondary data structure on the condition that the respective parent data storage resource of the particular secondary data structure is included in a set of resources to which the user associated with the respective user account (and/or user role) is granted user access according to the access control information.

For example, a user of a user account (and/or user role) associated with a user request may be determined to allow (grant) access to a particular secondary data structure on the condition that the respective parent data storage resource of the particular secondary data structure is included in a set of resources to which the user associated with the respective user account (and/or user role) is granted user access according to the access control information, and/or the respective owner data storage resource of the particular secondary data structure is included in a set of resources to which the user associated with the respective user account (and/or user role) is granted user access according to the access control information.

In some exemplary aspects, for each of the one or more user accounts (and/or for each of the one or more user roles, each user account associated with at least one user role), the access control information may further indicate one or more access levels indicating a range of access permitted for the respective user account (and/or user role).

In some exemplary aspects, the one or more levels of access may include at least one of: (1) a first access level that can indicate that users of respective user accounts (and/or user roles) associated with the first access level are permitted to access one or more secondary data structures on respective parent data storage resources, respective owner data storage resources of the (only) secondary data structures being included in a set of resources to which users associated with respective user accounts (and/or user roles) are permitted user access in accordance with the access control information; (2) a second access level that may indicate that a user of a respective user account (and/or user role) associated with the second access level is allowed to access (e.g., only) secondary data structures associated with one or more owner data storage resources provided by a node to which the user is currently logged in on a respective parent data storage resource, particularly if the respective associated owner data storage resource is included in a set of resources to which the user associated with the respective user account (and/or user role) is permitted user access in accordance with the access control information; and/or (3) a third access level that can indicate that a user of a respective user account (and/or user role) associated with the third access level is allowed to access, on a respective parent data storage resource, one or more (e.g., all) of the secondary data structures stored on the respective parent data storage resource, regardless of whether the one or more respective associated owner data storage resources are included in a set of resources to which the user associated with the respective user account (and/or user role) is permitted user access in accordance with the access control information.

In some exemplary aspects, for each of the one or more user accounts (and/or user roles), the access control information may also indicate at least one licensable user activity and/or at least one activity group including at least one licensable user activity that is allowed to be performed by a user associated with the respective user account (and/or user role) on a data storage resource of a set of resources to which the user associated with the respective user account (and/or user role) is granted user access.

In some exemplary aspects, determining whether to allow access to a particular secondary data structure by a user of the user account (and/or user role) associated with the user request may also be based on determining whether to permit the user of the user account (and/or user role) associated with the user request to perform a corresponding user activity requested by the user request based on the access control information.

In some exemplary aspects, the received user request may indicate a particular secondary data structure and requested activity to be performed on the particular secondary data structure. In this case, in some exemplary aspects, the method may further comprise: the requested activity is performed on the particular secondary data structure if it is determined that the respective user activity requested by the user request is permitted to be performed by the user of the user account (and/or user role) associated with the user request and the user of the user account (and/or user role) associated with the user request is allowed to access the particular secondary data structure, and/or the requested activity is denied to be performed on the particular secondary data structure if it is determined that the respective user activity requested by the user request is not permitted to be performed by the user of the user account (and/or user role) associated with the user request or the user of the user account (and/or user role) associated with the user request is not allowed to access the particular secondary data structure.

In some example aspects, the access control information may include RBAC (role-based access control) information, which may also indicate, for each of the one or more user accounts, a user role for a respective user associated with the respective user account.

In some exemplary aspects, each user role may be associated with at least one licensable user activity and/or at least one activity group including at least one licensable user activity.

In some exemplary aspects, the user access control profile may also indicate user roles associated with users associated with the respective user account, and/or the created payload may also indicate user roles associated with users associated with the respective user account.

In some exemplary aspects, the created payload is further indicative of at least one licensable user activity and/or at least one activity group including at least one licensable user activity associated with a respective user role associated with a user associated with a respective user account.

In some exemplary aspects, each resource handling controller may be further configured to manage activity metadata indicating, for each of the one or more user roles, at least one licensable user activity or at least one activity group including at least one licensable user activity associated with the respective user role.

In some exemplary aspects, determining whether to allow access to a particular secondary data structure by a user of a user account (and/or user role) associated with a user request may also be based on the determination: based on the activity metadata managed by the respective resource handling controller and the payload included in the received user request, it is determined whether to permit performance of the respective user activity requested by the user request by a user of the user account (and/or user role) associated with the user request.

In some example aspects, for each data structure, the data structure metadata may indicate one of a plurality of tenants (tenants) associated with the respective data structure, and/or for each of one or more user accounts, the access control information may indicate one of a plurality of tenants associated with the respective user account.

In some exemplary aspects, determining whether to allow access to the particular secondary data structure by a user of the user account associated with the user request may also be based on the determination of: a determination is made whether a tenant associated with a particular secondary data structure matches a tenant associated with a corresponding user account based on the access control information and the data structure metadata of the particular secondary data structure.

In some exemplary aspects, the method may further comprise: access to a particular secondary data structure of the one or more secondary data structures based on (or in accordance with) the received user request if the access control validation process determines that the tenant associated with the particular secondary data structure matches the tenant associated with the corresponding user account (and/or user role), and/or deny access to the particular secondary data structure of the one or more secondary data structures based on (or in accordance with) the received user request if the access control validation process determines that the tenant associated with the particular secondary data structure does not match the tenant associated with the corresponding user account (and/or user role).

According to some aspects, there is also presented a data storage system comprising one or more nodes providing a plurality of data storage resources configured to store one or more user-accessible primary data structures and one or more user-accessible secondary data structures, each secondary data structure being stored based on a respective associated primary data structure,

wherein the data storage system is configured to store, for each secondary data structure, data structure metadata indicating parent and owner data storage resources of the respective secondary data structure, the parent data storage resource of the respective secondary data structure being the data storage resource that stores the respective secondary data structure, and the owner data storage resource of the corresponding secondary data structure is the data storage resource that stores the corresponding associated primary data structure of the corresponding secondary data structure, and wherein the data storage system is further configured to store access control information that, for each of the one or more user accounts, the access control information indicates at least one set of resources of one or more data storage resources to which a user associated with the respective user account is granted user access.

In some aspects, the data storage system, or one or more nodes of the data storage system, may be configured to, upon receiving a user request to access a particular secondary data structure of the one or more secondary data structures stored on the respective parent data storage resource, perform: the method further includes determining, based on the data structure metadata stored for the particular secondary data structure, a corresponding owner data storage resource of the particular secondary data structure, and/or determining whether to allow access to the particular secondary data structure by a user of the user account associated with the user request based on an access control validation process that includes determining, based on the access control information, whether to grant access to the determined owner data storage resource of the particular secondary data structure by a user of the user account associated with the user request.

Further, in some aspects, a data storage system may be configured in accordance with and/or perform one or more steps of one or more of the above (and/or below) method aspects.

According to some aspects, a computer program product for controlling user access to a data storage system comprising one or more nodes providing a plurality of data storage resources is also presented. A data storage system may be provided in one or more of the aspects described above.

In some aspects, a computer program product may include computer-readable program instructions that, when run or loaded on a device or system having at least one processor, cause the at least one processor, for example, upon receiving a user request to access a particular secondary data structure of one or more secondary data structures stored on a respective parent data storage resource, to perform: determining, based on the data structure metadata stored for the particular secondary data structure, a corresponding owner data storage resource for the particular secondary data structure; and/or determining whether to allow a user of the user account associated with the user request to access the particular secondary data structure based on an access control validation process that includes determining whether to grant the user of the user account associated with the user request access to the owner data storage resource of the determined particular secondary data structure based on the access control information.

Further, in some aspects, a computer program product may comprise computer-readable program instructions that, when executed or loaded on a device or system having at least one processor, cause the at least one processor to perform one or more steps of one or more method aspects described above (and/or below), for example, upon receiving a user request to access a particular secondary data structure of the one or more secondary data structures stored on the respective parent data storage resource.

While certain exemplary aspects have been described above, it is to be understood that such aspects are merely illustrative of and not restrictive on the broad invention, and that exemplary aspects are not limited to the specific constructions and arrangements shown and described above, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, may be made.

Those skilled in the art will appreciate that various adaptations, modifications, and/or combinations of the just-described aspects may be configured. It is therefore to be understood that other aspects may be practiced other than as specifically described herein. For example, unless explicitly stated otherwise, the process steps described herein may be performed in a different order than that described herein, and one or more steps may be combined, divided, or performed simultaneously.

In view of the present disclosure, those skilled in the art will also appreciate that the different aspects described herein can be combined to form other aspects of the present disclosure.

Drawings

FIG. 1A illustrates a schematic diagram of a data system according to an exemplary embodiment.

FIG. 1B illustrates a schematic diagram of another data system, according to an exemplary embodiment.

FIG. 1C illustrates a schematic diagram of another data system, according to an exemplary embodiment.

FIG. 2 illustrates a flow chart of a process for a user authentication process, according to some exemplary embodiments.

FIG. 3 illustrates a flow chart of a process for user authorization processing, according to some exemplary embodiments.

Fig. 4 illustrates an example of an association between a user and a user-related access control profile and an association of access control profile information, according to some example embodiments.

Fig. 5A illustrates a flow chart of a process for UIC access request processing at a UIC, according to some exemplary embodiments.

Fig. 5B illustrates a flow chart of a procedure for UIC session management processing at a UIC, according to some exemplary embodiments.

Fig. 5C illustrates a flow chart of a process for UIC access request processing at a UIC, according to some other exemplary embodiments.

Fig. 5D illustrates a flow chart of a procedure for UIC session management processing at a UIC, according to some other exemplary embodiments.

Fig. 5E illustrates a flowchart of a process for UIC access request processing at a UIC, according to some other exemplary embodiments.

FIG. 6A illustrates a flow diagram of a process for storage handler access request processing at a storage handler, according to some other example embodiments.

FIG. 6B illustrates a flowchart of a process for storage handler access request processing at a storage handler, according to some other example embodiments.

FIG. 7 illustrates a distribution of data structures in an exemplary data storage system.

Detailed Description

Hereinafter, preferred aspects and embodiments of the present invention will be described in more detail with reference to the accompanying drawings. In the different figures and embodiments, the same or similar features are denoted by similar reference numerals. It should be understood that the following detailed description, in connection with various preferred aspects and preferred embodiments, is not intended to limit the scope of the invention.

As used in this specification and the appended claims, the following terms shall have the indicated meanings, unless the context requires otherwise:

a "storage device" is a device or system for storing data. The storage device may comprise one or more magnetic or magneto-optical or optical disc drives, solid state storage devices or magnetic tape. For convenience, the storage device is sometimes referred to as a "disk" or "hard disk". The data storage system may include the same or different types of storage devices having the same or different storage capacities.

A "RAID controller" is a device or system that combines the storage capacity of several storage devices into a virtual storage space, which may alternatively be referred to as a "system driver" ("SD"), "logical unit" ("LU" or "LAN"), or "volume. Typically, the SD is larger than a single storage device that extracts space from multiple storage devices and includes redundant information so that it can withstand the failure of a certain number of disks without losing data. In an exemplary embodiment, each SD is associated with a unique identifier, referred to hereinafter as a "logical unit identifier" or "LUID", and each SD is no greater than a predetermined maximum size (e.g., 2TB to 64TB or greater).

When a command is sent to the SD, the RAID controller typically forwards the command to all of the storage devices of the SD at the same time. RAID controllers help overcome the three main limitations of typical storage devices, namely, storage devices are typically the slowest components in a storage system, they are typically most likely to suffer catastrophic failures, and they typically have relatively small storage capacities.

A "RAID system" is a device or system that includes one or more RAID controllers and a number of storage devices. Typically, a RAID system will contain two RAID controllers (so that one RAID controller can continue to operate if the other RAID controller fails, and also share the load if both RAID controllers are normal) and tens of storage devices. In exemplary embodiments, a RAID system is typically configured with two to thirty-two SDs. When the file server needs to store or retrieve data, it sends commands to the RAID controller of the RAID system, which in turn is responsible for routing the commands forward to the corresponding storage device and storing or retrieving the data as needed.

With some RAID systems, a mirroring relationship may be established between SDs such that data written to one SD (referred to as a "primary SD") is automatically written to another SD (referred to herein as a "secondary SD" or "mirrored SD") by the RAID system for redundancy purposes. The secondary SD may be managed by the same RAID system as the primary SD or may be managed by a different local or remote RAID system. The mirrored SD effectively provides RAID 1+0 functionality over multiple SDs to enable recovery from loss or corruption of one SD or possibly even multiple SDs in some cases.

The "file system" is a structure of files and directories (folders) stored in the file storage system. Within a file storage system, the file system is typically managed using a number of virtual storage constructs, and in an exemplary embodiment, a hierarchy of virtual storage constructs called regions (regions), stripe sets (stripesets), and spans (spans). File system functions of the file server may include object management, free space management (e.g., allocation), and/or directory management.

An "archive" is a copy or partial copy of data created for long-term retention.

An "asynchronous copy" operation refers to a data transaction that is written to storage for backup or copy purposes and then sent to a destination. The data transactions are stored in a memory (memory) before being sent over the network and/or to the destination. Also, transactions may be kept in log files to prevent data loss in the event of a system failure. The transaction may be sent to the destination from memory and/or from a log file.

"backup" refers to a copy or partial copy of data created for operational recovery and/or disaster recovery. A backup may represent a complete copy of the entire data to be protected or may represent only a differential backup that stores data changes and/or differences since a previous backup. Further, backups may be processed continuously, such as by Continuous Data Protection (CDP) or real-time backups, where repositories are updated in a continuous manner with or without indexing using real-time update content. Further, backups may be processed in batches, e.g., periodically, where backups are created in batches. Bulk backup may refer to an operation of periodically or at least repeatedly updating a repository according to a predetermined resynchronization (e.g., involving a scan of source data for changes since a last backup), and transferring only changed data, changed files, and/or changed bytes to a destination for storage.

A "repository" may be a node (or cluster of nodes) that stores data received from a source node (or source cluster of nodes), for example, for real-time backup, batch backup, version management (versioning), and/or archiving. Version management may refer to a data protection operation that is employed by versions of a file, directory, and/or data portion as they are changed (e.g., each time a document is saved in a file, another version is retained and indexed, e.g., multiple generations of data are created based on a change history).

Exemplary System overview

In the data system of fig. 1A, a plurality of

client devices

100a and 100b (e.g., host computers) are illustratively connected to a network server 200 via a communication network. The networks in fig. 1A may each be implemented as a wired communication network (e.g., LAN) or a wireless communication network (e.g., WLAN), or may be represented by an internet connection, or in some example embodiments, each communication network may be interchangeable with a direct communication connection (wired or wireless).

Users of

client devices

100a and 100b may, for example, access web server 200 via a web browser (e.g., using an HTML interface and/or REST interface or other message transfer protocol interface), and/or they may access web server 200 via a CLI (command line interface) (e.g., using a REST interface or other message transfer protocol interface), and web server 200 may, for example, provide web browsers of

client devices

100a and 100b with multiple web pages or other types of HTML documents.

On the other hand, the web server 200 in the data system of fig. 1A is illustratively connected to the external storage system 900 via another communication network (or via the same communication network), and the web server 200 is also illustratively connected to the UIC (user interface controller) device 300 via another communication network (or via the same communication network).

The UIC device 300 is illustratively connected to the administrative computer 800, the authentication device 600, and the authorization device 700 via another communication network via another network (or via the same communication network).

Further, the UIC device 300 (user interface controller) is illustratively connected to the plurality of

storage handler devices

400a, 400b, and 400c (resource handling controllers) via another communication network via another network (or via the same communication network).

Illustratively, the (first) storage handler device 400a is communicatively connectable via another communication network (or via the same communication network) to a plurality of storage nodes 500a (e.g., a first source node) and 500b (e.g., a first destination node) via another network. Further illustratively, the (second) storage handler device 400b is communicatively connectable to the storage node 500c (e.g., a second source node) via another communication network (or via the same communication network) via another network, and the storage node 500c is communicatively connectable to the storage node 500d (e.g., a second destination node).

In the above, a storage node may exemplarily be a physical storage device providing one or more storage means for data storage. Further, a storage node may be a logical storage unit that provides one or more storage volumes (volumes) for data storage. In other exemplary embodiments, the storage node may represent a storage cluster having a plurality of cluster nodes providing a unified storage space. In general, a storage node may represent a physical, logical, or virtual storage entity for storing data.

In general, a source node may represent an entity or machine (e.g., a server, workstation, or virtual machine) that stores data to be managed. The source node may be configured to monitor one or more file systems of the host and to perform and initiate data protection operations according to user-defined data protection policies. The source node may be configured to store data, transmit locally stored data, or implement data tracking, blocking, or auditing functions.

The destination node may represent an entity or machine (e.g., a server, file server, workstation, or virtual machine) configured to receive (and store) data, such as a repository or general-purpose system designated as a recipient of the data in a replication configuration.

In general, a data protection policy is a configurable target that is mapped to a node or group of nodes and defines at least a source node and a destination node. That is, at an abstraction level, a data protection policy defines at least one of a source (source node) of a data protection operation, data to be protected managed by the source node, and a destination (destination node) of the data protection operation performed on the managed data.

In addition, the data protection policy may also define data movement operations according to a defined data path between the source node and the destination node. The data move operation may define the type and/or direction of data protection operations to be performed between the source node and the destination node, such as mirroring operations, copy operations, backup operations (e.g., bulk backup and/or live backup), snapshot operations, archive operations, versioning operations, and whether data movement should occur in bulk (e.g., bulk backup) or continuously (e.g., continuous data protection or as live backup) or whether data is moved synchronously or asynchronously with the temporary storage of data into a log file.

Further, for each data protection operation or group of multiple parallel or linked data protection operations, the data protection policy may include additional policy information, such as a protection target, including a data retention time (e.g., the time that the data stored by the data protection operation should be retained at the destination node receiving the data), a frequency, periodicity, or time window (e.g., a recovery point target, etc.) that the data protection operation should occur. Further, other goals may define which data needs to be protected (e.g., based on file type, relationship to application, based on user group or individual user identity, etc.) and other time constraints (e.g., excluded time windows in which data protection operations should not occur, etc.).

In fig. 1A, a user may log in to the data storage system via the

client device

100a or 100b, or an administrator may log in to the data storage system via the management computer 800, for example. However, such a management computer 800 may be optional. For example, in some example embodiments, each

client device

100a or 100b may act as an administrative computer because a user with administrative access privileges may log in as an administrator via the

client device

100a or 100b (e.g., under the user role of "administrator" associated with administrative access privileges).

The management computer 800 (and/or the

client device

100a or 100b when a user logs in as an administrator via the

client device

100a or 100b) may be configured to be able to change settings, management configurations, and policies (e.g., data protection policies) of the data storage system.

The UIC device 300 is illustratively configured to manage user access interactions with the data storage system (e.g., managing routing of user access requests), e.g., managing access requests to data stored on one or more storage nodes 500 a-500 d or even to the external storage system 900.

Thus, in an exemplary embodiment, the UIC device 300 may illustratively be configured for user communication via a user interface (e.g., graphical user interface/GUI or command line interface/CLI) via the web server 200. In an exemplary embodiment, the user interface may be provided to the client on the web server 200 or through the web server 200. In other embodiments, the user interface may be provided to the client through the UIC device 300 directly or indirectly via the web server 200.

The UIC device 300 is configured to communicate a user access request received at the UIC device 300 from one of the

client devices

100a and 100b and/or the administrative computer 800 to the storage handler devices 400 a-400 c. In particular, the UIC device 300 may illustratively be configured to route user access requests to one or more responsible

storage handler devices

400a, 400b, and 400c, which illustratively will manage execution of the respective user access requests.

Each

storage handler device

400a, 400b, and 400c may be configured to manage data storage resources provided by the storage nodes 500a through 500d or the external storage system 900. For example, each

storage processor device

400a, 400b, and 400c (resource handling controller) may be configured to manage one or more storage nodes of the data storage system or one or more storage resources provided on one or more storage nodes, and in particular, each storage node and/or storage resource of the data storage system may be managed and/or controlled by an associated storage processor device (resource handling controller).

For example, in fig. 1A, storage handler device 400a may be configured to manage one or more data storage resources provided by storage nodes 500a and 500b, while storage handler device 400b may be configured to manage one or more data storage resources provided by storage nodes 500c and 500 d.

Illustratively, the data protection operation may comprise copying data from the storage node 500a to the storage node 500b managed by the storage handler device 400a or even copied by the storage handler device 400a, illustratively, the data protection operation may comprise copying data from the storage node 500c to the storage node 500d managed by the storage handler device 400b, the storage handler device 400b instructing such a copy operation to be performed by the storage node 500c to copy data to the storage node 500d (illustratively, not directly connected to the storage handler device 400 b).

Further illustratively, the storage handler device 400c may be configured to manage one or more data storage resources provided by the external storage system.

In fig. 1A, an external storage system 900 is exemplarily connected to the web server 200. In other exemplary embodiments, an external storage system 900 may also be connected to the UIC device 300 and/or one or more storage handler devices 400a to 400 c.

Preferably, management of access to the external storage system 900 is managed by one or more responsible storage handler devices 400a to 400c, but messages or access requests from one or more storage handler devices 400a to 400c to the external storage system 900 may be sent directly or may be routed via the UIC device 300 and/or the web server 200.

For example, for a connection to the external storage system 900, one or more responsible storage handlers may interface with the external storage system 900.

For example, user requests to external storage system 900 may be routed via network server 200 and UIC device 300, and/or responsible storage handler devices will interact with external storage system 900 (e.g., routed directly or indirectly via UIC device 300 and/or network server 200).

In some exemplary embodiments, the external storage system 900 may be directly connected to the UIC device 300 and/or one or more storage handler devices, e.g., not via the web server 200.

In the data system of fig. 1B, similar to fig. 1A, a plurality of client devices 100a and 100B (e.g., host computers) are illustratively connected to a web server 200 via a communication network.

The web server 200 in the data system of fig. 1B is illustratively connected to the external storage system 900 via another communication network (or via the same communication network), and the web server 200 is also illustratively connected to the UIC (user interface controller) module 301 of the storage management device 1000 via another communication network (or via the same communication network).

Illustratively, the storage management device 1000 includes the UIC module 301, and further includes a plurality of storage handler modules 401a to 401 c. UIC module 301 may function and/or provide similar processing functionality similar to UIC device 300 of fig. 1A. The storage handler modules 401A to 401c may function and/or provide similar processing functionality similar to the storage handler devices 400a to 400c in fig. 1A.

The UIC module 301 of the storage management device 1000 is illustratively connected to the management computer 800, the authentication device 600, and the authorization device 700 via another communication network via another network (or via the same communication network).

Further, UIC module 301 (user interface controller) is illustratively communicatively connected to a plurality of

storage handler modules

401a, 401b, and 401c (resource handling controllers) within the storage management device 1000 environment.

Illustratively, the (first) storage handler module 401a is communicatively connected to a plurality of storage nodes 500a (e.g., a first source node) and 500b (e.g., a first destination node) via another communication network (or via the same communication network) via another network. Further illustratively, the (second) storage handler module 400b is communicatively connectable to the storage node 500c (e.g., a second source node) via another communication network (or via the same communication network) via another network, and the storage node 500c is communicatively connectable to the storage node 500d (e.g., a second destination node).

In fig. 1B, a user may log in to the data storage system via the client device 100a or 100B, or an administrator may log in to the data storage system via the management device 800, which is exemplarily connected to the storage management device 1000. However, such a management computer 800 may be optional. For example, in some example embodiments, each

client device

The management device 800 (and/or the

client device

100a or 100b when a user logs in as an administrator via the

client device

UIC module 301 is illustratively configured to manage user access interactions with the data storage system (e.g., manage routing of user access requests), for example, to manage access requests to data stored on one or more storage nodes 500 a-500 d or even to external storage system 900.

Thus, in an exemplary embodiment, UIC module 301 may illustratively be configured for user communication via a user interface (e.g., graphical user interface/GUI or command line interface/CLI) via web server 200. In an exemplary embodiment, the user interface may be provided to the client on the web server 200 or through the web server 200. In other embodiments, the user interface may be provided to the client through UIC module 301 directly or indirectly via web server 200.

UIC module 301 is configured to communicate user access requests received at UIC module 301 from one of

client devices

100a and 100b and/or management computer 800 to storage handler devices 400 a-400 c. In particular, UIC module 301 may illustratively be configured to route user access requests to one or more responsible

storage handler devices

401a, 401b, and 401c, which illustratively will manage execution of the respective user access requests.

Each

storage handler module

401a, 401b, and 401c may be configured to manage data storage resources provided by the storage nodes 500 a-500 d or the external storage system 900. For example, each

storage handler module

401a, 401b, and 401c (resource handling controller) may be configured to manage one or more storage nodes of the data storage system or one or more storage resources provided on one or more storage nodes, in particular, each storage node and/or storage resource of the data storage system may be managed and/or controlled by an associated storage handler device (resource handling controller).

For example, in fig. 1B, storage handler module 401a may be configured to manage one or more data storage resources provided by storage nodes 500a and 500B, while storage handler module 401B may be configured to manage one or more data storage resources provided by storage nodes 500c and 500 d.

Illustratively, the data protection operation may include copying data from the storage node 500a to the storage node 500b managed by the storage handler module 401a or even copied through the storage handler module 401a, illustratively, the data protection operation may include copying data from the storage node 500c to the storage node 500d managed by the storage handler module 401b, the storage handler module 401b instructing such a copy operation to be performed by the storage node 500c to copy data to the storage node 500d (illustratively, not directly connected to the storage handler module 401 b).

Further illustratively, the storage handler module 401c may be configured to manage one or more data storage resources provided by the external storage system.

Thus, as a difference from fig. 1A, in the exemplary embodiment according to fig. 1B, the UIC module 301 and the storage handler modules 401A to 401B are implemented on the same storage management device 1000, rather than as separate devices as exemplarily shown in fig. 1A. In further exemplary embodiments, UIC module 301 may be implemented on one device, while storage handler modules 401a through 401b may be implemented on another device.

In general, the UIC (user interface controller) and the storage processor (resource processing controller) may be implemented by hardware (including machines, workstations, computers, servers, or also machine clusters, workstation clusters, computer clusters, server clusters, etc.) or software (e.g., by separate or combined software modules executable on machines, workstations, computers, servers or also executable on machine clusters, workstation clusters, computer clusters, server clusters, etc., or as a uniformly distributed cloud service) or any combination of hardware and software (e.g., as a virtual machine or running on one or more virtual machines, etc.).

A benefit provided by having storage handlers (resource handling controllers) as software modules is that when additional storage nodes or storage systems are added to provide additional manageable storage resources, such newly added storage resources may be allocated to be managed by one or more of the one or more previously established storage handler modules (resource handling controllers) or one or more new storage handler modules may be initiated, created or installed to manage the one or more newly added storage resources. For example, in some exemplary embodiments, for each newly added storage resource and/or each newly added storage node, a respective new storage handler module (resource handling controller) may be launched, created, or installed to manage the respective newly added storage resource and/or each newly added storage node.

In fig. 1B, an external storage system 900 is exemplarily connected to the web server 200. In other exemplary embodiments, an external storage system 900 may also be connected to the storage management device 1000.

Preferably, the management of access to the external storage system 900 is managed by one or more responsible storage handler modules 401a to 401c, but messages or access requests from the storage handler modules 401a to 401c to the external storage system 900 may be sent directly or may be routed via the UIC module 301 and/or the web server 200.

For example, user requests to external storage system 900 may be routed via network server 200 and UIC module 301, and/or responsible storage handler modules will interact with external storage system 900 (e.g., routed directly or indirectly via UIC device 300 and/or network server 200).

In some exemplary embodiments, the external storage system 900 may be directly connected to the UIC module 301 and/or one or more storage handler modules, e.g., not via the web server 200.

In the data system of fig. 1C, similarly to fig. 1A and 1B, a plurality of client devices 100a and 100B (e.g., host computers) are exemplarily connected to the network server 200 via a communication network, the network server 200 is exemplarily connected to the external storage system 900 via another communication network (or via the same communication network), and the network server 200 is further exemplarily connected to the UIC (user interface controller) module 301 of the storage management device 1001 via another communication network (or via the same communication network).

Illustratively, the storage management device 1001 includes the UIC module 301, and also includes a plurality of storage handler modules 401a to 401 c. UIC module 301 may function and/or provide similar processing functionality similar to UIC device 300 of fig. 1A and UIC module 301 of fig. 1B. The storage handler modules 401A to 401c may function and/or provide similar processing functionality similar to the storage handler devices 400a to 400c in fig. 1A and the storage handler modules 401A to 401c in fig. 1B.

The UIC module 301 of the storage management device 1001 is illustratively connected to the management module 801, the authentication module 601, and the authentication module 701 via another communication network (or via the same communication network) via another network, and the management module 801, the authentication module 601, and the authentication module 701 are also illustratively included in the storage management device 1001.

Further, similar to the configuration in fig. 1B, UIC module 301 (user interface controller) is illustratively communicatively connected to a plurality of

storage handler modules

401a, 401B, and 401c (resource handling controllers) within the storage management device 1001 environment.

In fig. 1C, for example, a user may log in to the data storage system via the

client device

100a or 100b, or an administrator may log in to the data storage system via the management module 801 of the storage management device 1001. In some example embodiments, each

client device

The management module 801 (and/or the

client device

100a or 100b when a user logs in as an administrator via the

client device

100a or 100b) may be configured to be able to change settings, management configurations, and policies (e.g., data protection policies) of the data storage system. However, such a management module 801 may be optional. For example, in some example embodiments, each

client device

The management module 801 may communicate via a user interface to enter its configuration, settings and changes at the storage management device 1001, for example via a GUI (graphical user interface) and/or CLI (command line interface). In an exemplary embodiment, the user interface may be provided to the client on the web server 200 or through the web server 200. In other embodiments, the user interface may be provided to the client through UIC module 301 directly or indirectly via web server 200.

For example, the management module 801 may be configured to be accessed via a graphical user interface and/or a command line interface provided to one or more client devices via the web server 200. Then, the user can log in to the data storage system via the

client device

100a or 100b to change the management setting by accessing the management module 801.

The management module 801 may be provided by software and/or hardware. In some exemplary embodiments, management module 801 may be part of UIC module 301 or included in UIC module 301. UIC module 301 is illustratively configured to manage user access interactions to the data storage system, e.g., to manage access requests to data stored on one or more storage nodes 500 a-500 d or even to external storage system 900.

Thus, in an exemplary embodiment, UIC module 301 may be illustratively configured to provide a user interface (e.g., graphical user interface/GUI or command line interface/CLI) for a user via web server 200 to be provided at a respective client device/computer by web server 200.

client devices

100a and 100b and/or management module 801 to storage handler modules 401a through 401 c.

In particular, UIC module 301 may illustratively be configured to route user access requests to one or more responsible

storage handler modules

401a, 401b, and 401c, which illustratively will manage the execution of the respective user access requests.

Each

storage handler module

For example, for a connection to the external storage system 900, one or more responsible storage handlers may interface with the external storage system 900. For example, a user request to external storage system 900 may be routed via network server 200 and UIC module 301, and one or more responsible storage handlers will interact with external storage system 900 (e.g., directly or indirectly via UIC module 301 and network server 200). In some exemplary embodiments, the external storage system 900 may be directly connected to the UIC module 301 and/or one or more storage handler modules, e.g., not via the web server 200.

In FIG. 1C, for example, storage handler module 401a may be configured to manage one or more data storage resources provided by storage nodes 500a and 500b, while storage handler module 401b may be configured to manage one or more data storage resources provided by storage nodes 500C and 500 d.

Thus, unlike fig. 1A, but similar to fig. 1B, in the exemplary embodiment according to fig. 1C, the UIC module 301 and the storage handler modules 401A to 401B are implemented on the same storage management device 1001, rather than as separate devices as exemplarily shown in fig. 1A. In further exemplary embodiments, UIC module 301 may be implemented on one device, while storage handler modules 401a through 401b may be implemented on another device.

In fig. 1C, an external storage system 900 is exemplarily connected to the storage management apparatus 1001. In other exemplary embodiments, the external storage system 900 may also be connected through the web server 200.

For example, user requests to external storage system 900 may be routed via network server 200 and UIC module 301, and/or responsible storage handler modules will interact with external storage system 900 (e.g., routed directly or indirectly via UIC module 301 and/or network server 200).

Furthermore, the management module 801, the authentication module 601 and the authorization module 701 are illustratively implemented on the same storage management device 1001, rather than as separate devices as illustratively shown in fig. 1A and 1B.

In general, the management, authentication and authorization devices/modules may be implemented by hardware (including machines, workstations, computers, servers, or also machine clusters, workstation clusters, computer clusters, server clusters, etc.) or software (e.g., by separate or combined software modules executable on machines, workstations, computers, servers or also on machine clusters, workstation clusters, computer clusters, server clusters, etc., or as a uniformly distributed cloud service) or any combination of hardware and software (e.g., as a virtual machine or running on one or more virtual machines, etc.).

In the above exemplary embodiments, the respective storage handler devices/modules may be responsible for, for example, managing the source node and/or the destination node and processing, managing or controlling data protection operations performed from the source node to the destination node. Alternatively or additionally, a different storage handler device/module may manage a source node or data storage resource provided by a source node, a destination node for the source node or data storage resource provided by a destination node being managed by another storage handler device (s)/module, and a different storage handler device/module may manage a destination node or data storage resource provided by a destination node for which a source node or data storage resource provided by a source node is managed by another storage handler device (s)/module. Further, in an exemplary embodiment, one or more storage handler devices/modules may manage only the source node or data storage resources provided by the source node, while one or more other storage handler devices may manage only the destination node or data storage resources provided by the destination node.

Exemplary user authentication Process

For user authentication purposes, UIC device 300 (or UIC module 301), also referred to herein simply as a UIC (user interface controller), is illustratively configured to communicate with authentication device 600 (or authentication module 601), also referred to herein simply as an "authentication module".

For example, if a user logs in to the UIC from a client computer (client device) via a graphical user interface, a command line interface, or another user interface provided by web server 200, a corresponding login request may be received at the UIC indicating a username (or other user identifier) and password.

Such a username (or other user identifier) and password may have been entered by the respective user to the UIC (user interface controller) via a user interface (e.g., CLI or GUI, etc.) of the web server 200 provided at the client device.

FIG. 2 illustrates a flow chart of a process for user authentication, according to some exemplary embodiments.

Illustratively, in step S21, the UIC (user interface controller) receives a login request, e.g., via web server 200, including a username (and/or user role; if user role is not included, as may be the case in typical exemplary embodiments, the user role may optionally be determined later based on a user profile associated with the username). The login request also illustratively includes a password from the user input. The password may be transmitted with the login request in an encoded and/or encrypted format (e.g., the password may be hashed by a predetermined hash function or hash algorithm). In addition, the password may be sent over the network using other encryption techniques (e.g., by using TLS and/or SSL encryption such as SSLv 3).

In some exemplary embodiments, the login request may also indicate a user domain (user domain) of the user attempting to login to the data storage system. The term "user domain" or simply "domain" as used throughout the specification may refer to a domain (e.g., an active directory domain) in a narrower sense, or it may also refer to an authentication space of a user in a broader sense. A user domain or in a general way a domain may be seen as a group of users to which users may be added (or from which users may be deleted) and which may also have one or more subgroups.

In step S22, the UIC sends the received login request or the corresponding login information obtained or decoded from the login request to the authentication module. In the case of multiple user domains, the data storage system may comprise multiple authentication modules (modules, devices or systems), for example, in which case each authentication module may be responsible for user authentication of users of a respective one or more of the multiple user domains.

In such an exemplary embodiment, step 22 may further comprise determining the user domain of the respective user associated with the login request received at the UIC and determining the responsible authentication module to send the received login request (or the corresponding login information retrieved or decoded from the login request) to the determined authentication module.

In step S23, the authentication module, upon receiving a login request from the UIC (or corresponding login information obtained or decoded from the login request), checks the login request (or user login information) received from the UIC in association with the user to determine whether the user can be authenticated based on authentication data stored in the database of the authentication module.

For example, if the authentication data stored in the database of the authentication module has authentication data for a username of the respective user associated with the user login request, and if the password or encrypted representation thereof matches the authentication data for the username of the respective user associated with the user login request, it may be determined that the authentication of the user was successful. The user's authentication may be determined to be successful in other ways.

In some example embodiments, the authentication process may be performed by using an external authentication service/system, such as by checking the user's credentials against a third party authentication system (e.g., an active directory, LDAP, or local security service on the local and/or remote computer). In such a case (e.g., instead of the authentication process described below), authentication may be granted or denied based on interaction with a third party authentication system; and steps S23, S24, S25, and/or S27 may be performed by a third party authentication system.

In step S23, the authentication module illustratively checks whether the user authentication of the respective user associated with the user login request was successful, e.g., for the user login request actually being associated with a pre-registered user (i.e., the user is who they purport to be).

If step S23 returns a "NO," the authentication module may simply send a denial message to the UIC in step S25, and the UIC may deny access in step S26 (e.g., by instructing the web server 200 to provide an error or access denial message to the user). The process may then end.

On the other hand, if step S23 returns yes, the authentication module sends a confirmation message (e.g., including user information associated with the authenticated user) to the UIC in step S27, and upon receipt of the confirmation, the UIC initiates a session start, illustratively for the user associated with the login request, in step S28, and continues the user authorization process for access control purposes in step S29 (see, e.g., fig. 3).

In some exemplary embodiments, the information called "user information" transmitted in S27 may be user certificate information.

In some exemplary embodiments, the user credential information may confirm the username (and optionally the user domain) of the user associated with the login request, or in other exemplary embodiments, the user credential information may include a user identifier, such as a user ID, or the like. It may optionally additionally include a hash value of the user password. However, such information typically does not include a user password.

In other exemplary embodiments, the user information transmitted in S27 may not transmit individual user information such as a user name, but the user information may include "membership information" or "group information" about a group to which the user belongs. For example, such user "membership information" may indicate at least one of a group to which the user belongs and/or a domain of the user.

The information transmitted in S27 may be used in the authorization process of the exemplary embodiments described below.

It is noted that the above authentication process is optional, and in a secure environment, the user authentication process may be skipped in some exemplary embodiments. Further, a simpler authentication process may be used, and a user authentication process may also be implemented in the UIC to be directly performed by the UIC.

Further, while the above-described exemplary authentication process relies on the use of passwords, it is noted that other authentication processes for identifying a particular user associated with a login request may also be (alternatively or additionally) performed based on biometric information such as facial recognition, voice recognition, and/or fingerprint recognition, and/or may also be (alternatively or additionally) performed based on touch screen finger pattern authentication, and the like.

Exemplary user authorization Process (Access control authorization)

The UIC is illustratively configured to communicate with an authorization module/device for user authorization purposes, e.g., in conjunction with access control. For example, if a user logs in to the UIC (e.g., from a client computer (client device) via a graphical user interface, a command line interface, or another user interface provided by web server 200), a corresponding login request may be received at the UIC indicating a username (or other user identifier).

After performing an optional authentication process, such as described above, the UIC may perform initiation of an authorization process based on the username of the user associated with the login request.

Further, the UIC (user interface controller) may perform the initiation of the authorization process based on user information (e.g., user credential information or membership information) of the user associated with the login request provided by the authentication process described above, for example, by using a username and/or user identifier (e.g., user ID, etc.) or by using information about the group and/or domain of the user.

Illustratively, in some exemplary embodiments, user authorization is performed using a role-based access control (RBAC) scheme. However, while the use of a role-based access control (RBAC) scheme is a preferred exemplary aspect, in some exemplary embodiments, other access control schemes (without a defined user role) may be used.

In general, a role-based access control (RBAC) scheme may define associations between each of one or more user roles and one or more permitted user activities of users associated with the respective user roles, e.g., because each user associated with a particular user role may be permitted to perform (or request to perform) activities associated with the particular user role.

Such an association between each of the one or more user roles and one or more permitted user activities of the user associated with the respective user role may be defined in an affirmative manner, i.e., for each user role, such an association defines one or more activities permitted for the user of the respective user role. In some exemplary embodiments (additionally or alternatively), such an association between each of the one or more user roles and one or more permitted user activities of the user associated with the respective user role may optionally be defined in a negative manner, i.e. such an association defines, for each user role, one or more activities of a plurality of activities that are not permitted for the user of the respective user role.

If another access control scheme (without a defined user role) can be used, the access control scheme can directly define the association between each of the one or more users and one or more permitted user activities associated with the respective user, for example because each user can be permitted to perform (or request to perform) the activities respectively associated with them.

Such an association between each of the plurality of users and the one or more permitted user activities associated with the respective user may be defined in an affirmative manner, i.e., for each user, such an association defines one or more activities permitted for the respective user. In some exemplary embodiments (additionally or alternatively), such an association between each user of the plurality of users and one or more permitted user activities associated with the respective user may be defined in a negative manner, i.e., for each user, such an association defines one or more activities of the plurality of activities that are not permitted for the respective user.

However, although the present disclosure is not so limited, in some exemplary embodiments, the use of a role-based access control (RBAC) scheme is a preferred exemplary aspect, as such role-based access control (RBAC) need not define a permissive association for each individual user (in the case of hundreds or even thousands of users in the system), but may instead allow the definition of different groups of users (fewer in number than the total number of users), each associated with a particular user role, associated with one or more of the permissive specific groups. In addition, adding new users to the system (even a new group of users) is more efficient, since one or more new users may be assigned only appropriate user roles that may have been previously defined, or new user roles may be efficiently defined for a new group of many users.

In general, user roles may be associated with one or more activities and/or activities of one or more activity groups, with a user of a particular user role being allowed to perform the one or more activities and/or activities of one or more activity groups associated with the particular user role. For example, a first user role may allow a first activity and/or a first set of activities to be performed, while another second role may allow a second activity and/or a second set of activities to be performed.

Further, it should be noted that in some exemplary embodiments, user roles may also be associated with or otherwise controlled with respect to resources, for example because a particular user role may be associated with a particular activity that may be performed on a particular resource by a user of the respective user role. For example, a first user role may allow a first activity (and/or first set of activities) to be performed on a first resource (and/or first set of resources), while another second role may allow a second activity (and/or second set of activities) to be performed on a second resource (and/or second set of resources).

Further, in some example embodiments, user roles may be associated with resources such that user roles may be associated with particular resources on which activities are allowed to be performed. For example, a first user role may allow one or more activities to be performed on a first resource (and/or first set of resources), while another second role may allow one or more activities to be performed on a second resource (and/or second set of resources).

While exemplary aspects of the user authorization process will be described below, general exemplary aspects of the user authorization process are described herein below in connection with FIG. 3.

In this example, the access permissions of the user will be described in the access control profile information associated with the particular user that is currently logged into the system. Illustratively, the UIC performs such user authorization procedures, illustratively after the session begins (i.e., after the user logs in, and optionally after confirming a successful user authentication procedure).

Illustratively, in step S31 (e.g., after the authentication process described above, or directly after receiving a login request from a particular user), the UI controller (UIC) initiates a user authorization process and sends a corresponding authorization request (e.g., indicating the identity of the user, such as by using the user' S username, user ID or credential information of the user, and/or indicating the group and/or domain of the user, received from the authentication module or authentication device 600) to the authorization module/device.

The authorization module receives the corresponding authorization request for the user associated with the login request and, in step S32, looks up its authorization database, which may store associations between multiple users and one or more access control profiles. The authorization database may store associations with access control profiles for individual users (e.g., one or more associated access control profiles for each user), groups of users (e.g., one or more associated access control profiles for each group of users), and/or user domains (e.g., one or more associated access control profiles for each domain of users).

Thus, the authorization device/module is configured to determine one or more access control profiles for the respective user (and/or user group and/or user domain), i.e. one or more access control profiles associated with the respective user (and/or user group and/or user domain), and/or one or more access control profiles associated with a user role of the respective user (and/or user group and/or user domain), based on the corresponding authorization request of the user associated with the login request.

For example, the authorization database may store, for each of a plurality of users (and/or user groups and/or user domains), one or more access control profiles associated with the respective user (and/or user group and/or user domain), and/or the authorization database may store, for each of the one or more access control profiles, zero, one or more users (and/or user groups and/or user domains) associated with the respective access control profile.

Additionally or alternatively, the authorization database may store, for each of the one or more user roles, one or more access control profiles associated with the respective user role, and/or the authorization database may store, for each of the one or more access control profiles, one or more user roles associated with the respective access control profile. The authorization database may then preferably further store for each of a plurality of users (and/or user groups and/or user domains) one (or more) user roles associated with the respective user (and/or user group and/or user domain), and/or the authorization database may preferably further store for each of the one or more user roles zero, one or more users (and/or user groups and/or user domains) associated with the respective user role.

In further exemplary embodiments, the authorization database may store user group information associating each of the plurality of users with a respective one of the one or more user groups and/or user group information associating each of the one or more user groups with a respective one of the plurality of users. In such an exemplary embodiment, the authorization database may also store access control profile association information associating each of the one or more user groups with one or more access control profiles and/or associating one or more access control profiles with one or more user groups.

Herein, a group may also refer to a user domain (e.g., a user)bob@domain.comAndmary@domain.comcan be of the same domain "@Com "), and/or a group may also refer to a group of multiple users in a group (e.g., a subgroup of all users that are a particular domain).

In general, based on the foregoing, by looking up the respective users associated with the respective login requests in an authorization database, the authorization module/device is able to determine one or more access control profiles associated with the respective users associated with the respective login requests, e.g., directly via an association between the user and the access control profile, or indirectly via an association including determining a user group and/or user role associated with the respective users associated with the respective login requests.

As explained in more detail below, each access control profile may be related to respective access control profile information, and in a preferred exemplary aspect, the access control profile information of a particular access control profile may preferably indicate at least one or more activities (or user activities) permitted to be performed (or permitted to be performed by a user request determined to be associated with the respective access control profile) and one or more storage resources (e.g., provided by or represented by the aforementioned storage node, e.g., in the sense that the storage node or group of storage nodes may represent data storage resources and/or the storage node or group of storage nodes may provide one or more storage resources) permitted to be accessed by a user determined to be associated with the respective access control profile (e.g., the user is permitted to perform or request a permitted activity on the one or more data storage resources).

In addition to (or as an alternative to) the foregoing, in a preferred exemplary aspect, the access control profile information of a particular access control profile may preferably indicate at least one or more activities permitted to be performed by a user (or user activities) and one or more data storage resources permitted to be accessed by a user determined to be associated with the respective access control profile, the access control profile information of the particular access control profile may indicate one or more resource groups, each resource group being associated with one or more data storage resources.

In addition to (or in the alternative to) the above, where in a preferred exemplary aspect the access control profile information of a particular access control profile may preferably indicate at least one or more activities permitted to be performed by a user (or user activities) and one or more data storage resources permitted to be accessed by a user determined to be associated with the respective access control profile, the access control profile information of the particular access control profile may indicate one or more activity groups, each activity group being associated with one or more permitted activities (and the access control profile information of the particular access control profile may indicate zero or more activities, e.g., additional activities, in addition to the activity group).

Further preferably, in a role-based access control (RBAC) scheme, the access control profile information for a particular access control profile may indicate one or more user roles, each user role preferably associated with one or more activity groups (each activity group being associated with one or more activities) and zero or more activities or one or more activities (e.g., if there is already at least one association with an activity group).

Further preferably, in some exemplary embodiments, the access control profile information for a particular access control profile may, for example, preferably indicate one or more levels of access (e.g., one level of access per resource group). The level of access and its exemplary effects are described further below.

Illustratively, the access control profile of FIG. 4 is based on Role Based Access Control (RBAC), wherein the present invention is not limited to Role Based Access Control (RBAC), as described above. For example, instead of (or in addition to) associating each user of a plurality of users with at least one user role and associating each user role with one or more respective access control profiles, users may be directly associated with respective one or more access control profiles, e.g., without using a user role.

In general, in a preferred exemplary aspect, each user of a plurality of users is associated with one or more access control profiles (e.g., based on their user identity, based on one or more user groups of a particular domain to which the user belongs, and/or based on one or more domains to which the user belongs).

ACP (access control profile) associations are represented by administrative information that associates each of a plurality of users with a respective one or more access control profiles.

For example, an authorization database of the authorization module/device may store access profile association information that may indicate one or more of the following:

one or more associations (access control profile associations), wherein each association may be provided for an individual user, a group of users (user group), and/or a domain;

each association may indicate (or contain) one or more access control profiles;

each access control profile may indicate (or contain) a user role and/or a group of resources;

in each access control profile, an access level is preferably specified for each group of resources;

each user role can be associated with one or more activities and/or one or more activity groups, where each activity group can be associated with one or more activities (user activities);

each resource group may be associated with one or more storage resources.

In view of the above, if it is determined that a user (or a group of users to which the user belongs) is associated with a particular access control profile (access control profile association), the user may be granted access to allow him to perform/conduct one or more activities associated with the user role indicated in the access control profile and/or one or more activities associated with the group of activities associated with the user role on a storage resource included in the one or more groups of resources indicated in the associated access control profile according to the respective access levels indicated for the respective groups of resources.

It is noted that a particular user may be associated with multiple access control profiles. For example, if the authorization database stores access control profiles for individual users, groups of users, and domains, the users may be provided withbob@domain.comA plurality of access control profiles are allocated, for example a first access control profile ACP1 associated with an individual user "bob", a second access control profile ACP2 associated with the domain com ", and potentially further one or more access control profiles associated with one or more user groups to which the user" bob "may belong.

For example, fig. 4(a) illustrates that user "user 1" (of the plurality of users) is associated with access control profile "ACP 1" (of the plurality of access control profiles), as exemplarily illustrated by the arrows in fig. 4 (a). Alternatively or additionally, for example in fig. 4(B), user "user 1" (of the plurality of users) may illustratively be associated with a user group "user group 1" (of the plurality of user groups, each user group being associated with one or more users), the user group "user group 1" again being associated with the access control profile "ACP 1" (e.g., a user group associated with a group of users associated with a particular user role (e.g., a general user, a super user, and/or an administrator, etc.).

Thus, each user may be associated with one or more access control profiles. Also, the authorization module/device may determine one or more access control profiles (of the plurality of access control profiles) associated with a particular user (e.g., a user that is logged into the UIC and authorized) based on such authorization-associated information.

The access permissions of the users are illustratively indicated in the access control information associated with the respective one or more access control profiles. Thus, access control profile information may be stored for each defined access control profile, e.g., an association according to fig. 4 (C).

In fig. 4(C), illustratively, the access control profile "ACP 1" (of the multiple access control profiles) is illustratively associated with the user role "user role 1" (of the multiple user roles). Further illustratively, the user role "user role 1" (of the plurality of user roles) is associated with the activity group "activity group 1" (of the plurality of activity groups), the activity group "activity group 1" being illustratively associated with activities "activity 1" and "activity 2" (of the plurality of activities). A user role can also be directly associated with zero, one, or more of a plurality of activities. Each access control profile may be associated with a user role associated with one or more activity groups and zero, one, or more activities, and each activity group may be associated with one or more activities.

In fig. 4(C), illustratively, the access control profile "ACP 1" (of the multiple access control profiles) is illustratively associated with a resource group "resource group 1" (of the multiple resource groups), and the resource group "resource group 1" (of the multiple resource groups) is illustratively associated with the storage resources "resource 1", "resource 2", and "resource 3". Each access control profile may be associated with one or more resource groups, and each resource group may be associated with one or more resources.

In fig. 4(C), illustratively, the access control profile "ACP 1" (of the multiple access control profiles) is associated with the access level "access level 1" (of the multiple access levels). Each access control profile may be associated with one or more levels of access. Preferably, the access control profile is associated with a respective access level for each resource group associated with the respective access profile, e.g. by associating each resource group with a respective access level.

In summary, the association information and access control profile information of fig. 4 illustratively indicate that the respective user "user 1" is associated with the access control profile "ACP 1", the access control profile "ACP 1" indicates that the user "user 1" has the user role "user role 1" and is permitted to access the storage resources "resource 1", "resource 2", and "resource 4" according to the resource group "resource group 1" based on the access level "access level 1", and the user "user 1" is permitted to perform (or request to perform) on the storage resources "resource 1", "resource 2", and "resource 4" the activities "activity 1" and "activity 2" and "activity 5" of the activity group "activity group 1" according to the resource group "resource group 1" based on the access level "access level 1".

Thus, illustratively, an access control profile indicates that respective users that have been associated with a respective access control profile "ACP 1" are permitted to access a storage resource according to one or more resource groups based on an associated access level, and that the respective users are permitted to perform (or request to perform) activities of an associated activity group and/or associated activities on the storage resource according to one or more associated resource groups based on the associated access level.

Returning to fig. 3, in step S33, based on the lookup of step S32, the authorization module/device retrieves one or more access control profiles (and/or corresponding access control profile information) associated with the user associated with the login request and/or authentication request, and the corresponding access control profile information indicating the determined one or more access control profiles associated with the user associated with the login request and/or authentication request is used to create a payload (step S34) that is sent from the authorization module/device to the UIC (user interface controller) in step S35.

In step S37, the UIC (user interface controller) confirms the start of the session for the then (authenticated and) authorized user, illustratively by sending a confirmation message via the web server 200.

Illustratively, in step S34 (which may be performed in parallel with step S37, before or after step S37), a payload of access control information for the corresponding user is created. Thus, in some exemplary embodiments, the authorization device/module is responsible for creating a payload for the user based on the obtained one or more access control profiles associated with the respective user and sending the created payload to the UIC (user interface controller). In other exemplary embodiments, the authorization device/module may send the obtained one or more access control profiles associated with the user or access control profile information indicative of the one or more access control profiles associated with the user to the UIC, and in such exemplary embodiments, may create a payload based on the received one or more access control profiles or information of the one or more access control profiles at the UIC.

The payload preferably indicates the corresponding access control profile information obtained by the authorizing device/module for the respective user associated with the login request. In some exemplary preferred aspects, the corresponding access control profile information may be encoded at the time the payload is created, for example by a compressed data format of compression type.

Such a payload provides the following advantages: the above-described authorization process need not be performed again later, but the respective access control profile information for the respective user may remain stored (e.g., in cache, NVRAM, or on storage of the UIC, such as in a session database) for, for example, the entire session until the user logs off again, or even remain for a longer time until the user logs in again to be reused (at least unless the user's access control profile is not reset or reconfigured at the same time).

Further, such a payload provides the benefit that the UIC may embed the payload in the access request (e.g., by attaching the payload to such an access request, or by encoding or adding the payload to such an access request or a header portion thereof). Then, although the UIC performs the first authorization process in a centralized manner, since the storage processing device (resource handling controller) may perform individual access control of each access request at the end point, i.e. at the data access point of the data storage system, e.g. on the storage processing device (resource handling controller), on the respective node and/or through the storage controller for accessing the storage resource, the subsequent access control of each access request may be performed efficiently and reliably in a distributed manner.

Accordingly, access control in a distributed manner is more efficient (e.g., the workload burden on a central authorization system is greatly reduced because the necessity of processing queries to/from a centralized authorization system on a per-access basis is avoided, and/or the communication bandwidth within the system is greatly reduced because the necessity of querying to/from a centralized authorization system on a per-access basis is avoided).

Further, in optional step S36, the UIC illustratively stores the created payloads (and/or the received access control profile information) for the respective users as session information associated with the user' S session. The UIC may store such session information in the session management information memory portion as session management information for each of one or more currently logged-in users (including the respective user currently initiating the session).

The benefit of this is that when an access request is received at the UIC from a currently logged-on user (the user for which the session is running), the UIC can embed a corresponding payload into or onto the access request before routing the access request to one or more responsible storage handler devices (resource handling controllers).

Further, when one or more access control profiles of one or more currently logged-on users may change (e.g., an administrator user reconfigures any of the above associations managed by the authorization device/module, such as by redefining a set of resources, adding resources to a set of resources, or removing resources from a set of resources, and/or by redefining a user role and/or an activity or activity group associated with the user or user role, and/or by redefining an activity group, adding activities to an activity group or removing activities from an activity group, and/or by changing an access level in a user access control profile, etc.), the authorization device/module may notify the UIC accordingly (e.g., via a notification message).

The UIC may be configured to examine session information affected by the notified access control profile or change in underlying association, and the determined affected session information may be updated as appropriate during the affected user's current session, for example by requesting that associated payload and/or access control profile information be re-created and/or updated.

Then, upon receiving a new access request from an affected user, an updated/recreated payload reflecting changes during an ongoing session with respect to run-time (run-time) may be embedded in/on such newly received access request from the affected user with the changed access control profile.

Here, a plurality of exemplary embodiments may be implemented as described below in conjunction with fig. 5A to 5E.

In general, the UIC may immediately update (or request to update) the session information of currently logged-on users upon receiving notification from the authorization module/device that a change has been made (and that access control profile information and/or access control profile association information may have changed) and upon determining which of these users are affected. For example, the UIC may indicate that the stored session information and payload are "out of date" for the affected login user, and when a new access request is received from that user, a new payload may be created (e.g., from an authorization module/device via the UIC request). Further, in other exemplary embodiments, the session information and payload of all affected users may be updated/recreated upon receiving notification from the authorization module/device that a change has been made.

Exemplary UIC Access request handling

Illustratively, in step S41, a User Interface Controller (UIC) may receive a request for access to the store from a user who has been previously authenticated and/or authorized based on the foregoing, and/or for whom a session has been previously initiated. The access request may indicate one or more data structures stored on one or more storage resources of the data storage system to be accessed (i.e., the one or more data structures stored on one storage resource are requested to be accessed by the received access request).

Further, in some example embodiments, the access request may indicate one or more activities to be performed on one or more data structures stored on one or more storage resources of the data storage system indicated by the access request.

The access request may relate to a data operation, such as writing data, copying data, reading data, etc., related to data of a data structure stored on one or more storage resources of the data storage system.

However, the access request may also relate to viewing, configuring, or changing data protection operation settings for the data structure stored on one or more storage resources of the data storage system, such as configuring and/or setting data protection policies, snapshot policies, copy policies, mirroring policies, backup policies, and the like, e.g., relating to the performance of data protection operations that copy data of the data structure in whole, in part, or in a modified manner from a source node to a destination node or from a source data storage resource to a destination data storage resource, such as defining the source node and the target node, setting policies (e.g., when, how often, or from where to where based on which occurrence of an event which should be copied).

In step S42, based on the received access request (e.g., based on the target node and/or the target storage resource and/or the target data structure to be accessed), the UIC determines a storage handler (resource handling controller) responsible for managing and/or controlling access based on the access request, for example, by determining a corresponding storage handler (resource handling controller) responsible for managing and/or controlling the corresponding target node and/or the target storage resource and/or the target data structure to be accessed based on the access request.

Since the user has been previously authorized, a payload has been created that indicates one or more access control profiles associated with the user associated with the received access request.

In step S43, a previously created payload indicating one or more access control profiles associated with the user associated with the received access request is embedded into the access request, and in step S44 the access request with the embedded payload is sent from the UIC to the determined responsible storage handler (resource handling controller) for further processing by the responsible storage handler (resource control processor).

Accordingly, since the payload includes information of the access control profile, the storage handler can efficiently and reliably perform the access control process based on the payload without querying the UIC again.

However, if at the same time (e.g., during an ongoing session of the user) the administrator changes any of the above associations, e.g., by reconfiguring user roles, active groups, and/or resource groups, or other information of the above associations, such modifications will be reset at the authorizing device/module. To reflect such potential changes in time (without performing an authorization process each time an access request is received), in some exemplary embodiments the UIC may manage session information indicating the currently logged-in user and its payload and/or access control profile, and the UIC may update the corresponding session data based on the notification of the configuration change received from the authorization device/module to be configured to retain the updated payload information and embed the updated payload for requests from users of the ongoing session.

Illustratively, in step S45, the UIC receives a notification message from the authorizing device/module indicating that the access control profile information may have been changed due to a reset or reconfiguration or change of the access control profile, user role, activity set and/or resource set or other information associated therewith.

Based on the received notification message, the UIC determines the users of the affected ongoing session based on the session management information in step S46. For example, based on the notification message and the access control profile information stored for the currently logged-on user, the UIC determines the affected user by determining the access control profile and/or payload stored in the session management information.

Based on the received notification message, the UIC requests the authorizing device/module to update or recreate the payload for the affected user in step S47, and upon receiving the updated or newly created payload from the authorizing device/module, the UIC updates the session management information accordingly in step S48.

That is, although a change has occurred during the ongoing session of the affected user, when a new access request is received from the affected user, the payload to be embedded according to the above steps S41 and S44 is an updated payload that already reflects the change of the access control profile information of the affected user.

In the above, the UIC determines the affected user, illustratively, independently of whether the user may send additional access requests. Alternatively, in other exemplary embodiments, it may be possible to determine whether a user is affected by the latest change in access control profile information only after receiving an access request from the user, e.g., see fig. 5C, or to recreate/update the user's payload upon receiving another access request only when the access request is received from the affected user, e.g., see fig. 5D and 5E.

In step S46 ', based on the received notification message of step S45, the UIC determines, based on the session management information stored for the user associated with the access request, whether the respective user is affected by the change indicated in the notification message, e.g., by referencing a previously created payload associated with the respective user and/or the respective user' S associated access control profile. For example, based on the notification message and the access control profile information stored for the respective user, the UIC determines whether the respective user is affected by the change.

If step S46' returns a "NO," the process continues similarly to steps S42, S43, and S44 of FIG. 5A, described above. However, if step S46 ' returns yes, the method continues with steps S47 ' and S48 '.

In step S47 ', the UIC requests the authorization device/module to update or recreate the payload for the respective affected user, and upon receiving the updated or newly created information at the UIC, the UIC updates the session management information for the respective affected user accordingly in step S48'.

That is, although the change has occurred during the ongoing session of the affected user, when a new access request is received from the affected user, the payload to be embedded in S44 is an updated payload that has reflected the change of the access control profile information of the affected user. Then, the process continues similarly to steps S42, S43, and S44 of fig. 5A described above.

Based on the received notification message, the UIC determines the affected users of the ongoing session based on the session management information in step S46. For example, based on the notification message and the access control profile information stored for the currently logged-on user, the UIC determines the affected user by determining the access control profile and/or payload stored in the session management information.

In step S49, the UIC updates the session management information for the determined one or more affected users to indicate that the payloads for these users and the one or more access control profiles indicated in the session management information are past ("expired"), and may register that the previously created payloads are "expired" for the determined one or more affected users. This has the advantage that the payload does not have to be recreated immediately for all affected users and only when needed, see for example fig. 5E.

In step S46 ″, the UIC determines, based on the session management information stored for the user associated with the access request (which may have been updated in step S49 of fig. 5D), whether the corresponding user is affected by any recent changes indicated in any notification messages, by checking whether the session management information indicates that the user' S payload is expired.

If step S46 returns "NO," the process continues similarly to steps S42, S43, and S44 of FIG. 5A or FIG. 5C, described above. However, if step S46 returns "YES," the method continues similar to steps S47 'and S48' of FIG. 5C.

That is, although the change has occurred during the ongoing session of the affected user, when a new access request is received from the affected user, the payload to be embedded in S44 is an updated payload that has reflected the change of the access control profile information of the affected user. Then, the process continues similarly to steps S43 and S44 of fig. 5A or fig. 5C described above.

Exemplary storage processor Access request processing

Illustratively, in step S61, a storage handler (resource handling controller), such as the storage handler device or storage handler module described above, receives a user' S access request (e.g., transmitted in step S44 above) from the UIC with an embedded payload indicating access control profile information associated with a particular user.

In step S62, the storage handler (resource handling controller) determines access control profile information associated with the particular user associated with the received access request, illustratively based on the payload embedded in the access request.

Furthermore, the storage handler (resource handling controller) may illustratively perform decentralized access control (i.e., without further querying the UIC), e.g., based on one or more of the further described steps S63 and S64, S65 and S66, and/or S67 and S68 (in any order).

Illustratively, in step S63, the storage handler (resource handling controller) determines one or more storage resources to be accessed based on the access request, and in step S64, the storage handler (resource handling controller) determines whether the user associated with the access request is allowed/granted access to the determined one or more storage resources to be accessed. If step S64 returns a "NO," the access process is stopped, the requested access request is avoided from being executed, and the process ends (e.g., by sending a deny or error message to the UIC).

For example, if the determined one or more storage resources are included in a set of resources indicated in the access control profile information associated with the respective user, the storage handler (resource handling controller) may determine that the user associated with the access request is allowed/granted access to the determined one or more storage resources. Moreover, if the determined one or more storage resources are not included in the set of resources indicated in the access control profile information associated with the respective user, the storage handler (resource handling controller) may determine that the user associated with the access request is not allowed/permitted to access the determined one or more storage resources.

Illustratively, in step S65, the storage handler (resource handling controller) determines one or more activities to be performed based on the access request, and in step S66, the storage handler (resource handling controller) determines whether the user associated with the access request is allowed/permitted to perform or requests to perform the determined one or more activities to be performed. If step S66 returns a "NO," the access process is stopped, the requested access request is avoided from being executed, and the process ends (e.g., by sending a deny or error message to the UIC).

For example, if the determined one or more activities are included in the set of activities indicated in the access control profile information associated with the respective user, or if the determined one or more activities themselves are indicated in the access control profile information associated with the respective user, the storage handler (resource handling controller) may determine that the user associated with the access request is allowed/permitted to perform or request the determined one or more activities. Further, if the determined one or more activities are not included in any of the activity sets indicated in the access control profile information associated with the respective user, and/or if the determined one or more activities are not themselves indicated in the access control profile information associated with the respective user, the storage handler (resource handling controller) may determine that the user associated with the access request is not allowed/permitted to perform or request the determined one or more activities.

Illustratively, in step S67, the storage handler (resource handling controller) determines one or more data structures on the storage resource to be accessed based on the access request, and in step S68, the storage handler (resource handling controller) determines whether the user associated with the access request is allowed/granted access to the determined one or more data structures on the storage resource to be accessed. If step S68 returns a "NO," the access process is stopped, the requested access request is avoided from being executed, and the process ends (e.g., by sending a deny or error message to the UIC).

For example, the storage handler (resource handling controller) may determine whether the user associated with the access request is allowed/granted access to the determined one or more data structures based on the access level indicated in the access control profile information associated with the respective user or based on the access level indicated in the access control profile information associated with the respective user for a group of resources of the storage resource storing the respective one or more data structures.

Illustratively, if the above-described access control process has not resulted in stopping the access process and denying access, e.g., if the results of steps S64, S66, and S68 are "YES," the process continues with performing the requested access operation, e.g., by performing an access to the requested one or more storage resources to perform the requested one or more activities on the requested one or more data structures.

According to some example embodiments, it may be important to fully determine the activities that a user may perform on a requested storage resource, as this may be affected by the user role (one or more activities allowing one or more individual activities and/or one or more allowed groups of activities) and one or more groups of resources and the level of access specified for that group of resources. In other words, the preferred system determines whether to allow the user to perform the requested activity on the determined storage resource.

For example, a particular user may be allowed to perform activity a1 on storage node N1, and the same user may be allowed to perform activity a2 on storage node N2, but the user may not be allowed to perform activity a2 on storage node N1, and may also not be allowed to perform activity a1 on storage node N2. Therefore, these determinations are exemplarily made in the same step S68' in the exemplary flowchart of fig. 6B.

Further, it may be determined whether a user may access a particular data structure on a storage node based on the "access level" specified for the resource group to which the node belongs. The access level may be obtained from the access control profile information.

Illustratively, in FIG. 6B and in step S61, a storage handler (resource handling controller), such as the storage handler device or storage handler module described above, receives a user' S access request (e.g., sent in step S44 above) from the UIC with an embedded payload indicating access control profile information associated with a particular user.

Further, the storage handler (resource handling controller) may illustratively perform decentralized access control (i.e., without further querying the UIC).

Illustratively, in step S63, the storage handler (resource handling controller) determines one or more storage resources to be accessed based on the access request.

Illustratively, in step S65, the storage handler (resource handling controller) determines one or more activities to be performed based on the access request.

Illustratively, in step S67, the storage handler (resource handling controller) determines one or more data structures on the storage resource to be accessed based on the access request.

Then, in step S68', the storage handler (resource handling controller) determines whether to allow/grant the user associated with the access request to perform the determined activities of step S65 on the determined one or more data structures on the storage resource to be accessed determined in steps S63 and S65. As previously described, the determination of step S68 ' depends on the one or more access control profiles associated with the user, and step S68 ' is performed based on the allowed activities and/or the allowed groups of activities and resources and the access level of the resource groups in the information of the user ' S one or more access control profiles.

If step S68' returns a "NO," the access process is stopped, the requested access request is avoided from being executed, and the process ends (e.g., by sending a deny or error message to the UIC).

Illustratively, if the above-described access control process does not result in stopping the access process and denying access, i.e., if the outcome of step S68' is positive, then the process continues to perform the requested access operation, e.g., by performing an access to the requested one or more storage resources to perform the requested one or more activities on the requested one or more data structures.

Exemplary data structures in a data storage System

Illustratively, the data storage system of FIG. 7 includes nodes N1, N2, N3, N4, N5, N6, and N7. Nodes N1, N2, N3, N4, N5, N6, and N7 may be referred to as storage resources that provide storage for one or more user-accessible data structures.

In addition to physical or logical nodes representing storage resources, a node or a logical storage entity on a cluster system of nodes may also be referred to as a storage resource.

For example, in FIG. 7, nodes N5, N6, and N7 provide logical storage libraries R1, R2, and R3, respectively, as storage resources for storing data structures.

A "data structure" may be any form of data structure for data accessible by a user, for example, a data structure may refer to a file, a group of files, a file system, a group of file systems, a database, a group of databases, an archive, a group of archives, a storage volume, or a group of storage volumes (including logical volumes, virtual volumes), and the data in the data structure may be stored via a file-based storage structure, a block-based storage structure, or an object-based storage structure.

Such a data structure as described previously may be referred to as a "primary data structure" in the following sense: such "primary data structures" are added to the system by a user, administrator, manually or through an application, and/or such "primary data structures" are user-accessible (and/or application-accessible) to read and write data or add data to a corresponding data structure based on application access and/or user access (particularly independent of another data structure).

On the other hand, another type of data structure, referred to as a "secondary data structure," may refer to a data structure that may be dynamically and/or automatically created, and/or may specifically rely on a "primary data structure," such as by partially or fully documenting (store) a copy of the data of the associated "primary data structure. For example, if data of a "primary data structure" (and/or metadata of data of the "primary data structure") is partially or completely replicated for data protection purposes, e.g., as a replica, mirror copy, backup, snapshot, etc., such partial or complete replica, mirror copy, backup, and/or snapshot of the "primary data structure" is referred to as a corresponding "secondary data structure" of the particular "primary data structure".

Such "secondary data structures" may be dynamically and/or automatically created by a system (e.g., by a storage handler) by managing the "secondary data structures" based on data protection policies, e.g., by defining source and destination nodes, source data, a type of source data (e.g., a type of "primary data structure" such as a replica, mirror copy, backup, snapshot, etc.), and operational policies (e.g., a time of occurrence, frequency interval, or location of an event at which a secondary data structure should be created and/or updated).

With respect to the "primary data structure," the data storage system of FIG. 7 illustratively stores file system FS1 on node N1, file system FS2 on node N2, and file system FS3 on node N3. Further, node N2 illustratively stores database DB1 and node N3 illustratively stores database DB 2. Node N4 illustratively stores database DB3 and archive AR 1.

With respect to the "secondary data structure," the data storage system of FIG. 7 illustratively stores backup data for the primary data structure described above.

For example, node N5 provides repository R1, which repository R1 stores backup BUIs (as indicated by the arrows) for the file system FS1 of node N1. This may involve mirror copies or snapshots of the file system, or may involve partial copies of the file system, such as backup copies of certain files in the file system or backup copies of their metadata.

Similarly, repository R1 illustratively stores backup BU2 of file system FS2 of node N2 and backup copy BU3 of database DB1 of node N2. Further illustratively, repository R1 stores a backup BU4 of the file system FS3 of node N3.

In addition, node N6 provides a repository R2, which repository R2 stores a backup BU5 of the database DB2 of node N3. This may involve mirror copies, remote copy copies, partial copies or partial copies of their metadata, etc.

Similarly, repository R2 illustratively stores backup BU6 of database DB3 of node N4. Further illustratively, repository R2 stores a backup BU7 of the archive of node N4. This may involve mirror copies, remote copy copies, partial copies or partial copies of their metadata, etc.

In addition, node 7 provides repository R3, which stores backup BU8 of backup BU1 in repository R1 (e.g., as a copy or partial copy thereof). Repository R3 also illustratively stores backup BU9 of backup BU2 in repository R1, backup BU10 of backup BU4 in repository R1, backup BU11 of backup BU5 in repository R2, and backup BU12 of backup BU7 in repository R2.

Furthermore, the metadata portion of the respective responsible storage handler and/or the respective secondary data structure stores data structure metadata that preferably indicates, for each secondary data structure, a respective parent storage resource and an owner storage resource.

The "owner storage resource" of a respective secondary data structure is the storage resource that stores the corresponding associated "primary data structure".

Thus, in fig. 7, exemplarily:

the owner storage resource of both backup BU1 and BU8 is node N1, since it stores the associated primary data structure, i.e. file system FS1,

the owner storage resource of both backup BU2 and BU9 is node N2, since it stores the associated primary data structure, i.e. file system FS2,

the owner storage resource of the backup BU3 is node N2, since it stores the associated primary data structure, namely database DB1,

the owner storage resource of both backup BU4 and BU10 is node N3 because it stores the associated primary data structure, namely file system FS 3;

the owner storage resource of both backup BU5 and BU11 is node N3, since it stores the associated primary data structure, namely database DB2,

the owner storage resource of backup BU6 is node N4, since it stores the associated primary data structure, i.e. database DB3, and

the owner storage resource of both backup BU7 and BU12 is node N4 because it stores the associated primary data structure, archive AR 1.

On the other hand, the "parent storage resource" of the corresponding secondary data structure is a storage resource that stores the corresponding secondary data structure.

Thus, in fig. 7, exemplarily:

the parent storage resources of backup BU1 to BU4 are all storage libraries R1, since it stores the corresponding backup BU1 to BU4,

the parent storage resources of backup BU5 to BU7 are all storage libraries R2, since it stores the corresponding backup BU5 to BU7, and

the parent storage resources of backup BU8 to BU12 are all storage libraries R3, since it stores the corresponding backup BU8 to BU 412.

Thus, the following metadata may be stored for the respective backup in the metadata portion of the respective responsible storage handler (resource storage controller) and/or with the respective secondary data structure:

for backup BU1, the corresponding data structure metadata may indicate parent data storage resource R1 (repository R1, e.g., in the form of a storage resource ID) and owner data storage resource N1 (node N1, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant (tenant) associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU2, the corresponding data structure metadata may indicate parent data storage resource R1 (repository R1, e.g., in the form of a storage resource ID) and owner data storage resource N2 (node N2, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU3, the corresponding data structure metadata may indicate parent data storage resource R1 (repository R1, e.g., in the form of a storage resource ID) and owner data storage resource N2 (node N2, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU4, the corresponding data structure metadata may indicate parent data storage resource R1 (repository R1, e.g., in the form of a storage resource ID) and owner data storage resource N3 (node N3, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU5, the corresponding data structure metadata may indicate parent data storage resource R2 (repository R2, e.g., in the form of a storage resource ID) and owner data storage resource N3 (node N3, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU6, the corresponding data structure metadata may indicate parent data storage resource R2 (repository R2, e.g., in the form of a storage resource ID) and owner data storage resource N4 (node N4, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU7, the corresponding data structure metadata may indicate parent data storage resource R2 (repository R2, e.g., in the form of a storage resource ID) and owner data storage resource N4 (node N4, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU8, the corresponding data structure metadata may indicate parent data storage resource R3 (repository R3, e.g., in the form of a storage resource ID) and owner data storage resource N1 (node N1, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU9, the corresponding data structure metadata may indicate parent data storage resource R3 (repository R3, e.g., in the form of a storage resource ID) and owner data storage resource N2 (node N2, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU10, the corresponding data structure metadata may indicate parent data storage resource R3 (repository R3, e.g., in the form of a storage resource ID) and owner data storage resource N3 (node N3, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BUll, the corresponding data structure metadata may indicate a parent data storage resource R3 (repository R3, e.g., in the form of a storage resource ID) and an owner data storage resource N3 (node N3, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For backup BU12, the corresponding data structure metadata may indicate parent data storage resource R3 (repository R3, e.g., in the form of a storage resource ID) and owner data storage resource N4 (node N4, e.g., in the form of a storage resource ID). The data structure metadata may also indicate the tenant associated with the corresponding parent and/or owner storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

For primary data structures, on the other hand, the corresponding data structure metadata may indicate the storage resources that store the corresponding data structure. The data structure metadata may also indicate the tenant associated with the corresponding storage resource or data structure, e.g., in the form of a tenant ID, to allow access only to users of the indicated tenant.

When a tenant is further indicated in the data structure metadata, a user may only be given access to a particular storage resource (or data structure on a particular storage resource) if the user's tenant matches the tenant (e.g., tenant ID) indicated in the data structure metadata.

Example resource groups

For example, for the data storage system of FIG. 7, the following set of resources can be exemplarily defined:

a resource group RG1 ═ { N1, N2, N5, R1},

a resource group RG2 ═ N2, N3, N5, R1, N7, R3},

a resource group RG3 ═ { N3, N4, N6, R2, N7, R3}, and

the resource group RG4 ═ { N2, N7, R3 }.

For the primary data structure, the set of resources indicated in the user's access control profile may indicate those storage resources on which the user may access the primary data structure.

For example, a user associated with an access control profile associated with resource group RG1 may access the primary data structure on those resources of resource group RG1, i.e., for example, file system FS1 on node N1 and file system FS2 on node N2 and database DB1 on node N2, because nodes N1 and N2 are included in the respective resource node N1.

Thus, a user associated with an access control profile associated with the resource group RG1 may be denied access to any of the primary data structures FS3, DB2, DB3, and AR1 on nodes N1 and N4.

Exemplary levels of Access

As previously mentioned, preferably, the access control profile information may preferably indicate for each resource group indicated in or associated with the respective access control profile a specific access level according to which the respective user may access the level storage resource, in particular the secondary data structure on such storage resource. Thus, preferably, each resource group in the access control profile is assigned an access level.

For example, the following access levels may be provided:

-a first access level (GROUP access level, which may also be referred to as LIMITED access level) indicating that users of respective user accounts associated with the first access level for a particular GROUP of resources are allowed to access a secondary data structure on respective parent data storage resources, the respective owner data storage structure of the secondary data structure being included in the particular GROUP of resources to which users associated with the respective user accounts are granted user access according to the access control information. In other words, when a first access level is specified for a particular resource group in an access control profile associated with a user, the user is able to access secondary data structures from storage resources in the same particular resource group (e.g., in the case of resource group RG1 in fig. 7 having the first access level, the user will be able to see BU1, BU2, and BU3 (as they come from N1 and N2), but the user will not see BU 4);

-a second access level (OWNER access level, which may also be referred to as pessonal access level) indicating that a user of a respective user account associated with the second access level for a particular group of resources is allowed to access, on a respective parent data storage resource, a secondary data structure associated with an OWNER data storage resource provided by the node to which the user is currently logged in, in particular if the respective associated OWNER data storage resource is included in the particular group of resources to which the user associated with the respective user account is granted user access according to the access control information. In other words, when a second access level is specified for a particular resource group in the access control profile associated with the user, the user is able to access the secondary data structure from the storage resource to which the user is logged in (e.g., in the case of resource group RG1 in fig. 7 having the second access level, the user logged in at node N1 will be able to see BU1 but not BU2, BU3, and BU4, but if the same user is logged in at node N2 they will be able to see BU2 and BU3 but not BU1 and BU 4); and

-a third level of access (FULL level of access) indicating that users of respective user accounts associated with the third level of access are allowed to access the secondary data structure stored on the respective parent data storage resource irrespective of whether the respective associated owner data storage resource is included in the set of resources to which users associated with the respective user accounts are granted user access according to the access control information. In other words, when a third access level is specified for a particular resource group in the access control profile associated with the user, the user is able to access all secondary data structures on any storage resource in the particular resource group (e.g., in the case of resource group RG1 in FIG. 7 having the third access level, the user will be able to see all data structures on R1 (BU1, BU2, BU3, and BU4) because R1 is granted FULL access.

For example, a user logged in through node N1, allowed to access the file system FS1 thereon, and associated with an access control profile associated with the resource group RG1 ═ N1, N2, N5, R1} and the third (FULL) access level, can access all secondary data structures on the repository R1, including BU1, BU2, BU3, and in particular, BU4, but the backup BU4 is a backup copy of the primary data structure (FS3) on a node (node N3) that is not included in the user's associated resource group RG 1.

However, despite the third access level being "FULL", the user still cannot access any secondary data structures on repositories R2 and R3, because these repositories R2 and R3 are not included in resource group RG1, and will deny any access requests based on access control.

Further exemplarily, a user logged in via node N1 and associated with an access control profile associated with a resource GROUP RG1 ═ N1, N2, N5, R1} and a first (GROUP or LIMITED) access level can only access the secondary data structure BU1, BU2, BU3 on the repository R1, since its owner storage resources are provided on the storage resources (nodes N1 and N2) comprised in the user's resource GROUP RG 1.

However, since the owner storage resource (node N3) of the backup BU4 is not included in the user's resource group RG1, although its parent storage resource (repository R1) is included in the user's resource group RG1, the corresponding user cannot access the backup BU 4. Furthermore, the user cannot access any secondary data structures on the repositories R2 and R3, because these repositories R2 and R3 are not included in the resource group RG1, and will deny any access requests based on access control.

Further illustratively, a user logged in via node N1 and associated with an access control profile associated with resource group RG1 ═ N1, N2, N5, R1} and a second (ower or pessonal) access level can only access the secondary data structure BU1 on store R1, since the user is currently logged onto its OWNER storage resource (node N1).

However, although the storage resources as the storage data structures FS2 and DB1, the node 2 as the owner storage resources of the backups BU2 and BU3, and the parent storage resources (repository R1) of the backups BU2 and BU3 are all included in the user's resource group RG1, the user still cannot access those backup BU2 and BU3 on the repository R1 because the user is not currently logged into the node N2, and the node N2 is the owner storage resource of the backups BU2 and BU 3.

Furthermore, since the owner storage resource (node N3) of the backup BU4 is not included in the user's resource group RG1, the corresponding user cannot access the backup BU4 despite its parent storage resource (repository R1) being included in the user's resource group RG 1. Furthermore, the user cannot access any secondary data structures on the repositories R2 and R3, because these repositories R2 and R3 are not included in the resource group RG1, and will deny any access requests based on access control.

Further illustratively, regardless of the access level, users having an access control profile associated with the resource group RG2 ═ { N2, N3, N5, R1, N7, R3} cannot access any primary data structures on nodes N1 and N4 because they are not included in the resource group RG 2. Moreover, the user cannot access any secondary data structures on node N6 and the repository R2 because they are also not included in the resource group RG 2.

However, the user may access the primary data structure on nodes N2 and N3 included in the resource group RG 2.

Depending on the level of access, since nodes N5 and N7 and repositories R1 and R3 are included in the resource group RG2, users may access specific secondary data structures on repositories R1 and R3.

In particular, at access level "FULL" (third access level), a user may access all secondary data structures on repositories R1 and R3.

However, at the access level "GROUP" (first access level), the user cannot access the data structures of backup BU1 on repository R1 (not included in resource GROUP RG2 because its owner storage resource is node N1), backup BU8 on repository R3 (not included in resource GROUP RG2 because its owner storage resource is node N1), and backup BU12 on repository R3 (not included in resource GROUP RG2 because its owner storage resource is node N4).

When a user associated with the resource group RG2 logs on to node N2 at the access level "OWNER" (second access level), the user can only access the backups BU2, BU3 and BU9 on the repositories R1 and R3, since they are secondary data structures that store resources with node N2 through which the user logs on as the OWNER.

Further illustratively, regardless of the access level, users having an access control profile associated with the resource group RG3 ═ { N3, N4, N6, R2, N7, R3} cannot access any primary data structures on nodes N1 and N2 because they are not included in the resource group RG 3. Moreover, the user cannot access any secondary data structures on node N5 and the repository R1 because they are also not included in the resource group RG 3.

However, the user may access the primary data structure on nodes N3 and N4 included in the resource group RG 3. Depending on the level of access, since nodes N6 and N7 and repositories R2 and R3 are included in the resource group RG3, users may access specific secondary data structures on repositories R2 and R3.

In particular, at access level "FULL" (third access level), a user may access all secondary data structures on repositories R2 and R3.

However, at the access level "GROUP" (first access level), the user cannot access the data structures of backup BU8 (not included in resource GROUP RG3 because its owner storage resource is node N1) on storage repository R3 and backup BU9 (not included in resource GROUP RG3 because its owner storage resource is node N2) on storage repository R3.

When a user associated with the resource group RG3 logs on to node N3 at the access level "OWNER" (second access level), the user can only access the backups BU5, BU10 and BU11 on the repositories R2 and R3, since they are secondary data structures that store resources with node N3 through which the user logs on as the OWNER.

Further illustratively, regardless of the level of access, users having access control profiles associated with the resource group RG4 ═ { N2, N7, R3} cannot access any of the primary data structures on nodes N1, N3, and N4 because they are not included in the resource group RG 4. Moreover, the user cannot access any secondary data structures on node N5 and repository R1, as well as node N6 and repository R2, because they are also not included in the resource group RG 4.

However, the user may include a primary data structure on node N2 in the access resource group RG 4. Depending on the level of access, since the node N7 and the repository R3 are included in the resource group RG4, a user may access a particular secondary data structure on the repository R3.

In particular, at access level "FULL" (third access level), a user may access all secondary data structures on repository R3.

However, at the access level "GROUP" (first access level) or the access level "ower" (second access level), the user can only access the data structure of the backup BU9 on the repository R3 when logging in via node N2, which is the only node of the primary data structure included in the user's resource GROUP RG4, since this is the only secondary data structure on the repository R3 having the OWNER storage resources included in the resource GROUP RG 4.

Further illustratively, at the access level "OWNER" (second access level), if a user logs on at a storage node that is not within any resource group that the user has access to, the user will not see any secondary data structures on the storage resource. For example, if a user with the second level of access to the resource group RG1 in FIG. 7 were to log in at storage node N4, the user would not see any secondary data structures in R1.

In view of the above, in exemplary embodiments, an efficient and reliable and very flexible access control scheme for access control to primary and secondary data structures may be provided, e.g., based on an access control profile indicating one or more resource groups and/or indicating different levels of access for accessing a secondary data structure created based on a primary data structure. Moreover, these access control schemes can be reliably and efficiently integrated with role-based access control (RBAC) and activity permissions, e.g., based on activity groups and/or activities associated with an access control profile. Such aspects may also be defined in conjunction with a tenant differentiation scheme to allow users to access data storage resources on a tenant-by-tenant basis.

Furthermore, in exemplary embodiments, a decentralized access control scheme may be advantageously provided in a distributed system that reduces communication bandwidth and processing burden required at a central authorization module/device or user interface management device/module (e.g., an exemplary UIC (user interface controller) in exemplary embodiments thereof), for example, by implementing or embedding a payload indicative of a user's access control profile into a user's access request and/or by retaining metadata of data structures in the management of an endpoint controller (e.g., the exemplary storage processor or resource processing controller described above).

As will be appreciated by one skilled in the art, the present invention, as described above and illustrated in the figures, may be implemented as a method (e.g., a computer-implemented process, a business process, or any other process), an apparatus (including a device, machine, system, computer program product, and/or any other apparatus), or a combination thereof.

Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "system. Furthermore, embodiments of the invention may take the form of a computer program product on a computer-readable medium having computer-executable program code embodied in the medium.

It should be noted that arrows may be used in the drawings to represent communications, transmissions, or other activities involving two or more entities. Double-ended arrows generally indicate that activity may occur in both directions (e.g., a command/request in one direction and a corresponding reply in the other direction, or peer-to-peer communication initiated by either entity), but in some cases, activity may not necessarily occur in both directions.

Single-ended arrows generally exclusively or primarily indicate activity in one direction, but it should be noted that in some cases such directed activity may actually involve activity in both directions (e.g., a message from a sender to a receiver and a receipt from the receiver to the sender, or establishing a connection prior to transmission and terminating a connection after transmission). Accordingly, the types of arrows used to indicate particular activities in a particular figure are illustrative and should not be construed as limiting.

Embodiments of the present invention are described above with reference to flowchart illustrations and/or block diagrams of methods and apparatus, and a number of example views of graphical user interfaces generated by methods and/or apparatus. It will be understood that each block of the flowchart illustrations and/or block diagrams, and/or combinations of blocks in the flowchart illustrations and/or block diagrams, and graphical user interfaces may be implemented by computer-executable program code.

Computer-executable program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a particular machine, such that the program code, which executes via the processor of the computer or other programmable data processing apparatus, creates means for implementing the functions/acts/outputs specified in the flowchart, block diagram block or blocks, drawing and/or written description.

These computer-executable program code may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the program code stored in the computer-readable memory produces an article of manufacture including instruction means which implement the function/act/output specified in the flowchart, block diagram block or blocks, drawing and/or written description.

The computer-executable program code may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the program code which executes on the computer or other programmable apparatus provides steps for implementing the functions/acts/outputs specified in the flowchart, block diagram, drawing and/or written description. Alternatively, computer program implemented steps or acts may be combined with operator or human implemented steps or acts in order to implement embodiments of the present invention.

It should be noted that terms such as "server" and "processor" may be used herein to describe devices that may be used in particular embodiments of the present invention, and should not be construed to limit the present invention to any particular device type unless the context requires otherwise. Thus, a device may include, but is not limited to, a bridge, router, bridge-router (bridgeware), switch, node, server, computer, appliance, or other type of device. Such devices typically include one or more network interfaces for communicating over a communication network and a processor (e.g., a microprocessor with memory and other peripherals and/or dedicated hardware) that is accordingly configured to perform the device functions.

The communication network may generally comprise a public and/or private network; may include a local area network, a wide area network, a metropolitan area network, a storage network, and/or other types of networks; and may employ communication technologies including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., bluetooth), networking technologies, and internetworking technologies.

It should also be noted that the devices may use communication protocols and messages (e.g., messages created, sent, received, stored, and/or processed by the devices), and that such messages may be transmitted by a communication network or medium.

The present invention should not be construed as limited to any particular communication message type, communication message format, or communication protocol unless the context requires otherwise. Thus, the communication message may generally include, but is not limited to, a frame, a packet, a datagram, a user datagram, a memory cell (cell), or other type of communication message.

Unless the context requires otherwise, references to particular communication protocols are exemplary, and it should be understood that alternate embodiments may employ variations of such communication protocols (e.g., modifications or extensions to the protocols that may be made from time to time) or other protocols that are known or developed in the future, as appropriate.

It should also be noted that a logic flow may be described herein to illustrate various aspects of the invention, and should not be construed as limiting the invention to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e.g., programs, modules, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the invention.

In general, logic elements may be added, modified, omitted, performed in a different order, or implemented using different logic constructs (e.g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing from the true scope of the invention.

The invention can be implemented in many different forms, including, but not limited to, computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer), programmable logic for use with a programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or other PLD), discrete components, integrated circuitry (e.g., an Application Specific Integrated Circuit (ASIC)), or any other means including any combination thereof. The computer program logic implementing some or all of the described functionality is typically implemented as a set of computer program instructions that are converted into computer-executable form, stored as such in a computer-readable medium, and executed by a microprocessor under the control of an operating system. Hardware-based logic implementing some or all of the described functionality may be implemented using one or more suitably configured FPGAs.

Computer program logic implementing all or part of the functionality previously described herein may be embodied in various forms, including, but in no way limited to, source code forms, computer executable forms, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator).

The source code may include a series of computer program instructions implemented in any of a variety of programming languages, such as object code, assembly language, or a high-level language (e.g., Fortran, C + +, JAVA, or HTML) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in computer-executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into computer-executable form.

Computer executable program code for carrying out operations of embodiments of the present invention may be written in an object oriented, scripted or unscripted programming language such as Java, Perl, Smalltalk, C + +, or the like. However, the computer program code for carrying out operations of embodiments of the present invention may also be written in conventional procedural programming languages, such as the "C" programming language or similar programming languages.

Computer program logic implementing all or part of the functionality previously described herein may execute at different times (e.g., concurrently) on a single processor, or may execute at the same or different times on multiple processors, and may run under a single operating system process/thread or under different operating system processes/threads.

Thus, the term "computer process" generally refers to the execution of a set of computer program instructions, whether different computer processes are executed on the same or different processors, and whether different computer processes are run under the same or different operating system processes/threads.

A computer program may be fixed in any form, such as source code form, computer executable form, or intermediate form, either permanently or temporarily in a tangible storage medium such as a semiconductor memory device (e.g., RAM, ROM, PROM, EEPROM or flash programmable RAM), a magnetic memory device (e.g., a floppy or fixed disk), an optical memory device (e.g., a CD-ROM), a PC card (e.g., a PCMCIA card), or other memory device.

The computer program may be fixed in any form in a signal that can be transmitted to a computer using any of a variety of communication techniques, including but not limited to analog, digital, optical, wireless (e.g., bluetooth), networking, and internet techniques.

The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation, for example, shrink-wrapped software, preloaded with a computer system, for example, on system ROM or fixed disk, or distributed from a server or electronic bulletin board over the communication system, for example, the internet or world wide web.

Hardware logic implementing all or part of the functionality previously described herein, including programmable logic used with programmable logic devices, may be designed using conventional manual methods, or may be designed, captured, simulated, or electronically documented using various tools (e.g., Computer Aided Design (CAD), hardware description languages (e.g., VHDL or AHDL), or PLD programming languages (e.g., PALASM, ABEL, or CUPL).

Any suitable computer readable medium may be utilized. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or medium.

More specific examples of a computer-readable medium include, but are not limited to, an electrical connection having one or more wires or other tangible storage medium, such as a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a compact disc read-only memory (CD-ROM), or other optical or magnetic storage device.

Programmable logic may be fixed permanently or temporarily in a tangible storage medium such as a semiconductor memory device (e.g., RAM, ROM, PROM, EEPROM, or flash programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM), or other memory device.

Programmable logic may be fixed in a signal that can be transmitted to a computer using any of a variety of communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., bluetooth), networking technologies, and internetworking technologies.

Programmable logic can be distributed as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the internet or world wide web). Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Other embodiments of the invention are implemented entirely as hardware or entirely as software.

While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that embodiments of the invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, may be made.

Those skilled in the art will recognize that various adaptations, modifications, and/or combinations of the just described embodiments can be configured without departing from the scope and spirit of the invention. It is, therefore, to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein. For example, the steps of processes described herein may be performed in an order different than that described herein, and one or more steps may be combined, divided, or performed concurrently, unless explicitly stated otherwise.

Those of skill in the art will also recognize, in view of the present disclosure, that different embodiments of the invention described herein can be combined to form other embodiments of the invention.

Claims

1. A method for controlling user access to a data storage system, the data storage system comprising one or more nodes providing a plurality of data storage resources,

the plurality of data storage resources storing one or more user-accessible primary data structures and one or more user-accessible secondary data structures, each secondary data structure being stored based on a respective associated primary data structure,

wherein for each secondary data structure, the data storage system stores data structure metadata indicating parent and owner data storage resources of the respective secondary data structure,

the parent data storage resource of the respective secondary data structure is a data storage resource that stores the respective secondary data structure, and the owner data storage resource of the respective secondary data structure is a data storage resource that stores the respective associated primary data structure of the respective secondary data structure, and

wherein the data storage system further stores access control information indicating, for each of the one or more user accounts, at least one set of resources of the one or more data storage resources to which a user associated with the respective user account is granted user access;

the method comprises the following steps:

-receiving a user request to access a particular secondary data structure of the one or more secondary data structures stored on the respective parent data storage resource;

-determining, based on data structure metadata stored for the particular secondary data structure, a respective owner data storage resource of the particular secondary data structure, and

-determining whether to allow access to the specific secondary data structure by a user of the user account associated with the user request based on an access control verification process, the access control verification process comprising determining whether to grant access to the determined owner data storage resource of the specific secondary data structure by a user of the user account associated with the user request based on the access control information,

wherein the access control information further indicates, for each of the one or more user accounts, one or more levels of access; wherein:

-a first access level of the one or more access levels indicates that users of a respective user account associated with the first access level are allowed to access one or more secondary data structures on a respective parent data storage resource, respective owner data storage resources of the one or more secondary data structures being included in a set of resources to which users associated with the respective user account are granted user access according to the access control information,

-a second access level indication of the one or more access levels, on a condition that a respective associated owner data storage resource is included in a set of resources to which a user associated with the respective user account is granted user access according to the access control information, a user of the respective user account associated with the second access level being allowed to access, on a respective parent data storage resource, one or more secondary data structures associated with one or more owner data storage resources provided by a node to which the user is currently logged in, and/or

-a third access level of the one or more access levels indicates that users of a respective user account associated with the third access level are allowed to access the one or more secondary data structures stored on a respective parent data storage resource on the respective parent data storage resource irrespective of whether the owner data storage resource associated with the one or more respective is included in a set of resources to which users associated with the respective user account are permitted user access in accordance with the access control information.

2. The method of claim 1, wherein:

the data storage system further includes a user interface controller configured to receive a user request,

the method further comprises the following steps:

-performing an authorization procedure after a session has started when a user of the user account associated with the user request initiates a communication connection with the user interface controller, the authorization procedure obtaining, based on the access control information, a user access control profile indicating at least one set of one or more data storage resources to which the user associated with the respective user account is granted user access.

3. The method of claim 2, further comprising:

-creating a payload indicative of a user access control profile of a user associated with the respective user account,

the method further comprises the following steps:

-upon receiving at the user interface controller the user request to access the particular secondary data structure, including the created payload into the user request of the user associated with the respective user account.

4. The method of claim 3, wherein:

the data storage system further comprising one or more resource handling controllers, each resource handling controller configured to manage user access to one or more data storage resources of the data storage system,

the method further comprises the following steps:

-sending a user request comprising the created payload from the user interface controller to the resource handling controller managing access to the parent data storage resource of the particular secondary data structure.

5. The method of claim 4, wherein:

each resource handling controller is further configured to manage the data structure metadata related to the secondary data structures stored on the one or more data storage resources managed by the respective resource handling controller,

the method further comprises the following steps:

-receiving the user request comprising the created payload at the resource handling controller managing access to the parent data storage resource of the particular secondary data structure,

wherein determining the respective owner data storage resource of the particular secondary data structure and determining whether to allow access to the particular secondary data structure by a user of the user account associated with the user request are performed by the resource handling controller managing access to the parent data storage resource of the particular secondary data structure based on data structure metadata managed by the respective resource handling controller and the payload included in the received user request.

6. The method of claim 1, wherein:

determining whether a user of the user account associated with the user request is allowed access to the particular secondary data structure is further based on a determination that: determining, from the access control information, whether to grant a user of the user account associated with the user request access to the parent data storage resource of the particular secondary data structure.

7. The method of claim 6, wherein:

the user of the user account associated with the user request is determined to be permitted to access the particular secondary data structure on a condition that the respective parent data storage resource of the particular secondary data structure is included in a set of resources to which the user associated with the respective user account is permitted user access in accordance with the access control information.

8. The method of claim 1, wherein:

for each of the one or more user accounts, the access control information further indicates at least one licensable user activity or at least one activity group including at least one licensable user activity that is allowed to be performed by a user associated with the respective user account on a data storage resource of a set of resources for which the user associated with the respective user account is licensed for user access.

9. The method of claim 8, wherein:

determining whether a user of the user account associated with the user request is allowed access to the particular secondary data structure is further based on a determination that: determining, based on the access control information, whether to permit performance of a respective user activity requested by the user request by a user of the user account associated with the user request.

10. The method of claim 3, wherein:

the access control information includes role-based access control, RBAC, information that further indicates, for each of the one or more user accounts, a user role for a respective user associated with the respective user account,

each user role is associated with at least one licensable user activity or at least one activity group comprising at least one licensable user activity, and

the user access control profile also indicates a user role associated with the user associated with the respective user account, and the created payload also indicates the user role associated with the user associated with the respective user account.

11. The method of claim 10, wherein:

the created payload further indicates the at least one licensable user activity or at least one activity group including at least one licensable user activity associated with a respective user role associated with a user associated with a respective user account.

12. The method of claim 11, wherein:

each resource handling controller is further configured to manage activity metadata indicating, for each of one or more user roles, the at least one licensable user activity or at least one activity group including at least one licensable user activity associated with the respective user role, and

determining whether a user of the user account associated with the user request is allowed access to the particular secondary data structure is further based on a determination that: determining whether to permit performance of a respective user activity requested by the user request by a user of the user account associated with the user request based on the activity metadata managed by the respective resource handling controller and the payload included in the received user request.

13. A data storage system comprising one or more nodes providing a plurality of data storage resources,

the plurality of data storage resources configured to store one or more user-accessible primary data structures and one or more user-accessible secondary data structures, each secondary data structure being stored based on a respective associated primary data structure,

wherein the data storage system is configured to store, for each secondary data structure, data structure metadata indicating parent and owner data storage resources of the respective secondary data structure,

wherein the data storage system is further configured to store access control information, for each of the one or more user accounts, indicating at least one set of resources of the one or more data storage resources to which a user associated with the respective user account is granted user access;

the data storage system, or one or more nodes of the data storage system, is configured to, upon receiving a user request to access a particular secondary data structure of the one or more secondary data structures stored on the respective parent data storage resource, perform:

14. A computer-readable storage medium for controlling user access to a data storage system, the data storage system comprising one or more nodes providing a plurality of data storage resources storing one or more user-accessible primary data structures and one or more user-accessible secondary data structures, each secondary data structure being stored based on a respective associated primary data structure, wherein for each secondary data structure the data storage system stores data structure metadata indicating a parent data storage resource and an owner data storage resource of the respective secondary data structure, the parent data storage resource of the respective secondary data structure being the data storage resource storing the respective secondary data structure, and the owner data storage resource of the respective secondary data structure being the respective associated data storage resource storing the respective secondary data structure A data storage resource of a joined primary data structure, and wherein the data storage system further stores access control information indicating, for each of one or more user accounts, at least one set of resources of one or more data storage resources to which a user associated with the respective user account is granted user access,

the computer-readable storage medium includes computer-readable program instructions that, when executed or loaded on a device or system having at least one processor, cause the at least one processor, upon receiving a user request to access a particular secondary data structure of one or more secondary data structures stored on a respective parent data storage resource, to perform: