PROTECTING API KEYS FOR ACCESSING SERVICES

A method, system, and computer program product for protecting API KEYs for accessing services in a cloud environment are disclosed. A first request for generating a virtual key for a user in an organization to access a service in a cloud environment is received. The first request includes information of the organization, an identity of the user, and information of the service. A first authentication request is sent to an identity provider of the organization based on the information of the organization and the identity of the user. In response to the first authentication being successful, an API key for the organization to access the service is determined. The virtual key for the user to access the service is generated based on the API key, the information of the organization, and the identity of the user. The virtual key is returned as a response of the first request.

FIELD

The present disclosure relates to computing technologies and, more specifically, to methods, systems, and computer program products for protecting API KEYs for accessing services in a cloud environment.

BACKGROUND

With the rise of service (such as a microservice) in a cloud environment, many large-scale projects have hundreds of services in a cloud environment. Now the access to application program interfaces (APIs) of some public services has become more and more common. For convenience, API keys are often provided for users to access these public services.

SUMMARY

The present disclosure provides a computer-implemented method, system, and computer program product for protecting API KEYs for accessing services in a cloud environment. The method may comprise receiving, by one or more processors, a first request for generating a virtual key for a user in an organization to access a service in a cloud environment, wherein the first request comprises information of the organization, an identity of the user in the organization, and information of the service, and wherein an API key is required to access the service. The method may also comprise sending, by the one or more processors, a first authentication request to an identity provider of the organization based on the information of the organization and the identity of the user in the organization. The method may also comprise determining, by the one or more processors, whether the first authentication is successful. The method may also comprise in response to the first authentication being successful, determining, by the one or more processors, the API key for the organization to access the service; generating, by the one or more processors, the virtual key for the user to access the service based on the API key, the information of the organization and the identity of the user in the organization; and returning, by the one or more processors, the virtual key as a response of the first request.

DETAILED DESCRIPTION

The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of exemplary embodiments as defined by the claims and their equivalents. It comprises various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications can be made without departing from the scope and spirit of the embodiments described herein. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

In the following, reference is made to various embodiments. However, it should be understood that the disclosure is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the method, computer system, and computer program described herein. Furthermore, although embodiments may achieve advantages over other possible solutions and/or over the prior art, whether a particular advantage is achieved by a given embodiment is not limiting. Thus, the following aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).

It is to be understood that the singular forms “a,” “an,” and “the” comprise plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a component surface” comprises reference to one or more of such surfaces unless the context clearly dictates otherwise.

As previously described, with the rise of service (such as a microservice) in a cloud environment, many large-scale projects have hundreds of services in a cloud environment. Now the access to application program interfaces (APIs) of some public services has become more and more common. For convenience, API keys are often provided for users to access these public services. However, in the current solution, an API key for accessing a service is always shared in an organization. When a member of the organization has left the organization, the solution may lead serious security risk for the organization. It may be advantageous, therefore, to generate keys based on verifying whether an individual is a member of the organization.

Referring toFIG.1, computer system100is a computer system/server102is shown in the form of a general-purpose computing device, according to some embodiments. In some embodiments, computer system/server102is located on the linking device. In some embodiments, computer system102is connected to the linking device. The components of computer system/server102may comprise, but are not limited to, one or more processors processors110, a system memory160, and a bus115that couples various system components comprising system memory160to the one or more processors110.

Computer system/server102typically comprises a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server102, and it comprises both volatile and non-volatile media, removable and non-removable media.

System memory160can comprise computer system readable media in the form of volatile memory, such as random-access memory (RAM)162and/or cache memory164. Computer system/server102may further comprise other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system165can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to bus115by one or more data media interfaces. As will be further depicted and described below, memory160may comprise at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments disclosed herein.

Program/utility168, having a set (at least one) of program modules169, may be stored in memory160by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may comprise an implementation of a networking environment. Program modules169generally carry out the functions and/or methodologies of embodiments as described herein.

Computer system/server102may also communicate with one or more external devices140such as a keyboard, a pointing device, a display130, etc.; one or more devices that enable a user to interact with computer system/server102; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server102to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces120. Still yet, computer system/server102can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter150. As depicted, network adapter150communicates with the other components of computer system/server102via bus115. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server102. Examples comprise, but are not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that comprises a network of interconnected nodes.

Referring now toFIG.3, a set of functional abstraction layers300provided by cloud computing environment50(FIG.2) is shown, according to some embodiments. It should be understood in advance that the components, layers, and functions shown inFIG.3are intended to be illustrative only and embodiments disclosed herein are not limited thereto. As depicted, the following layers and corresponding functions are provided:

