Basic Concepts of Identity Aware Proxy

Programmatic authentication

Lets look at the differents ways of programatic authentication:

Authenticating a user account

To enable a program to communicate with an IAP-secured resource, you can give user access to your application from a desktop or mobile app.

Authenticating from a mobile app

• For your mobile app, create an OAuth 2.0 client ID in the same project as the IAP-secured resource:
  • Access the Credentials page.
     
  • Access the Credentials page.
     
  • Pick the undertaking that uses an IAP-secured resource.
     
  • Select OAuth Client ID after clicking Create credentials.
     
  • The application type for which you wish to create credentials should be chosen.
     
  • When necessary, enter a Name and restrictions, then click "Create.”
     
• Make a note of the Client ID for the IAP-secured resource you want to connect to in the OAuth client window that displays.
   
• Obtain an ID token for the client ID that is IAP-secured:
  • Android: In order to obtain an OpenID Connect (OIDC) token, use the Google Sign-In API. The client ID for the resource you are connecting to should be entered as the requestIdToken client ID.
     
  • iOS: Use Google Sign-In on iOS to obtain an ID token. The client ID for the resource you are connecting to should be set as serverClientID.
     
• An authorization should include the ID token: To make the authenticated request to the IAP-secured resource, use a bearer header.

Authenticating from a desktop app

You must first create OAuth client ID credentials of type Desktop app in order to permit developers to access the application from the command line.

• Access the Credentials page.
   
• Pick the undertaking that uses an IAP-secured resource.
   
• Select OAuth Client ID after clicking Create credentials.
   
• Select Desktop app under Application type, enter a Name, and then click Create.
   
• Take note of the client ID and the client secret on the resulting OAuth client window. To handle credentials, you'll need to employ a script or otherwise communicate information with your developers.
   
• Your new Desktop app credentials and the main client ID required to access your program are displayed in the Credentials pane.

Authenticating from a service account

To authenticate a service account to an IAP-secured resource, use an OpenID Connect (OIDC) token. The procedures below will help you locate your customer ID.

• Navigate to the IAP page.
   
• Once you have located the resource, you want to use, select More > Edit OAuth Client.
   
• Note the client ID on the next Credentials page.
   

The service account must also be added to the IAP-secured project's access list. The code examples that follow demonstrate how to get an OIDC token. Whichever option you use, the token must be contained in an Authorization: To make the authenticated request to the IAP-secured resource, use a bearer header.

Authenticating from Proxy-Authorization Header

You can provide the ID token in a Proxy-Authorization: Bearer header in place of the Authorization request header if your application uses it. IAP uses a valid ID token to authorise a request if one is found in a Proxy-Authorization header. IAP does not process the request's content after authorising it; instead, it passes the Authorization header to your application.\
IAP continues to evaluate the Authorization header and strips the Proxy-Authorization header if there is no valid ID token in the Proxy-Authorization header before sending the request to your application.

Let's dive into the overview of Identity-Aware Proxy.

Identity-Aware Proxy overview

IAP enables you to create a central authorization layer for applications accessed via HTTPS, allowing you to forego network-level firewalls in favour of an application-level access control architecture.
IAP guidelines apply to the entire organisation. Applying centrally defined access policies across all of your resources and applications is possible. You can safeguard your project from improper policy formulation or execution in any application when you designate a specialised team to develop and enforce policies.

When to use IAP

When you need to impose access control rules on applications and resources, use IAP. IAP secures your app using signed headers or the App Engine standard environment Users API. You can set up group-based application access with IAP so that a resource is only available to certain departments or to employees while being inaccessible to contractors.

Authentication

Requests are routed through App Engine and Cloud Load Balancing (External and Internal HTTP(S) Load Balancing) to reach your Google Cloud services. If IAP is enabled for the backend service or the app, the serving infrastructure code for these goods checks this. Information about the protected resource is provided to the IAP authentication server if IAP is enabled. This includes details like the URL of the request, the Google Cloud project number, and any IAP credentials stored in cookies or the request headers.
The user's browser credentials are then checked by IAP. If none are found, the user is forwarded to a Google Account sign-in flow using OAuth 2.0, where a token is saved in a browser cookie for later sign-ins. You can apply the Google Cloud Directory Sync to synchronise with your Active Directory or LDAP server if you need to generate Google Accounts for your current users.
The authentication server utilises the request credentials if they are legitimate to determine the user's identity (email address and user ID). The identification is then used by the authentication server to check the user's IAM role and determine whether they had permission to access the resource.

If you use Google Kubernetes Engine or Compute Engine, users who have access to the Virtual Machine's (VM) application-serving port can avoid IAP authentication. Firewall rules for Compute Engine and GKE cannot block access from code that is running on the same VM as the IAP-secured application. Only correctly set firewall rules can prevent access from another VM. Users who have access to the auto-assigned URL can avoid IAP authentication if you're utilising Cloud Run. Only when configured appropriately can ingress controls restrict access to load balancing.

Authorization

IAP implements the pertinent IAM policy after authentication to determine whether the user is permitted access to the requested resource. The user is permitted to access the application if they hold the IAP-secured Web App User role on the Google Cloud console project where the resource is located. Utilize the IAP panel on the Google Cloud dashboard to manage the IAP-secured Web App User role list.
An OAuth 2.0 client ID and secret are generated automatically when you enable IAP for a resource. IAP won't work properly if you remove the automatically created OAuth 2.0 credentials. In the Google Cloud console APIs & services, OAuth 2.0 credentials can be viewed and managed.

Your responsibilities

All requests to App Engine, cloud load balancing (HTTPS), or internal HTTP load balancing are authenticated and authorised with IAP security. IAP does not offer protection against internal project activities, such as another VM running inside the project.

