LAYERED AUTHENTICATION METHOD FOR MANAGING ACCESS TO CLOUD RESOURCES

Abstract

A disclosed method for managing access to cloud infrastructure include responding to receiving a user request to access a cloud resource, such as a cluster associated with a hyper-converged infrastructure appliance, associated with an entity by performing a layered authentication of the user. The layered authentication includes determining first layer privileges based on first user credentials associated with a first authentication module and determining second layer privileges based on second user credentials associated with a second authentication module. The request is granted or denied based on a combination of the user's first and second layer privileges. The first authentication module may be associated with a first authentication domain such as an authentication domain of a cloud service provider or an OEM of cloud infrastructure resources. The second authentication module may comprise an authentication module maintained by the entity associated with the resource targeted by the user request.

Claims

1. A method for managing access to cloud infrastructure, the method comprising: responsive to receiving a request to access a cloud resource associated with an entity, performing a layered authentication of a user associated with the request, wherein the layered authentication includes: determining first layer privileges of the user based on first user credentials associated with a first authentication module; determining second layer privileges for the user based on second user credentials associated with a second authentication module; and determining whether to grant the request based, at least in part, on a combination of the first layer privileges and the second layer privileges.

2. The method of claim 1, wherein the cloud infrastructure resource includes a cluster associated with a hyper-converged infrastructure appliance.

3. The method of claim 1, wherein the first authentication module comprises a cloud service provider authentication module.

4. The method of claim 3, wherein the second authentication module comprises an authentication module maintained by the entity.

5. The method of claim 4, wherein the first credentials and the second credentials are independent and distinct.

6. The method of claim 4, wherein the user request contains only one of the first credentials and the second credentials.

7. The method of claim 1, wherein the first layer privileges and the second layer privileges both include privileges indicative of cloud infrastructure resources viewable to the user.

8. The method of claim 7, wherein the second layer privileges include action privileges indicative of actions the user is authorized to perform on the cloud infrastructure resources.

9. The method of claim 8, wherein the action privileges are selected from a group of privileges comprising: download privileges for downloading data from the cloud infrastructure resources; update privileges for taking one or more actions to update the cloud infrastructure resources; pre-check privileges for performing a pre-update health check of the cloud infrastructure privileges.

10. The method of claim 7, wherein determining whether to grant the request includes denying the request unless both the first layer privileges of the user and the second layer privileges of the user include view privileges.

11. An information handling system, comprising: a central processing unit; and a memory including process executable instructions that, when executed by the central processing unit, cause the system to perform operations for managing access to cloud infrastructure, the operations comprising: responsive to receiving a request to access a cloud resource associated with an entity, performing a layered authentication of a user associated with the request, wherein the layered authentication includes: determining first layer privileges of the user based on first user credentials associated with a first authentication module; determining second layer privileges for the user based on second user credentials associated with a second authentication module; and determining whether to grant the request based, at least in part, on a combination of the first layer privileges and the second layer privileges.

12. The information handling system of claim 11, wherein the cloud infrastructure resource includes a cluster associated with a hyper-converged infrastructure appliance.

13. The information handling system of claim 11, wherein the first authentication module comprises a cloud service provider authentication module.

14. The information handling system of claim 13, wherein the second authentication module comprises an authentication module maintained by the entity.

15. The information handling system of claim 14, wherein the first credentials and the second credentials are independent and distinct.

16. The information handling system of claim 14, wherein the user request contains only one of the first credentials and the second credentials.

17. The information handling system of claim 11, wherein the first layer privileges and the second layer privileges both include privileges indicative of cloud infrastructure resources viewable to the user.

18. The information handling system of claim 17, wherein the second layer privileges include action privileges indicative of actions the user is authorized to perform on the cloud infrastructure resources.

19. The information handling system of claim 18, wherein the action privileges are selected from a group of privileges comprising: download privileges for downloading data from the cloud infrastructure resources; update privileges for taking one or more actions to update the cloud infrastructure resources; pre-check privileges for performing a pre-update health check of the cloud infrastructure privileges.

