On Sun, 05 Sep 2010 17:25:14 +1200, Michael Hudson michael.hudson@linaro.org 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:
- you'd run some configuration command for abrek
- launch-control would pop up in your browser
- you would authenticate yourself to launch-control, any which way
- you would click a button saying "yes, allow abrek to upload results"
- 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-force attacks much easier, as you could just type in "password" and will probably get logged in.
Authorization - whether the user is allowed to perform a particular task. This one is fairly obvious, can the user (perhaps anonymous, perhaps identified but not authenticated) perform whatever action they are trying to do? - Without identification then you basically have a boolean system, whether the anonymous user can do something. - Without authentication you have easy impersonation, and so the controls are more advisory than mandatory.
]
Thanks,
James