On 09/20/2011 09:40 AM, Martyn Taylor wrote:
On 09/19/2011 09:16 PM, Hugh Brock wrote:
> On Mon, Sep 19, 2011 at 01:52:10PM -0400, Matt Wagner wrote:
>> Hi all,
>>
>> I picked up #2121 this morning, to integrate a warden authentication
>> strategy that provides two-legged OAuth. (Which someone described as
>> "our favorite catch-phrase ever.")
>>
>> I've spent a bit looking into this, and I think I have a decent
>> understanding of the technical side of things. But what's not clear to
>> me at all is the user story.
>>
>> I think we're actually trying to do two very different things with
>> OAuth.
>>
>> One is to be an OAuth "server" that aeolus-image can connect to.
I'm
>> thinking this is more a case of 3-legged OAuth, though, as I think we
>> want aeolus-image to have user-level permissions. (i.e., aeolus-image
>> authenticates the user to Conductor via token.)
> I'm not clear that we need to do this in the short term, if at
> all. I'd be happy with the user passing their credentials to Conductor
> on each call for the short term, and in the long term it sounds a bit
> like replicating Kerberos.
Hugh,
Maybe I'm wrong here but I was of the opinion that we want to lock down
the conductor API using OAuth. If we are also wanting Katello to talk
to conductor we should follow suit and do so via OAuth too right?
meaning that conductor must act as an OAuth server? aeolus-image would
use the same API meaning it too (as well as Katello) must act as a OAuth
client.
I'm not sure what you mean by replicating Kerberos, but wouldn't that
apply to all 3 legged auth? I've probably misunderstood. But afaik
there is no way for Kerberos to manage permissions on "protected
resources" that exist in Conductor. Which is one of the main advantages
of using OAuth.
I guess how we move forward depends on what we are trying to achieve
with OAuth, are we using it only to integrate with Katello, or is it to
be used as a solution for a secure conductor API too?
Thanks
Martyn
>
>> The other is to act as an OAuth client when connecting to other
>> services, using two-legged OAuth. Off the top of my head, we want to be
>> consumers of Katello, iwhd, and Factory. (Actually, I'm thinking that we
>> want Katello to work both ways, and I'm not sure how this is normally
>> handled. I suspect that sometimes we'll want to make calls to Katello,
>> and other times they may wish to make calls to us.)
> I think this critical for 1.0 b/c otherwise we wind up with iwhd and
> Factory listening on the box with no authentication.
>
>> How many of these things are in scope for this sprint? How many of these
>> providers actually support OAuth on their end yet?
>>
>> And how about #2309, "Ensure that owner information is stored as
>> meta-data in iwhd"? Does it make any sense to consider passing this
>> information along via OAuth from aeolus-image to Factory?
> However we need to pass the UID is fine with me as long as we know
> Conductor is the only trusted writer -- i.e. the only thing that can
> give the information to Factory.
>
> --H
>
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.
About aeolus-image, I thought there will be no change - it will use
basic http auth.
Simple example how consumer oauth looks like:
require 'rubygems'
require 'oauth'
consumer = OAuth::Consumer.new(
'cloud_forms',
'shhh',
:site => "https://localhost:4000",
:request_token_path => "",
:authorize_path => "",
:access_token_path => "")
access_token = OAuth::AccessToken.new consumer
response = access_token.get('https://localhost:3000/api/organizations',
{ 'katello-user' => 'admin' })
Jan