阅读说明：本技术 安全绑定工作流 (Secure binding workflows ) 是由 A·D·利 C·杰克逊 E·J·马尔姆 S·C·莱文 Z·D·罗宾逊 于 2019-09-10 设计创作，主要内容包括：在计算机存储介质上编码的用于将服务凭证绑定到应用程序的方法、系统和计算机程序。一个示例系统接收对云应用平台中应用程序的服务绑定请求。该服务绑定请求包括绑定由云应用平台中的服务主机提供的服务的请求。该服务绑定请求指定(i)该服务的标识符和(ii)该应用程序的唯一标识符。该系统从服务主机接收用于应用程序访问该服务的凭证。该系统将凭证提供给安装在云应用平台上的安全凭证中心。该安全凭证中心将凭证与凭证位置标识符关联地存储。该系统向应用程序的唯一标识符授予对凭证位置标识符的读取访问权限。该系统将凭证位置标识符存储为该应用程序的应用程序元数据。(Methods, systems, and computer programs encoded on a computer storage medium for binding service credentials to an application. One example system receives a service binding request for an application in a cloud application platform. The service binding request includes a request to bind a service provided by a service host in the cloud application platform. The service binding request specifies (i) an identifier of the service and (ii) a unique identifier of the application. The system receives credentials from a service host for an application to access the service. The system provides credentials to a security credential center installed on a cloud application platform. The secure credential center stores credentials in association with a credential location identifier. The system grants read access to the credential location identifier to the unique identifier of the application. The system stores the credential location identifier as application metadata for the application.)

1. A system comprising one or more computers and one or more storage devices storing instructions that, when executed by the one or more computers, cause the one or more computers to perform operations comprising:

receiving a service binding request for an application in a cloud application platform system, wherein the service binding request comprises a request to bind a service provided by a service host in the cloud application platform system, wherein the service binding request specifies (i) an identifier of the service and (ii) a unique identifier of the application;

receiving credentials from the service host for the application to access the service;

providing the credentials to a security credential center installed on the cloud application platform system, wherein the security credential center stores the credentials in association with a credential location identifier;

granting read access to the credential location identifier to the unique identifier of the application; and

storing the credential location identifier as application metadata for the application.

2. The system of claim 1, wherein the operations further comprise:

receiving a request to populate the credential within an environment of the application;

generating, by a computing resource host hosting the application within the cloud application platform system, a certificate encoding the unique identifier of the application;

providing, by the computing resource host, the certificate to the security credential center, the certificate encoding the unique identifier and the credential location identifier of the application; and receiving, by the computing resource host, the credentials for the application to access the service from the security credential center.

3. The system of claim 2, wherein the operations further comprise:

populating the credentials within a process environment of a running instance of the application on the computing resource host,

wherein the application is configured to access the service by obtaining the credentials from the process environment.

4. The system of claim 2, wherein the security credential center verifies that the application has read access to the location identified by the credential location identifier.

5. The system of claim 2, wherein generating the certificate comprises: a public key and private key pair is generated.

6. The system of claim 2, wherein generating the certificate comprises: the certificate is signed using an intermediate certificate.

7. The system of claim 6, wherein the computing resource host is preconfigured with the intermediate certificate.

8. The system of claim 3, wherein populating the credentials in a process environment of a running instance of the application on the computing resource host occurs at application startup.

9. The system of claim 1, wherein storing the credential location identifier as application metadata for the application comprises: storing the credential location identifier in a centralized database on the cloud application platform, and wherein the operations further comprise:

retrieving, by a computing resource host hosting the application within the cloud application platform, the credential location identifier from the centralized database.

10. The system of claim 1, wherein providing the credentials to a secure credential center comprises:

authentication is performed using a pre-configured client.

11. The system of claim 1, wherein the unique identifier is for an application that has not yet been launched.

12. The system of claim 1, wherein the credential location identifier is a path.

13. The system of claim 1, wherein multiple applications have read access to the same credential location identifier.

14. A method, comprising:

receiving a service binding request for an application in a cloud application platform system, wherein the service binding request comprises a request to bind a service provided by a service host in the cloud application platform system, wherein the service binding request specifies (i) an identifier of the service and (ii) a unique identifier of the application;

receiving credentials from the service host for the application to access the service;

providing the credentials to a security credential center installed on the cloud application platform system, wherein the security credential center stores the credentials in association with a credential location identifier;

granting read access to the credential location identifier to the unique identifier of the application; and

storing the credential location identifier as application metadata for the application.

15. The method of claim 14, further comprising:

receiving a request to populate the credential within an environment of the application;

generating, by a computing resource host hosting the application within the cloud application platform system, a certificate encoding the unique identifier of the application;

providing, by the computing resource host, the certificate to the security credential center, the certificate encoding the unique identifier and the credential location identifier of the application; and receiving, by the computing resource host, the credentials for the application to access the service from the security credential center.

16. The method of claim 15, further comprising:

populating the credentials within a process environment of a running instance of the application on the computing resource host,

wherein the application is configured to access the service by obtaining the credentials from the process environment.

17. The method of claim 15, wherein the security credential center verifies that the application has read access to the location identified by the credential location identifier.

18. The method of claim 15, wherein generating the certificate comprises: a public key and private key pair is generated.

19. The method of claim 15, wherein generating the certificate comprises: the certificate is signed using an intermediate certificate.

20. The method of claim 19, wherein the computing resource host is preconfigured with the intermediate certificate.

21. The method of claim 16, wherein populating the credentials in a process environment of a running instance of the application on the computing resource host occurs at application startup.

22. The method of claim 14, wherein storing the credential location identifier as application metadata for the application comprises: storing the credential location identifier in a centralized database on the cloud application platform, and wherein the operations further comprise:

retrieving, by a computing resource host hosting the application within the cloud application platform, the credential location identifier from the centralized database.

23. The method of claim 14, wherein providing the credentials to a secure credential center comprises:

authentication is performed using a pre-configured client.

24. The method of claim 14, wherein the unique identifier is for an application that has not yet been launched.

25. The method of claim 14, wherein the credential location identifier is a path.

26. The method of claim 14, wherein multiple applications have read access to the same credential location identifier.

27. One or more non-transitory computer storage media storing instructions operable, which when executed by one or more computers, cause the one or more computers to perform operations comprising:

receiving a service binding request for an application in a cloud application platform system, wherein the service binding request comprises a request to bind a service provided by a service host in the cloud application platform system, wherein the service binding request specifies (i) an identifier of the service and (ii) a unique identifier of the application;

receiving credentials from the service host for the application to access the service;

providing the credentials to a security credential center installed on the cloud application platform system, wherein the security credential center stores the credentials in association with a credential location identifier;

granting read access to the credential location identifier to the unique identifier of the application; and

storing the credential location identifier as application metadata for the application.

Background

This specification relates to computing platforms.

A computing platform is a service that provides a virtual space for an organization, in which processes provided by its users can be developed, deployed, run, and managed. One example of a computing platform is a cloud application platform, which facilitates the development of mobile and Web applications. Typically, cloud application platforms include Application Programming Interfaces (APIs) that provide developers access to the platform. Through the API, developers can upload their application code to the platform, can connect to services that support their applications, and can compile and run their applications. The API may also define spaces and user roles for an organization. A space is a shared location where applications are developed, deployed, or maintained. User roles define developer access to these spaces.

The cloud application platform tracks application code, application versions, and application instances. They can also provide access to services, which simplifies this development and management of applications, enabling developers to focus on the logic in their application code. A service is an external resource that is necessary for an application to perform its intended function. Services provide resources such as middleware, databases, message queues, email, etc.

Typically, an application on the cloud application platform accesses a respective service using service credentials (e.g., a username and password for a user account) generated by the respective service. The service credential may be stored as metadata of the application in a centralized database on the cloud application platform. Storing the service credentials as metadata has some security drawbacks. For example, the service credential may need to be transmitted opaquely through certain components of the system, potentially exposing the service to a wider range of vulnerabilities and attacks than necessary. Further, the service credential may be visible to a computing resource hosting the application instance.

Disclosure of Invention

This specification describes techniques for securely storing service credentials for a service on a cloud application platform. Under the direction of the platform controller, for a specific application program on the cloud application platform, a service agent of a specific service sends a provisioning request and a service binding request to the service. The provisioning request causes the service to reserve resources for the application. For example, if the service is a database service, the provisioning request may cause the service to create a new database instance reserved for the application. At the same time, the service binding request causes the service to provide credentials that allow the application to access the service. The credentials are typically a username and password that "belongs" to the user account of the application.

The service broker receives credentials from the service, but does not store the credentials in a centralized database on the cloud application platform. Instead, the service agent provides the credentials to a security credential center installed on the cloud application platform. The secure credential center stores the credential in a location identified by the credential location identifier. The secure credential center provides the credential location identifier to the service agent. The credential repository also grants read access to the application for which the binding request was sent based on the application's unique identifier.

Thereafter, the service agent provides the credential location identifier (rather than the actual credential) to the centralized database of the cloud application platform. The credential location identifier is stored in a centralized database as metadata for the application.

When the cloud application platform starts an instance of an application, the computing resource hosting the instance generates a certificate that encodes a unique identifier of the application. To access the service, the computing resource provides the certificate and the credential location identifier to the secure credential center. The security credential center verifies that the unique identifier is associated with an application that can access the location defined by the credential location identifier and provides the credentials stored at the location to the computing resource. The computing resource then populates a process environment of the launched instance of the application with the credentials. An application may access a service by obtaining credentials from a process environment.

The subject matter described in this specification can be implemented in particular embodiments to realize one or more of the following advantages. Access to the service credentials is restricted by storing the credential location identifier as application metadata instead of the service credentials, i.e., by storing references to the service credentials instead of the service credentials themselves. Only an application with a unique identifier that is granted read access to a location in the secure credential center where the credential is stored can retrieve the credential. Other components of the cloud application platform (and developers and entities using the cloud application platform) cannot access the location. Thus, the service credentials are only disclosed to the service that created them, the entity responsible for storing them, and the consuming entity, e.g. the container hosting the application that uses the respective service. This limits the ability of developers and other entities to view, use, or distribute these credentials, either intentionally or unintentionally.

Using a service broker may also ensure that credentials are not exposed to components of the cloud application platform that do not require such credentials. The service broker facilitates secure communication between the platform controller, the security credential center, and the computing resources hosting the application instance. The service broker facilitates secure communications by using a Transport Layer Security (TLS) protocol that provides connection security with mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameter negotiation.

Storing the service credentials in separate components also allows the cloud application platform to decouple the process of changing the service credentials from changing the application state, which enables the service credentials to rotate without rescheduling the application workload across computing resources.

Finally, from the application's perspective, there is nothing to do with. When an application instance is launched, credentials that the application expects to see in the process environment will be provided.

The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

Drawings

FIG. 1 is a schematic diagram of an example cloud application platform.

FIG. 2 is a flow diagram of an example process for binding a service to an application in a cloud application platform.

FIG. 3 is a flow diagram of an example process for populating a process environment of an application instance with service credentials.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

Fig. 1 is a schematic diagram of an example cloud application platform 100. The cloud application platform 100 is a computing service that provides an organization with a virtual space in which to develop, deploy, run, and manage their mobile and web applications.

The cloud application platform 100 includes a platform controller 110. The platform controller 110 may track application code, application versions, and application instances. The platform controller 110 also includes an API 112, and the API 112 may provide developers with access to the cloud application platform 100. In some implementations, the API 112 is a graphical user interface. In other implementations, the API 112 is a command line interface. Through the API 112, developers can upload their application code to the cloud application platform 100 and compile and run their applications. The API 112 may also allow developers to define spaces and user roles for an organization. A space is a shared location where applications are developed, deployed, or maintained. User roles define the developer's access to these spaces.

The API 112 may also provide access to services that simplify the development and management of applications, allowing developers to focus on the logic of their application code. Services provide resources such as middleware, databases, message queues, email, etc.

The cloud application platform 100 has a container management system 120, and the container management system 120 can control the containers in which the application instances are hosted. That is, the container management system 120 can create containers in which application instances run and adjust the allocation of resources between these containers.

The container management system 120 may host one or more virtual machines, and each virtual machine may host one or more application instance containers 122a-122 n. In this specification, a container refers to an isolated user space instance implemented by operating system level virtualization. The containers share the computing resources, such as memory or processing power, of their respective computing systems. The computing system may dynamically adjust the allocation of resources between containers as needed.