20. The information handling system of claim 17, wherein determining whether to grant the request includes denying the request unless both the first layer privileges of the user and the second layer privileges of the user include view privileges.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more complete understanding of the present embodiments and advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:

[0010] FIG. 1 illustrates a user requesting access to a cloud platform resource;

[0011] FIG. 2 illustrates a layered authentication manager in accordance with disclosed teachings;

[0012] FIG. 3 illustrates an example of layer authentication modules in accordance with disclosed teachings;

[0013] FIG. 4 illustrates a flow diagram of a layered authentication method in accordance with disclosed teachings; and

[0014] FIG. 5 illustrates an exemplary information handling system.

DETAILED DESCRIPTION

[0015] Exemplary embodiments and their advantages are best understood by reference to FIGS. 1-5, wherein like numbers are used to indicate like and corresponding parts unless expressly indicated otherwise.

[0016] For the purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, an information handling system may be a personal computer, a personal digital assistant (PDA), a consumer electronic device, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include memory, one or more processing resources such as a central processing unit (“CPU”), microcontroller, or hardware or software control logic. Additional components of the information handling system may include one or more storage devices, one or more communications ports for communicating with external devices as well as various input/output (“I/O”) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communication between the various hardware components.

[0017] Additionally, an information handling system may include firmware for controlling and/or communicating with, for example, hard drives, network circuitry, memory devices, I/O devices, and other peripheral devices. For example, the hypervisor and/or other components may comprise firmware. As used in this disclosure, firmware includes software embedded in an information handling system component used to perform predefined tasks. Firmware is commonly stored in non-volatile memory, or memory that does not lose stored data upon the loss of power. In certain embodiments, firmware associated with an information handling system component is stored in non-volatile memory that is accessible to one or more information handling system components. In the same or alternative embodiments, firmware associated with an information handling system component is stored in non-volatile memory that is dedicated to and comprises part of that component.

[0018] For the purposes of this disclosure, computer-readable media may include any instrumentality or aggregation of instrumentalities that may retain data and/or instructions for a period of time. Computer-readable media may include, without limitation, storage media such as a direct access storage device (e.g., a hard disk drive or floppy disk), a sequential access storage device (e.g., a tape disk drive), compact disk, CD-ROM, DVD, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and/or flash memory; as well as communications media such as wires, optical fibers, microwaves, radio waves, and other electromagnetic and/or optical carriers; and/or any combination of the foregoing.

[0019] For the purposes of this disclosure, information handling resources may broadly refer to any component system, device or apparatus of an information handling system, including without limitation processors, service processors, basic input/output systems (BIOSs), buses, memories, I/O devices and/or interfaces, storage resources, network interfaces, motherboards, and/or any other components and/or elements of an information handling system.

[0020] In the following description, details are set forth by way of example to facilitate discussion of the disclosed subject matter. It should be apparent to a person of ordinary skill in the field, however, that the disclosed embodiments are exemplary and not exhaustive of all possible embodiments.

[0021] Throughout this disclosure, a hyphenated form of a reference numeral refers to a specific instance of an element and the un-hyphenated form of the reference numeral refers to the element generically. Thus, for example, “device 12-1” refers to an instance of a device class, which may be referred to collectively as “devices 12” and any one of which may be referred to generically as “a device 12”. As used herein, when two or more elements are referred to as “coupled” to one another, such term indicates that such two or more elements are in electronic communication, mechanical communication, including thermal and fluidic communication, thermal, communication or mechanical communication, as applicable, whether connected indirectly or directly, with or without intervening elements.

[0022] Referring now to the drawings, FIG. 1 illustrates an information handling system 100 and a user 103 interacting with an end user computing device, such as a laptop 104, connected to a public or private network 106, to browse to or otherwise connect with a cloud portal 120 of a cloud platform 101, and to submit an access request identifying, at least in part, a cloud-based resource and one or more actions that the user wishes to take with respect to the resource.

[0023] The illustrated cloud platform 101 includes, in addition to cloud portal 120, cloud infrastructure 130 and a cloud platform manager 110. The cloud infrastructure 130 depicted in FIG. 1 may include various types and configurations of information handling components including, as a non-limiting example, the HCI appliance 140 illustrated in FIG. 1. In at least some embodiments, HCI appliance 140 implements a software-centric architecture that supports and tightly integrates virtualized compute, storage, and networking resources. A commercially distributed example suitable for use as the illustrated HCI appliance 140 is any of various VxRail appliances from Dell Technologies.

[0024] The illustrated HCI appliance 140 includes four nodes 143 that have been configured as a 4-node cluster 145. Although the illustrated cluster 145 encompasses four nodes 143, other embodiments of cluster 145 may include more or fewer nodes. Cluster 145 supports virtualized information handling resources including, as examples, one or more virtual machines and/or one or more containerized resources. For the sake of clarity, FIG. 1 omits virtualized resources associated with cluster 145.

[0025] Cluster 145 may be entirely or partially allocated to or otherwise associated with an entity such as a corporate, governmental, or educational entity. For purposes of the following description of layered authentication, it is stipulated that cluster 145 is entirely allocated to or associated with the entity and that user request 105 includes a request to access at least some part of cluster 145. For example, user request 105 may include a request to view and, optionally, updating or taking some other action pertaining to cluster 145. Because user 103 may or may not be an employee or agent of the entity and because user 103 may or may not be authorized to access cluster 145, some form of authentication is necessary. In some cases, there may be two or more authentication modules associated with cluster 145. For example, a cloud service provider or a component vendor, e.g., an OEM of the HCI appliance, may provide a first authentication platform that encompasses, not only cluster 145 and the corresponding entity, but also other resources and other entities. A second authentication platform pertaining to cluster 145 may be an entity-specific module. To illustrate for a case in which HCI appliance 140 is a VxRail appliance from Dell Technologies, permission to perform actions on VxRail resources via cloud portals may be based, at least in part, on the user's identity in a Dell single sign on (SSO) system that encompasses a domain of users that includes extends beyond the entity associated with cluster 145. In addition, however, the entity may wish to control permissions based on entity-specific credentials and security provided, for example, by on-premises server management software such as VMware vCenter SSO. Layered authentication teachings disclosed herein address such situations.

[0026] FIG. 2 illustrates an implementation of cloud platform manager 110 in accordance with disclosed teachings for layered authentication. The cloud platform manager 110 illustrated in FIG. 2 includes a layered authentication manager (LAM) 210 configured to coordinate two distinct authentication modules 211, illustrated as a first authentication module 211-1 and a second authentication module 211-2, for granting access to information handling resources including, in the illustrated example, cluster 145. Each authentication module 211 includes a corresponding authentication interface (AIF) 220 and an authentication database server 230. Each authentication module 211 may be associated with a corresponding user domain. For example, the first authentication module 211-1 may be associated with a user domain maintained by the cloud service provider or a manufacturer or distributer of the cloud infrastructure while the second domain may be associated with a user domain corresponding to the entity associated with cluster 145.

[0027] The LAM 210 illustrated in FIG. 2 includes a LAM interface 212 configured to receive user request 105 and to communicate with AIF 1 220-1 and AIF 2 220-2. The user request 105 shown in FIG. 2 includes credential information 202 indicative of an identity of user 103, resource information 204, indicative of the resource targeted by user request 105, i.e., the resource user 103 would like to access, and action information 206 indicative of an action, command, or procedure to be performed on the targeted resource. Although FIG. 2 represents user request 105 as a single data structure, those of ordinary skill in the field of distributed computing systems and messages will readily appreciate that, in at least some embodiments including RESTful embodiments, the credential, resource, and action information illustrated in FIG. 2 may be conveyed in one or more packets, datagrams, or the like, each of which may be embedded in one or more layers of packet headers.

[0028] Each of the illustrated AIFs 220 is communicatively coupled to the corresponding authentication database server 230. Each of the illustrated authentication database servers 230 has access to a database of records indicating authorized users and their corresponding credentials, e.g., userID, password, biometric data, or the like, as well as the managed resources the user is authorized to access and the privileges, including the actions or commands the user is authorized to perform or execute for each resource.

[0029] Upon receiving user request 105 from cloud portal 120, LAM interface 212 extracts credentials information 202 and resource information 204 from user request 105. The credentials information 202 and resource information 204 are provided to one or both AIFs 220 to invoke AIFs 220 to query the corresponding authentication database servers 230 and thereby retrieve one or more records 231, one of which is illustrated in FIG. 3. The records 231 depicted in FIG. 2, which may be referred to herein as user privilege records 231 indicate the privileges a user has with respect to a particular resource.

[0030] In some embodiments, the credentials information 202 in user request 105 includes separate and distinct credentials for each authentication module 211. In these embodiments, LAM interface 220 may segregate the credentials for each module and forward the appropriate credentials to each AIF 220. In other embodiments, user request 105 may include one but not both sets of credentials. In these embodiments, LAM interface 212 may be configured to obtain credentials for the other authentication module based on the credentials that are provided in user request 105. In one such embodiment, LAM interface 212 may maintain records mapping each user's credentials for the first authentication module 211-1 the users credentials for the second authentication module 211-2. In another embodiment, the mapping of a user's two sets of credentials may be embedded within one of the authentication database servers 230.

[0031] The illustrated AIFs 220, upon receiving credential and resource information from LAM interface 212, query the corresponding database server to determine the user's privileges, if any, with respect to the targeted resource. AIFs 220 may then provide the privileges information to layered access logic 240.

[0032] Layered access logic 240, which may be implemented in hardware, software, or a combination thereof, processes the privileges information received from AIFs 220 and generates a request grant signal 250, indicative of whether the user's requested access to the targeted resource has been granted, based at least in part on a combination of the user's privileges in the first and second authentication modules.

[0033] Each authentication module may maintain privilege information for a number of different privilege parameters corresponding to actions a user may perform on a targeted resource. Non-limiting examples of privileges might include view privileges, download privileges, update privileges, and “pre-check” privileges indicative of the authority to perform pre-update health checks. In some embodiments, the privilege parameters may include a primary privilege parameter, such as a view privilege, that is a perquisite to other privileges. In some such embodiments, layered access logic may deny access to a user who does not have the primary privilege within both authentication modules.

[0034] To resolve conflicts that might arise when the privilege information for a particular privilege parameter differs between the two authentication modules, layered access logic 240 may be configurable to specify which of the authentication modules has priority over any given privilege parameter. In addition, some embodiments may be configured wherein a conflict involving a primary parameter is always resolved in favor of either denying access or granting access. If, as in the previous example, a view privilege is designated as a primary privilege and the two authentication modules contain conflicting view privilege information for a specific user and resource, layered access logic 240 may be configured to specify whether to grant or deny view access to the user.

[0035] FIG. 3 illustrates a layered authentication example for three users 103-1, 103-2, and 103-3, and four privilege parameters (view, pre-check, download, and update) in accordance with disclosed layered authentication teachings. The first module privileges 310-1 illustrated in FIG. 3 indicate the access privileges of each user 103, with respect to cluster 145, within the first authentication module. Similarly, second module privileges 310-2 indicate the access privileges of each user 103, with respect to cluster 145, within the second authentication module. In the illustrated example, first module privileges 310-1 convey that each user 103 has view privileges within the first authentication module. Second module privileges 310-2 convey that, within the second authentication module, first user 103-1 has view and pre-check privileges, second user 103-2 has view, pre-check, download, and update privileges, and third user 103-3 has no access privileges with respect to cluster 145. In the illustrated example, layered access logic 240 has been configured such that the resulting layered privileges 320 granted to each user 103 with respect to cluster 145 include view and pre-check privileges for first user 103-1, view, pre-check, download, and update privileges for second user 103-2, and no privileges for third user 103-3.

[0036] The layered privileges 320 may reflect an implementation of layer access logic 240 in which (1) the view privilege is a primary privilege, (2) the view privilege is the only privilege maintained within the first authentication module, and/or (3) users must have view privilege authority within both authentication modules as a prerequisite to all other privileges. It will, however, be appreciated by those of ordinary skill in the field that other implementations, not represented in FIG. 3, corresponding to one or more different rules or policies implemented by layered access logic 240. As one non-limiting example, a different implementation of layered access logic 240 could treat the primary privilege, such as the view privilege in FIG. 3, as a logical OR case, meaning that view access within either authentication module is sufficient. As another example, both authentication modules could maintain data for each of the applicable privileges, in which case, the resulting privileges could be determined based upon whether the user has the applicable privilege within both authentication modules, i.e., a logical AND policy, or whether the user has the privilege within either authentication module, a logical OR policy. In some cases, layered authentication logic 240 may be configurable wherein a logical AND policy is applied to one or more privileges while a logical OR policy is applied to one or more other privileges. Again, however, these examples are not intended to be exhaustive and other policies for determining the layered privileges 320 are encompassed by teachings disclosed herein.

[0037] FIG. 4 illustrates a flow chart for a layered authentication method 400 in accordance with disclosed teachings. In at least some embodiments, method 400 may be performed by the LAM 210 illustrated in FIG. 2. The illustrated method 400 includes detecting (operation 402) a user request to access a cloud infrastructure resource associated with an entity, which may be a business, an educational institution, a government agency, or the like. Upon detecting the user request, first layer privileges of the user are determined (operation 404) based on first user credentials provided to a first authentication module, which may associated with a first user domain such as a user domain associated with a cloud service provider or a user domain associated with an OEM of the cloud infrastructure. The illustrated method 400 then determines (operation 406) second layer privileges for the user based on second user credentials associated with a second authentication module, wherein the second user domain may refer to a user domain associated with the entity. A grant/deny determination, indicative of whether the user request is granted or denied is then made (operation 408) based, at least in part, on a combination of the first layer privileges and the second layer privileges.

[0038] Referring now to FIG. 5, any one or more of the components illustrated in FIG. 1 and FIG. 2 may implanted as or within an information handling system exemplified by the information handling system 500 illustrated in FIG. 3. The illustrated information handling system includes one or more general purpose processors or central processing units (CPUs) 501 communicatively coupled to a memory resource 510 and to an input/output hub 520 to which various I/O resources and/or components are communicatively coupled. The I/O resources explicitly depicted in FIG. 3 include a network interface 540, commonly referred to as a NIC (network interface card), storage resources 530, and additional I/O devices, components, or resources including as non-limiting examples, keyboards, mice, displays, printers, speakers, microphones, etc. The illustrated information handling system 500 includes a baseboard management controller (BMC) 560 providing, among other features and services, an out-of-band management resource which may be coupled to a management server (not depicted). In at least some embodiments, BMC 560 may manage information handling system 500 even when information handling system 500 is powered off or powered to a standby state. BMC 560 may include a processor, memory, an out-of-band network interface separate from and physically isolated from an in-band network interface of information handling system 500, and/or other embedded information handling resources. In certain embodiments, BMC 560 may include or may be an integral part of a remote access controller (e.g., a Dell Remote Access Controller or Integrated Dell Remote Access Controller) or a chassis management controller.

[0039] This disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments herein that a person having ordinary skill in the art would comprehend. Similarly, where appropriate, the appended claims encompass all changes, substitutions, variations, alterations, and modifications to the example embodiments herein that a person having ordinary skill in the art would comprehend. Moreover, reference in the appended claims to an apparatus or system or a component of an apparatus or system being adapted to, arranged to, capable of, configured to, enabled to, operable to, or operative to perform a particular function encompasses that apparatus, system, or component, whether or not it or that particular function is activated, turned on, or unlocked, as long as that apparatus, system, or component is so adapted, arranged, capable, configured, enabled, operable, or operative.

[0040] All examples and conditional language recited herein are intended for pedagogical objects to aid the reader in understanding the disclosure and the concepts contributed by the inventor to furthering the art, and are construed as being without limitation to such specifically recited examples and conditions. Although embodiments of the present disclosure have been described in detail, it should be understood that various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the disclosure.