WO2017171810A1

WO2017171810A1 - Multi-credential authentication

Info

Publication number: WO2017171810A1
Application number: PCT/US2016/025379
Authority: WO
Inventors: Russell Ian Monk; Douglas L. Voigt; Siamak Nazari; Mark Mills
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2016-03-31
Filing date: 2016-03-31
Publication date: 2017-10-05

Abstract

In some examples, a system includes a memory and an authentication engine. The memory may store a data object. The authentication engine may control access to the data object according to a multi-credential access policy that requires authentication of user credentials from multiple users to access the data object.

Description

[0001] Recent advances in technology have spurred the generation and storage of immense amounts of data. Corporations may generate immense amounts of data through financial logs, e-mail messages, business records, and the like. Web search engines support searching of huge amounts of data scattered across the Internet. High definition video files may encode vast amounts of audio and video data. Countless numbers of business records and documents each day. Various mechanisms exist to access the generated data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain examples are described in the following detailed description and in reference to the drawings.

[0003] Figure 1 shows an example of a system that supports multi-credential authentication.

[0004] Figure 2 shows an example of an architecture that supports multi- credential authentication for data objects.

[0005] Figure 3 shows an example of a multi-credential access policy.

[0006] Figure 4 shows an example of a communication exchange to access a data object controlled through a multi-credential access policy.

[0007] Figure 5 shows an example of an architecture that supports multi- credential authentication for data objects.

[0008] Figure 6 shows an example of a communication exchange between an authentication engine and a multi-user client to access a data object controlled through a multi-credential access policy. [0009] Figure 7 shows an example of logic that a system or device may implement to support multi-credential authentication.

[0010] Figure 8 shows an example of a system that supports multi-credential authentication.

DETAILED DESCRIPTION

[0011] Examples consistent with the present disclosure may support multi- credential authentication, which may refer to any mechanism, process, system, device, logic, method, framework, platform, and the like, that requires a collaboration of multiple users to access a data object. As described in greater detail below, the multi-credential authentication features described herein may control access to the data object through requiring authentication of user credentials from multiple users to access a data object. Multi-credential authentication may include controlling access to a data object according to a multi-credential access policy, which may indicate a threshold number of authenticated users required to access the data object as well as various other access criteria or other access parameters.

[0012] The multi-credential authentication features may support collaboration in a storage layer between multiple users requesting to open or access a particular data object. Requiring authentication of multiple users to access a data object may increase data security, as the multiple users may be required to cooperate to access the particular data object. Multi-credential authentication may thus prevent unilateral access, reading, copying, changing, or deleting of a data object, requiring that multiple users consent to access prior to any actual data access occurs.

[0013] Figure 1 shows an example of a system 100 that supports multi- credential authentication. The system 100 may take the form of a computing system, including a single or multiple computing devices such as servers, compute nodes, memory or storage systems, desktop or laptop computers, smart phones or other mobile devices, tablet devices, embedded controllers, and more. [0014] The system 100 may control storage of data objects. As used herein, a data object may refer to any representation of data, and may thus take the form of any type of data structure, data file, or various other data representations. The data object may include the represented data itself, metadata, an identifier or filename, various other elements, and any combination thereof. The system 100 may thus store data objects, control access to data objects, or both. As seen in the example shown in Figure 1 , the system 100 includes a memory 102 that stores data objects, such as the data object 104. The memory 102 may be any storage medium that stores data, including disk drives, optical storages, flash memory, solid-state drives, and much more. In some examples, the memory 102 is a distributed memory, e.g., distributed across multiple different devices or memory systems. In that regard, the system 100 may implement a distributed memory system (e.g., a distributed object store) and the data objects stored or controlled by the system 100 may be stored in a distributed manner.

[0015] As described in greater detail herein, the system 100 may control access to data objects through multi-credential authentication. That is, the system 100 may require authentication of multiple, different users in order to access a particular data object. Such access control may be provided through a multi- credential access policy, which may specify various criteria required to access the data objects, including a threshold number of users to authenticate prior to granting access to the data object.

[0016] The system 100 may include various components to provide any of the multi-credential authentication features described herein. For instance, the system 100 may implement an authentication engine 1 10 that controls access to the data object 104 by requiring authentication of multiple users to access the data object 104. The system 100 may implement the authentication engine 1 10 (and components thereof) in various ways, for example as hardware and programming. The programming for the authentication engine 1 10 may take the form of processor-executable instructions stored on a non-transitory machine- readable storage medium, and the processor-executable instructions may, upon execution, cause hardware to perform various multi-credential authentication features described herein. In that regard, various programming instructions or modules of the authentication engine 1 10 may implement engine components to support or provide the multi-credential authentication features described herein. The hardware for the authentication engine 1 10 may include a processing resource to execute such instructions. A processing resource may include various number of processors and may be implemented through a single- processor or multi-processor architecture.

[0017] The authentication engine 1 10 may include components to support access control of data objects through multi-credential authentication. In the example implementation shown in Figure 1 , the authentication engine 1 10 includes an engine component to control access to the data object 104 according to a multi-credential access policy that requires authentication of user credentials from multiple users to access the data object 104. These and other example multi-credential authentication features are described in greater detail below.

[0018] Figure 2 shows an example of an architecture 200 that supports multi- credential authentication for data objects. The architecture 200 shown in Figure 2 includes a storage system 210. The storage system 210 may be any set of storage components that stores data objects. The storage system 210 may include storage devices (e.g., memory), logic, controllers, circuitry, or various other components to support storage and access of data objects. The storage system 210 may utilize any storage paradigm or architecture to store the data objects, including as examples object-based storage, file-based storage or file hierarchies, block-based storage, and more. In some examples, the storage system 210 takes the form of an object store that utilizes containers to store and control access to multiple data objects.

[0019] The storage system 210 may control access to stored data objects. In that regard, the storage system 210 may implement an authentication engine 1 10 to control access to stored data objects through multi-credential authentication. In controlling access to the data objects, the authentication engine 1 10 may reference, maintain, store, or otherwise access a multi-credential access policy 220. The multi-credential access policy 220 may set forth various access criteria to satisfy in order to open or access a particular data object. Opening a data object may refer to any process that makes the data object available for access and accessing the data object may refer to operations performed on the data object, such as a read, write, copy, delete, move, or other operation.

[0020] The authentication engine 1 10 may apply a particular multi-credential access policy to any number of data objects. For example, the authentication engine 1 10 may apply the multi-credential access policy 220 to a single data object, to a particular container storing multiple data objects, to a data block, or at any other granularity at which the storage system 210 organizes data objects. In some implementations, the multi-credential access policy 220 may set forth a threshold number of users to authenticate in order to access a particular data object or a particular set of data objects, and the authentication engine 1 10 may grant access to requested data object when the threshold number of users have been authenticated.

[0021] The storage system 210 may apply different multi-credential access policies to different data objects. Different multi-credential access policies applicable to different data objects may specify varying access criteria, such as differing threshold number of users for data access (e.g. , two user authentications to access a first data object, four user authentications to access a second data object, etc.). To illustrate, a first data object may require authentication of three users to open and a second object may require authentication of twenty users to open. Other variations in access criteria are possible as well, including any of the different multi-credential access policy parameters set forth below in the description of Figure 3.

[0022] To authenticate the multiple users required to access a data object, the authentication engine 1 10 may receive user credentials from the multiple users. A user credential may include any data that identifies or verifies a particular users, examples of which include a user password, user authentication token (e.g. , provided by the storage system 210 or another authentication system to support token-based authentication and data access), digital certificate, biometric data, and more. In the example shown in Figure 2, the authentication engine 1 10 receives user credentials from multiple users through a user client 231 and a user client 232, which may take the form of any interface, application, hardware- programming combination, or logic through which a user provides a user credential. The user clients 231 and 232 may be a web interface or a mobile application through which users provide user credentials.

[0023] As a particular example, the multi-credential access policy 220 may require authentication of at least two users to access a particular data object. To illustrate this particular example through Figure 2, a first user provides a user credential 241 through the user client 231 . The user credential 241 may be part of or embedded within an open request message to open a particular data object stored by the storage system 210. A second user may provide a user credential 242 through the user client 232. Responsive to authenticating both the first and second users (e.g., via authentication of the user credentials 241 and 242), the authentication engine 1 10 may grant access (e.g., open) to a particular data object requested by the first and second users. That is, the authentication engine 1 10 may grant access to a requested data object upon determination that the access criteria of the multi-credential access policy 220 applicable to the requested data object are satisfied. Such a determination process by the authentication engine 1 10 may be referred to as a data object opening sequence, and the opening sequence may include the reception and authentication of user credentials from users to open a requested data object for access.

[0024] While the multi-credential access policy 220 may require authentication of the user credentials of multiple users as an access criterion for a data object, the multi-credential access policy 220 may specify any number of additional or alternative access criteria as well. Some example access policy parameters are described next in Figure 3.

[0025] Figure 3 shows an example of a multi-credential access policy 310. !n the example shown in Figure 3, the multi-credential access policy 310 includes six different access policy parameters, which may specify a particular access criterion (or type of access criterion) to satisfy in order to access a data object the multi-credential access policy 310 applies to. The access policy parameters may additionally or alternatively specify an access characteristic of the data object, e.g., a limitation to any aspect of the access to the data object that the multi- credential access policy 310 applies to.

[0026] The multi-credential access policy 310 may include a user number parameter 31 1 . The user number parameter 31 1 may specify a threshold (e.g., minimum) number of users to be authenticated in order to open a data object for access. Thus, for muiti-credentiai authentication, the user number parameter 31 1 may specify that authentication of user credentials for at least two users is required to access the data object, though the threshold may be higher than two as well. To describe in another way, the user number parameter 31 1 may specify a minimum number or users required to (successfully) participate in the data object opening sequence through providing user credentials that are authenticated by the authentication engine 1 10. Thus, when the user number parameter 31 1 specifies a value of three, the authentication engine 1 10 may grant access to a data object according to the multi-credential access policy 310 upon authentication of user credentials from no less than three different users.

[0027] Continuing description of example access policy parameters, the multi- credential access policy 310 may include an authorized user list 312. The authorized user list 312 may specify a list of users authorized to open or access data objects that the multi-credential access policy 310 applies to. That is, the authorized user list 312 may indicate which users are authorized to initiate or participate in a data object opening sequence to open a data object controlled by the multi-credential access policy 310. The authorized user list 312 may specify the authorized users as a list of user identification (ID) values, though other user identification mechanisms are possible as well. When the authentication engine 1 10 receives a user credential from a user not specified in the authorized user list 312, the authentication engine 1 10 may reject the user credential or not count the user credential toward the threshold number of user credential authentications required to open the data object.

[0028] The users specified in an authorized user list 312 may be authorized to participate in the opening sequence for a data object, but may or may not be able to access the data object after the data object is opened. In some examples, the authorized user list 312 may also indicate the users authorized to access a data object (and thus all users participating in an opening sequence are each granted access to the data object). In other examples, the multi-credential access policy 310 includes different lists to specify the users authorized to open the data object (e.g., participate in the data object opening sequence) and the users authorized to access the data object (e.g., read, write, copy, delete, or otherwise access the data object after opening). Thus, in some examples, not all users participating in the opening sequence are actually granted access to the data object, e.g., as described below with respect to an access mode parameter.

[0029] Continuing the description of example access policy parameters, the multi-credential access policy 310 may include an open window parameter 313. The open window parameter 313 may specify a time period requirement to receive user credentials from the multiple users to access a data object. For example, the open window parameter 313 may specify a time limit for a data object opening sequence to complete, requiring user credentials from the multiple users to be provided within the time limit. To illustrate, the authentication engine 1 10 may require the time period between a first of the multiple users providing a user credential to the last of the multiple users providing a user credential to be less than the time period specified in the open window parameter 313. As another way to describe the open window parameter 313, the authentication engine 1 10 may deny access to a data object when user credentials have not been received from a threshold number of users (specified in the user number parameter 31 1 ) after the time period specified in the open window parameter 313 has elapsed since the opening sequence started (e.g., when a first user provides user credentials).

[0030] As yet another example of an access policy parameter, the multi- credential access policy 310 may include user role criteria 314. The user role criteria 314 may specify a required user roles for at least one of the multiple users authenticated to open a data object. Through user role criteria 314, the multi- credential access policy 310 may require particular user types to participate in the data object opening sequence, which may provide increased security or protection against unsanctioned use. As examples, a user role criteria may indicate a particular employee level (e.g., VP level or higher), a particular organization role (e.g., customer service role to access a service log), a particular combination of user roles (e.g., both a patient and a doctor to access a medical file of the patient or both an attorney and a client to access a client file), and the like.

[0031] In controlling access to a data object according to the user role criteria 314, the authentication engine 1 10 may deny access to the data object when the multiple, authenticated users collectively fail to satisfy the user role criteria 314. As a particular example, a user role criterion of a multi-credential access policy may require authentication of at least one of authorized user in the data opening sequence with an associated "attorney" user role among the at least three user authentications required to open a data object for access. In this example, the authentication engine 1 10 may authenticate the user credentials from three authorized users (thus satisfying a user number parameter), but deny access to the data object when none of the three authorized users has an associated "attorney" user role.

[0032] Accordingly the user role criteria 314 may specify a particular user role characteristic required for at least one user participating in the opening sequence of a requested data object. More generally, the multi-credential access policy 310 may include access parameters specifying any user characteristic requirement or combination of user characteristic requirements for the multiple authenticated users in the multi-credential authentication. Example user characteristics include a threshold user age, geographic location, internet protocol (IP) address, enterprise department, and countless more. Example user characteristic combinations include a combination of male-female users, of employees from a first department and a second department, or of users representing each of the multiple geographic locations of an organization. Many other combinations are possible. The specific user characteristics or user characteristic combinations are nearly limitless and may be flexibly configured by a system administrator or other control entity as an access parameter of the multi-credential access policy 310.