Containers differ from virtual machines in several ways. First, a container hosted on a particular physical computer may share operating system resources with other containers hosted on the same physical computer. Thus, it is possible to run multiple containers using only a single operating system. On the other hand, different virtual machines do not share operating system resources. In other words, to run two different virtual machines on the same physical computer, it is often necessary to run two complete operating systems.

Second, computing systems may allocate different levels of computing resources to different containers running on the same physical computer. Further, the allocation may be dynamically altered. In contrast, a virtual machine cannot easily change the allocation of resources to programs on the virtual machine.

Each instance of the application may run in its own container in one of the virtual machines. The container may use operating system features and characteristics of the virtual and physical infrastructure in which the cloud application platform 100 is deployed to isolate processes, memory, and file systems.

The cloud application platform 100 also includes a centralized database 130. Centralized database 130 may store any suitable application data, such as application code, application name, number of instances specified by the developer, build packages of the application (if applicable), and information related to the services supporting the application.

Developers may use the cloud application platform 100 to deploy and run their applications. First, a developer may provide a directory containing application source code through the API 112 of the platform controller 110 and may issue a push command using the API 112. The push command initiates a series of steps that ultimately cause the application to run on the cloud application platform 100, where the application may begin performing tasks, e.g., servicing requests from external users.

In response to receiving the push command, the platform controller 110 may create a record of the application in the centralized database 130. That is, the platform controller 110 writes application metadata to the centralized database 130, including, for example, the application name, the number of instances specified by the developer, and the build package for the application, among other information. The platform controller 110 may also write application files in the specified directory to the centralized database 130 and may create an application package from these application files. The platform controller 110 may then issue a staging request to the container management system 120, and the container management system 120 schedules the container to run the application's staging task. The staging task may download a build package for the application and may compile and stage the application using the build package.

The virtual machine for staging the application may be scheduled and the output of the staging process may be streamed to the API 112 so that the developer may troubleshoot the application staging problem. The staging task may package the compiled and staged application into an execution unit that is selected to run in its own container. The staging task may also write data to the cache for the next time the application is staged.

As above, applications on the cloud application platform 100 may utilize services. The service facilitates the development, deployment, and management of applications. For example, services simplify the development and management of applications by allowing developers to focus on the logic in their application code, rather than the backend infrastructure. Although only a single service 140 is depicted in fig. 1, the cloud application platform 100 may provide access to any number of services. Examples of services include middleware, databases, message queues, and email, to name a few.

The cloud application platform 100 includes one or more service agents 150 to facilitate secure communication between the platform controller 110, one or more services, and one or more containers hosting application instances. In some embodiments, the cloud application platform 100 has a single service agent. For example, the cloud application platform 100 of fig. 1 includes only a single service agent 150 connected to multiple services. In other implementations, the cloud application platform 100 has multiple service agents. For example, the cloud application platform 100 may have a separate service agent for each service. For convenience, the cloud application platform 100 will be described as having a single service agent.

In some implementations, the service agent 150 is a separate underlying component of the cloud application platform 100. In other implementations, the service agent 150 is an application running on the cloud application platform 100.

The service agent 150 may implement an API for which the platform controller 110 is a client. Service agent 150 may publish a service directory, which is a service offering and service plan for one or more services. The service agent 150 may also facilitate transmission requests from the platform controller 110 to the service. The provisioning request reserves resources on the service for a particular application instance. The reserved resources are also referred to as service instances. The binding request requires that the service provide credentials that allow the application instance, or the container in which the application instance is running, to access the reserved resources, such as a username and password for the user account. And de-provisioning request (de-provisioning) will delete the resource. The content of a service instance may vary from service to service, it may be a single database on a multi-tenant server, a dedicated cluster, or even an account on a Web application.

The service agent 150 may establish secure connections with the services and with other components of the cloud application platform 100 using any suitable protocol. For example, service broker 150 may use a Transport Layer Security (TLS) protocol that provides connectivity for mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameter negotiation. Using the TLS protocol may ensure that third parties cannot access credentials because credentials are exchanged between the service and the service broker 150, or between the service broker 150 and other components of the cloud application platform 100.

The framework of the cloud application platform 100 may be used to reduce exposure of components to service credentials. To this end, the centralized database 130 on the cloud application platform 100 may store references to the service credentials, rather than storing the service credentials themselves. The actual service credentials may be stored in different locations using more stringent access control and built-in security protocols. To this end, the cloud application platform 100 further includes a security credential center 160, and the security credential center 160 may store the service credentials. In addition to storing service credentials, the security credential center 160 may also store credential metadata and handle credential generation and version control.

After the service 140 creates the service instance and creates the service credential for the application, the platform controller 110 may receive a request from a developer or from an application deployment pipeline to apply the service credential to the application. Typically, such a request is associated with a request to launch an application. In this case, the platform controller 110 may instruct the container management system 120 to launch the application in the new container, as described above.

The container may then begin applying the service credentials to the application. To this end, the container may generate a certificate that encodes a unique identifier of the application. The container may provide both the certificate and the reference to the service credential to the secure credential center 160. The security credential center 160 uses (i) the unique identifier encoded in the certificate and (ii) the reference to the service credential to verify (verify) whether the application can access the service credential. Once the security credential center 160 does determine that the application can access the service credential, it retrieves the service credential from the location identified by the reference. The secure credential center 160 may optionally use additional information provided in the certificate to encrypt the credential.

The container receives credentials for the application to access the service from the security credential center 160. Thereafter, the container can be populated with credentials in the process environment of the running instance of the application. By obtaining credentials from the process environment, an application may use the credentials to access a service.

The process of binding the service credential to the application described above may be performed at one of several stages of the application lifecycle. In some implementations, the build package (buildpack) of the application includes code that specifies how the application is to be configured to communicate with the service. In such implementations, the binding process is performed during initial compilation and staging of the application, and when the application is launched, the container in which the application is running is populated with service credentials in the process environment of the application. In other implementations, the platform controller 110 injects separate code into the container in which the application is running. The separate code may cause the container to be filled with a particular service credential only when needed, i.e., when the staged application needs to access the service. In other implementations, the container may bind certain credentials at application startup and only bind certain credentials when they are needed by the application.

FIG. 2 is a flow diagram of an example process for binding a service to an application in a cloud application platform. The process may be performed by, and under the direction of, one or more components of the cloud application platform. For example, the process may be performed by the service agent 150 under the direction of the platform controller 110. For convenience, the process will be described as being performed by a system of one or more computers in one or more locations.

The system receives a service binding request for an application in the cloud application platform (210). Typically, a developer initiates a service binding request using an API of the cloud application platform. The API may provide a list of services and a list of plans for each service. Each offering different levels of resources at different costs. The developer may initiate a service binding request by selecting a particular service and a particular plan. For example, a developer may select a 2GB plan on the storage service.

A service binding request is a request to retrieve credentials (e.g., username and password for a user account) from a particular service host. The credentials allow the application to access resources provided by the service host. Continuing with the example above, the credential would allow the application to access 2GB of storage on the server. The service binding request specifies an identifier of the desired service and a unique identifier of an application that will use the service. In some cases, the unique identifier identifies an application that has not yet been launched.

In some cases, the provisioning request precedes the service binding request. The provisioning request reserves service resources for the application.

In response to the service binding request, the system receives credentials from the service host for the application to access the service (220).

The system provides credentials to a security credential center installed on the cloud application platform (230). In some implementations, the security credential center is an application. In other implementations, the security credential center is a native component of the cloud application platform.

The secure credential center stores credentials in association with a credential location identifier, the credential location identifier representing a location in the secure credential center where the service credentials are stored. In some implementations, the credential location identifier is a path, e.g., a name of a file or directory in the security credential center that stores the service credential.

The system also provides a security credential center with a unique identifier of an application that will use the credential to access the service. The security credential center grants read access to the application having the unique identifier to a location in the security credential center identified by the credential location identifier (240). Thus, only the application can access the credential, while other applications cannot.

Finally, the system stores the credential location identifier as application metadata in a centralized database of the cloud application platform (250). Developers and other applications cannot access the service because the system does not store the credentials themselves in a centralized database.

