Accessing client credential sets using a key

Techniques are disclosed relating to a computer system accessing a client credential set to authenticate with a destination computer system. A computer system may, subsequent to receiving an indication to make available an application for a particular user, retrieve configuration data specifying a reference to a key value. The computer system may maintain a data object that includes a client credential set for the particular user. In response to an occurrence of an event associated with the application, the computer system may access the client credential set of the particular user from the data object using the key value and an indication of the particular user. The computer system may then send a request including the client credential set to a destination computer system for authentication with the destination computer system and receive a response indicating whether the computer system has been authenticated.

BACKGROUND

Technical Field

This disclosure relates generally to computer systems and, more specifically, to the accessing of client credential sets to authenticate with destination computer systems.

Description of the Related Art

Computer systems such as cloud-based platforms often run applications that interact with data stored by those systems for their users. Users who are not the provider of these computer systems may develop applications that are downloaded and installed to run on the computer systems. These applications may be designed to retrieve a user's data from databases that are accessible to the computer systems and then to perform operations on the data. In some cases, however, users may wish to handle their data in a particular manner that is not supported by the applications that are running on these computer systems.

The term “configured to” is not intended to mean “configurable to.” An unprogrammed FPGA, for example, would not be considered to be “configured to” perform some specific function, although it may be “configurable to” perform that function and may be “configured to” perform the function after programming.

As used herein, the terms “first,” “second,” etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless specifically stated. For example, in a one-time password that has multiple portions, the terms “first” portion and “second” portion can be used to refer to any portion of the one-time password. In other words, the first and second portions are not limited to the initial two portions of a one-time password.

DETAILED DESCRIPTION

Because the applications running on a particular computer system may not be able to perform particular tasks, it may be desirable to push data to (or request that tasks be performed by) another computer system that is remotely located and which may be referred to as a “destination computer system.” In order to push the data to a destination computer system, an application may first have to authenticate (on behalf of a given user) with the destination computer system by providing client credentials belonging to the user. In some cases, a computer system may authenticate with the destination computer system on behalf of the application using client credentials specified by the application. Such applications, however, may not be designed to support multiple, unique client credentials across different users or to cause a computer system to issue requests to different destination computer systems depending on the user using the application. Thus, it may be desirable to enable an application to be installed by different users of a computer system and to be able to facilitate access to multiple client credentials depending on the user.

The present disclosure describes various techniques for enabling access to one or more client credential sets usable to authenticate with a respective destination computer system. In various embodiments described below, a computer system uses a key that it receives in association with a particular application to lookup client credential sets stored for different user accounts. In particular, in various embodiments, a computer system provides a server-based platform, which is accessible to multiple users, that allows for an application developed by one user to be installed and used by other users. Accordingly, in some embodiments, a user may install a particular application (at the computer system) that is capable of causing requests to be sent to a destination computer system—in some cases, using functionality that is provided by the computer system. When a user wishes to setup the application, in various embodiments, the computer system retrieves configuration data from a different computer system. This configuration data may specify a key for accessing one or more client credential sets stored for different user accounts. In various cases, the user may independently provide a mapping from the key to their client credential set. Accordingly, in various embodiments, when an event occurs with the application, the computer system then accesses the client credential set for the user by using the key and the mapping provided by the user. Thereafter, in various embodiments, the computer system sends a request to authenticate with a destination computer system, where the request includes the client credential set. In various cases, another user may install the application and provide a mapping from the key to their own client credential set. Accordingly, when an event occurs with that application, the computer system may access that user's client credential set within that user's account using the key. Thus, the key may enable access to one or more client credential sets.

In some embodiments, the particular application might be implemented as part of a larger framework. For example, in one context, the particular application might be something that is selectable within a tool that allows the development of a workflow process. (Such a tool might allow a user to develop a computer-implemented method, one step of which might be execution of the particular application.) Accordingly, a user may install an application under their account with the computer system. The user may then add a step to a workflow process, where the step corresponds to the application. In such an environment, when the step in the workflow process is reached, in various embodiments, the computer system then executes the installed application to perform desired operations such as sending a notification to a destination system.

As one of many possible examples that illustrate aspects of such an approach, consider a communication application that sends messages to a third-party system that requires authentication. For example, different instances of an application might be installable by different users to send messages (referred to as tweets) to TWITTER. In order to send these communications, the communication application may first have to authenticate with the third-party system before it can send the messages. In prior approaches, in order to authenticate, the communication application might need to be embedded with authentication credentials during the creation of the application. In other words, in this type of implementation, in order for the communication application to be installed and used by multiple users (which is a requirement for many applications), a different instance of the application would have to be built for each user, with each instance containing credentials for the corresponding user. But using the techniques described herein allows a developer to create, for example, a single communication application that can access the appropriate credentials for each of many users who install and use the application. In some implementations, the communication application may use a key value to lookup a client credential set for the account under which the communication application is installed.

These techniques may be advantageous over prior approaches as these techniques allow for the creation of a single, multi-tenant application that facilitates authenticated requests to a destination computer system (in some cases, multiple systems) on behalf of one or more users. That is, the key (explained above) may enable an application 1) to be installed in different user accounts and 2) to access the client credential set for a respective user account when making authenticated requests to a destination computer system on behalf of the user of that account. A system for implementing these techniques will now be discussed below, starting withFIG. 1.

