environs/httpstorage: authentication support

environs/httpstorage: authentication support

This change to httpstorage enables authentication,
where authentication implies authorisation.
For an authenticating httpstorage, authentication
is required only for Put/Remove* methods; List/Get
will work unauthenticated.

Authentication is implemented by a client providing
a certificate signed by the CA, where the CA is
previously agreed upon.

There will be a followup branch which enables this
for the null provider, via additions to the
worker/localstorage.LocalStorageConfig interface,
and storage CA certificate generation at bootstrap
time.

NOTE: one caveat is that wget et al. will need to
skip certificate validation.

Fixes #1225916

https://code.launchpad.net/~axwalk/juju-core/1225916-httpstroage-authentication/+merge/187152

(do not edit description out of merge proposal)

[axw, 2013-09-24 06:19:29]

Please take a look.

[fwereade, 2013-09-24 13:33:06]

message: Lovely; LGTM. It makes me think a bit though: AFAIR the only clients
that need authentication will be the CLI and the manager nodes, and both of
those do already have suitable storage-manipulation pathways.

So, if cert distribution proves to be a hassle, we can in fact fall back to
other storage mechanisms without losing functionality (and we still get the
security we care about). Handy if we need it.

[axw1, 2013-09-25 02:30:33]

On 2013/09/24 13:33:06, fwereade wrote:
> message: Lovely; LGTM. It makes me think a bit though: AFAIR the only clients
> that need authentication will be the CLI and the manager nodes, and both of
> those do already have suitable storage-manipulation pathways.

What do you mean by "suitable storage-manipulation pathways"?

> So, if cert distribution proves to be a hassle, we can in fact fall back to
> other storage mechanisms without losing functionality (and we still get the
> security we care about). Handy if we need it.

Not really following. What are the other storage mechanisms that can be fallen
back on?