FIG. 3 is a flow diagram of an example process for populating service credentials within an application's environment so that the application can access the service. The process may be performed by, or at the direction of, one or more components of the cloud application platform. For example, the process may be performed by the service agent 150 under the direction of the platform controller 110, or under the direction of a computing resource hosting an application that needs to use credentials.

The system receives a request to populate credentials within environment variables of an application (310). Typically, upon launching an application, the system receives the request from the container management system. In some cases, the container management system sends the request only when the application needs to access the service.

In response to the request, a computing resource of the application, such as a virtual machine or container hosting the application, is hosted within the cloud application platform, generating a certificate encoding a unique identifier of the application (320). In some implementations, the certificate includes a public key and a private key pair for encrypting messages between the computing resource and the secure credential center. Messages are typically encrypted according to the TLS protocol. In some implementations, the certificate is signed with an intermediate certificate that is unique to the computing resource, rather than a set of computing resources, as compared to the case of the master certificate. In some cases, the computing resources hosting the application may be pre-configured with this intermediate certificate. If each computing resource hosting an application instance has its own intermediate certificate and private key pair, the security credential center may be more selective in verifying the certificates. For example, the security credential center may check whether the application instance corresponding to the unique identifier is actually located on the computing resource. This may prevent an intermediate certificate that leaks another computing resource and is used to issue any instance-specific certificates. Similarly, a computing resource may selectively revoke its intermediary credentials if it is known that the computing resource has been compromised. The validity of the intermediate certificate is higher when its validity period is shorter.

The computing resource hosting the application provides (i) a certificate encoding a unique identifier of the application and (ii) a credential location identifier to the security credential center (330). The computing resource may retrieve the credential location identifier from a centralized database on the cloud application platform that initially stores the credential location identifier. The credential location identifier defines a location in the security credential center where the service credential is stored. The credential location identifier may be a path, e.g., the name of a file or directory in the security credential center. Using the unique identifier of the requesting application, the security credential center verifies that the application has read access to the path of the stored credential. If the requesting application does have read access, the secure credential center retrieves the credential from the path.

The computing resource receives credentials for an application to access a service from a security credential center (340).

Thereafter, the computing resource may populate a credential in a process environment of a running instance of the application on the computing resource host (350). In some cases, the computing resource will populate the credential when the application is launched. In other cases, the application may not need to use the credentials immediately, so the computing resources do not populate the credentials in the process environment until later. The application can then use these credentials to access the service by obtaining them from the process environment. If the credential is encrypted, the application may decrypt it using a private key previously generated by the computing host.

The description uses the term "configured to" in connection with systems, apparatuses, and computer program components. A system consisting of one or more computers configured to perform a particular operation or action means that the system has installed thereon software, firmware, hardware or a combination thereof that in operation causes the system to perform the operation or action. By one or more computer programs configured to perform certain operations or actions, it is meant that the one or more programs include instructions, which when executed by data processing apparatus, cause the apparatus to perform the operations or actions. To the extent that a specific logic circuit is configured to perform a particular operation or action, that means the circuit has electronic logic to perform the operation or action.

Embodiments of the subject matter described in this specification, and the acts and operations, can be implemented in digital electronic circuitry, tangibly embodied in computer software or firmware, in computer hardware (including the structures disclosed in this specification and their equivalents), or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be, or be part of, a machine-readable storage device, a machine-readable storage substrate, a random or serial access storage device, or a combination of one or more of them. Computer storage media is not a propagated signal.

The term "data processing apparatus" encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The data processing apparatus may comprise special purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application-specific integrated circuit), or a GPU (graphics processing unit). The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

A computer program, which may also be referred to or described as a program, software application, app, module, software module, engine, script, or code, can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and a computer program can be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment that may include one or more computers interconnected by a data communication network at one or more locations.

The computer program may, but need not, correspond to a file in a file system. A computer program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).

The processes and logic flows described in this specification can be performed by one or more computers executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can also be performed by, and in particular by, special purpose logic circuitry, e.g., an FPGA, an ASIC, or a GPU, or by a combination of special purpose logic circuitry and one or more programmed computers.

A computer suitable for executing a computer program may be based on a general purpose or special purpose microprocessor, or both, or on any other type of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

