Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for JCA Provider to ServiceAccountCredentials #410

Open
stian-svedenborg-gul-katt opened this issue Mar 2, 2020 · 0 comments · May be fixed by #411
Open

Add support for JCA Provider to ServiceAccountCredentials #410

stian-svedenborg-gul-katt opened this issue Mar 2, 2020 · 0 comments · May be fixed by #411
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@stian-svedenborg-gul-katt
Copy link

stian-svedenborg-gul-katt commented Mar 2, 2020

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

  1. Add another JCA provider providing the "RSAwithSHA256" signature algorithm to the stack bottom of the stack.
  2. Create an opaque private key.
  3. Use this key for signing the authentication assertions.
@yoshi-automation yoshi-automation added triage me I really want to be triaged. 🚨 This issue needs some love. labels Mar 3, 2020
@chingor13 chingor13 added the type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. label Mar 9, 2020
@yoshi-automation yoshi-automation removed triage me I really want to be triaged. 🚨 This issue needs some love. labels Mar 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
3 participants