Turning now toFIG. 1, a block diagram of a system100is shown. System100is a set of components that are implemented via hardware or a combination of hardware and software routines. In the illustrated embodiment, system100includes computer system110, peripheral computer system120, and destination computer system130. As further shown, computer system110includes an application112and a data object114having a client credential set115. Also as shown, peripheral computer system120includes configuration data124that has a key125. In some instances, application112may be maintained by peripheral computer system120. In some embodiments, system100is implemented differently than shown—e.g., systems120and130may be part of the same component (i.e. combined).

Computer system110, in various embodiments, implements a server-based platform that allows users of that service to develop, run, and manage applications, including those associated with workflow processes such as application112. Computer system110may be, for example, a multi-tenant database system such as the multi-tenant database system discussed in detail below with respect toFIGS. 8 and 9. Accordingly, computer system110may interact with users, applications, databases, and other systems (e.g., systems120and130) in order to store, analyze, operate on, and serve data.

In various embodiments, computer system110provides a service through the server-based platform that allows a tenant (i.e., a designated group of users, such as those belonging to a company or a group within a company) of that service to create a workflow process that has various steps designed to control the flow of the process and to cause interactions to occur with users (e.g., customers) that are associated with the tenant. One possible example of such a workflow service is SALESFORCE's JOURNEY BUILDER, which allows for the users of SALESFORCE's platform to track a series of interactions with customers, potentially across different channels such as mobile devices and the Web.

The steps in a workflow process may include, for example, deciding which path to take in the workflow process, sending a text or email to a user, updating a database record of a user, etc. In various embodiments, the steps in a workflow process are implemented by underlying applications (e.g., application112). Returning to the communication application example, a user that installs the application might add a step to a corresponding workflow process (e.g., an indication of the step such as an icon) that causes one or more e-mails to be sent to the user (or some other entity). When that step is reached, computer system110may execute or cause execution of the communication application to send a notification to the user. (Note that while the interactions involving application112are described in the context of a workflow process, other contexts are considered—e.g., computer system110may simply execute application112in response to a request from a user to run the application.)

