| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC][PATCH] Secure XML-RPC for Xend
Ewan Mellor wrote:
On Fri, Jun 09, 2006 at 07:10:23AM -0500, Anthony Liguori wrote:
It's tempting to use https/basic auth since it seems like it ought to
just work with existing clients. However, that doesn't appear to be the
case.
Python doesn't seem to provide any real support for authentication
out-of-the-box. It wouldn't be that hard to add but neither was an SSH
transport.
Personally, I'd use SSL to secure the connection and authenticate the server
to the client, but I'd not use HTTP's basic auth -- I'd add a "login" message
that checked the username/password using PAM, in other words, have the
authentication of the user handled at Xend's level, rather than relying on the
transport/session layer to do it. Like you say, HTTP's authentication stuff
doesn't seem to be well supported.
I see three ways of making this work.
1) Have a login message that returns some sort of random key. This key
would have to be passed to all other RPCs. The key would have to come
from a good random source and be sufficiently large that a brute-force
attack wasn't likely. We would have to introduce some sort of way to
expire these keys though (to prevent a user from reusing a key from a
previous authentication after the root user password has changed).
2) Pass the credentials to every RPC (this is essentially what HTTP
Basic auth does). The good thing about this is that it solves the above
key expiration problem but PAM authentication can be pretty heavy weight
depending on how your PAM is configured. This could prove rather nasty.
3) Make sure the client uses Keep-Alive and have the login RPC
authentication the rest of the session. I like this approach the most
since it avoids the problems with both of the above. Of course, it
assumes your client library is capable of doing XML-RPC over a
Keep-Alive session which probably isn't a good assumption.
What do you think? Is there another way of doing this that I'm missing?
The plus side of using the login RPC is that with stunnel it will be
pretty easy to implement on the server end.
The other problem is that Python doesn't provide support for certificate
verification. That's okay if you're just using Python to screen scrap
but if you're in an enterprise environment it's not a very good thing.
The other problem I'm concerned about is certificate management on our
end. The average user is going have to end up using snake oil certs and
I've always found configuring these things to be a real pain.
It's only not a pain with SSH because your distro has set it up for you to
generate a key at install time. Hopefully, we could arrange or rely upon the
distros to arrange a similar thing for Xend.
It's worse because SSL assumes that there is a single root-of-trust
(namely Verisign). Properly signed certs are expensive. Managing snake
oils certs becomes a PITA.
I still think HTTPS is worth doing because it will be useful to an awful
lot of clients.
Regards,
Anthony Liguori
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home