-----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'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.

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.

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.
- - 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.
- - 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.

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.

Thanks
Zygmunt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMgnSeAAoJEKkR4hQBRI+lvRUIAKs90kr/238PoltUbb+ET5ti
qnEgQA0UYR1ocykxlL+8gkNhDLroQuSE6HpFBlVXZb2kLc1wqb5ggK0XpwViuzwo
qr7aZ2HfkL6gMBQNhdW1OOSK7RxI1Z731vG6dFAo3UTCX737lCitYW6ipkqA//h3
slbIn5Voh43cbBKneRZvpIeHJbd6oKW4HKLeEVAzheuprXtjvhyXkg1qjUVH3V+Y
FHRp7V1fVAYvTlObhVVW2j95OEyVJK+7dbdpmwQ/8vai2WiDXdDlqJqpO2PuZNuy
mu8C0gBdZsP+ZYB2AER5RKbhZIPISf2l1fmwem79yVaxstFmHU+/KwO7AeWCR3I=
=h4TW
-----END PGP SIGNATURE-----

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to