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

[FEATURE REQ] Improved support for JWS Signing and JWE Decryption for java nimbus jose #31965

Open
2 tasks
vtapadia opened this issue Nov 5, 2022 · 1 comment
Open
2 tasks
Assignees
Labels
blocking-customer-adoption Issue is blocking the migration from Track 1 to Track 2 Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. feature-request This issue requires a new behavior in the product in order be resolved. KeyVault needs-team-attention This issue needs attention from Azure service team or SDK team

Comments

@vtapadia
Copy link

vtapadia commented Nov 5, 2022

Is your feature request related to a problem? Please describe.
We use Spring Java + Azure Key Vault for Signing and Decryption. However, the lack of support for the defacto standard library nimbus-jose-jwt causes a bit of barrier to adoption.

Describe the solution you'd like
Mainly there are 2 interfaces that if supported, would work great and standardize the way Signing and Decryption is done.
com.nimbusds.jose.JWEDecrypter
com.nimbusds.jose.JWSSigner

Describe alternatives you've considered
I created my own implementation for use. For signer this is easy..

    @Override
    public Base64URL sign(JWSHeader jwsHeader, byte[] bytes) {
        //Getting the exact key version, I have used keyname/version as the keyID. Wish Azure would also have used the same mechanism for defining key ID. :)
        String[] keyParts = jwsHeader.getKeyID().split("/");
        CryptographyClient cryptographyClient = keyClient.getCryptographyClient(keyParts[0], keyParts[1]);
        SignResult signResult = cryptographyClient.signData(
                SignatureAlgorithm.fromString(jwsHeader.getAlgorithm().getName()),
                bytes);
        return Base64URL.encode(signResult.getSignature());
    }

For Decryption, again created the same decrypter, but it would have been easy had the implementation is available from Azure. I only built it for RSA_OAEP_256 use case, but similar could be done for all the possible flavors

    @Override
    public byte[] decrypt(JWEHeader header, Base64URL encryptedKey, Base64URL iv, Base64URL cipherText, Base64URL authTag) throws JOSEException {
        //Getting the exact key version.
        String keyID = header.getKeyID();
        String[] keyParts = keyID.split("/");
        //Create client for KV for the specific key
        CryptographyClient cryptographyClient = keyClient.getCryptographyClient(keyParts[0], keyParts[1]);
        if (header.getAlgorithm() == JWEAlgorithm.RSA_OAEP_256) {
            //Decrypt the Content Encryption Key from the KV
            DecryptParameters rsaOaep256Parameters = DecryptParameters.createRsaOaep256Parameters(encryptedKey.decode());
            DecryptResult decryptResult = cryptographyClient.decrypt(rsaOaep256Parameters, Context.NONE);

            //Use the Content Encryption key to decrypt the data
            SecretKey secretKey = new SecretKeySpec(decryptResult.getPlainText(), header.getEncryptionMethod().getName());
            return ContentCryptoProvider.decrypt(header, encryptedKey, iv, cipherText, authTag, secretKey, new JWEJCAContext());
        } else {
            throw new RuntimeException("Unsupported Encryption");
        }
    }

Additional context
I think implementation similar for these interfaces should be part of the Java keys library or even a separate project.

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

  • Description Added
  • Expected solution specified
@ghost ghost added needs-triage This is a new issue that needs to be triaged to the appropriate team. customer-reported Issues that are reported by GitHub users external to the Azure organization. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Nov 5, 2022
@joshfree joshfree added KeyVault Client This issue points to a problem in the data-plane of the library. labels Nov 7, 2022
@ghost ghost removed the needs-triage This is a new issue that needs to be triaged to the appropriate team. label Nov 7, 2022
@joshfree joshfree added feature-request This issue requires a new behavior in the product in order be resolved. blocking-customer-adoption Issue is blocking the migration from Track 1 to Track 2 and removed question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Nov 7, 2022
@ghost ghost added the needs-team-attention This issue needs attention from Azure service team or SDK team label Nov 7, 2022
@joshfree
Copy link
Member

joshfree commented Nov 7, 2022

Thanks for sharing this feedback @vtapadia! @vcolin7 please take a look

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocking-customer-adoption Issue is blocking the migration from Track 1 to Track 2 Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. feature-request This issue requires a new behavior in the product in order be resolved. KeyVault needs-team-attention This issue needs attention from Azure service team or SDK team
Projects
None yet
Development

No branches or pull requests

3 participants