inWebo provides innovative, no-hardware, 100% SaaS, strong authentication solutions for employee and consumer secure transactions.
The purpose of this guide is to explain how to use inWebo as an Identity Provider for your "G suite (Google Apps)" account.
inWebo strong authentication service supports many built-in interfaces such as Radius, SAML 2.0, Web Services API, G Suite and many more.
Users can download and manage inWebo tokens by themselves. In order to get the whole system up and running, your company G Suite domain administrator only has to:
Create an inWebo account (2 min)
Download, install and activate one of inWebo tokens (2 min)
Configure G suite (Google Apps) connector in the inWebo account (2 min)
Configure inWebo on your G Suite account and enable Federated authentication (3 min)
Perform a test authentication (5 min)
Basically, the whole system can be up and running in 15 minutes.
In order to use inWebo with G Suite (https://gsuite.google.com/), you need to have a valid G suite (Google Apps) domain and have administrator rights for it. If you don’t have one already, you can get one here. In particular.
You also need to have administrator access to an inWebo Enterprise account. You can create your own inWebo account at inWebo Signup page.
On the “Secure site” tab/page, you have to add in the connectors section. The G suite (Google Apps) connector
Create a connector of type Google Apps
Within the “Google Apps connector” popup
Define your domain name
Copy the redirection URL
Download the verification certificate
Save by clicking on “Add” button
The newly created connector is now visible in the connectors list (if not, resume the previous step). You should now define one or several “Secure Sites” for this connector, i.e. url shortcuts for your users to Mail, Calendar, Drive and any other services you have enabled in your G suite Domain. The preconfigured G suite comes with Mail, Calendar and Drive already configured.
Note: you can only add a Secure Site of type Google Apps if the Google Apps connector has already been created.
The inWebo account set-up is now complete. Keep the inWebo administration console open as you will need to come back to it eventually for testing.
Configure your G suite (Google Apps) domain
Connect to your G suite (Google Apps) domain control panel. You can access the control panel by typing “www.google.com/a/<your_domain.com>”
Log into the admin console of your G Suite apps account.
Choose "Security" within the menu.
In the security section :
Select "Set up single sign-on (SSO)"
Tick the "Setup SSO with third party identity provider" box.
Copy information in the inWebo connector settings for your service
In G Suite, fill the following paths with inWebo details and upload the certificate file
Your G suite domain configuration (i.e. “federation” with inWebo) is now complete.
Create a user and test inWebo authentication
Go back to your inWebo administration console, this time in tab/page “Service users” and select “Add a new user”
For a given G suite (Google Apps) user “email@example.com”, you should define the login to be “test.user”, without the “@mydomain.com”. This is an important point that will make authentication fail if it is not correctly addressed.
For test purposes, tick the “Send an activation email” box. You might change the activation code distribution process for real users afterwards.
The test user should click on the activation code link in the received email
The target page will give the test user a choice between various inWebo soft-tokens. For the sake of simplicity here, let’s assume the test user chooses to activate inWebo in his/her browser.
This is simply done by defining one’s own second factor (“inWebo password”).
The user is then redirected to his my inWebo page, where he can connect to Google Mail. Note: of course, mail.google.com/a/mydomain.com and www.gmail.com can still be used to access Google Mail, the Identity Provider being now inWebo.
Removing static password access to G suite (Google Apps)
Even after having federated G suite with Identity Provider inWebo, a user can still access his account with his static password from the page www.google.com/a/mydomain.com, and therefore ‘bypass’ the 2-factor authentication.
In order to prevent this, the G suite domain administrator should force (google) 2-step authentication for the desired users / groups. It will apply to the www.google.com/a/mydomain.com access. It will also force google-defined complex passwords for POP3-client access (client-based access does not support 2-factor authentication).