-
Notifications
You must be signed in to change notification settings - Fork 927
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
Support using Cryptographic providers #597
Comments
* No tests were changed and still compile, so the API is unchanged * ProviderName is only checked ate crypto helper. If null, then the previous code still stands. Otherwise it is used when getting an instance of java.security.Signature * Hope you find this work useful
Hello again, I have the code ready but have no permissions to push a new branch ;). I was able to keep the API untouched, as the tests remain unchanged and still compile. Hope to hear back from you. In the meantime, I'm using my fork from release-4.0.0. Regards |
Yeah, in the previous comment I attached the patch but forgot to say so.. Regards |
Hi @aps-dnxt, apologies for the delay. Thanks for the request and offer to make a PR. We'll take a look at this and see if this is something that makes sense to add. |
Hi @jimmyjames In our case it did given that we are using both BouncyCastle's Provider and a Luna HSM (which has it's own provider). Regards, |
I had a similar situation come up where I was using this JWT library in a java application running on a CentOS 7 image with FIPS enabled and it was refusing to allow any of the algorithms supported by this library to be used. It would be nice to allow alternative providers like BouncyCastle for those cases. It would be great if Argon2 could be added. Spring's Security Crypto module uses bouncy castle under the hood to implement it. https://docs.spring.io/spring-security/site/docs/6.0.x/api/org/springframework/security/crypto/argon2/Argon2PasswordEncoder.html |
@aps-dnxt 👋 If we can add this through standard Java typings, it may be a win-win. Could you provide some details about the new public APIs proposed (signatures) and if any additional dependencies would be required (doesn't sound like it, but just to be sure). Or if you already have the changes made, we could just review in a PR (are you still unable to make a PR?). If not we can look at the patch you provided (though we do want contributions so should figure out why that's an issue). Thanks again! |
Hi @jimmyjames! Just opened a PR. Yes, I used all standard Java typings. Hope it's up to the project's quality. Regards. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇♂️ |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇♂️ |
It would be nice to have a facility of mentioning the SecurityProvider, say BouncyCastleProvider, while creating a JWTCreator & JWTVerifier. |
Hi y'all
Describe the problem you'd like to have solved
In my project, I'm required to use an HSM (Hardware Security Module) for computing digital signatures. This particular HSM provides a Java API which includes a java.security.Provider class. This class is tasked with making the HSM specific calls for computing signatures with a given java.security.PrivateKey reference.
The same could be said if we want to use BouncyCastleProvider, another common crypto provider in the Java and .NET crypto communities.
Specifying the signature provider is standard Java, as can be observed in the Signature.getInstance(String algorithm, String provider).
Unfortunately, there's no way in auth0 to pass a provider instance or it's name to the CryptoHelper.
Describe the ideal solution
Since auth0 is already relying on java.security.Signature class to compute signatures, for me, the ideal solution would be to add a provider parameter to the JWTCreator.Builder#sign(Algorithm algorithm) method to match the java.security.Signature.getInstance(String algorithm, String/Provider provider) method in the Java API.
Alternatives and current work-arounds
I'm unsure if setting the HSM provider as the provider in position 0 of the providers list would suffice. Other than this, I'm forking auth0 and modifying the code.
Additional information, if any
I'm using auth0 3.16.0.
I'm also available to implement this and create a pull request with the code. I'm doing it right now..
Regards
Antonio Pedro Santos
The text was updated successfully, but these errors were encountered: