This took me a bit to come around to as well. I share your frustration about the
documentation.
I only reached this after looking through the katello code yesterday and I was comfortable
with the conductor -> imagefactory interaction being just a shared secret generated and
configured by aeolus-configure. I didn't catch that a user header is used to identify
the user. So for the conductor -> imagefactory -> iwhd interaction, I assume I
would use an imagefactory/iwhd shared secret and pass along the user header conductor sent
with its request to imagefactory. If we use different access tokens for conductor/iwhd
and imagefactory/iwhd we could actually enforce the idea that imagefactory writes to
warehouse and conductor reads from it for certain resources.
-steve
On Sep 21, 2011, at 9:10 AM, Matt Wagner wrote:
The bit that took me a little bit to understand after reading so
much
about three-legged OAuth with multiple key and token exchanges is that
none of that happens here. We "get" the consumer key and consumer secret
by having me open katello.yml and vim and copy-and-paste them into our
config file. (The consumer key and consumer secret in two-legged OAuth
can almost be thought of as a username/password pair, though obviously
we don't send the secret over the wire.)