deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Dynamic selection of driver
Date Fri, 12 Nov 2010 15:26:32 GMT

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:
>> 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 ;)
View raw message