Hardware and software layer60comprises hardware and software components. Examples of hardware components comprise: mainframes61; RISC (Reduced Instruction Set Computer) architecture-based servers62; servers63; blade servers64; storage devices65; and networks and networking components66. In some embodiments, software components comprise network application server software67and database software68.

Virtualization layer70provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers71; virtual storage72; virtual networks73, comprising virtual private networks; virtual applications and operating systems74; and virtual clients75.

In one example, management layer80may provide the functions described below.

An API key is a token for a user to access a public service in a cloud environment. In one existing solution, the cloud environment may generate an API key for a service and assign a credential comprising the API key to a user when the user registers to the service. In another existing solution, the cloud environment may generate the API key when the user requests the API key for accessing the service.FIG.4Adepicts a schematic diagram of an exemplary usage scenario of API Keys for accessing services in a cloud environment, according to some embodiments. Refer toFIG.4A, a user401may register with a plurality of services403in a cloud environment400, and the user401may obtain a plurality of credentials each comprising an API key corresponding to one of the plurality of services403. The user401may provide the plurality of credentials comprising the plurality API keys to a user404, then the user404may access each of the plurality of services403using a corresponding credential comprising a corresponding API key in the plurality of API keys402.

As part of a credential for a user to access a service in a cloud environment, an API key is a long string of a composition of numbers, letters, characters, and the like.FIG.4Bdepicts an exemplary credential410for a user to access a service in a cloud environment. Referring toFIG.4B, the credential410comprises an API key420and other information.

During development, an API key for accessing a service is always shared in a developing team. And during operation and maintenance, an API key for accessing a service may be shared in an organization. This situation may lead to a security risk. For example, a member who obtained an API key may access a corresponding service using a credential comprising the API key after the member leaves the organization, which makes the member have opportunity to, such as, change data of the organization by accessing the service. The action of changing data may lead serious security risk for the organization. On the other hand, it's difficult to revoke all API keys obtained by the member who has left the organization.

FIG.5depicts a schematic diagram of an existing service manager500, according to some embodiments. Referring toFIG.5, the service manager500comprises an API key manager503. In some solutions, the API key manager503may generate a plurality of API keys for a plurality of services in a service pool506and maintain mappings between each respective API key of the plurality of API keys and a corresponding service of the plurality of services. When a user504registers with the service manager500to access a service, such as a service A, in the service pool506, the API key manager503may receive a request from the service manager500for providing an API key. Then the API key manager503may select an API key from the generated plurality keys for the user504to access the service A. In some other solutions, when the user504in the organization requests for an API key to access the service A in the service pool506, the API key manager503, in response to the request, may generate the API key for the user504to access the service A instead of generating API key prior to the request, and then add a mapping between the generated API key and the service A. In both kinds of solutions, if the user504requests to access the service A with a credential comprising the API key, the API key manager503may verify the API key and route the request to the service A based on the mapping. In addition, if the user504who loses the identity in the organization (such as leaves the organization) accesses the service A with a previous obtained API key, the API key manager503may still verify the API key and route the request to the service A based on the mapping. In other words, the API key manager503does not verify the identity of the user, which may bring security risks to the organization.

Therefore, there is a need to develop a method, a system, and a program product for protecting API keys for accessing services in a cloud environment.

According to some embodiments, to protect an API key for accessing a service in a cloud environment, a virtual key may be provided for a user instead of providing the API key itself to the user directly and each user may apply for his/her virtual key for a specific service. A virtual key for a user to access a service may be generated based on at least a corresponding API key for accessing the service and identity of the user in the organization. When the user accesses the service with his/her virtual key, the identity of the user in the organization can be obtained from the virtual key and the identity can be authenticated by an identity provider of the organization. If the user's identity cannot be authenticated, i.e., the user is not a member of the organization, the access request will be rejected to avoid the security risk caused by the unprotected API key, so as to achieve the purpose of maintaining the sustainability of services and meeting strict security regulations.

FIG.6depicts a schematic diagram of a proposed service manager600, according to some embodiments. Though there are many components in the service manager600, only the components related to the disclosure are considered in this description, and other components unrelated to this disclosure are ignored. Referring toFIG.6, the service manager500may comprise a key manager601which may comprise a virtual key manager602and the existing API key manager503.

All components inside of the service manager600are connected directly or indirectly via communication network (not shown inFIG.6). The communication network inFIG.6may comprise various types of communication networks, such as a wide area network (WAN), local area network (LAN), a telecommunication network, a wireless network, a public switched network and/or a satellite network. The communication network may comprise connections, such as wire, wireless communication links, or fiber optic cables.

Each component in the service manager600may be, for example, a mobile device, a telephone, a personal digital assistant, a netbook, a laptop computer, a tablet computer, a desktop computer, or any type of computing device capable of running a program and accessing a network. The service manager600may operate in a cloud computing service model, such as Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS). The service manager600may also be located in a cloud computing deployment model, such as a private cloud, community cloud, public cloud, or hybrid cloud.

Referring toFIG.6, the virtual key manager602may be configured to create and/or withdraw a virtual key for a user in an organization to access a service. The virtual key manager602may comprise a virtual key creator6021and a virtual key verifier6022. Specifically, as an API key for the organization is required for all users in the organization to access a service, the virtual key creator6021may receive a first request for generating a virtual key for a user in an organization to access a service in a cloud environment. In some embodiments, the first request may comprise information of the organization, an identity of the user in the organization, and information of the service. The first request may be from the user who requests a private virtual key to access the service or from the service manager600which may receive a request from the user to register with the service. The information of an organization may be an ID of the organization, or a name of the organization, or a special code of the organization, etc. which may be used to obtain an identity provider605of the organization to authenticate the identity of the user in the organization. The identity of the user in the organization may be an ID of the user in the organization, or a name of the user in the organization, etc. which will be used to be authenticated by the identity provider605. The information of the service may be ID of the service or name of the service in a service pool506, which can be used to uniquely identify the service.

Then the virtual key creator6021may send a first authentication request to an identity provider605of the organization based on the information of the organization and the identity of the user in the organization. The identity provider605may be a service provided by the organization to verify the identity of the user, e.g., authenticate the identity of the user in the organization. If the authentication is successful and there is no virtual key for the user to access the service (e.g., it is first time for the user to request the virtual key for accessing the service), the virtual key creator6021may determine the API key for the organization to access the service. In some embodiment, the virtual key creator6021may determine the API key by querying the API key for the organization to access the service to a storage which store a mapping between API keys and organizations. In some embodiments, the API key manager503may generate the API key for the organization at this time point. After obtaining the API key, the virtual key creator6021may generate a virtual key for the user to access the service based on the API key, the information of the organization and the identity of the user in the organization. Then the API key manager503may return the virtual key as a response of the first request.

In this way, each user of the organization may apply for a private virtual key to access a specific service, so that each user in the organization has a private virtual key mapping to the API key for the organization to access the specific service and each user does not know the content of the API key. In addition, only a member who has an identity in the organization can apply for a private virtual key for accessing a specific service accessible for the organization.

In some embodiments, when generating the virtual key, the virtual key creator6021may encrypt a combination of the API key, the information of the organization and the identity of the user in the organization into ciphertext, which is used as the virtual key. In some embodiments, the virtual key creator6021may use a key generated only by itself to encrypt the combination information using any symmetric encryption algorithm to obtain the virtual key. Later, the virtual key may be decrypted by the virtual key creator6021using the generated key to obtain the API key, the information of the organization and the identity of the user in the organization. In some embodiments, the virtual key creator6021may use its public key to encrypt the combination information to obtain the virtual key. And later, the virtual key may be decrypted by the virtual key creator6021using its private key to obtain the API key, the information of the organization and the identity of the user in the organization. Those skilled in the art may understand that any encryption algorithm can be used to encrypt the combination information to obtain the virtual key and a corresponding decryption algorithm can be used to decrypt the virtual key to obtain the API key, the information of the organization and the identity of the user in the organization later.

In some embodiment, after generating the virtual key, the virtual key creator6021may store a mapping between the virtual key for the user and the identity of the user in the organization, which means that the virtual key creator6021stores the virtual key for the user. If the virtual key needs to be withdrawn, the virtual key creator6021may just delete the mapping. In addition, the mapping can be used to determine whether it is the first time for the user to apply for the virtual key to avoid repeatedly generating the virtual key for the user. If the first authentication is successful and there is the virtual key for the user based on the stored mapping, the virtual key creator6021may return the virtual key as a response of the first request instead of generating the virtual key as a response of the first request.

In some embodiment, if the first authentication is unsuccessful, i.e., the user with the virtual key is not a member of the organization now, the virtual key creator6021may reject the first request to avoid the security risk caused by the unprotected API key, so as to achieve the purpose of maintaining the sustainability of services and meeting strict security regulations.

Still referring toFIG.6, the virtual key verifier6022may be configured to verify a request for accessing a service. Specifically, the virtual key verifier6022may receive a second request for the user to access the service in the cloud environment, the second request comprising the virtual key for the user to access the service. The virtual key verifier6022may then decrypt the virtual key for the user to obtain a decrypted API key, decrypted information of the organization and decrypted identity of the user in the organization, as mentioned before. The virtual key verifier6022may then send a second authentication request to the identity provider of the organization based on the decrypted information of the organization to authenticate the decrypted identity of the user in the organization. If the virtual key verifier6022determines that the second authentication is unsuccessful, i.e., the user with the virtual key is not a member of the organization now, the virtual key verifier6022may reject the second request to avoid the security risk caused by the unprotected API key, so as to achieve the purpose of maintaining the sustainability of services and meeting strict security regulations. Alternatively, the virtual key verifier6022may determine whether there is the virtual key corresponding to the decrypted identity of the user in the organization based on the stored mapping between the virtual key for the user and the identity of the user in the organization. If there is the virtual key corresponding to the decrypted identity of the user in the organization, the virtual key verifier6022may withdraw the mapping to withdraw the virtual key.

In some embodiment, any mapping in the above description can be stored in, such as, a table in a database, an XML file, a TXT file, and the like. Those skilled in the art my understand that the virtual key creator6021may use other methods to store virtual keys, entities of users, API keys, and services and their relationship instead of the mapping.

It should be noted that the virtual key manager602in the service manager600according to embodiments, could be implemented by computer system/server102ofFIG.1. It also should be noted that the virtual key manager602in the service manager600according to embodiments could be implemented in any computer system. In some embodiments, the virtual key manager602in the service manager600can a cloud computing environment (such as cloud computing environment50fromFIG.2) or a service thereof.

FIG.7depicts a flowchart700for the virtual key manager602in the service manager600to create a virtual key according to some embodiments. The flowchart700may be implemented by the virtual key manager602in the service manager600, or other suitable computer/computing systems. For ease of understanding, the flowchart700will be described with reference toFIG.6.

At710, the virtual key manager602may receive a first request for generating a virtual key for a user in an organization to access a service in a cloud environment, wherein the first request comprises information of the organization, an identity of the user in the organization, and information of the service, and wherein an API key is required to access the service.

At720, the virtual key manager602may send a first authentication request to an identity provider of the organization based on the information of the organization and the identity of the user in the organization.

At730, the virtual key manager602may determine whether the first authentication is successful or not.

At740, if the virtual key manager602determines that the first authentication is successful, the virtual key manager602may further determine whether there is stored virtual key for the user for accessing the service.

If virtual key manager602determines that the first authentication is successful and there is no virtual key for the user to access the service, the virtual key manager602may first determine the API key for the organization to access the service at750, and then generate the virtual key for the user to access the service based on the API key, the information of the organization and the identity of the user in the organization at760, and then return the virtual key as a response of the first request at780. Then the flowchart700is ended

Alternatively, the virtual key manager602may, at770, store a first mapping between the virtual key for the user and the identity of the user in the organization, so that the virtual key manager602, at740, may further determine whether there is the stored virtual key for the user to access the service based on the first mapping. If the virtual key manager602determines that the first authentication is successful and there is a virtual key for the user to access the service, the virtual key manager602may go to780directly to return the virtual key as a response of the first request.

At790, if the first authentication is unsuccessful, the virtual key manager602may reject the first request to avoid a security risk caused by the unprotected API key, so as to achieve the purpose of maintaining the sustainability of services and meeting strict security regulations. Then the flowchart700is ended.

FIG.8depicts a flowchart800for the virtual key manager602in the service manager600to verify the virtual key according to some embodiments. The flowchart800may be implemented by the virtual key manager602in the service manager600, or other suitable computer/computing systems. For ease of understanding, the flowchart800will be described with reference toFIG.6.

At810, the virtual key manager602may receive a second request for the user to access the service in the cloud environment, the second request comprising the virtual key for the user to access the service.

At820, the virtual key manager602may decrypt the virtual key for the user to obtain a decrypted API key, decrypted information of the organization and decrypted identity of the user in the organization.

At830, the virtual key manager602may send a second authentication request to the identity provider of the organization using the decrypted information of the organization and decrypted identity of the user in the organization.

At840, the virtual key manager602may determine whether the second authentication is successful or not.

If the virtual key manager602determines that the second authentication is unsuccessful, at850, the virtual key manager602may reject the second request to avoid a security risk caused by the unprotected API key, so as to achieve the purpose of maintaining the sustainability of services and meeting strict security regulations.

Alternatively, if the second authentication is unsuccessful, at860, the virtual key manager602may further determine whether there is the virtual key corresponding to the decrypted identity of the user in the organization based on the first mapping generated on770. If the first mapping exists, i.e., the virtual key exists, the virtual key manager602may withdraw the virtual key by withdrawing the first mapping at870. Then the flowchart800is ended.

If the second authentication is successful, the virtual key manager602may verify the decrypted API key for the user based a second mapping between API keys and services at880. If the verification is successful, the virtual key manager602may access the service at890. Then the flowchart800is ended. But if the verification is unsuccessful, the virtual key manager602may go to850to reject the second request.