On Nov 12, 2010, at 10:04 AM, Toby Crawley wrote: > On 11/12/2010 09:29 AM, Jim Jagielski wrote: >> >> On Nov 11, 2010, at 8:21 PM, David Lutterkort wrote: >>> Toby actually experimented with this (wanna share your patch, Toby ?). >>> To me, the cleanest way to enable dynamic selection of the driver is to >>> select the driver through add'l HTTP headers. For example, by sending >>> >>> X-Deltacloud-Driver: ec2 >>> X-Deltacloud-Endpoint: https://eu-west-1.ec2.amazonaws.com/ >>> >>> >> >> Sounds good, but shouldn't there be some sort of auth mechanism >> to "verify" that an authorized entity set those headers? >> > > If we suspect the source of the headers, we should suspect any data in the > request. If an entity can munge headers, it can munge anything else in the > request - the requests currently have no signing mechanism. If this type of > security is a concern, the deltacloud server should be accessed via https. > The client is based on RestClient, so should support https out of the box if > deltacloud is running with a valid certificate. If using a self signed > certificate, the client would probably need to be modified to not validate > the server cert, or given the CA for the server cert so it can validate.
That's not 100% true. Sure, one can munge headers; it's trivial. But what if there is some simple md5 hash check, for example, related to the IP address of the client and some shared secret. The client IP, since it's NOT part of the http request, is not as easily munged... Any time you use http req headers as a control mechanism, you need some sort of a&a mechanism to provide oversight. Even something as simple a Digest auth (or some variant) provides *some* level of protection w/o the full overhead of ssl. Of course, it goes w/o saying, that I'm offering to *add* this capability ;)
