Integration of Google Cloud Platform with OKTA (Single Sign

On)

1
Table of Contents
Integration of Google Cloud Platform with OKTA (Single Sign On)......................................................1
Need for SSO.........................................................................................................................................3
Problems with Traditional non-SSO approach:..................................................................................3
Administration Problems...............................................................................................................3
User Problems...............................................................................................................................3
Benefits of OKTA as an SSO...............................................................................................................3
Administration Benefits with OKTA...............................................................................................3
User benefits with OKTA................................................................................................................4
SSO Terminology...................................................................................................................................5
Identity Provider (IdP)....................................................................................................................5
Service Provider (SP)......................................................................................................................5
Security Assertion Markup Language (SAML)................................................................................5
Single Sign On (SSO).......................................................................................................................5
RelayState......................................................................................................................................5
Network Masking:.........................................................................................................................5
GCP – OKTA Flow Diagram.....................................................................................................................6
SSO and Provisioning Overview.............................................................................................................7
User Provisioning via OKTA..................................................................................................................15
OKTA to GCP IAM provisioning Flow Diagram.....................................................................................16
OKTA to GCP IAM provisioning Process...............................................................................................17
Background..................................................................................................................................17
Group Mapping from OKTA to GCP.............................................................................................17
Advanced Use Cases............................................................................................................................20

2
Need for SSO

Modern enterprises rely on hundreds of applications for carrying out day to day operations. Security
policies dictate that there must be a secure way of accessing these applications to enforce
Confidentiality, Integrity and Availability. This is usually enforced by enabling authentication, to
ensure that only authenticated users can access the desired applications.

This necessitates that each of the applications poses an authentication challenge, forcing the user to
enter username and password (there can be multi-factor authentication, but that is not the topic to
be discussed here). In case of hundreds of applications in a typical enterprise, this directly implies
the user needs to have credentials for logging into each of the applications separately. More arduous
is the User Lifecycle Management - user provisioning, user review and user deletion. (Think hundred
users joining an or / leaving an organization which has hundred odd applications for which the
access needs to be created / revoked)

Single Sign On (SSO) is the answer to this. SSO sits in between the users and the applications,
provides an authentication prompt, authenticates the user and provides access to the applications.

A reliable single sign-on service like OKTA integrates with all the web and mobile applications in
addition to having a full-featured federation engine and flexible access policy.

Problems with Traditional non-SSO approach:

Administration Problems
1. Time consuming and de-centtralized user management
2. Lack of security (if an administrator forgets to remove a user account from an
appplication after the user leaves the organization, the user can misuse the system)

User Problems
1. Multiple user ids and passwords to manage
2. Lack of productivity, less than ideal experience
3. Lack of security (if user changes password of each app and makes it same)

Benefits of OKTA as an SSO

Administration Benefits with OKTA

1. OKTA synchronizes very well with Microsoft Active Directory or LDAP to bring all the
existing identities viz. users, groups etc. into OKTA
2. There is no need to create user accounts manually and map them with target
applications like G-Suite. OKTA connects with them by leveraging the APIs.
3. Post integration of OKTA with the target applications, user provisioning needs to be
done only once, either via AD or OKTA and then OKTA automatically provisions the user
to the desired list of applications
4. It is possible to enforce MultiFactor Authentication (MFA) by prompting the user to add
additional authentication credentials apart from passwords. Conditional MFA can be

3
 enabled by defining policies such as the user accessing the applications from untrusted
network.

User benefits with OKTA

1. Users do not need to remember multiple usernames and passwords for different
applications. Logging into OKTA with unique username-password combination provides
them access to all the desired applications, they are supposed to have access to. This
provides a rich user experience.
2. Secure Access based on the access policies setup by the administrator.

4
SSO Terminology

Identity Provider (IdP)

1. Identity Provider or IdP is an authority system which provides the identity of the user to
the relying parties. OKTA, in this case, is an Identity Provider.
2. Passport Authority issues passport which can be used to provide a valid identity at
Airport Security. Here Passport Authority is the IdP and Airport Security is the Service
Provider (SP).

Service Provider (SP)

1. Service provider is the relying party in SSO world. It is usually an application or service
which relies on the IdP to authenticate the user and provide its service to the user.
2. In the above example, Airport Security is the Service Provider (SP)

Security Assertion Markup Language (SAML)

1. Security Assertion Markup Language (SAML) is an open standard for exchanging
authenticaion and authorization data between parties, in particular, between Identity
provider (IdP) and Service provider (SP).

Single Sign On (SSO)

1. An authentication method where a user can login to multiple applications with just one
set of credentials is called Single Sign On (SSO).
2. This one set of credentials belong to user’s identity provider (for e.g Okta in our use case
here), and then behind the scenes this identity provider integrates with other
applications or service providers (e.g G Suite, Salesforce etc).These applications rely on
Identity provider for user authentication instead of asking users to provide user id and
password.

RelayState

1. RelayState is the first destination where the user lands after IdP authenticates the user
to the service provider.

2. For example, after Okta authenticates the user to Google, whether the user would land
at Gmail, or Google Drive or Google Sites, it really depends on what the administrator
has set up in the RelayState parameter of the SAML response.

Network Masking:

1. This is specific to Google Cloud Identity (or G Suite) where the administrator can restrict
the scope of Single Sign On (SSO) to an IP range.
2. For example, if an IP range is defined in Google’s network mask while setting up SSO,
Google will only redirect users to the IdP if they login from an IP address that belongs to
this IP range, other users will be required to login via their Google email address and
password as usual.

GCP – OKTA Flow Diagram

5
 1. Flow Diagram

SSO and Provisioning Overview

Prerequisites

6
 1. Google Cloud Identity Super Administrator email id and password
2. OKTA Super Administrator user id and password
3. At least one test user account in OKTA (either created directly in OKTA or pulled over
from Active Directory)
4. Have clarity on the list of users which should be onboarded to Google from OKTA
5. Google Cloud Platform supports only SAML 2.0 for integration with OKTA. The same will
be used for the intergration.

Actual steps:

1. Login to OKTA dashboard. It is usually companyname.okta.com. Enter your OKTA Super

Administrator credentials

2. Click on “Admin” button at the top, post successful login

3. Click on Applications and add application

7
4. Type Google Cloud Platform and select it from the suggestions found under Integration

8
5. GCP doesn’t provide provisioning capabilities (evident as all the fields under Provisioning are
greyed out). The users should already be provisioned.
6. Under Capabilities you will see that only SAML and SWA are supported. We will use SAML
(SAML 2.0) for setting up connection between our OKTA and Google Cloud Platform Console.
Click Add

7. Provide Application Label. This would be the name of the icon displayed to the user post
successful sign-in. We will keep this as Google Cloud Platform for ease of use.
8. Add your company domain. This should be the same one as configured on OKTA. Uncheck
Browser Plugin auto-submit is the password vaulting. We will uncheck it as we will be using
SAML 2.0.

9
 9. Default Relay state will be the landing page post clicking the “Google Cloud Platform”
application icon in OKTA window.
10. Select SAML 2.0 and click on View Setup Instructions for finding the values of Sign-in page
URL, Sign-out page URL and Change Password URL. View Setup Instructions should lead
you to the following URL:

https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Google-Cloud-
Platform.html

(This is a generic setup document. You should be able to get the exact fields such as “Sign-in page
URL, Sign-out Page URL, Change Password URL” if you are logged into your OKTA dashboard)

10
11. Go to Google Cloud Console and click on Security

11
12. Scroll down to “Set up single sign-on (SSO) with a third party IdP”.

13. Click on “Set up SSO with third-party identity provider” and fill in the below details, as
obtained from the OKTA setup page above.

12
14. Provide the Network Masks value to the subnets from where the SSO should work. In case
the IP address of the user is not a part of the Network Masks, the user will get normal login.

15. Click Save

16. In the OKTA dashboard, under Google Cloud Platform application, go to Assignments and
assign the users / groups to the application i.e. GCP. Only these users will be allowed to use
OKTA SSO login. Non-assignment users’ login would fail.

13
17. Upon successful login, the Test User will be able to see the Google Cloud Platform icon,
clicking on which will take him to the GCP console page, without additional login prompt.

14
User Provisioning via OKTA

Though it really depends on the use case, following are couple of ways to do user provisioning with
OKTA.

1. AD Group based provisioning: Administrator creates a group in their Active Directory called
google_users and then use this as provisioning basis (e.g whoever is member of this group,
provision them to Google).

2. AD OrgUnit based provisioning: Though rarely used, some organizations go with OrgUnit
based approach where any user of a given AD orgUnit gets provisioned to Google (via Okta).

3. Attribute based approach: Some organizations in some complex or custom use cases also go
with user attribute based provisioning (e.g if the user.department = “IT”, then provision
them to Google.

15
OKTA to GCP IAM provisioning Flow Diagram

16
OKTA to GCP IAM provisioning Process

Let us take a scenario wherein we would like to import a particular Group (having multiple users in
that group) from Microsoft AD and move it to Google Cloud Platform (or G Suite).

The aim here is to assign the IAM policies automatically to the new users added to the Group.

Background
1. OKTA Agent software is installed on a server / VM which polls the AD server to “pull” the
users and groups (along with the user attributes assigned to the users / groups) and imports
it to the OKTA Cloud portal (which is the management pane where all the configuration is
done)
2. You already have imported the users and groups from your AD server to your OKTA account.

Group Mapping from OKTA to GCP

1. Check that the Group that needs to be imported to Google Cloud is present in Windows AD.
The name of the group that we will move is : Google Users

2. After the OKTA and GCP is done, the group should reflect in OKTA. On the OKTA portal, go to
“Applications” click on “Assignments” and under “Assign to group”, search with the group

17
 name. Check the same as below. DO NOT “Assign” it yet, as we intend to leverage
granularity.

3. Instead, we will create an OKTA managed group. Go to OKTA Directory >> Groups >> Add
Group. Let us name it as “Okta-Google-Int-Group”

4. This group by default doesn’t have anything in it. We will have to create Rules, which to map
the AD group with this.

18
5. Now create a rule, which matches the Group membership from AD and moves it to OKTA
group. You can preview the users in the Google Users group (Source) to ensure that they will
be moved to Okta-Google-Int-Group (Target)

6. Save the rule and preview. The rule by default is inactive. Activate it.

7. Now go to OKTA Applications >> Select Google Cloud Platform >> Assignments >> Groups >>
Assign Group.

19
 8. Assign the group Okta-Google-Int-Group to the Application.
Select the fields such as:
Organization unit: / (root directory)
Deactivation options: Keep default
Licenses: All the licenses you have bought

9. In addition to this, we can set user attributes at our AD and then map the attributes in OKTA
such that the target attribute is something that is configured in Google Cloud Identity.
10. The Google Cloud Groups will have the IAM policies set to the groups which will determine
the access level of a particular user.

Advanced Use Cases

In the above integration example, we mentioned that the domain name of OKTA and GCP should be
the same. However, this is not always the case, wherein there might be a change in the domain
name post merger, acquisition or rebranding of the company.

In such case,

OKTA will send user@olddomain.com in SAML

Google will expect user@newdomain.com.

Thereby breaking the SSO.

OKTA can be configured intelligently by leveraging its attribute transformation feature which
provides flexibility to transform attribute before sending it to the target application.

20
1. Ensure you have clicked on “Custom” from the application username format dropdown.

2. Here you should put the expression (based on Okta’s expression language) which would
result the required email address for your Google user.
Example -: in below scenario, my users email in Okta is username@id.goldyarora.com,
however my G Suite domain is @newDomain.com, so i want Okta to send the transformed
email address in SAML (nameID)

So, I will use the following Okta expression

(String.substringBefore(user.email, “@”) +”@newDomain.com”)
where Okta does the following-:
(i) It first parses the username string which is before @
(ii) Then it appends @newDomain.com to it.

3. Now before you save your change, it is critical to ensure that your expression is correct and
giving you the expected email address.
For that, you can put any of your Okta user email in preview box (look at #3 in below
screenshot)

4. You should then check the result that preview gives you (look at #4 in screenshot below),
this result should match this user’s Google username/email.
You can then save the changes, now onwards, Okta would send the transformed email
address (e.g user@newdomain.com in our example) to Google.

21
22