On Sun, 05 Sep 2010 17:25:14 +1200, Michael Hudson
wrote:
> I may be talking out of my behind here, but do you really mean oauth?
> OAuth is more about authorization -- should this request be permitted --
> and the subject of this mail talks about "authentication" -- who is this
> request on behalf of. The two questions are related of course, but
> Launchpad supports *openid*, which is a way of delegating
> authentication. Launchpad also supports oauth for authenticating API
> requests, but I don't think that's relevant to the issue at hand. AIUI
> launch-control would still need to implement the server end of oauth and
> not be able to leverage Launchpad's implementation -- I may be wrong
> about this though.
Yes. I think that Zygmunt conflated two thoughts in that paragraph.
We have the question of identity. For the linaro instance (and maybe
all), we could use openid for this. This allows us to identify a user
(and presumably have their openid provider authenticate them, though
there's no guarantees of that.) In particular we could support Launchpad
openid.
openid is all but useless for authenticating API requests to
launch-control. We need both identification and authentication here (and
there will be authorization too, but that's beside the point here in my
opinion, once you have identity you can do authorization anyway you
like.) oauth is one candidate for this step, the client signs the
requests on behalf of the user, and by checking that signature we get
identification and authentication.
> Using Launchpad's openid opens the door to doing *authorization* by
> Launchpad team membership -- users who belong to team ~X can upload
> results to this method.
Yes.
> If you really meant oauth, then it probably makes sense -- but it
> doesn't really handle authentication. The typical workflow would be:
>
> 1) you'd run some configuration command for abrek
> 2) launch-control would pop up in your browser
> 3) you would authenticate yourself to launch-control, any which way
> 4) you would click a button saying "yes, allow abrek to upload results"
> 5) the configuration command would receive a token that it could
> include in subsequent requests
In my mind oauth does handle authentication, at the request level at
least, as it authenticates you to the API when you make requests.
> > Other options are (off the top of my head):
> > - - Basic/Digest HTTP authentication. Digest is pretty good (or so
> > wikipedia tells me) and has a very nice property of not requiring any
> > changes to the API. User identity is provided as out-of-band HTTP
> > header.
>
> Yeah, this sounds fine to me, basically. Less sexy than the above
> suggestions of course :-) If we delegate to Launchpad for identity, then
> I would not be especially comfortable putting my LP password on every
> device that I might want to talk to launch-control.
That's not really feasible anyway.
If we want HTTP digest auth, then we have to do the following:
1. Have users create an account on the system (possibly using openid
against LP or any other provider, this provides them with one method
to log in.)
2. Have them enter a password/generate one for them that they can
discover.
3. Allow that password to be used to authenticate API requests (and
possibly web requests too.)
We are not limited to a single password here, and could have e.g. one
per device if we wanted.
At no point though should we ask the user for their LP/SSO password.
> > - - Custom authentication via special XML-RPC methods and some
> > user/pass/token/whatever arguments. This is IMHO pretty ugly as it
> > affects the interface. The upside is that we can build any
> > authentication options we like.
>
> This sounds pointless and ugly. Let's use an existing standard of some
> kind.
+1
[ Just so we are clear about terms, some definitions for how I am using
them:
Identification - who the user is. If you don't have this then you
can't tell users apart. It is possible to have a system with just
identification, for instance lots of tills behind bars do this, where
a server presses their name before they start entering a transaction,
so all transactions are attributed a person, but can easily be
spoofed.
Authentication - whether the user is who they say they are. This
prevents the spoofing in the bar case. This is the model we all know
and love from Unix, where you enter your username and password. There
are systems where you have authentication, but not identification,
which is a sort of authenticated anonymous model. Then you know the
user is allowed, but can't tell the users apart. Think of the
"warthogs" account on the Canonical RT.
- Authentication implying identification is a bad idea. Usually our
passwords will be different, so on a multi-user Ubuntu machine we
could just request the password and log in whoever that
matches. However, what happens if two people choose the same password?
Also, it makes brute