[0033] The example access policy parameters discussed above include various access criteria that the multi-credential access policy 310 may impose to control access to a particular data object. That is, some or all of the access policy parameters of the multi-credential access policy 310 may apply to opening of a requested data object for subsequent access. As other examples described next, the multi-credential access policy 310 may specify access constraints or limitations once a data object is opened for access.

[0034] As one such example, the multi-credential access policy 310 may include an open timeout parameter 315. The open timeout parameter 315 may specify a time limit for accessing a data object. Thus, in controlling access to a data object according to the multi-credential access policy 310, the authentication engine 1 10 may close the data object after a predetermined time period has elapsed as specified by the open timeout parameter 315. For example, when the open timeout parameter 315 has a value of ten minutes, the authentication engine 1 10 may automatically close a data object ten minutes after opening or granting access to the data object. The authentication engine 1 10 may do so by restricting or denying access to the data object after the time limit elapses. In some examples, the authentication engine 1 10 may control access to a data object according to the open timeout parameter 315 by embedding the time limit as a valid period applicable for a multi-credential authentication token (discussed in greater detail below) granted to access the data object.

[0035] As another example of an access policy parameter, the multi-credential access policy 310 may include an access mode parameter 316. The access mode parameter 316 may specify which of the multiple users authenticated to open the data object is granted access to the data object. The access mode parameter 316 may list specific users that can access the data object after opening (e.g., in contrast to the authorized user list 312 which may specify which users are authorized to provide user credentials in the opening sequence to open the data object for access). As another example, the access mode parameter 316 may grant access to a subset of the multiple users authenticated to open the data object. The access mode parameter 316 may specify that all users are granted access to the data object, only a particular user that first provides a user credential is granted access to the data object, only a particular user that last provides a user credential is granted access to the data object, only a particular user that satisfies a particular user role criterion is granted access to the data object, or any other delineated subset of the authenticated users.

[0036] As such, the authentication engine 1 10 may control which particular users are granted access to the data object after opening the data object. Not ail of the multiple users whose user credentials were authenticated to open the data object may be granted access to the data object, as the access mode parameter 316 may constrain access of the data object to some, or even none, of the multiple users. As another example, the access mode parameter 316 may increase the scope of access for an opened data object. For instance, the access mode parameter 316 may specify that different users that did not participate in the opening sequence are granted access to the data object, possibly including users that are not specified in the authorized user list 312 as well. Through the access mode parameter 316, the authentication engine 1 10 may control which particular users are granted access to an opened data object.

[0037] As shown in Figure 3, a multi-credential access policy 310 may include various access parameters that may specify criteria to open to a data object for access, constraints for the accessing of the data object, and the like. Example parameter values for the access policy parameter discussed above are also in shown in Figure 3. Thus, in controlling a data object according to the example parameter values of the multi-credential access policy 310 shown in Figure 3, the authentication engine 1 10 may require that authentication of user credentials from at least two users (user number parameter 31 1 ) authorized to participate in the opening sequence (as specified in the authorized user list 312) occur within 30 seconds (open window parameter 313) and that at least one of the users has an associated "doctor" user role and that at least one of the users has an associated "patient" user role (user role criteria 314). Further, in this example, the authentication engine 1 10 may grant access to the data object to all users involved in the opening sequence (access mode parameter 318) and automatically close the data object after 10 minutes (open timeout parameter 315).

[0038] While some example access policy parameters of a multi-credential access policy 310 are described in Figure 3, many additional or alternative parameters are possible. The authentication engine 1 10 may control access to a data object according to a multi-credential access policy that includes some or all of the example access policy parameters described in Figure 3, and further include any number of additional or alternative access policy parameters as well.

[0039] Figure 4 shows an example of a communication exchange 400 to access a data object controlled through a multi-credential access policy. In Figure 4, the authentication engine 1 10 may authenticate multiple users to open and grant access to a data object, in particular a first user communicating through a user client 231 and a second user communicating through a user client 232.

[0040] In the communication exchange 400, the first and second users may each obtain a user authentication token through which the first and second users may respectively provide a user credential in the opening sequence for a requested data object. For example, in Figure 4, the user client 231 used by the first user may send a getToken message 410 to the authentication engine 1 10, which may include a user ID and a user password for the first user. The authentication engine 1 10 may authenticate the user password, and provide a user authentication token for the first user, shown as the user token 41 1 in Figure 4. Likewise, the user client 232 used by the second user may send the getToken message 415 and the authentication engine 1 10 may respond with a user authentication token for the second user, shown as the user token 416 in Figure 4.

[0041] The authentication engine 1 10 may identify that an opening sequence for a particular data object has been initiated. The authentication engine 1 10 may do so upon receiving a message requesting to open a particular data object (also referred to as a requested data object). In Figure 4, the user client 231 used by the first user sends the open request message 420, which may identify the requested data object, e.g., by filename, pathname, object or global identifier value, by a container or block ID that stores the data object, or in various other ways. The open request message 420 may also include an identification of the user requesting to open the data object (e.g., user ID of the first user in this example) and include the user authentication token of the user (e.g., the user token 41 1 of the first user). The authentication engine 1 10 may identify the initiation of the open sequence responsive to receiving the open request message 420.

[0042] When the multi-credential access policy includes an open window parameter, the authentication engine 1 10 may deny access to a requested data object when a threshold number of users fail to provide user credentials for authentication during the time period specified by the open window parameter. In the example shown in Figure 4, the time period specified by an open window parameter elapses without the authentication engine 1 10 receiving any additional user credentials for authentication to open the requested data object for access. Thus, the opening sequence initiated by the open request message 420 fails, and the authentication engine 1 10 may send an access denied message 421 to the user client 231 .

[0043] Continuing the example communication exchange 400 shown in Figure 4, the authentication engine 1 10 may subsequently identify initiation of another opening sequence for the requested data object, this time by receiving the open request message 430 from the user client 231 . The open request message 430 may be similar to the open request message 420 previously sent by the user client 231 used by the first user, e.g. , by requesting to open the same data object, specifying the first user as the requesting user, and providing the user token 41 1 of the first user. In this subsequent opening sequence, the authentication engine 1 10 may receive user credentials of the second user within the time period specified by the open window parameter.

[0044] As shown in the communication exchange 400, the authentication engine 1 10 receives the open request message 431 from the user client 232 used by the second user, which may request to open the same data object as the open request message 430 and 420, specify the second user as a requesting user, and include the user token 416 of the second user. Upon receiving the open request message 431 (or upon authenticating the user token 418 contained in the open request message 431 ), the authentication engine 1 10 may determine that authentication of the multiple users required to open and access the requested data object has occurred (in this case, the multi-credential access policy requires authentication of two authorized users).

[0045] The multi-credential access policy may include various access criteria, such as those specified by the threshold number of user authentications and open window parameter as well as any other parameters described above. Upon a determination that the access criteria of the multi-credential access policy are satisfied, the authentication engine 1 10 may grant access to the requested data object. That is, the authentication engine 1 10 may open the requested data object by making the data object available for access, but limit actual access of the requested data object only to the users specified in an access mode parameter. The authentication engine 1 10 may, for example, grant access to the first user but not the second user, even though both users participated in the opening sequence (and were authorized to do so). The authentication engine 1 10 may grant access to the second user, but not the first user, for example when an access mode parameter of the multi-credential access policy grants access to the data object only to users meeting a particular user role or user characteristic criterion satisfied by the second user, but not the first user.

[0046] In the example shown in Figure 4, the authentication engine 1 10 grants access to the data object to both the first user and the second user. In particular, the authentication engine 1 10 may do so sending a multi-credential authentication token 440 to the user client 231 of the first user as well as the user client 232 of the second user. The multi-credential authentication token 440 may allow the first and second user to access (e.g., read, write to, copy, or delete) the data object by presenting the multi-credential authentication token 440 as an access credential. In some examples, the multi-credential authentication token 440 includes or specifies a time limit for which the multi-credential authentication token 440 is valid (e.g., according to the time limit specified in an open timeout parameter of a multi-credential access policy). The access state for the requested data object may be encapsulated within the multi-credential authentication token 440 itself, so a storage system need not maintain access state for opened data objects.

[0047] In other examples, the authentication engine 1 10 or a storage system storing the requested data object maintains access state for a data object. As such, the authentication engine 1 10 may grant access to users by sending an indication (e.g., message) to a user client indicating a user has been granted access to the requested data object. Regarding tracking of access states, the authentication engine 1 10 or a storage system may track access state of various stored data objects, such as the time the requested data object was opened, the authorized users participating in the opening sequence, the particular users granted access to the requested data object, the time at which the requested data object will automatically close, other state values relevant to access of the data object, or any combinations thereof.

[0048] As another feature, the authentication engine 1 10 may control access to a data object based on an explicit close command from one of the multiple users granted access to the data object. As multiple users may be authenticated and granted access to a requested data object, the authentication engine 1 10 may control access to the data object when one (or more) of the users determines to close the object (e.g., close access to the data object prior to expiration of the time limit specified in an open timeout parameter). When the authentication engine 1 10 determines that at least one user requests to close a data object, the authentication engine 1 10 may restrict or deny access to the data object for other users as well.

