GCP – Control access to your web sites with Identity-Aware Proxy

Does your company need to make an internal website accessible to employees, temporary workers, and contractors? How about running a public site open to all, but with some functions requiring personalization? Or perhaps providing a highly restricted site that only authorized users, running on secure platforms, can access?

Those are all common use cases, and there are many different ways to address each of them. But there is one easy-to-use and deploy solution that can handle them all: Google Cloud Identity-Aware Proxy (IAP).

IAP is a service that intercepts requests to a web site, authenticates the user making the request, and allows only authorized users’ requests to reach the site. IAP can be used to protect web sites running on many platforms, including App Engine, Compute Engine, and other services behind a Google Cloud Load Balancer. But it isn’t restricted to Google Cloud: you can use it with IAP Connector to protect your own on-premises applications, too.

Protecting a website with IAP can be configured using the Google Cloud Console. Identity-Aware Proxy is managed under the Security submenu. From there, an organization can enable IAP and then turn it on for selected sites. Access is permitted by granting the IAP-secured Web App User role to one or more individual email addresses, entire email domains, or a group email address. Those users can use the sites just like any other internet site after an authentication step.

The core steps are similar regardless of the case:

• Create an employee-only, or “intranet”, server by specifying that only users who authenticate with company email addresses should be allowed access. IAP can authenticate Gmail or Google Workspace addresses, addresses in a company’s Active Directory or other LDAP directory via Google Cloud Directory Sync, or addresses supported by other common identity providers. 
• For public, but authenticated, access, specify that IAP should allow “allAuthenticatedUsers”. Anyone willing and able to authenticate will be given access to the site. IAP’s second major function is to add headers to each request with user identity information, so the receiving site can use that information without having to perform its own authentication.
• Access can be limited to any group, or combination of groups, by specifying a group email address instead of individual ones. And IAP can go even further than basing access on identity only. Organizations can set device policies members of a group must follow in order to be given access. Those policies can require specific operating system versions, use of company profiles on browsers or mobile devices, or even use of company owned equipment only.

Over my career, I have set up web sites, managed user registration and authentication, tracked sessions, configured firewalls, and used VPNs for internal sites. I was thrilled to discover Identity-Aware Proxy. I didn’t need to do any of those things any more! It seemed almost magical. If you have similar use cases, you should take a close look at IAP for yourself.