Bug 782899

This bug is to track the changes to the oauth communication between conductor -> iwhd.  This is already fixed, built, and ready to be tested.


+++ This bug was initially created as a clone of Bug #760592 +++

+++ This bug was initially created as a clone of Bug #760377 +++

Automation uses httpclient in conjuncture of signpost (oauth lib) to make requests to configserver. For regular GET request, the server was able to authorized and return the proper information. For POST or PUT, it returns a 401 Unauthorized error while using the same consumer key/secret.

After speaking w/ the dev, it sounds like conductor does not take the entire header and generate the hash and signature. Instead it omits the "data=..." section. 

As a result, because the automation includes the data section when it generate the hash and signature, it fails verification on configserver side.

--- Additional comment from gblomqui on 2011-12-06 09:52:56 EST ---

The correct behavior according to oauth standards is to include the entire post body payload when generating the signature in the HTTP request.  However, Conductor is using the RestClient ruby library with a request preprocessor that signs the request via oauth prior to sending the request.  Either the way Conductor is using the RestClient library, or the library itself, is not including the entire post body when signing the request.  Namely, it's not including the "data=..." part of the post body payload when generating the oauth signature.

The workaround on the server side (i.e., inside of configserver) is to omit the "data=..." part of the post body when validating the signature.  The security implications here are minimal, since there is a timestamp as well as other oauth headers included in the signed value.  

The major downside to this approach is that it is non-standard.  Which leads right back to David's comment about test automation failing.

--- Additional comment from whayutin on 2012-01-03 12:41:52 EST ---

adding ce-sprint-next bugs to ce-sprint

--- Additional comment from matt.wagner on 2012-01-04 13:29:37 EST ---

In #760377, Greg got around this by <a href="https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007547.html">using the oauth gem directly</a> instead of using restclient at all. That's probably a good path to take here as well.

--- Additional comment from matt.wagner on 2012-01-04 15:43:28 EST ---

Where this actually matters for Conductor (besides the config server code, which was fixed in 760377) is in our iwhd client in rubygem-aeolus-image. Fixing it there would mean that we want to implement https://www.aeolusproject.org/redmine/issues/2606 to have iwhd verify the full hash.

--- Additional comment from matt.wagner on 2012-01-04 17:33:00 EST ---

Patch sent for feedback: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-January/007838.html

--- Additional comment from matt.wagner on 2012-01-10 13:36:00 EST ---

Pushed to aeolus-image-rubygem's master:

commit 67fdf6ff1a395624c81df8b16832248b45185505
Author: Matt Wagner <matt.wagner>
Date:   Wed Jan 4 17:04:10 2012 -0500

    Use oauth gem directly for signing OAuth requests
    
    Using restclient appears to cause part of the request to get dropped
    on the floor, causing oauth_body_hash to be invalid.
    
    This appears backwards compatible with existing versions of iwhd.
    
    Resolves https://bugzilla.redhat.com/show_bug.cgi?id=760592

--- Additional comment from matt.wagner on 2012-01-10 13:39:25 EST ---

I've pushed this, but note that the code to validate this on the iwhd side isn't yet committed. It's possible that it won't be committed: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-January/007896.html

This patch is still a good thing in that we're sending a properly-signed request to iwhd now, but it will have no real-world benefit as iwhd isn't checking whether the oauth_body_hash is correct or not unless the patch linked in the previous paragraph is committed to iwhd.

--- Additional comment from slinaber on 2012-01-10 17:02:46 EST ---

Blindly setting this to ON_QA in the belief that a fix is included in the latest aeolus packages.

--- Additional comment from whayutin on 2012-01-12 11:14:20 EST ---

bugs in verified or on_qa moving off tracker

--- Additional comment from dgao on 2012-01-12 16:23:13 EST ---

Fixed in the latest build of audrey client and configserver:

aeolus-audrey-agent-0.4.3-1.el6.noarch.rpm                                  
aeolus-configserver-0.4.5-1.el6.noarch.rpm

--- Additional comment from dgao on 2012-01-12 16:25:10 EST ---

oops mistakenly commented the wrong bug, disregard the last comment.

--- Additional comment from gblomqui on 2012-01-18 14:46:54 EST ---

Setting this back to POST because https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007547.html has never been applied.

I'll work with someone from conductor to get this in.

--- Additional comment from gblomqui on 2012-01-18 15:07:20 EST ---

This bug is to track the changes on the conductor side of the conductor -> config server communication.

It looks like Matt's comments relate to the same type of communication between conductor -> iwhd.  This should be opened and tracked in another bug.