First up, let me apologize for the slightly waffly nature of this
email. I'm not an expert in this area, but I hope I know enough to be
of some use...
On Sat, 04 Sep 2010 18:32:30 +0200, Zygmunt Krynicki
<zygmunt.kryni...@linaro.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello guys.
>
> I'd like to ask for your advice in for implementing authentication
> mechanism for the XML-RPC interface to the dashboard. I believe this
> problem has two aspects: user needs and client program needs. I was
> about to implement HTTP Digest authentication that will authorize the
> user against the Django user database. James pointed out that we should
> discuss this topic more. I'd like to know what you think.
>
> What users need to have.
> ========================
>
> I think that for our internal use cases a best option would be launchpad
> integration. We don't mind using launchpad, we already have accounts
> there. We could use oauth for authentication.
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.
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.
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
> I'm not an expect on oauth
> so I'm not sure what kind of impact it has on the API itself, if any (do
> we need to pass some special argument to each call?). I suspect it has a
> negotiation phase where the client and oauth provider exchange some
> messages after which the client can authenticate by providing some extra
> header in each request. In any way that's one option.
I think that's more or less right, but generally the exchange happens
outside your application. There have been some conversations about ways
to do the token generation without heading to a web browser, but I
didn't really pay much attention to them.
> For a centralized installation this would be pretty good. For ad-hoc
> installations it could be difficult to setup but I'm just guessing here.
There are simple-ish openid servers around, I think. Not many of them
support launchpad's team extension though.
> 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.
> - - 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.
> - - No authentication at all. All XML-RPC interfaces are public and anyone
> may call them. Surprisingly this is not such a bad option. Since all
> request would be anonymous all the users would be allowed to do is
> upload data to public "directories". All other interaction would have to
> be performed via the website or the administration panel.
If this is a realistic option, it certainly has a certain appeal :-)
> What clients need to implement.
> ===============================
>
> So this is about everyone who has to interact with the API, currently
> that's just dashboard itself (we have a command-line client that can use
> each exposed method) and of course abrek. While I don't mind changing
> the API or security method to make it better we need to consider that
> each client will have to adapt as well. Worse, if one client has to
> interact with two servers it may be required to discover/negotiate
> supported authentication before we can even connect.
OAuth and OpenID intend to be standards in this area, so using one of
these shouldn't be too bad in this respect.
Hope this helped.
Cheers,
mwh
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
