External Authentication: Google OpenID

Document created by rich_patterson Employee on Jun 12, 2018Last modified by thanh_n88 on Jul 31, 2018
Version 8Show Document
  • View in full screen mode

In this example, we will use External Authentication with our API. I used a multi-node/high availability (HA) Authentication Broker installed on an AWS server and have Google API Services as the Identity Provider. 


Reference Articles


Infrastructure Setup

I chose to setup in AWS. For others, you can setup your broker wherever you want and take care of the internal/external URL and internet traffic accordingly. 


Authentication Broker

For this use case, I have a Boomi Authentication Broker installed on an AWS server. Similar to a Molecule installation, the HA Broker will consist of two or mode nodes (EC2 instances). These nodes are backed by a shared network storage. You can setup an EFS drive (Running a Molecule on Amazon Web Services) or you can setup an NFS server that simply shares an EBS volume via NFS.


Network, Security Groups, and Local Working directories should be configured similar to how you might configure a Molecule (Linux Hardening Best Practices). 


Refer to the Reference Guide for complete installation instructions. At a high level, just like a Molecule install, from one of the node, install the Broker software onto the NFS. Then, setup the systemd on each node to automatically start the Broker service on each node.


Load Balancer

Like a Molecule, the cluster must also be behind a load balancer. In this example, the AWS ELB will terminate SSL(443) and forward traffic to an internal port (9093). We will allow AWS to manage the SSL certificates, as most systems implicitly trust AWS certificates. The ELB should be configured to check for a 200 return code, from each node, on /auth/. Note: Take note of the trailing "/". This is in contrast to using the /_admin/status page on a Molecule or Atom).


Internal URL and /etc/hosts

There must be a common network alias that can be used on each node, to define that node's network address. Each node, must be able to reference this alias, to identify the network adapter on which the software will accept requests. This is similar to how we use localhost to identify the loopback address on each machine. In this example, we use the alias "networkhost." In the /etc/hosts file on each machine, this alias refers to the network address of that specific machine.


Broker Configuration

There are only a few items to configure on the Broker itself. To access the External Authentication page:

  1. Switch to the API Management UI from the platform
  2. Go to the Authentication tab and select External
  3. Select the Broker you wish to configure, and update the following settings



By default, the Broker's host name will be set to that of the node on which you ran the install. You should change this to be the name of the Broker itself.


Broker Settings

Under Cluster Nodes, you must add an entry for each node under your load balancer. You can use host names or aliases that are known to the internal network. These do not need to be publicly addressable. In my example, I add "atom01" and "atom02," which resolve locally within my network.


The Internal URL should be set using the "networkhost" alias above. Again, in my example, because the ELB terminates SSL, internally, I will use the http protocol, and I will be using the port 9093 e.g. the Internal URL is "http://networkhost:9093".


For External URL, I have configured a public DNS entry to reference my load balancer, and my AWS certificates are based on this domain e.g. the External URL is "https://example.boomi.cloud". 


To know if your Auth Broker was setup correctly, you should be able to go to: <<external_URL>>/auth e.g. "https://example.boomi.cloud/auth" in the browser and see a keycloak page like the one below:



Note: my AWS certificate is publicly trusted, so it is not necessary to specify it here. This way, I can leverage the AWS Certificate Manager to replace it, without having to update my configuration.


Identity Provider Configuration

Google OpenID is used as the identity provider. 


Configuring Google (1/2)

  1. Go to https://console.developers.google.com 
    : for any actions within the Google tools, if you are currently managing multiple Google accounts, you may need to open an "incognito" page and log into a single account at a time
  2. On left, select "Credentials"
  3. Click "Create Credentials then select "OAuth Client ID"
  4. Select "Web Application" as the application type
  5. Give the client ID any name e.g. "Google OAuth client for use with Boomi Broker"
  6. Copy the "Client ID" and "Client Secret" somewhere convenient, you will need these when you configure the Authentication Source in the next steps


Configuring Authentication Source

  1. Go to the AtomSphere API Management page
  2. Go to "Authentication", select "External"
  3. Click "New" then "Authentication Source" to create a new authentication source
  4. Add an Authentication Source Name e.g. "google_openid" and choose Identity Provider Type as "OpenID Connect v1.0"
  5. Click "Save"
  6. Change the Authentication Broker to the broker you installed above
  7. Uncheck the "OpenID Implicit Flow" option and leave "OpenID Authorization Code Flow" checked


Identity Provider Settings

  1. Go to the Identity Provider tab in the authentication source
  2. Give an alias e.g. "google_openid"
  3. Authentication URL is https://accounts.google.com/o/oauth2/v2/auth 
  4. Token URL is https://www.googleapis.com/oauth2/v4/token 
  5. Enter the Client ID and Client Secret copied from "Configuring Google (1/2)", step 5
  6. In default Scopes, add "openid"
    Note: you can add other scopes as long as it is in accordance with how google's OAuth 2.0 and OpenID works
  7. Prompt Type is "Unspecified"
  8. Copy the Redirect URL for the next steps and click "Save"



Configure Google (2/2)

  1. Return to the Google Developer Console again and edit (pencil icon) the OAuth Client
  2. Update "Authorized redirect URIs" with the copied value of the "Redirect URL" captured in "Identity Provider Settings", step 8
  3. Click "Save"


Test Identity Provider Configuration

  1. On the Authentication Source, click "Test Identity Provider Configuration" button at bottom
  2. This should pop up a new browser tab, and you must select/login with your Google account
  3. You should get confirmation that the "Authorization Token" was correctly generated, both on the new tab and back on the authentication source page


End to End Testing

We're assuming you have a working API with some REST/SOAP endpoint setup prior to the external authentication setup. If you do not, set one up to make sure it is working properly and returning some response when called. Deploy your API component(s) and related processes. 


Shared Web Server Settings

  1. On the Atom/Runtime that will be hosting the Web Service/API, navigate to "Atom Management"
  2. Go to "Shared Web Server"
  3. Set the "API Type" to "Advanced" and "Authentication Type" to "External Provider"
    Note: In cloud environments, this must be enabled by the cloud owner


API Management

This is to setup your API to use the external authentication

  1. Switch to API Management
  2. Go to the "APIs" page
  3. Select "Manage" next to the API component you are testing, you'll be taken to the "Deployments" page
  4. Under "Authentication", select "Atom Controlled"
  5. In the "Configure an Authentication Source" window that appears, change "Authentication Type" to "External authentication provider"
  6. Under "Authentication Source" select the source created in the "Configuring Authentication Source" steps
  7. Copy the following "Connection Information" somewhere convenient:

    1. Authentication URL

    2. Token URL
    3. Client ID
  8. Under "Contracts", select "No Contracts"
  9. In the dialog that appears, click "Add Contract" and give the contract a name e.g. "unlimited"
    Note: for this example, we will not restrict our test API
  10. Go to "Applications" page, and click "Create an Application"
  11. Fill in the "Name," "Owner," and "Email" fields
  12. Under the "Authorized APIs" tab, click "Authorize an API" and search for your API component
  13. Click "Choose a Contract," click to highlight the "unlimited" contract made in step 9, and click "Choose this Contract"
  14. Copy the API Key somewhere


Client Process

You can build test process with a new HTTP Client connector to call the API you deployed.



There are some specific fields you will need for the HTTP connection:

Authentication Type: OAuth 2.0

Grant Type: Authorization Code

Client ID: "Api Management" step 7c, Client ID

Client Secret: leave empty

Authorization Token URL: "Api Management" step 7a, Authentication URL

Scope: leave empty

Access Token URL: "Api Management" step 7b, Token URL

Access Token: Click "Generate" to get a token. If prompted, select the Google account you used to create the OAuth credentials above. You should see a token was created and stored


Add an additional "X-API-KEY" header and set as the value copied from "API Management", step 14.



Run the test process in "Test Mode" against any run time and you should get the expected response when it was working without external authentication. In my example, I am using the public Test Cloud, to consume a service hosted on a Private Cloud.

2 people found this helpful