feat(auth): mTLS endpoint for Regional Access Boundaries by vverman · Pull Request #13318 · googleapis/google-cloud-java

vverman · 2026-05-31T23:00:03Z

Added logic to:

Centralize mTLS enablement logic within the auth library.
Based on 1. determine whether mtls or regular RAB lookup endpoint should be called.
Added tests for the same.

gemini-code-assist

Code Review

This pull request introduces centralized mTLS enablement checks and adds fallback support for SPIFFE credentials in MtlsUtils and X509Provider, alongside integrating mTLS transport initialization during regional access boundary refreshes. The review feedback suggests optimizing performance by removing redundant configuration checks and file parsing in X509Provider.getKeyStore() and GoogleCredentials.java, and improving robustness in RegionalAccessBoundary.java by replacing only the host name in the IAM credentials URL.

lsirac

Should we be checking GOOGLE_API_USE_MTLS_ENDPOINT?

lsirac · 2026-06-05T15:23:50Z

+   * @throws IOException if the configuration file is present but contains missing or malformed
+   *     files
+   */
+  public static boolean canMtlsBeEnabled(


I’m not sure that cert being present == automatically use mTLS. They can be using different credentials / not using it at all. So then we’d be adding mTLS setup and calls for credentials that are not actually using it.

I think the decision should be based on the credential type, and perhaps expose some state from the credential that we can use to check if mTLS should happen for these calls.

…h library.

Added an E2E test to check the call to RAB mtls endpoint and check x-allowed-locations header. Unified redundant method(s) waitForRegionalAccessBoundary.

lqiu96 · 2026-06-11T21:27:04Z

+   * @throws IOException if the configuration file is present but contains missing or malformed
+   *     files
+   */
+  public static boolean canMtlsBeEnabled(


nit: can this be updated to canBeEnabled or isEnabled? I think mtls when writing MtlsUtil.canMtlsBeEnabled is a bit redundant and the context exists.

I think the eventual goal wrt MWLID is to move to a this singular method to be used by all client libraries which depend on google-auth-java to use the canMtlsBeEnabled to determine whether or not they should use mTLS.

We can rename it later at the new location whenever it comes to that. For now, can we update the name for the existing file (in case the future changes get deprioritized)

lqiu96 · 2026-06-11T21:28:11Z

+    if (policy == MtlsEndpointUsagePolicy.NEVER) {
+      return false;
+    }
+    if (policy == MtlsEndpointUsagePolicy.ALWAYS) {
+      return true;
+    }


Can we move the Never policy up so that the method returns fast?

For the Always policy, why do we return true and not check the configs below? Do we only check the configs for auto?

I think the first priority goes to the GOOGLE_API_USE_CLIENT_CERTIFICATE which is why we check it first.

The reason I chose to keep the Never check down is that it allows us to pair it with the Always check.

IIUC from the logic, the order shouldn't matter except for ALWAYS. It's just a small nitpick from my end since it makes it easier for me to track the states once we rule out different states at the top.

Bumping the second part of the question: Why does Always simply return true? IIUC, only AUTO ends up checking the state of the config file right? Is that intended?

IIUC from the logic, the order shouldn't matter except for ALWAYS

As per AIP-4114, we should prioritize GOOGLE_API_USE_CLIENT_CERTIFICATE i.e. if it is set to false, even if GOOGLE_API_USE_MTLS_ENDPOINT is set to ALWAYS, we will not enable mTLS.

Why does Always simply return true

Yes this is intentional, we will always try to call mTLS endpoint even if the cert hasn't been discovered.

only AUTO ends up checking the config state

That's right, as the default value, only when certs are discovered shall we attempt to switch to mTLS.

lqiu96 · 2026-06-11T21:59:20Z

  @Override
  public boolean isAvailable() throws IOException {
-    try {
-      this.getKeyStore();


I vaguely remember this and the unfortunate hack we had to make to determine if each MtlsProvider could be used. I recall that there wasn't a way to determine if it could be used without having to initialize the keystore and create it.

If we change it to MtlsUtils.canMtlsBeEnabled I think it ends up changing how we determine if each provider can be used right?

I just want to check what the exact requirements are for determining if X509PRovider can be used or not. Is it just checking if Mtls can be used and that the files exist and we don't need to create the KeyStore?

The getKeyStore before was doing the same cert-detection logic that the canMtlsBeEnabled does.

The only addition with the canMtlsBeEnabled is that we're also checking for the GOOGLE_API_USE_MTLS_ENDPOINT env variable. To respect the AIP.

Technically it was a 'bug' in the previous implementation since we weren't checking for it.

IIUC, for X509 was doing a bit more as it was loading the cert file and the private key path and building the actual keystore. If this extra step isn't actually needed, then I think it can be replaced with canMtlsBeEnabled. I'm not the biggest fan of having to build the keystore to determine if we can use it, so any way to simply it would be better and I would prefer this if possible.

I think I actually prefer to get rid/ not use isAvailable at all if possible

I think I actually prefer to get rid/ not use isAvailable at all if possible

We're restricted to this because X509Provider implements MtlsProvider which defines the isAvailable in the contract.

IIUC MtlsProvider used to live in the gax library from whence it was moved to the auth lib and code within gax relies on the isAvailable method.

lqiu96 · 2026-06-12T17:00:29Z

+    MtlsUtils.MtlsEndpointUsagePolicy mtlsPolicy =
+        MtlsUtils.getMtlsEndpointUsagePolicy(SystemEnvironmentProvider.getInstance());
+    if (transportFactory instanceof com.google.auth.mtls.MtlsHttpTransportFactory
+        || mtlsPolicy == MtlsUtils.MtlsEndpointUsagePolicy.ALWAYS) {
+      url = url.replace("iamcredentials.googleapis.com", "iamcredentials.mtls.googleapis.com");
+    }


qq, does this need to be done within refresh()? IIUC, the mtls configs should not be changing and I wonder if we can do this once?

That's a good point, I added a cache for checking the userMtlsPolicy so we check only the first time.

Though this shouldn't have a material effect because we only do the refresh once every 5 hours, still I think this is the right call.

lqiu96 · 2026-06-12T17:06:31Z

+    transportFactory =
+        MtlsUtils.prepareTransportFactoryIfMtlsEnabled(
+            transportFactory, getEnvironmentProvider(), getPropertyProvider(), null);


This looks to be setting the transport only for RAB requests. Is that intended as other auth endpoints may not support mTLS?

I was thinking that we just configure the default http transport to resolve whether mtls or not should be used:

google-cloud-java/google-auth-library-java/oauth2_http/java/com/google/auth/oauth2/OAuth2Utils.java

Line 135 in 79e26b8

return HTTP_TRANSPORT;

That is a good suggestion, I believe the python library does something similar where it dynamically switches to the mtls transport for all requests when it discovers that mTLS is enabled.

I think this can be for a future implementation since we are focused on RAB. This change might span across STS and IAM calls as well.

Added #13461

lqiu96 · 2026-06-12T17:10:00Z

+
+    MtlsEndpointUsagePolicy mtlsPolicy = getMtlsEndpointUsagePolicy(envProvider);
+    try {
+      boolean canMtls = canMtlsBeEnabled(envProvider, propProvider, certConfigPathOverride);


nit: rename boolean field to mtlsEnabled

I think that'll clash with mtlsutils.canBeEnabled.

Instead changed it to -> userMtlsPolicy

gemini-code-assist Bot reviewed May 31, 2026

View reviewed changes

vverman changed the title ~~Regional access boundaries~~ feat(auth): mTLS endpoint for Regional Access Boundaries Jun 1, 2026

vverman marked this pull request as ready for review June 4, 2026 08:45

vverman requested review from a team as code owners June 4, 2026 08:45

vverman marked this pull request as draft June 4, 2026 08:46

vverman marked this pull request as ready for review June 4, 2026 22:05

vverman requested review from lqiu96 and nbayati June 4, 2026 22:05

lsirac reviewed Jun 5, 2026

View reviewed changes

lqiu96 reviewed Jun 5, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsHttpTransportFactory.java

lqiu96 reviewed Jun 5, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java

lqiu96 reviewed Jun 5, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java Outdated

lqiu96 reviewed Jun 5, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java Outdated

lqiu96 reviewed Jun 5, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java Outdated

lqiu96 reviewed Jun 5, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/oauth2/RegionalAccessBoundary.java Outdated

nbayati requested changes Jun 10, 2026

View reviewed changes

vverman added 7 commits June 10, 2026 19:06

Added changes to enable cert-discovery and mtls by default in the aut…

30662d6

…h library.

Added changes for RAB mtls endpoint.

401df41

Removed redundant call to canMtlsbeEnabled.

62ddec4

Added GOOGLE_API_USE_MTLS_ENDPOINT check to canMtlsBeEnabled.

1eca146

Added an E2E test to check the call to RAB mtls endpoint and check x-allowed-locations header. Unified redundant method(s) waitForRegionalAccessBoundary.

RAB lookup url replacement to mtls is made more robust.

93dc126

Added changes to always call mTLS RAB endpoint. Removed SPIFFE fallback.

2646ebb

nit Fixes.

48c3b59

vverman force-pushed the regional-access-boundaries branch from 2c53152 to 48c3b59 Compare June 11, 2026 02:13

vverman requested review from lqiu96 and nbayati June 11, 2026 03:16

lqiu96 reviewed Jun 11, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java Outdated

lqiu96 reviewed Jun 11, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java Outdated

lqiu96 reviewed Jun 11, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java Outdated

lqiu96 reviewed Jun 11, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java Outdated

lqiu96 reviewed Jun 11, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java Outdated

Moved cert-discovery to a common function. Addressed PR comments.

af9e51f

lqiu96 reviewed Jun 12, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java Outdated

lqiu96 reviewed Jun 12, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java Outdated

vverman added 2 commits June 12, 2026 20:34

cache userMtlsPolicy so we read only once other comment addressals.

c436e7f

lint fixes.

d115ef9

vverman requested a review from lqiu96 June 15, 2026 18:07

Conversation

vverman commented May 31, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lsirac left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lqiu96 Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vverman Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

lqiu96 Jun 11, 2026 •

edited

Loading

vverman Jun 12, 2026 •

edited

Loading