[0049] By doing so, the authentication engine 1 10 may ensure that none of the multiple users granted access may change the data object after another user has already requested to close access to the object. Such measures may increase the security and effectiveness of multi-user collaboration and access of the data object, !n some examples, the authentication engine 1 10 updates the state of the data object to close access, whether locally in a storage system, by revoking or invalidating the multi-credential authentication token 440 previously sent to users to access the data object, or in various other ways.

[0050] Figure 5 shows an example of an architecture 500 that supports multi- credential authentication for data objects. The architecture 500 shown in Figure 5 includes the storage system 210 that implements an authentication engine 1 10 to control access to stored data objects according to a multi-credential access policy 220 applied to the data objects.

[0061] The architecture 500 shown in Figure 5 also includes a multi-user client 510. The multi-user client 510 may support access to data objects controlled by a multi-access credential policy 220 as a virtual multi-user. Put another way, the multi-user client 510 may support requests to open or access a particular data object by providing the user credentials of multiple users in a combined open request, as described in greater detail below. The multi-user client 510 may be implemented in multiple ways, for example as a combination of hardware and programming as similarly described above with respect to the authentication engine 1 10.

[0062] In operation, the multi-user client 510 may receive user credentials from multiple, different users. In Figure 5, the multi-user client 510 receives a user credential 51 1 from a first user and a user credential 512 from a second user. In some examples, the multi-user client 510 itself may present a user interface through which the first and second users provide the user credentials 51 1 and 512 respectively. In such examples, the first and second users may be present in the same physical location to sequentially enter their respective user credentials (e.g., a multi-user client 510 implemented by terminal at a hospital or physician's office used by a physician and patient, a computer used at a real estate closing by an attorney and client, or in any number of other scenarios). In some examples, the multi-user client 510 may operate below an application layer, operating "under the hood" of an application and aggregating the user credentials 51 1 and 512 from different application user interfaces such as the user clients 231 and 232 discussed above.

[0053] The multi-user client 510 may aggregate a sufficient number of user credentials from different users to satisfy a user number parameter of the multi- credential access policy 220, Thus, when three user authentications are required to access a data object, the multi-user client 510 may aggregate user credentials for three authorized users. The multi-user client 510 may then send the aggregated user credentials in a single, combined open request message to the authentication engine 1 10. In Figure 5, the multi-user client 510 sends the combined open request message 520, which may identify the first and second users, specify a particular data object requested for access, and include the user credentials 51 1 and 512 of the first and second users.

[0054] By providing a combination of user credentials, the multi-user client 510 may request access for a "combined" user, which may be a virtual user collectively representing the users providing user credentials to the multi-user client 510. In some examples, the multi-credential access policy 220 may specify an access criteria! specifically requiring presentation of user credentials through a combined open request or an access mode parameter that grants access to a data object only to a virtual "combined" user represented through the multi-user client 510. The virtual "combined^" user represented by the multi-user client 510 may increase security of data accesses, for example by granting access to the virtual "combined" user without exposing individual user authentication tokens. This feature is also described in Figure 6.

[0055] Figure 6 shows an example of a communication exchange 600 between an authentication engine 1 10 and a multi-user client 510 to access a data object controlled through a multi-credential access policy.

[0056] !n Figure 6, the multi-user client 510 receives a first open request from a first user to open a particular data object controlled by a multi-credential access policy, shown as the Open Request (userl ) message 610. The first open request may include a user password of the first user or another form of user authentication. Along similar lines, the multi-user client 510 may receive a second open request from a second user also to open the particular data object, shown as the Open Request (user 2) message 61 1 in Figure 6. This second open request may include a user password of the second user.

[0057] Through the user passwords provided in the open requests, the multiuser client 510 may obtain user authentication tokens for the first and second users. For the first user, the multi-user client 510 may send a get token message providing the user password of the first user, shown as the getToken(user1 ) message 820 in Figure 6. Responsive to this get token message, the multi-user client 510 may receive a user authentication token for the first user, shown in Figure 6 as the user token 621 sent from the authentication engine 1 10. Similarly, the multi-user client 510 may send the getToken(user2) message 622 including the user password of the second user and receive a user authentication token for the second user in response, shown as the user token 623. Then, the multi-user client 510 may send a combined open request message 631 that includes the user authentication tokens of both the first and second users, e.g., the user tokens 621 and 623. Upon determination by the authentication engine 1 10 that the access criteria of the multi-credential access policy are satisfied, the authentication engine 1 10 may grant access to a combined "virtual" user represented by the multi-user client 510 and send a multi-credential authentication token 640 for the combined "virtual" user to access the requested data object.

[0058] As shown in the example communication sequence 600 in Figure 6, the multi-user client 510 may obtain access to a requested data object without exposing the individual user authentication tokens 621 and 623 to the users themselves. That is, the first and second users or user clients used by the first and second users may provide access to a requested data object without receiving or acquiring a user authentication token, which may result in increased data security and less chance of malicious acquisition or use of user authentication tokens.

[0059] Figure 7 shows an example of logic 700 that a system or device may implement to support multi-credential authentication. A system may implement the logic 700 as hardware, executable instructions stored on a machine-readable medium, or as combinations of both. For example, an authentication engine 1 10 may implement the logic 700, and the authentication engine 1 10 may perform or execute the logic 700 as a method or process.

[0060] Through implementing or performing the logic 700, an authentication engine 1 10 may provide multi-credential authentication for a data object (702), which may include requiring authentication of multiple users to grant access to the data object. In providing the multi-credential authentication, the authentication engine 1 10 may receive a first open request for a first user to open the data object, the first open request including a user credential of the first user (704). The authentication engine 1 10 may also receive a second open request for a second user to open the data object, the second open request including a user credential of the second user (706). Then, the authentication engine 1 10 may grant access to the data object responsive to authenticating the user credentials of the first and second users (708). Granting access through the logic 700 may include providing a multi-credential authentication token through which the first user, the second user, or both, access the data object.

[0061] The logic 700 may include any number of additional or alternative elements as well, for example to implement any of the multi-credential authentication features described herein with respect to the authentication engine 1 10, the multi-user client 510, or both.

[0062] For example, the logic 700 may include providing multi-credential authentication through a multi-credential access policy applicable to the data object. Thus, in implementing the logic 700, the authentication engine 1 10 may grant access to the data object responsive to authenticating the user credentials of the first and second users within a predetermined time period, e.g., as specified by an open window parameter of the multi-credential access policy. The multi- credential access policy may, as another example, specify any number of user role or user characteristic parameters. In implementing the logic 700, the authentication engine 1 10 may grant access to the first user, but not the second user in accordance with various user roles or characteristics associated with the first and second users respectively. As yet another example, the multi-credential access policy may include an open timeout parameter. In implementing the logic 700 in this example, the authentication engine 1 10 may, after granting access to the data object, close the data object after a predetermined time period has elapsed as specified by the open timeout parameter.

[0063] In some examples, the logic 700 may include determination of the multiple users participating in an opening sequence of a data object. For instance, the authentication engine 1 10 may determine that the first open request identifies the second user as an additional opener also requesting to open the data object, and likewise determine that the second open request identifies the first user as an additional opener also requesting to open the data object. More generally, the authentication engine 1 10 may determine that each of the multiple users requesting to open a particular data object (e.g., participating in an opening sequence) are identified by the other users participating in the opening sequence.

[0064] Thus, for a data object requiring authentication of three different authorized users, an open request message from a first user may identify a second and third user also participating in the opening sequence (e.g., as additional openers). An open request message from the second user may identify the first and third users as additional openers in the opening sequence, and the like. The authentication engine 1 10 may confirm that a particular user providing user credentials as part of an opening sequence is identified by other users as a user participating in the opening sequence. If not identified by other users, the authentication engine 1 10 may ignore an open request from the non-identified user or determine not to count the provided user credentials towards the threshold number of user authentications required to access a data object. By doing so, the authentication engine 1 10 may confirm the particular users participating in the opening sequence and prevent other users not involved in the opening sequence from inadvertent access or inadvertent providing of user credentials to satisfy a threshold number of user authentications required by a multi-credential access policy. [0065] While some example elements have been described, the logic 700 may implement any additional or alternative multi-credential authentication features described herein.

[0066] Figure 8 shows an example of a system 800 that supports multi- credential authentication. The system 800 may include a processing resource 810, which may take the form of a single or multiple processors. The processor(s) may include a central processing unit (CPU), microprocessor, or any hardware device suitable for executing instructions stored on a machine-readable medium, such as the machine-readable medium 820 shown in Figure 8. The machine- readable medium 820 may be any non-transitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as the instructions 822, 824, 826, 828, and 830 in Figure 8. As such, the machine- readable medium 820 may be, for example, Random Access Memory (RAM) such as dynamic RAM (DRAM), flash memory, memristor memory, spin-transfer torque memory, an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disk, and the like.

[0067] The system 800 may execute instructions stored on the machine- readable medium 820 through the processing resource 810. Executing the instructions may cause the system 800 to perform any of the multi-credential authentication features described herein, including according to any features of the authentication engine 1 10, the multi-user client 510, and the like.

[0068] For example, the instructions 822, 824, 828, 828, and 830 shown in Figure 8 may implement various features of the multi-user client 510. Execution of the instructions 822, 824, 826, 828, and 830 by the processing resource 810 may cause the system 800 to, for example, receive a first open request for a first user to open a data object controlled through a multi-credential access policy, the first open request including a user password of the first user (822); receive a second open request for a second user to open the data object, the second open request including a user password of the second user (824); provide the user password of the first user and the user password of the second user to an authentication engine that controls access to the data object, and afterwards, receive a user authentication token for the first user and a user authentication token for the second user (828); send a combined open request to the authentication engine, the combined open request including both of the user authentication tokens (828); and access the data object after the authentication engine grants access to the data object (830).

[0069] In some examples, the machine-readable medium 820 may include instructions executable by the processing resource 810 further to receive, after sending the combined open request, a multi-credential authentication token for both the first user and the second user; and access the data object using the multi-credential authentication token.

[0070] The systems, methods, devices, and logic described above, including the authentication engine 1 10 and the multi-user client 510, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium. For example, the authentication engine 1 10, the multi-user client 510, or both, may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits, A product, such as a computer program product, may include a storage medium and machine-readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above, including according to any features of the authentication engine 1 10, the multi-user client 510, or both.

[0071] The processing capability of the systems, devices, and engines described herein, including the authentication engine 1 10 and the multi-user client 510, may be distributed among multiple system components, such as among multiple processors and memories, which may include multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library (e.g., a shared library).

[0072] While various examples have been described above, many more implementations are possible.

Claims

1 . A system comprising:

a memory storing a data object; and

an authentication engine to control access to the data object according to a multi-credential access policy that requires authentication of user credentials from multiple users to access the data object.

2. The system of claim 1 , wherein the multi-credential access policy includes a user number parameter specifying a threshold number of users for the multiple users, wherein the threshold number of users is two or more.

3. The system of claim 1 , wherein the multi-credential access policy comprises an open window parameter specifying a time period requirement to receive the user credentials for the multiple users.

4. The system of claim 1 , wherein the multi-credential access policy comprises a user role criterion specifying a required user role for at least one of the multiple users.

5. The system of claim 1 , wherein the multi-credential access policy comprises an access mode parameter specifying which of the multiple users are granted access to the data object.

6. The system of claim 5, wherein the access mode parameter specifies: only a particular user that first provides a user credential is granted access to the data object;

only a particular user that last provides a user credential is granted access to the data object; or

only a particular user that satisfies a user role criterion is granted access to the data object.

7. The system of claim 1 , wherein the user credentials comprise a user password, a user authentication token, or a combination of both.

8. A method comprising:

providing multi-credential authentication for a data object by:

receiving a first open request for a first user to open the data object, the first open request comprising a user credential of the first user;

receiving a second open request for a second user to open the data object, the second open request comprising a user credential of the second user; and

granting access to the data object responsive to authenticating the user credentials of the first and second users.

9. The method of claim 8, comprising granting access to the data object responsive to authenticating the user credentials of the first and second users within a predetermined time period.

10. The method of claim 8, wherein providing the multi-credential access for the data object further comprises:

determining that the first open request identifies the second user as an additional opener also requesting to open the data object; and

determining that the second open request identifies the first user as an additional opener also requesting to open the data object.

1 1 . The method of claim 8, wherein granting access to the data object comprises granting access to the first user, but not the second user,

12. The method of claim 8, wherein providing multi-credential access for a data object further comprises, after granting access to the data object, closing the data object after a predetermined time period has elapsed.

13. The method of claim 8, wherein granting access to the data object comprises providing a multi-credential authentication token through which the first user, the second user, or both, access the data object.

14. A non-transitory machine-readable medium comprising instructions executable by a processing resource to:

receive a first open request for a first user to open a data object controlled through a multi-credential access policy, the first open request including a user password of the first user;

receive a second open request for a second user to open the data object, the second open request including a user password of the second user;

provide the user password of the first user and the user password of the second user to an authentication engine that controls access to the data object, and afterwards, receive a user authentication token for the first user and a user authentication token for the second user;

send a combined open request to the authentication engine, the combined open request including both of the user authentication tokens; and access the data object after the authentication engine grants access to the data object.

15. The non-transitory machine-readable medium of claim 14, wherein the instructions are executable by the processing resource further to:

receive, after sending the combined open request, a multi-credential authentication token for both the first user and the second user; and

access the data object using the multi-credential authentication token.