-
Notifications
You must be signed in to change notification settings - Fork 768
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
Algorithm enum needs to be moved from JwtSigner impls #7
Comments
Each is relevant to the specific implementation, e.g., HMACSHA256 has no relevance to a RSA Signer. |
So doesn't belong in an interface. |
No, these values are defined by the JWS specification in a central list and they need to be used as common keys to select signers. They need to be coalesced into a central Enum class. |
We should discuss out of band. |
The issue is that there are several places in the code where (in future) we will need to have services that can get a JwtSigner by algorithm name. In order for that to work smoothly, the algorithm name should be accessible from the interface, not from the implementations. That way I can say "JwtSigner currentSigner = signerService.getSignerByAlgorithm("HMACSHA256")". It would also be useful to be able to retrieve the algorithm name from a JwtSigner whose implementation is unknown. For right now we are just using a default signer (the RSA one), but further on we will need to be able to retrieve a signer corresponding to the Client's registered preferred algorithm. |
We should discuss offline as the spec permits multiple instances of a specific signer algorithm as i read it |
Yes it does, and this doesn't restrict that capability. |
We still need to be able to choose a signer based on the Client's preferred algorithm. signerService.getSignerByAlgorithm() can return a list, and we can have some rule for determining which one to use if we have several. But either way, we need that capability. |
I recognized some needed refactoring an code clean up across the signers responding to issue #5 as I learned more about creating Spring beans writing the client Authentication Filter. My advice would be to the keep the Algorithm enums where they are as they are specific to the individual signers in the purpose that they serve: They map the Spec defined names to the Java Standard cryptographic algorithm names for each respective signer. Each of the signers use the ENUM in their respective afterPropertiesSet-method to instantiate an instance of the algorithm by which the respective class will sign and verify signatures. I do believe you both are correct an enum needs to be in the interface, though. The afterPropertiesSet interface supports an exception being thrown for implementations of this method, and an exception will be thrown if an spec algorithm name is submitted not matching one supported by the signer. |
Refactored to JwsAlgorithm enum |
The Algorithm enum is defined in all of the JwtSigner implementations. It should be moved to a centralized Enum class.
The text was updated successfully, but these errors were encountered: