This article provides additional information on using external identities with Identity-Aware Proxy (IAP) instead of Google accounts.
Overview
IAP controls access to your App Engine apps and Compute Engine VMs running on Google Cloud. It leverages user identity and the context of a request to determine if a user should be allowed access. IAP is a building block toward BeyondCorp, an enterprise security model that enables employees to work from untrusted networks without using a VPN.
By default, IAP uses Google identities and IAM. By leveraging Identity Platform instead, you can authenticate users with a wide range of external identity providers, such as:
- Email/password
- OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.)
- SAML
- OIDC
- Phone number
- Custom
- Anonymous
This is useful if your application is already using an external authentication system, and migrating your users to Google accounts is impractical.
Multi-tenancy
Identity Platform multi-tenancy was originally designed for B2B scenarios, where one company is selling a service to other companies. In these cases, it's common for developers to want to segregate user populations into isolated pools. These silos are referred to as tenants.
Consider the fictional relationship diagram below:
In this example, Acme is a car manufacturer (the agent) who uses Identity Platform to provide a service to dealerships (the tenants). These dealerships in turn provide services to their customers, employees, and contractors. Although the manufacturer owns the service, each dealership could use their own set of identity providers for authentication. User sessions and data are scoped on a per-tenant basis, so if a user has relationships with multiple dealerships, each is handled independently.
Depending on your use case, there are a number of ways you can structure your tenant hierarchy.
No tenants
You only need multi-tenancy if you need to isolate resources. Not all applications have this requirement. For example, if you have a single App Engine app and want to block access to all users outside your network, there is no need for multi-tenancy. By default, Identity Platform stores and authenticates users on a per-project basis, so no additional configuration is required in this case.
Another example is a conglomerate with several subsidiaries. Even if each subsidiary has its own managed authentication system (using OIDC or SAML), all employees might share the same high-level benefits, such as healthcare, vacations, and payroll. In this case, authenticating at the project level is sufficient.
One tenant per resource
By default, non-tenant Identity Platform tokens are valid at the project level. Theoretically, this means a user could authenticate with one IAP resource, then use the token to access another service in the same project. This is a security risk.
To prevent token leakage, isolate each IAP by assigning each its own tenant. Tokens minted in a tenant-specific context are only valid for that specific tenant. If the user attempts to access another IAP resource that uses a different tenant, they'll be asked to authenticate again.
Multiple tenants per resource
A single IAP resource can have multiple tenants associated with it.
When a user accesses the resource, you have several options for determining what tenant to use. For example, you might prompt the user to enter their email first, and then programmatically locate a tenant that matches the email's domain. Alternatively, you might display a UI that lists all valid tenants, and ask the user to choose one.
Users can belong to multiple tenants with varying levels of access. Although you can't use IAM to manage access control with external identities, the JSON Web Token generated by IAP carries the claims from the Identity Platform ID token, and the application can filter access based on these claims.
An example multi-tenancy scenario is an employee benefits company that has many customers sharing a single web portal. When a user visits the portal, they first select their company (the tenant), and then authenticate with whatever provider their employer uses with their corporate credentials.