Yeah that's why we generate ~/reports for you every hour - that's what our billing runs off of. I know there's an internal "turn that into daily $ script" somebody wrote -- we'll get that put out as a sample job.
This entire HN thread is a perfect example of why we built Manta. Lots of engineers/scientists/sysadmins/... already know how to (elegantly) process data using Unix and augmenting with scripts. Manta isn't about always needing to work on a 10TB dataset (you can), but about it being always available, and stored ready to go. I know we can't live without it for running our own systems -- all logs in the entire Joyent fleet are rotated and archived in Manta, and we can perform both recurring/automated and ad-hoc analysis on the dataset, without worrying about storage shares, or ETL'ing from cold storage to compute, etc. And you can sample as little as much or as much as you want. At least to us (and I've run several large distributed systems in my career), that has tremendous value, and we believe it does for others as well. And that's just one use case (log processing).
If by SAS you mean SSH, then really it's that there's a much smaller client surface area (really, openssh), and the fallback is always "use a PKCS#8 private key", which is much more uniform than SSL. SSL mixes in x509, and protocol, and UX.
That said, you don't have to agree with it. My macro point was really assessing these things against basic security threat modeling, not whether or not you agree with our choices of using SSH.
I expected something very different from this article based on the headline. Specifically, I completely disagree with the "leave it to industry standards" approach, as that doesn't help people understand what they should do, and more importantly, why.
Request/response protocols (well, many things) really break down into 5 top-level categories (some sources will say the 6th is Audit):
- Authentication
- Authorization
- Integrity
- Confidentiality
- Non-repudiation
It's a far more interesting exercise to walk through what you would get from each solution. Basic-Auth over TLS, actually gets you quite a ways towards that goal (specifically, C-I-A (authentication)). Where that, and notably HMAC, fall over is non-repudiation because they're based on a shared-secret model; admittedly HMAC keys are better than passwords because you're not sending the secret on every request, but asymmetric crypto is preferred. Authorization that the
server system does is really out of scope in all of these protocols, so Basic-Auth over TLS doesn't really impact that one. It can be as simple as "caller = owner," or as full-featured as a security policy language [1] (full disclosure: I am the original author of [1]).
OAuth really doesn't differ that much besides specifically solving the delegated access and website SSO problem(s); but IMO it does so with an overly baroque protocol that has too many parts. The "long pole" of setting up such a system (that is, allowing 3rd party sites to act on behalf of my site's users) isn't the specifics of what my REST api
looks like, but really it's all the "governance" of user decisions, and more-over, key management (in all these cases, key management is generally the hardest or almost hardest problem).
While it can be debated whether it was right or wrong, we (Joyent) released an open-source spec to solve straight up authentication of REST requests using SSH keys [2]. At the end of the day, the user signs the Date header of requests with their private key (which by definition the server has never seen), and all requests must be over TLS. Disregarding Authorization, this scheme gives you Confidentiality (TLS), Integrity (TLS), Authentication (Signature), Non-Repudiation (asymmetric signature), and adds a "poor man's nonce,"
assuming you disallow requests where the clock skew of the date header is too large. And lastly, SSH solves a lot of key management problems for humans. Note: I didn't drop that reference to advocate for our specification here, but rather the security process you should think about when evaluating whether a protocol is secure.
Mutual-Auth SSL/TLS is a royal PITA, and is basically guaranteed to cause you grief. The client compatibility matrix might as well be considered an NP hard problem to assure yourself coverage, and failure modes of the different browsers/SDKs all differ. As a REST API should
have maximum accessibility to clients (i.e., don't wed yourself to any one language/sdk), this is pretty much a non-starter.
We didn't want token-based auth (i.e, Oauth2 or openstack), nor did we want shared-secret based auth (i.e., hmac). We specifically wanted to offer authentication with public-key crypto, and as the blog post points out, the usability of client-auth SSL sucks.
So when you say it's not solving a problem that hasn't already been solved, if you're talking about "the ability to sign a request" in the most generic sense, sure, it's already been solved N times.
Generally speaking though, in most of those schemes key management is an afterthought, and we didn't want it to be an afterthought. It's been solved by SSH, and that's what we wanted to leverage.; the point was not to reinvent the wheel, the point was to leverage an existing security mechanism.