You must take the following safety procedures to ensure security:

• Set up your load balancer and firewall to block traffic that does not get through the serving infrastructure.
   
• If you're utilising Cloud Run, you may also limit access by implementing ingress controls.
   
• Use the App Engine standard environment Users API or signed headers.
   

Let's look into the details of setting up an external HTTPS load balancer.

Setting up an external HTTPS load balancer 

The following backend types allow external HTTP(S) load balancing using an identity-aware proxy (IAP):

• Instance groups
   
• Zonal network endpoint groups (NEGs)
   
• Serverless NEGs: Several Cloud Run services
   
• Internet NEGs for devices not connected to the Google Cloud (also known as custom origins)

Create a managed instance group

Your VMs must be in an instance group if you want to configure a load balancer with a Compute Engine backend. This post explains how to set up load balancing after creating a managed instance group using Linux virtual machines running Apache. Each managed instance in a managed instance group is built using the instance templates you define. The backend servers of an external HTTP load balancer are run by VMs that are part of the managed instance group. Backends serve their own hostnames as an example.

Make an instance template first, then a managed instance group.

Command:

gcloud compute instance-templates create TEMPLATE_NAME \
   --region=us-east1 \
   --network=default \
   --subnet=default \
   --tags=allow-health-check \
   --image-family=debian-10 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     sudo apt-get update
     sudo apt-get install apache2 -y
     sudo a2ensite default-ssl
     sudo a2enmod ssl
     sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
   http://169.254.169.254/computeMetadata/v1/instance/name)"
   sudo echo "Page served from: $vm_hostname" | \
   tee /var/www/html/index.html
   sudo systemctl restart apache2'

 

Based on the template, create the managed instance group.

Command:

gcloud compute instance-groups managed create lb-backend-example \
--template=TEMPLATE_NAME --size=2 --zone=us-east1-b

Adding a named port to the instance group

Define an HTTP service for your instance group and assign a port name to the appropriate port. The designated port receives traffic from the load balancing service.

Command:

gcloud compute instance-groups set-named-ports lb-backend-example \
    --named-ports http:80 \
    --zone us-east1-b

Configure a firewall rule

You will build a fw-allow-health-check firewall rule in this illustration. This ingress rule permits traffic from the systems that monitor the health of the Google Cloud (130.211.0.0/22 and 35.191.0.0/16). The target tag allow-health-check is used in this instance to identify the VMs.

Command:

gcloud compute firewall-rules create fw-allow-health-check \
    --network=default \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-health-check \
    --rules=tcp:80

Reserve an external IP address

You can set up a global static external IP address that your customers can use to access your load balancer now that your instances are up and running.

Command:

gcloud compute addresses create lb-ipv4-1 \
    --ip-version=IPV4 \
    --network-tier=PREMIUM \
    --global

Set up the load balancer

In this illustration, the client and load balancer are connected through HTTP or HTTPS. To configure the proxy for HTTPS, you require one or more SSL certificate resources. We advise utilising a certificate that is administered by Google.

You can use HTTP on the backend even if HTTPS is being used on the front end. Traffic between your backends and Google Front Ends (GFEs) that are located inside Google Cloud VPC networks is automatically encrypted by Google.

• Create a health check.

Command:

   gcloud compute health-checks create http http-basic-check \
    --port 80

 

• Create a backend service.

Command:

    gcloud compute backend-services create web-backend-service \
        --load-balancing-scheme=EXTERNAL \
        --protocol=HTTP \
        --port-name=http \
        --health-checks=http-basic-check \
        --global

Include your instance group in the backend service as the backend.

Command:

    gcloud compute backend-services add-backend web-backend-service \
        --instance-group=lb-backend-example \
        --instance-group-zone=us-east1-b \
        --global

Make a URL map for HTTP to direct incoming requests to the standard backend service.

Command:

    gcloud compute url-maps create web-map-http \
        --default-service web-backend-service

Connect your domain to your load balancer

When the load balancer is finished being constructed, write down its IP address, for instance 30.90.80.100. Use your domain registration service to set up an A record that points your domain to your load balancer. Each A record must point to the load balancer's IP address if you added more than one domain to your SSL certificate.

Test traffic sent to your instances

You can easily send traffic to the forwarding rule that the load balancing service is up and running and observe as the traffic is divided up among the many instances.

Command:

gcloud compute addresses describe lb-ipv4-1 \
   --format="get(address)" \
   --global

 

Let's continue our discussion on Advanced Concepts of Identity-Aware Proxy in our next blog.

Frequently Asked Questions

What is Load balancing?

Load balancing, commonly referred to as server farming or server pools, is the process of efficiently dispersing incoming network traffic among a collection of backend servers.

What is a GCP firewall?

According to a configuration you define, Google Cloud Platform (GCP) firewall rules enable you to allow or reject traffic to and from your virtual machine (VM) instances.

What is the default port for SSH?

The default port for SSH is 22.

Conclusion

In this article, we have extensively discussed the details of Basic Concepts of Identity Aware Proxy, along with the details of using IAP for TCP forwarding, programmatic authentication, and setting up an external HTTPS load balancer. 

We hope that this blog has helped you enhance your knowledge regarding Basic Concepts of Identity Aware Proxy, and if you would like to learn more, check out our articles on Google Cloud Certification. You can refer to our guided paths on the Coding Ninjas Studio platform to learn more about DSA, DBMS, Competitive Programming, Python, Java, JavaScript, etc. To practice and improve yourself in the interview, you can also check out Top 100 SQL problems, Interview experience, Coding interview questions, and the Ultimate guide path for interviews. Do upvote our blog to help other ninjas grow. Happy Coding!!