In some instances, when a step is reached in a workflow process, it may be desirable to communicate with a destination computer system130(e.g., an endpoint system such as a user's own server system or a third-party system such as TWITTER that provides a service of interest). Accordingly, in various embodiments, application112may cause application programming interface (API) calls to be made to destination computer system130. In some cases, application112may make these calls directly to the destination computer system130while, in other cases, application112may be designed to utilize the functionality of computer system110to make such API calls—e.g., application112may issue a request to another program running on computer system110to make the API calls. In either case, it can be said that computer system110makes the API calls to destination computer system130. In order to make these API calls to destination computer system130, computer system110may first have to authenticate with destination computer system130. In various embodiments, computer system110uses a client credential set115maintained in data object114to authenticate with destination computer system130. In particular, computer system110may pass in a client credential set115to an authentication service provided by destination computer system130in order to receive an authentication token, which may allow for authenticated API calls. In various embodiments, a client credential set115is provided by the user who installs application112under their account at computer system110.

Application112may be developed and installed by users (i.e., tenants) of computer system110and then used by those users (or other users) in their own workflow processes. While application112is depicted as residing at computer system110, in various embodiments, application112resides at a different system such as peripheral computer system120. In such embodiments, when application112needs to be executed, computer system110may cause execution of application112by instructing peripheral computer system120to execute it. If application112is executed at peripheral computer system120to make API calls directly to destination computer system130, then peripheral computer system120can be said to make such calls. In some embodiments, application112may be divided into at least two components: program instructions that are executed by computer system110and program instructions that are executed by peripheral computer system120. As an example, computer system110may execute program instructions to present a user interface to a user for configuring a step in a workflow process whereas peripheral computer system120may execute program instructions to carry out the functionality of that step.

When installing application112, in some embodiments, computer system110may retrieve (e.g., download) application112from peripheral computer system120. That is, application112may be a third-party application developed and provided by peripheral computer system120for downloading by other entities. For example, computer system110may download the communication application from a server system of the company that created the application. In some embodiments, application112is maintained at computer system110as part of an application store, which may be provided by computer system110. Once installed, in various embodiments, application112is made available to the user (who installed it) for inclusion into their workflow process. Thus, a user may add an indication (e.g., a step) to their workflow process that corresponds to the installed application112.

After installing application112(or, in some cases, before), in various embodiments, a user may provide a mapping between key125and a client credential set115—this mapping may be stored in or as data object114. In various cases, that user may obtain key125from the provider of application112(e.g., the developer) and may obtain a client credential set115from a provider of destination computer system130. In various embodiments, key125is also separately included in configuration data124, which may be provided to computer system110by peripheral computer system120. In particular, when a user adds a step (corresponding to an application112) to their workflow process, computer system110may retrieve configuration data124from peripheral computer system120for configuring that application112.

When that step is reached within the workflow process, in various embodiments, computer system110looks up a client credential set115in data object114using key125. In particular, client credential set115may be stored in association with a particular account at computer system110and thus system110may look up the client credential set115stored for that account using key125. Thereafter, in various embodiments, computer system110issues an authentication request132to authenticate with destination computer system130. Request132may include the retrieved client credential set115. Computer system110may then receive an authentication response134indicative of whether computer system110has been authenticated.

Peripheral computer system120, in various embodiments, provides a particular application112(and corresponding configuration data124) that can be installed by users of computer system110and then used by those users in their workflow processes. Peripheral computer system120may be, for example, a computer system maintained by a third-party provider who develops applications112for installation/registration at computer system110. In some embodiments, peripheral computer system120separately provides application112and configuration data124to computer system110. In particular, peripheral computer system120may upload a particular application112to an application store service provided by computer system110. Accordingly, users of computer system110may download and install the particular application112by accessing the application store service. Once a user has added a step that corresponds to an installed application112to their workflow process, that user may configure that application112. Accordingly, computer system110may retrieve configuration data124from peripheral computer system120.

In various embodiments, peripheral computer system120provides configuration data124via a web page. In particular, in some embodiments, peripheral computer system120hosts a web application that is associated with application112. Accordingly, when computer system110wishes to retrieve configuration data124, computer system110may send a set of Hypertext Transfer Protocol (HTTP) requests to peripheral computer system120and receive a web page that includes configuration data124in response. In some embodiments, computer system110presents the web page to the user through an iframe. The user may then provide additional information (into forms and other elements of the web page) that can be used when processing application112. In some embodiments, a user may provide the mapping between key125and a client credential set115via the presented web page.

Destination computer system130, in various embodiments, is an end-point computer system that provides desired functionality. In particular, it may be desirable to access particular data and/or functions that are not supported by a particular application112. For example, a user may wish to push data from computer system110to destination computer system130for post data processing. In some embodiments, the functionality of destination computer system130is accessible via a protected API. As such, in various embodiments, computer system110may first have to authenticate with destination computer system130before using the protected API to access some desired functionality. Accordingly, computer system110may provide a client credential set115to destination computer system130in order to authenticate with destination computer system130on behalf of the particular user corresponding to that client credential set. After being authenticated, computer system110may then make API calls for sending data to destination computer system130or accessing particular functionality that is provided by system130. In some embodiments, computer system110receives responses to the API calls. The response may, for example, indicate a success (or failure) or may include requested data.

In one example implementation of system100, a computer system110provides a server-based platform (e.g., a multi-tenant database system) accessible to a plurality of users. In this example, the server-based platform allows an application112such as the communication application to be installed by users of computer system110. The communication application may be provided by a third-party provider and used in a workflow process. Accordingly, in this example, the user who has installed this communication application may add a step into their workflow process that corresponds to the application. After the user has added the step, in this example, computer system110retrieves configuration data124from the third-party provider's system (peripheral computer system120). This configuration data124may specify a key125. Separately, the user may provide a mapping between that key125and a client credential set115usable for authenticating with a destination computer system130. The user may obtain that key125from the third-party provider. When the step in the workflow process is triggered, in this example, computer system110uses the particular key125to access the client credential set115provided by the user. Once the client credential set115has been accessed, computer system110may authenticate with the destination computer system130and then provide it with a notification.

Continuing with the example implementation, computer system110may receive a request from another user to install the communication application so that this other user can add a step to their workflow process. Accordingly, this other user may provide a mapping between key125and their client credential set115. This mapping may be specified in a data object114that is maintained under this other user's account. Thus, when the step is triggered in this other user's workflow, computer system110uses the same key125, but looks under this other user's account (instead of the original user's account) for a client credential set115. Once the client credential set115has been accessed for this other user, computer system110may authenticate with the same (or another) destination computer system130and then provide it with a notification.

Implementing system100in this manner may be advantageous as it may allow for an application to be developed that can facilitate access to the client credential sets of the different users who install the application. An example high-level view of the mapping between key125and client credential sets115will now be discussed with respect toFIG. 2.

Turning now toFIG. 2, a block diagram of an example approach for mapping a key125to different client credential sets115is shown. In the illustrated embodiment, approach200involves a computer system110having accounts210A and210B. As further shown, account210A includes a data object114A having a client credential set115A, and account210B includes a data object114B having a client credential set115B. While multiple accounts210are shown as residing at computer system110, in some embodiments, one or more accounts210may be maintained at another location.

As mentioned earlier, computer system110may be a multi-tenant database system capable of providing a server-based platform to multiple users. Accordingly, in various embodiments, computer system110maintains accounts210for its users that allows them to access functions that are provided by computer system110, including the storing of data in association with an account210. In some embodiments, computer system110may store, for a given account210, a data object114defining a mapping from key125to client credential set115(and, in some cases, additional information such as the location (e.g., a URL) of destination computer system130).

Key125, in various embodiments, is an identifier usable for looking up client credential sets115in data objects114of accounts210. In some embodiments, key125is a value that is globally unique and is defined by a developer of the associated application112. Key125may be, for example, a String value of random characters (e.g., numbers, letters, etc.). In various embodiments, key125is provided to computer system110at two different points: 1) when a user provides the mapping of key125to a client credential set115and 2) when computer system110retrieves configuration data124. In some instances, computer system110may receive key125only when it receives configuration data124. In such instances, computer system110may then request that a user provide a client credential set115to which computer system110will map key125. Key125may be usable to access multiple client credential sets115. In particular, as a data object114is stored in association with an account210, the combination of key125and account210may allow computer system110to access the particular client credential set115associated with a particular user.

Client credential set115, in various embodiments, is a set of values that enable systems such as computer system110to be authenticated with a destination computer system130(on behalf of a user of those credentials). A client credential set115may be, for example, a client identifier and a client secret (such as what is used in OAUTH), or may be a username and password. In various embodiments, a client credential set115is provided by a user of application112. For example, a user may provide a client credential set115when providing a mapping between key125and that client credential set115.

In various embodiments, valid service uniform resource locators (URLs) may be stored with client credential set115and accessed using key125. Valid service URLs may identify a set of locations where a token (received via authentication response134) may be used to access resources. For example, if a valid service URL pattern of www.twitter.com/* is specified, a token received in a token response payload may then be sent to all TWITTER endpoints (e.g., www.twitter.com/api), but not to other endpoints (e.g., www.fakeendpoint.com/api).

As intended to be shown inFIG. 2, key125may be used to access the client credential set115stored within accounts210. Accordingly, when computer system110attempts to lookup a client credential set115, computer system110may access the data object114stored in the relevant account210—that relevant account may be associated with a workflow process that includes a step corresponding to an application112. That is, in various embodiments, when a step that corresponds to an application112is reached in a workflow process, computer system110may then access the client credential set115(using key125) that is stored the particular account210that is associated with that workflow process. Thus, application112may be installed by multiple users and used in multiple workflow processes while still being able to facilitate access to the particular client credential set115relevant to each workflow process and user. An example of computer system110will now be discussed with respect toFIG. 3.

Turning now toFIG. 3, a block diagram of computer system110is shown. In the illustrated embodiment, computer system110includes accounts210and a workflow engine310. As shown, workflow engine310includes two workflow processes315and a key125. As further shown, each account210includes a corresponding data object114having a client credential set115. In some embodiments, computer system110is implemented differently than shown. For example, computer system110may not include a workflow engine310, but instead may execute applications112and use key125absent a workflow process—i.e., in a context different than a workflow process.

Workflow engine310, in various embodiments, enables the management of workflow processes315, including the creation and execution of those processes. Accordingly, a user may create a workflow process315by adding various steps that are indicative of actions to be performed during the execution of that process. While workflow engine310may provide (or support) a default set of steps (e.g., steps that are supplied by the provider of computer system110), in various embodiments, engine310allows a user to add custom steps designed by that user or another entity. To add a custom step, a user may register/install an application112as was noted earlier. In some cases, as part of the installation of a particular application112, a user may provide an indication (e.g., an endpoint URL) of where that particular application112is maintained—e.g., a URL of peripheral computer system120. Accordingly, computer system110may retrieve that particular application112and make it available to use in workflow processes315that are associated with the user who requested it. Once the particular application112is available to use in a workflow process315, the user may add a step corresponding to that application to their workflow process. In some embodiments, such steps are added to a workflow process315by dragging and dropping steps onto a canvas that is displayed within a graphical user interface provided by computer system110.

In some embodiments, a workflow process315is associated with event-driven triggers that control the movement through the various steps. For example, a user purchasing a product may initiate a workflow process315where the first step is to send an email about the purchase to the email of the user. Accordingly, the occurrence of a step corresponding to an application112may be triggered in response to an event117. As an example, in response to a month passing since the previous step was performed, workflow engine310may initiate the next step which might be a step corresponding to an application112. In response to such a step being triggered, computer system110, in various embodiments, executes or causes execution of (e.g., instructs peripheral computer system120to execute) the corresponding application112.

The execution of application112, in various embodiments, causes computer system110to retrieve a particular client credential set115using key125. As mentioned earlier, a workflow process315may be associated with an account210. As shown, for example, workflow process315A is associated with account210A and workflow process315B is associated with account210B. Thus, the execution of application112in association with workflow process315A may cause computer system110to access client credential set115A as it is stored for account210A. In addition to accessing a client credential set115, in some embodiments, computer system110further accesses information (e.g., a URL), stored for the appropriate account210, that identifies a destination computer system130. Such information may be stored in a data object114. Thereafter, in various embodiments, computer system110issues a request132to authenticate with the destination computer system130and receives a response134indicating whether computer system110is authenticated with destination computer system130. Response134may include an authentication token. Accordingly, computer system110may make further API calls (which include the received authentication token) to destination computer system130for performing certain operations. An example of destination computer system130will now be discussed with respect toFIG. 4.

Turning now toFIG. 4, a block diagram of a destination computer system130is shown. In the illustrated embodiment, destination computer system130includes an authentication service410and an API420. In some embodiments, destination computer system130is implemented differently than shown—e.g., destination computer system130may be combined with peripheral computer system120. As noted earlier, destination computer system130may authenticate computer system110and then allow for computer system110to make authenticated API calls.

Authentication service410, in various embodiments, facilitates the authentication of a computer system such as computer system110. In order to authenticate computer system110, service410may verify the client credential set115supplied in request132by comparing it against a valid client credential set115stored by destination computer system130. In various embodiments, if the client credential set115supplied in the request132is valid, then service410returns an authentication token in a response134. The token may allow for computer system110to make authenticated API calls to destination computer system130. If the client credential set115is not valid, then service410may return an indication that computer system110has not been authenticated.

Application programming interface420, in various embodiments, allows computer system110to interact with the functionality provided by destination computer system130. As an example, computer system may provide data to destination computer system130or issue commands via API420. In order to utilize API420, computer system110may have to an obtain authentication token through service410. Once computer system110has an authentication token, computer system110may make API calls422through API420. In some embodiments, destination computer system130provides an API response424to computer system110. An API response424may include, for example, requested data or an indication that a particular operation has been performed.

Turning now toFIG. 5, a flow diagram of a method500is shown. Method500is one embodiment of a method performed by a computer system such as computer system110to authenticate with a destination computer system (e.g., destination computer system130). Method500may include additional steps such as the computer system providing a user access to a data store for installing an application (e.g., application112).

Method500begins in step510with the computer system providing a server-based platform that is accessible to a plurality of users. This server-based platform may permit an application that is developed by one of the plurality of users to be utilized by others of the plurality of users.

In step520, subsequent to receiving an indication to make available an application for a particular one of the plurality of users, the computer system retrieves configuration data (e.g., configuration data124) from a different computer system (e.g., peripheral computer system120). This configuration data may specify a reference to a key value (e.g., key125). Making the application available, in some embodiments, includes installing or registering the application under an account (e.g., account210) of the particular user and allowing the particular user to add a step corresponding to the application to a workflow process (e.g., process315).

In step530, the computer system maintains a data object (e.g., data objects114) that includes a client credential set (e.g., client credential set115) for the particular user.

In step540, in response to an occurrence of an event (e.g., event117) associated with the application, the computer system accesses the client credential set of the particular user from the data object using the key value and an indication of the particular user (e.g., an account identifier). In some embodiments, the indication of the particular user corresponds to an account under which the data object is maintained. Thus, accessing the client credential set may include accessing the data object for that account. The occurrence of the event may include reaching the step in the workflow process.

In step550, the computer system sends, to a destination computer system, a request (e.g., request132) to authenticate with the destination computer system. The request may include the client credential set. In various embodiments, prior to sending the request to authenticate with the destination computer system, the computer system receives, from the particular user, information defining a mapping from the key value to the client credential set. The data object may specify the mapping. In some embodiments, prior to sending the request to authenticate with the destination computer system, the computer system receives, from the particular user, information specifying a uniform resource locator (URL) that corresponds to the destination computer system. Accordingly, the request to authenticate may be sent based on the specified URL.

In step560, the computer system receives, from the destination computer system, a response (e.g., response134) that indicates whether the computer system has been authenticated with the destination computer system.

In some embodiments, the computer system receives an indication to make available the application for a different one of the plurality of users. The computer system may maintain a second data object (e.g., data object114B) that includes a client credential set (e.g., set115B) for the different user. In response to an occurrence of an event associated with the application and the different user (e.g., the event occurs in association with an application that is installed under the different user's account210), in some embodiments, the computer system accesses the client credential set of the different user from the second data object using the key value and an indication of the different user. The computer system may then send to a different (or the same) destination computer system a request to authenticate with that destination computer system. The request may include the client credential set of the different user.

Turning now toFIG. 6, a flow diagram of a method600is shown. Method600is one embodiment of a method performed by a computer system such as computer system110for accessing client credential sets (e.g., client credential sets115) to authenticate with a destination computer system (e.g., destination computer system130). Method500may include additional steps such as the computer system providing a user access to a data store for installing an application (e.g., application112).

Method600begins in step610with the computer system providing a server-based platform accessible to a plurality of users. The server-based platform may permit an application (e.g., application112) that is developed by one of the plurality of users to be installed by others of the plurality of users.

In step620, the computer system receives, from a particular user, a request to install the application in association with an account (e.g., an account210) of the particular user at the server-based platform.

In step630, subsequent to installing the application for the particular user, the computer system retrieves configuration data (e.g., configuration data124) that specifies a reference to a key value (e.g., key125). Subsequent to installing the application for the particular user, in various embodiments, the computer system receives a request from the particular user to modify a workflow process (e.g., workflow process315) to add a step corresponding to the application. In response to receiving a request to configure the added step, the computer system may retrieve the configuration data.

In step640, the computer system maintains a data object (e.g., a data object114) in association with the account of the particular user. In various embodiments, the data object includes a client credential set (e.g., client credential set115) for the particular user.

In step650, in response to an occurrence of an event associated with the application, the computer system accesses the client credential set of the particular user from the data object. The client credential set of the particular user may be accessed using the key value and an indication of the particular user. The indication of the particular user may be an account identifier corresponding to the account under which the data object is maintained. In various embodiments, in response to the occurrence of the event associated with the application, the computer system executes the installed application to perform a set of operations that initiate steps660and670.

In step660, the computer system sends, to a destination computer system, a request (e.g., request132) to authenticate with the destination computer system. In various embodiments, the request includes the client credential set. In various embodiments, the computer system receives, from the particular user, authentication information that specifies a uniform resource locator (URL), the client credential set, and a mapping between the key value and the client credential set. The URL may correspond to an authentication service (e.g., service410) implemented at the destination computer system and the data object may correspond to the mapping.

In step670, the computer system receives, from the destination computer system, a response (e.g., response134) that indicates whether the computer system has been authenticated with the destination computer system. In various embodiments, the response from the destination computer system includes an authentication token. As such, the computer system may make authenticated application programming interface (API) calls to the destination computer system on behalf of the application. Such API calls may include the authentication token.

In various embodiments, the computer system receives, from a different user, a request to install the application in association with an account (e.g., account210B) of the different user at the server-based platform. In some embodiments, the computer system maintain a second data object (e.g., data object114B) in association with the account of the different user. This data object may include a client credential set for the different user. As such, in response to an occurrence of an event associated with the application, the computer system may access the client credential set of the different user from the second data object using the key value and an indication of the different user. In some embodiments, the computer system sends, to the destination computer system, a request to authenticate with the destination computer system. The request may include the client credential set of the different user.

Turning now toFIG. 7, a flow diagram of a method700is shown. Method700is one embodiment of a method performed by a computer system such as computer system110for accessing client credential sets (e.g., client credential sets115) to authenticate with a destination computer system (e.g., destination computer system130). In some embodiments, method700includes additional steps such as the computer system providing a user access to a data store for installing an application (e.g., application112).

Method700begins in step710with the computer system receiving, from a particular user, a request to register an application at the computer system. In various embodiments, the registration of the application may cause the application to be available for use in a workflow process (e.g., workflow process315). In various embodiments, the execution of the application causes the computer system to send one or more requests (e.g., requests132) to a destination computer system. In some embodiments, the computer system includes a multi-tenant database system storing data for a plurality of users in respective tenant-specific storage areas.

In step720, the computer system receives, from the particular user, a request to add a step to a particular workflow process. This step may correspond to the registered application, and reaching the step in the particular workflow process may result in the registered application being executed.

In step730, subsequent to adding the step to the particular workflow process, the computer system retrieves configuration data (e.g., configuration data124) from a different computer system (e.g., peripheral computer system120). In various embodiments, the configuration data specifies a key value (e.g., key125). The key value may be a globally unique identifier that is specified by a developer of the application.

In step740, the computer system receives, from the particular user, mapping information indicative of a mapping of the key value to a client credential set usable to authenticate with the destination computer system. In some embodiments, the mapping information is stored in association with an indication of the particular user—e.g., stored in or as a data object114. The client credential set may include a client identifier and a client secret. In some embodiments, the client credential set is stored in a tenant-specific storage area corresponding to the particular user.

In step750, subsequent to the step being reached and to accessing the client credential set using the key value and the indication of the particular user (e.g., under the particular user's account), the computer system sends, to the destination computer system, a request (e.g., request132) to authenticate with the destination computer system. In various embodiments, the request includes the client credential set. In some embodiments, the computer system receives, from the particular user, information indicative of an address of the destination computer system. Accordingly, the request to authenticate with the destination computer system may be sent to the address.

In step760, the computer system receives, from the destination computer system, a response (e.g., response134) indicating whether the computer system has been authenticated with the destination computer system.

In various embodiments, the computer system receives, from a different user, a request to add, to a different workflow process, a step corresponding to the application. The computer system, in some embodiments, receives from the different user mapping information that is indicative of a mapping of the key value to a different client credential set usable to authenticate with the destination computer system. The mapping information from the different user may be stored in association with an indication of the different user. Subsequent to the step being reached in the workflow process, in various embodiments, the computer system accesses the different client credential set using the key value and the indication of the different user. The computer system, in some embodiments, sends, to the destination computer system, a request to authenticate with the destination computer system, where the request includes the different client credential set. In some embodiments, the computer system receives, form the destination computer system, a response indicating whether the computer system has been authenticated with the destination computer system.

Exemplary Multi-Tenant Database System

FIG. 8illustrates an exemplary environment in which a multi-tenant database and cache system might be implemented. Note that the disclosed multi-tenant systems are included to illustrative purposes but are not intended to limit the scope of the present disclosure. In other embodiments, similar techniques may be implemented in non-multi-tenant environments such as various client/server environments, cloud computing environments, clustered computers, etc. As illustrated inFIG. 8(and in more detail inFIG. 9) one or more user systems812may interact via a network814with a multi-tenant database system (MTS)816, which may be computer system110. The users of those user systems812may be users in differing capacities and the capacity of a particular user system812might be determined by the current user. For example, when a salesperson is using a particular user system812to interact with MTS816, that user system812may have the capacities allotted to that salesperson. However, while an administrator is using the same user system812to interact with MTS816, it has the capacities allotted to that administrator. Accordingly, in various embodiments, information (e.g., data object114) maintained by a system (e.g., computer system110) implementing system816can be modified by only the users that have the appropriate capacities (e.g., permissions).

Network814may be a LAN (local area network), WAN (wide area network), wireless network, point-to-point network, star network, token ring network, hub network, or any other appropriate configuration. The global internetwork of networks often referred to as the “Internet” with a capital “I,” will be used in many of the examples herein and is one example of a TCP/IP (Transfer Control Protocol and Internet Protocol) network. It should be understood, however, that the networks that the present invention may utilize any of various other types of networks.

User systems812may communicate with MTS816using TCP/IP and, at a higher network level, use other common Internet protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. As an example, where HTTP is used, user system812might include an HTTP client commonly referred to as a “browser” for sending and receiving HTTP messages from an HTTP server at MTS816. Such a server might be implemented as the sole network interface between MTS816and network814, but other techniques might be used as well or instead. In some implementations, the interface between MTS816and network814includes load sharing functionality, such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers. Preferably, each of the plurality of servers has access to the MTS's data, at least for the users that are accessing a server.

In some embodiments, the system shown inFIG. 8implements a web-based customer relationship management (CRM) system. For example, in some embodiments, MTS816includes application servers configured to implement and execute CRM software applications as well as provide related data, code, forms, web pages and other information to and from user systems812and to store to, and retrieve from, a database system related data, objects and web page content. In embodiments of a multi-tenant system, tenant data is preferably arranged so that data of one tenant is kept separate from that of other tenants so that that one tenant does not have access to another tenant's data, unless such data is expressly shared.

One arrangement for elements of MTS816is shown inFIG. 8, including a network interface820, storage822for tenant data, storage824for system data accessible to MTS816and possibly multiple tenants, program code826for implementing various functions of MTS816, and a process space828for executing MTS system processes and tenant-specific processes, such as running applications as part of an application service.

Several elements in the system shown inFIG. 8may include conventional, well-known elements that need not be explained in detail here. For example, each user system812may be a desktop personal computer, workstation, laptop, PDA, cell phone, or any WAP-enabled device or any other computing device capable of interfacing directly or indirectly to the Internet or other network connection. User system812may execute an HTTP client, e.g., a browsing program, such as Microsoft's Internet Explorer™ browser, Netscape's Navigator™ browser, Opera's browser, or a WAP-enabled browser in the case of a cell phone, PDA or other wireless device, or the like, allowing a user (e.g., subscriber of a CRM system) of user system812to access, process, and view information and pages available to it from MTS816over network814. Each user system812may include one or more user interface devices, such as a keyboard, a mouse, touch screen, pen or the like, for interacting with a graphical user interface (GUI) provided by the browser on a display monitor screen, LCD display, etc. in conjunction with pages, forms and other information provided by MTS816or other systems or servers. As discussed above, the present invention is suitable for use with the Internet, which refers to a specific global internetwork of networks. It should be understood, however, that other networks may be used instead of the Internet, such as an intranet, an extranet, a virtual private network (VPN), a non-TCP/IP based network, any LAN or WAN or the like.

In some embodiments, each user system812and its components are operator configurable using applications, such as a browser, that include computer code executable on one or more processing elements. Similarly, in some embodiments, MTS816(and additional instances of MTSs, where more than one is present) and their components are operator configurable using application(s) that include computer code executable on one or more processing elements. Thus, various operations described herein may be performed by executing program instructions stored on a non-transitory computer-readable medium and executed by one or more processing elements. The program instructions may be stored on a non-volatile medium such as a hard disk, or may be stored in any other volatile or non-volatile memory medium or device as is well known, such as a ROM or RAM, or provided on any media capable of staring program code, such as a compact disk (CD) medium, digital versatile disk (DVD) medium, a floppy disk, and the like. Additionally, the entire program code, or portions thereof, may be transmitted and downloaded from a software source, e.g., over the Internet, or from another server, as is well known, or transmitted over any other conventional network connection as is well known (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as are well known. It will also be appreciated that computer code for implementing aspects of the present invention can be implemented in any programming language that can be executed on a server or server system such as, for example, in C, C+, HTML, Java, JavaScript, or any other scripting language, such as VBScript.

FIG. 9illustrates exemplary embodiments of an MTS816and various interconnections in more detail. In this example, the network interface is implemented as one or more HTTP application servers900. Also shown is system process space902including individual tenant process spaces904, a system database960, tenant database(s)908and a tenant management process space910. Tenant database908may be shared across application servers900and may be divided into individual tenant storage areas912, which can be either a physical arrangement or a logical arrangement. Within each tenant storage area912, user storage914might be allocated for each user. While not shown, one or more applications112provided by tenants of MTS816may be running on application servers900.

In the illustrated embodiment, each application server900also includes at least a portion of a cache918. In some embodiments, user systems812that utilize web applications can request that data be stored in cache918(e.g., using a “put” operation) and later retrieve the data (e.g., using a “get” operation) rather than re-generating the data. In some embodiments, capacity limits may be assigned to different users/tenants/partitions, etc. and cached data may be evicted in order to remain below the allotted capacity. In some embodiments, cached data for a particular tenant is kept private from other tenants. Further, the visibility scope for cached data within a particular tenant may be configurable.

In some embodiments, cache918is split across multiple application servers900. In some embodiments, splitting across multiple instances may allow the data in cache918to fit in system memory space, which may improve response times relative to storing data for cache918in disk storage, for example. As used herein, an “in-memory cache” is a cache that stores data in system memory space (which typically means that the data can be stored in RAM) rather than requiring paging for storage (as is typically required for traditional disc storage, for example). Cache918may also be a “multi-tenant” cache in the sense that a single cache is used to provide separate virtual caches for multiple different tenant entities. The different tenants may use the same data structure to store data or different tenants may have different data structures in the cache. In various embodiments, multi-tenant caches enforce data security between tenants such that data from one tenant is not available to other tenants. Thus, as used herein, the term “tenant” in the context of a multi-tenant cache refers to an entity for which cache entries are separately maintained such that different tenants cannot access each other's data. In some embodiments, tenants may authorize other tenants to access their data via the cache, while in other embodiments a given tenant's data may be accessible to only that tenant via the multi-tenant cache (although that tenant may subsequently share data retrieved from the cache, as that tenant desires).

It should also be understood that each application server900may be communicably coupled to database systems, e.g., system database960and tenant database(s)908, via, a different network connection. For example, one server9001might be coupled via network814, another server900N−1might be coupled via a direct network link, and another server900Nmight be coupled by yet a different network connection. Transfer Control Protocol and Internet Protocol (TCP/IP) are preferred protocols for communicating between servers900and the database system, however, it will be apparent to one skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.

In preferred aspects, each application server900is configured to handle requests for any user/organization. Because it is desirable to be able to add and remove application servers from the server pool at any time for any reason, there is preferably no server affinity for a user and/or organization to a specific application server900. In one embodiment, therefore, an interface system (not shown) implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the servers900and the user systems812to distribute requests to the servers900. In one aspect, the load balancer uses a least connections algorithm to route user requests to the servers900. Other examples of load balancing algorithms, such as are round robin and observed response time, also can be used. For example, in certain aspects, three consecutive requests from the same user could hit three different servers, and three requests from different users could hit the same server. In this manner, MTS816is multi-tenant, wherein the MTS816handles storage of different objects and data across disparate users and organizations.

As an example of storage, one tenant might be a company that employs a sales force where each salesperson uses MTS816to manage their sales process. Thus, a user might maintain contact data, leads data customer follow-up data, performance data, goals and progress data, all applicable to that user's personal sales process (e.g., in tenant database908). In some MTS embodiments, since all of this data and the applications to access, view, modify, report, transmit, calculate, eta, can be maintained and accessed by a user system having nothing more than network access, the user can manage his or her sales efforts and cycles from any of many different user systems. For example, if a salesperson is paying a visit to a customer and the customer has Internet access in their lobby, the salesperson can obtain critical updates as to that customer while waiting for the customer to arrive in the lobby.

While each user's sales data may be separate from other users' sales data regardless of the employers of each user, some data may be organization-wide data shared or accessible by a plurality or all of the sales three for a given organization that is a tenant. Thus, there may be some data structures managed by MTS816that are allocated at the tenant level while other data structures are managed at the user level. Because an MTS may support multiple tenants including possible competitors, the MTS should have security protocols that keep data, applications and application use separate. Also, because many tenants will opt for access to an MTS rather than maintain their own system, security, redundancy, up-time and backup are more critical functions and need to be implemented in the MTS.

In addition to user-specific data and tenant-specific data, MTS816might also maintain system level data usable by multiple tenants. Such system level data might include industry reports, news, postings, and the like that are sharable among tenants.

In certain aspects, client systems812communicate with application servers900to request and update system-level and tenant-level data from MTS816that may require one or more queries to database960and/or database908. Accordingly, servers900may run applications112supplied by a provider of MTS816to perform one or more particular operations. In some embodiments, MTS816automatically generates one or more SQL statements (the SQL query) designed to access the desired information.

Each database may generally be viewed as a set of logical tables containing data fitted into predefined categories. Each table typically contains one or more data categories logically arranged in physical columns. Each row of a table typically contains an instance of data for each category defined by the columns. For example, a CRM database may include a table that describes a customer with columns for basic contact information such as name, address, phone number, fax number, etc. Another table may describe a purchase order, including columns for information such as customer, product, sale price, date, etc.

Turning now toFIG. 10, a block diagram of an exemplary computer system1000, which may implement computer system110, peripheral computer system120, and/or destination computer system130, is depicted. Computer system1000includes a processor subsystem1080that is coupled to a system memory1020and I/O interfaces(s)1040via an interconnect1060(e.g., a system bus). I/O interface(s)1040is coupled to one or more I/O devices1050. Computer system1000may be any of various types of devices, including, but not limited to, a server system, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, tablet computer, handheld computer, workstation, network computer, a consumer device such as a mobile phone, music player, or personal data assistant (PDA). Although a single computer system1000is shown inFIG. 10for convenience, system1000may also be implemented as two or more computer systems operating together.

Processor subsystem1080may include one or more processors or processing units. In various embodiments of computer system1000, multiple instances of processor subsystem1080may be coupled to interconnect1060. In various embodiments, processor subsystem1080(or each processor unit within1080) may contain a cache or other form of on-board memory.

System memory1020is usable store program instructions executable by processor subsystem1080to cause system1000perform various operations described herein. System memory1020may be implemented using different physical memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system1000is not limited to primary storage such as memory1020. Rather, computer system1000may also include other forms of storage such as cache memory in processor subsystem1080and secondary storage on I/O Devices1050(e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem1080. Applications112described above may be included within system memory1020.

I/O interfaces1040may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface1040is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces1040may be coupled to one or more I/O devices1050via one or more corresponding buses or other interfaces. Examples of I/O devices1050include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system1000is coupled to a network via a network interface device1050(e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.).