On Tue, Sep 20, 2011 at 10:36:53AM +0200, Jan Provaznik wrote:
From discussion some time ago I thought that:
1) conductor provides 2-legged OAuth in 'provider' mode:
- this is needed by katello, Katello user defines template and wants to
launch it.
katello<->conductor user stories can be found here:
https://fedorahosted.org/pipermail/aeolus-devel/2011-August/003736.html
2) conductor provides 2-legged OAuth in 'consumer' mode:
- this is needed for communication with:
- katello: conductor fetches templates from katello
- iwhd and imagefatory
in 2-legged oauth, user is passed from consumer to provider in http
header, provider trusts consumer and sets this user
Both modes are already implemented in Katello, nothing difficult to do
same in conductor.
So after going back and forth on this with a number of people, it sounds
like there's no need for Conductor to act as an OAuth server at this
point in time. (Though it should be very little work to implement when
we get there.) Instead, this OAuth task is actually about implementing
clients for the various services we use, which will provide OAuth.
About aeolus-image, I thought there will be no change - it will use
basic http auth.
It sounds like this is the case for now. Long-term it would be nifty if
this was done over three-legged OAuth, but it sounds like this isn't one
of the biggest problems we're facing at the moment.
-- Matt