End-user authentication in Cloud Service Mesh
1. End-user authentication in Cloud Service Mesh
In addition to service authentication, you can also authenticate individual user requests. This allows you to verify the identity of end users accessing your applications. Requests are authenticated with JSON Web Tokens, JWTs. End users can authenticate using a variety of methods, including custom authentication providers or popular OpenID Connect providers, like Auth0 ORY Hydra, Firebase Authentication, or Keycloak. The provider returns the token, which can be used to place requests to services in the mesh. Before authentication, the token is validated by the gateway's sidecar proxy. The provider returns the token, which can be used to place requests to services in the mesh. Before authentication, the token is validated by the gateway's sidecar proxy. JWTs use request authentication policies to specify values that must be verified, including [AUDIO OUT] the location of the token in the request, the issuer of the request, and the public JSON Web Key Set, JWKS, used to verify the token's signature. If the authentication information provided in the request is invalid, it's rejected. Requests without identity are accepted, but won't be authenticated. JWTs from different providers are acceptable, but requests can only have one valid token. If more than one token is provided, the output principal of the request is undefined. Cloud service mesh's authservice component reduces management overhead by handling user authentication with JWTs. Acting as an external authorization service within the Envoy-based ingress, it intercepts incoming requests. Mesh's authservice implements the client side of the OIDC protocol, allowing users to authenticate via a browser using an interactive flow to establish a short-lived session. It uses industry-standard protocols to integrate with any OIDC authorization server. When a request goes to the cloud load balancer, HTTPS, or internal HTTP load balancer, the load balancer checks that IAP is enabled for the app or backend service. If enabled, information about the protected resource, like the Google Cloud project number, the request URL, and any IAP credentials in the headers or cookies is sent to the IAP authentication server. Next, IAP checks the user's browser credentials. If it doesn't find any credentials, the user is redirected to an OAuth 2.0 Google account sign-in flow. A token is stored in a browser cookie for future sign-ins. For existing users, you can use Google Cloud Directory Sync to synchronize with your Active Directory or LDAP server. If credentials are valid, the authentication server uses those credentials to retrieve a user's identity, email address, and user ID. After authentication, IAP applies the relevant IAM policy to verify that the user is authorized to access the requested resource. Users are authorized to use the application if they have the IAP-secured Web App User role applied on the project that contains the resource. To manage the IAP-secured Web App User role list, use the IAP panel on the Google Cloud console. Employee authentication is specifically tailored for employees within an organization. In Google Cloud, you can leverage Identity Aware Proxy, IAP, as the authentication and authorization provider for employees. IAP allows access to internal applications without relying on network-level firewalls or a VPN. IAP provides a centralized way to manage access to your HTTPS applications, and you can use group-based permissions to easily control which departments or teams have access to different applications. When IAP is enabled for a resource, an OAuth 2.0 client ID and secret are automatically created. If you delete the automatically generated OAuth 2.0 credentials, IAP won't function correctly. You can view and manage OAuth 2.0 credentials in the Google Cloud console APIs and Services. Once IAP is set up and your application's OAuth 2.0 credentials are configured, you need to ensure your application is accessible via HTTPS. This is where ingress resources come in. They help direct traffic to your application within the mesh. You can create an ingress resource to configure an HTTPS load balancer. Google-managed SSL certificates are provisioned, renewed, and managed for your domain. After the ingress resource has been created, it forwards the request to the mesh ingress gateway, which then forwards the request to your app via the virtual service configuration. Request authentication configures IAP as the request authentication method. By default, IAP issues a JSON Web Token to verify user identity. This JWT is linked to the OAuth client you set up for your application. For more granular control within cloud service mesh, you can configure IAP to issue a special kind of JWT called a request context token, RC token. The key advantage of RC token is that you can customize its audience field. With RC token, you can customize the audience of the JWT, allowing you to create more precise authorization rules in cloud service mesh.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.