As part of SmartDataCenter 6.5, we’ve introduced something I’m pretty excited
about sharing, which is an open signing protocol for HTTP. We’re using it in
what we call CloudAPI, which is the REST API that powers our customer portal, and is
exposed to you to create your own applications. In this post I’ll go over what the signing
protocol is and why you should care, how SmartDataCenter is using it, and some
ideas we have in mind for the future.
If you’re not an RFC nerd, HTTP defines a “pluggable” framework for
authentication so that any number of authentication mechanisms can be used, and
goes on to define Basic Authentication. Basic Authentication is nothing more
than sending your username and password across the wire, so it’s not ideal from
a security perspective. Following Basic Authentication, HTTP also goes on to define
Digest Authentication, which involves sending a hashed form of your password
across the wire, but it’s hard to use and doesn’t see much use these days.
However, for the best security properties, you really want to be leveraging
public key cryptography to authenticate. HTTPS (well, really SSL) has a mode
of allowing this called “client-auth”; basically your client has a certificate
and private key, and in addition to validating the server’s certificate, the
server asks you (the client) to present your certificate. Sounds great, and
does do what we want from a security perspective. However, it’s plagued by poor
usability in browsers, is more or less a programming nightmare (especially with
“custom” CAs), and can incur significant server-side cost, since it’s usually
a load balancer (i.e., HTTPS termination point) that is handling the
cryptography validation. All of this means that we want the benefits of public key crypto
without the burden of client-auth SSL.
To solve this problem with SmartDataCenter, we’re introducing the HTTP Signature
authentication scheme, which is already released as open source. The HTTP
Signature scheme allows for digital signatures to be leveraged as your
credentials, and does not imply any particular key management scheme. It should
be suitable for just about any REST API out there, so we’re certainly hoping if
you’re an API vendor you take a look at it, but rather than jump into the
technical details of the spec itself, I thought it would be interesting to
show you some CLI candy, so lets walk through some examples.
Read More »
We’ve known Theo Schlosnsnagle (