Typically, a computer will also include or be operatively coupled to receive data from or transfer data to one or more mass storage devices. For example, the mass storage device may be a magnetic, magneto-optical, or optical disk, or a solid state drive. However, a computer need not have such devices. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a Universal Serial Bus (USB) flash drive), to name a few.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on or configured to communicate with a computer having a display device (e.g., an LCD (liquid crystal display) monitor) for displaying information to the user and an input device through which the user can provide input to the computer, such as a keyboard and a pointing device (e.g., a mouse, trackball, or touch pad). Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input. Further, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a web page to a web browser on the user device in response to a request received from the web browser, or interacting with an application running on the user device (e.g., a smartphone or electronic tablet). Moreover, the computer may interact with the user by sending text messages or other forms of messages to a personal device (e.g., a smartphone running a messaging application) and, in turn, receiving response messages from the user.

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface), a Web browser, or an app, through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a Local Area Network (LAN) and a Wide Area Network (WAN), such as the Internet.

The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, the server sends data (e.g., HTML pages) to the user device, e.g., to display data to a user interacting with the device, and to receive user input from the user interacting with the device, the device acts as a client. Data generated at a customer premises device (e.g., the result of a user interaction) may be received at a server from the device.

In addition to the above embodiments, the following embodiments are also innovative:

embodiment 1 is a method comprising:

receiving a service binding request for an application in a cloud application platform system, wherein the service binding request comprises a request to bind a service provided by a service host in the cloud application platform system, wherein the service binding request specifies (i) an identifier of the service and (ii) a unique identifier of the application;

receiving credentials from the service host for the application to access the service;

providing the credentials to a security credential center installed on the cloud application platform system, wherein the security credential center stores the credentials in association with a credential location identifier;

granting read access to the credential location identifier to the unique identifier of the application; and

storing the credential location identifier as application metadata for the application.

Embodiment 2 is the method of embodiment 1, further comprising:

receiving a request to populate the credential within an environment of the application;

generating, by a computing resource host, a certificate encoding the unique identifier of the application, the computing resource host hosting the application within the cloud application platform system;

providing, by the computing resource host, the certificate to the security credential center, the certificate encoding the unique identifier and the credential location identifier of the application; and receiving, by the computing resource host, the credentials for the application to access the service from the security credential center.

Embodiment 3 is the method of embodiment 2, further comprising:

populating the credentials within a process environment of a running instance of the application on the computing resource host,

wherein the application is configured to access the service by obtaining the credentials from the process environment.

Embodiment 4 is the method of any of embodiments 2-3, wherein the security credential center verifies that the application has read access to the location identified by the credential location identifier.

Embodiment 5 is the method of any of embodiments 2-4, wherein generating the certificate comprises: a public key and private key pair is generated.

Embodiment 6 is the method of any of embodiments 2-5, wherein generating the certificate comprises: the certificate is signed using the intermediate certificate.

Embodiment 7 is the method of embodiment 6, wherein the computing resource host is preconfigured with the intermediate certificate.

Embodiment 8 is the method of embodiment 3, wherein populating the credentials in a process environment of a running instance of the application on the computing resource host occurs at application startup.

Embodiment 9 is the method of any of embodiments 1-8, wherein storing the credential location identifier as application metadata for the application comprises: storing the credential location identifier in a centralized database on the cloud application platform, further comprising:

retrieving, by a computing resource host hosting the application within the cloud application platform, the credential location identifier from the centralized database.

Embodiment 10 is the method of any of embodiments 1-9, wherein providing the credential to the security credential center comprises:

authentication is performed using a pre-configured client.

Embodiment 11 is the method of any of embodiments 1-10, wherein the unique identifier is for an application that has not yet been launched.

Embodiment 12 is the method of any of embodiments 1-11, wherein the credential location identifier is a path.

Embodiment 13 is the method of any of embodiments 1-12, wherein multiple applications have read access to the same credential location identifier.

Embodiment 14 is a system comprising one or more computers and one or more storage devices storing instructions that, when executed by the one or more computers, cause the one or more computers to perform the method of any of embodiments 1-13.

Embodiment 15 is one or more computer storage media storing instructions that are operable, when executed by one or more computers, to cause the one or more computers to perform the method of any of embodiments 1-13.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed or claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claims may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings and described in the claims in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.