Jump to a Section

Overview

The first time that you add a Google Cloud Functions card to a flow, you will be prompted to create a connection. Connecting your account will enable you to save your account information and reuse that connection the next time you build a flow with the connector. Note that you can create multiple connections and share them with your team.

  1. On the Settings page, click +New Connection. Or, if you’ve already started a new flow, you’ll be prompted to enter a new connection when you select your Google Cloud Functions action.
  2. Enter an Connection Nickname. As a best practice, make this nickname unique so that you can connect multiple Google Cloud Functions accounts.
  3. Enter your Project ID, then click Create. You can obtain the project ID from the project URL.
  4. Choose an account, then click Allow.

Set up the Google Cloud Functions Project

Your Google Cloud Functions Project provides access to the Google Cloud Functions API. By using the connector’s Custom API Action card, authorized users can call the API for their project. For example, users can call the API to list the cloud functions that are deployed in a particular region. To use the Okta Workflows Custom API Action action card to list all the functions in the project, your Google Cloud Functions Project must be set up properly.

Complete the following steps:

  • Create a Google Cloud Functions project
  • Enable the Google Cloud Functions API (search and enable it in Library). Otherwise, users will not be able to call the API.
  • The default region for new cloud functions is us-central1.
  • Note that cloud functions with the same name can be deployed to multiple regions.
  • Use the IAM & Admin menu to add users to the project, and assign roles to those users.
    • To invoke a cloud function, a user must be assigned the Cloud Functions Invoker role.
    • Consider assigning other roles to cloud functions: Cloud Functions Admin, Cloud Functions Developer, or Cloud Functions Viewer:
    • Cloud Functions Developer can edit and invoke functions
    • Cloud Functions Admin can add usrs and change permissions on functions
    • Cloud Functions Viewer can only view functions

Addtionally, be aware of the following:

  • When you authenticate using the Invoke Function card you must provide the Google Cloud Project ID. Users are authenticated using IAM roles that are assigned within your Google Cloud Functions Project.
  • When the connector calls a Google Cloud Function it will utilize an ID Token (JWT) for your user.
  • The Invoke Function card requires that the user has Google Functions Invoker role. Calls to unsecure cloud functions is not supported by the Invoke Function card, however users can call unsecure functions using the Custom API Action card.
  • You can only create a secure function at the time of creation by making sure that the Allow unauthenticated invocations checkbox is left unchecked. You cannot secure a function after you’ve created it. Even if users are assigned to an unsecured function with proper roles, they will not be able to call it.
  • After deployment of a cloud function, security can be configured independently by adding users to the Cloud Functions Invoker role.

    Actions

    • Custom API Action

      Make an authenticated HTTP request to the Google Cloud Functions API for your project

    • Invoke Function

      Invoke a Google Cloud function using an HTTP request. Refer to the Google Cloud Functions API documentation.

      Options

      • Region (drop-down): assigned region for your project; the following regions are available:
        • asia-east2
        • asia-northeast1
        • europe-west1
        • europe-west2
        • europe-west3
        • us-central1
        • us-east1
        • us-east4

      The names of the cloud functions in each region are unique, but you can have the same named function in two different regions. us-central1 is the default.

      • Function Name (drop-down): the name of the function
      • Request Type (drop-down): one of five supported HTTP request methods (sometimes called verbs) in custom API calls:
        • GET retrieves data from a web server based on your parameters. GET requests a representation of the specified resource. If successful, GET will receive a 200 OK response message with the requested content. Refer to additional documentation here.
        • POST sends data to a web server based on your parameters. POST requests include actions like uploading a file. Multiple POSTs may result in a different outcome than a single POST, so you should be cautious about unintentionally sending multiple POSTs. If a POST is successful, you will receive a 200 OK response message. Refer to additional documentation here.
        • PUT sends data to a location in the web server based on your parameters. PUT requests include actions like uploading a file. The difference between a PUT and POST is that PUT is idempotent, meaning that the result of a single successful PUT is the same as many identical PUT’s. If a PUT is successful, you will receive a 200 response message (usually 201 or 204). Refer to additional documentation here.
        • PATCH applies partial modifications to a resource on a web server based on your parameters. PATCH is not idempotent, meaning that multiple PATCHs could have unintended consequences. If a PUT is successful, you will receive a 200 response message (usually 204). Refer to additional documentation here.
        • DELETE deletes the specified resource from the web server based on your parameters (if the resource exists). If a DELETE is successful, you will receive a 200 OK response message. Refer to additional documentation here.

      Input

      • Query (object or text): JSON object that determines the action taken at the URL

        Example: {"name":"something-urgent"}
      • Headers (object): JSON object that determines the content type of the request. This will usually be a replica of the example below.

        Example: {"Content-type":"application/json"}
      • Body (object): JSON object that is passed in the content of the request. This will usually be a replica of the example below.

        Example: {"id":10}

      Output

      • Status Code (number): Success or failure of your HTTP request. Here is a list of all status codes.
      • Headers (object): A detailed context for the status code, unrelated to the output body. Response headers are dependent on your selected HTTP request option. Note that not all headers are response headers.
      • Body (object): data returned from your selected HTTP request (for example, the data from a GET request)
    • Custom API Action

      Make a custom, authenticated HTTP call to the Google API.

      Options

      • Request Type (dropdown): use the appropriate request type depending on the endpoint/method
        • GET
        • POST
        • PUT
        • PATCH
        • DELETE

      Input

      • Relative URL (text): Specify the relative URL as /api/{insert_remaining_URL}. You can specify query parameters in the relative URL using “?”, or specify the query parameters as an object key pair in the Query input.
      • Query (object): Specify any additional query parameters that should be included in object format (key value pairs).
      • Headers (object): Specify any headers required in addition to authorization or content-type (these are already handled by this connector).
      • Body (object): Specify a request body in JSON format. Only available for POST, PUT, and PATCH requests.

      Output

      Response

      • Status Code (number): success or failure of your HTTP request. Here is a list of all status codes.
      • Headers (object): a detailed context for the status code, unrelated to the output body. Response headers are dependent on your selected HTTP request option. Note that not all headers are response headers. This will usually be a replica of the example below.

        Example: {"Content-type":"application/json"}
      • Body (object): data returned from your selected HTTP request (for example, the data from a GET request).