[SECOAUTH-36] Add suport for encoder injection Created: 10/Dec/10 Updated: 13/Jan/11 Resolved: 12/Jan/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Closed Spring Security OAuth OAuth 1, OAuth 2 1.0.0.M2 Type: Reporter: Resolution: Labels: Remaining Estimate: Time Spent: Original Estimate: New Feature Hellmut Adolphs Complete None Not Specified 1.0.0.M2 Priority: Assignee: Votes: Minor Ryan Heaton 0 Not Specified Not Specified Reference URL: http://forum.springsource.org/showthread.php?t=99494 Description In spring security, its possible pass an encoder to the Authenticationprovider, using the password-encoder attribute (or just setting it directly in the daoAuthenticationProvider. There should be a similar feature in Spring security Oauth. An initial idea (without looking too much in detail) could be to pass an encoder by allowing the OAuthProviderProcessingFilter validateSignature method to use an encoder. Currently the method gets a ConsumerAuthentication object, this object is buit based of the oauthparams, credentials and the ConsumerDetails. By allowing the ConsumerDetails implementation to hold an encoder (injectable through spring or programmatically), the validate signature method can check if there is an encoder included in the object and use it to hash/encrypt the secret that has been received in the request (hence allowing the comparison to happen with the hashed secret stored in the database). Comments Comment by Ryan Heaton [ 23/Dec/10 ] Hi. I finally got around to looking at this issue. The OAuth spec says that (for HMAC-SHA1 signature method) the value of the secret has to be used to calculate the hash. I could find no way to use an encoder to successfully validate a signature. Feel free to reopen if I'm missing anything. Comment by Hellmut Adolphs [ 24/Dec/10 ] I dont have permissions to re-open, but my intend with this comment is to hopefully do so. I should have clarified initially, but this particular feature is for when using PLAINTEXT in the transport (secured through SSL), so assuming the secret arrives in plaintext to the server side. I am aware of the limitation if we were to use HMAC-SHA1 in the transport, then there is no way to store the secret hashed in the database. But, assuming we would rather protect the whole request with SSL (not just the secret by hashing it) and use the PLAINTEXT method, the idea behind this task is to protect the secret stored in the server (in the database), instead of storing the secret in clear when the secret and key are created we store the secret hashed in any encoding picked by the owner) in the database. So, to put it simple the purpose of this is to be able to store hashed secrets in the server side. The flows would be something like this: 1. During secret/key creation, the client receives the secret in "clear' 2. For each request the client sends the key/secret in PLAINTEXT (assuming SSL wrapping to the request due to the lack of hashing on the secret) - another nice feature there would be to enforce SSL when method is PLAINTEXT for this case from the spring configuration (today we can do that by checking the resulting SecurityContext). 3. When the secret arrives to the server, it is hashed using the encoder registered in spring security oauth (for example an encoder that would use a unique salt for each key stored along the hashed secret in the database) 4. The hashed secret is compared against the hashed secret stored in the database and so on... On a side note, I wasn't able to make PLAINTEXT work on the server side and this derailed me a bit... if you could provide some light on that regard it would be great. Thanks! Comment by Ryan Heaton [ 24/Dec/10 ] Ah. I see. Of course, that makes a lot more sense. Comment by Hellmut Adolphs [ 24/Dec/10 ] Thanks Ryan, I am sorry for the confusion Comment by Ryan Heaton [ 12/Jan/11 ] Fixed for next release. A PasswordEncoder can now be wired into org.springframework.security.oauth.common.signature.CoreOAuthSignatureMethodFactory which if an instance is defined in an annotation-config-enabled spring context, will be autowired into the filters. Comment by Ryan Heaton [ 13/Jan/11 ] closing with the release of 1.0.0.M2 Generated at Tue Feb 09 18:27:16 UTC 2016 using JIRA 6.4.11#64026sha1:78f6ec473a3f058bd5d6c30e9319c7ab376bdb9c.