You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current API for ServiceAccountCredentials does not support explicitly setting a Provider. (This is true for all Credentials implementing ServiceAccountSigner, but changing it consistently for all these should also incorporate changes to com.google.api.client.json.webtoken.JsonWebSignature in my opinion).
The current behaviour relies on JCA to always yield the correct provider for java.security.Signature regardless of how the key is stored. When the key is stored in a KeyVault or on a HSM this assumption fails. This is a design limitation in the JCA and requires the use of explicit providers.
I have a patch that fixes the issue for ServiceAccountCredentials, and suggest that similar work is done on the other GoogleCredentials implementations.
Environment details
OS: All
Java version: 1+
google-auth-library-java version(s): All versions before 0a57cd5
Steps to reproduce
Add another JCA provider providing the "RSAwithSHA256" signature algorithm to the stack bottom of the stack.
Create an opaque private key.
Use this key for signing the authentication assertions.
The text was updated successfully, but these errors were encountered:
The current API for ServiceAccountCredentials does not support explicitly setting a Provider. (This is true for all Credentials implementing ServiceAccountSigner, but changing it consistently for all these should also incorporate changes to com.google.api.client.json.webtoken.JsonWebSignature in my opinion).
The current behaviour relies on JCA to always yield the correct provider for java.security.Signature regardless of how the key is stored. When the key is stored in a KeyVault or on a HSM this assumption fails. This is a design limitation in the JCA and requires the use of explicit providers.
I have a patch that fixes the issue for ServiceAccountCredentials, and suggest that similar work is done on the other GoogleCredentials implementations.
Environment details
Steps to reproduce
The text was updated successfully, but these errors were encountered: