[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.