Single Sign On with GCP Identity Platform/Identity Providers and Okta using SAML Standard

I want to show the steps to implement SAML Authentication using GCP identity platform service which internally uses Firebase and authenticating the user with Okta as IDP (Identity Provider).

First we will walkthrough on each platform and understand basic terminologies associated for Authentication configuration.

SAML

Security Assertion Markup Language (SAML) is an XML based protocol used for single sign-on (SSO) authentication and authorization to web-based applications.

To support SSO, SAML allows web-based applications to communicate with each other. The applications share information to determine if users are authenticated to one application, thus allowing them to access another application without having to share the local identity database.

Main Components of SAML

Identity Provider (IdP)

The server or authorization authority that the client ultimately authenticates with. It holds the client’s credentials. Example:When you log in to an application using Gmail credentials, Gmail is the IdP.

Service Provider (SP)

The web-based application that the client tries to access. Example: When you log in to GitHub using your Gmail credentials, then GitHub is the SP. SPs do not authenticate the user but delegate the task to the IdP.

SAML Authentication Types:

SP-Initiated:

1. The client tries to authenticate to a protected resource directly on SP (GitHub) without the IdP being aware of the
   attempt.
2. The SP redirects the client to IdP (Gmail) for authentication. There are two situations in this case:

• If the client has already authenticated, the IdP grants access immediately.
• If the client has not been authenticated, they need to enter their IdP credentials for authentication to access the SP.

The client can now access the protected resource on SP.

IdP-Initiated:

1. The client tries to authenticate to SP (GitHub) and selects the option to be authenticated via IdP (Gmail).
2. The client is redirected to the IdP where they enter the IdP credentials.
3. Since the authentication is IdP-initiated, the browser is redirected to a generic landing page of the SP.

Note: For our example, we are only considering SP-initiated SSO.

Let’s get started:

Configuring OKTA

First of all, Setup Okta account. Learn more.
After signing in, Under Applications tab, Create New app integration and Select SAML 2.0 as sign in method and give suitable name to application.

1. Single sign on URL : The location where the SAML assertion is sent with a HTTP POST. This is often referred to as the SAML Assertion Consumer Service (ACS) URL for your application. ex: https://your.domain.name/Controller/Action
2. Audience URI (SP Entity ID) : The application-defined unique identifier that is the intended audience of the SAML assertion. This is most often the SP Entity ID of your application. ex: https://your.domain.name
3. Default RelayState :Identifies a specific application resource in an IDP initiated Single Sign-On scenario. In most instances this is blank. ex: keep this as a blank .
4. Using Attributes Statement you can pass user email and first name and last name fields to service provider.
5. After completing setup “On SignOn Tab” click on “View Setup Instructions” where you can get “Identity Provider Issuer:” detail like : http://www.okta.com/XXXXXXXXXXX where “xxxxxx” is unique. (you app identification)

Okta: Create Application configuration

1. After the application is created on Okta, Under Directory tab, click on People, add Person details and activate it.
2. The user will be received Activation email to set the password.
3. Assign the application to the user to make the user access the application using the credentials.

Okta: Add users

GCP Identity Platform

In this tutorial we use “demo-saml” as project ID.

Entire SAML configuration is done with Cloud Identity Platform via Google Cloud Platform Console.

We open GCP Console at https://console.cloud.google.com/ and then select our firebase project.

Then we open Identity Platform, via the left side menu of the console, and choose Providers.

We add a new SAML provider :

For the Google Identity Provider fields:

1. EntityID: The SAML IdP entity identifier
2. providerId: The unique provider identifier. For a SAML provider, this must be prefixed by saml.
3. Service Provider EntityId: The SAML relying party (service provider) entity ID. This is commonly the URL of the app. On the SAML identity provider, this is referred to as the audience. So this would be Audience URI or SP Entity ID from Okta.
4. SSO URL: The SAML IdP SSO URL (Identity Provider Single Sign-On URL). This has to be a valid URL.

Note: Dont forget to add Application domain in Authroized Domains List, else 403 Forbidden URL error will be received.

Javascript Code Snippet

1) A Javascript code snippet needs to be added which contain API_KEY as well AUTH_DOMAIN and will redirect the application to Firebase Auth handler.
2) Whenever the request is received, it will check whether the user is already authenticated. If YES, the user will be directly signed in to the application, else will be redirected to Okta auth page.
Learn More on Firebase code.

And voila!!!!
Application is ready to be authenticated by Okta!!

Summary:

1. When we hit our application URL(Home page), it will redirect to firebase Auth Handler, which will check if request received is from Authroized domains.
2. Further, it will send SAML request to Okta, where the user needs to authenticate itself by providing valid credentials.
3. After the user is authenticated, Okta will send response to auth Handler which in turn will send response to our application in form of IdToken, Refresh token etc.., which is JWT Token and needs to be validated by application backend code and relevant attributes will be fetched for use.
   Learn more on Validation of IdToken.

References:
1) https://www.parallels.com/blogs/ras/saml-basics/ — SAML Basics
2) https://stackoverflow.com/questions/59926042/integration-of-saml-2-0-okta-with-google-identity-provider — Terminologies