Mashed Articles

Google is bringing two-factor authentication to the masses: the Google Authenticator project. This is an open source implementation of pluggable authentication modules (PAM) and one time password generators for mobile devices.

One time password (OTP) are often small dongles. RSA, Vasco and Yubico are well known vendor of this hardware (with RSA getting hacked recently).

Google itself has two-step authentication already for a while. The two-step authentication uses an SMS of voice call to send an 6 digit code. For a while now, Google is using the one time password generators on mobile devices itself (although I can’t get it working for my own Google account).

Also other are adopting it, e.g. Lastpass is also supporting Google authenticator. To be clear, Google is not used for the actual authentication, only the (open source) implementation of Google is used.

Triggered by the upcoming Devoxx conference, I did some reading last weekend. With Fri Nov 11 as a national holiday in Belgium – because of the end of World War I – I had some extra time. Looked a bit into most recent development around HTML 5 and Android development.

Quickly I ended up diving deeper into REST. Must confess that I was very WS-* minded and was not really impressed by REST initially. But with the incompleteness of WS-* and the success of REST, I’m changing my mind.

So I ended up browsing through the book “Restful Java with JAX-RS“. This REST stuff triggered me into looking into different REST API’s, including the one from Dropbox. And Dropbox security is based on OAuth, which triggered me to dive (back) into OAuth.

Looked for an OAuth book on Safari and Amazon, but none (yet?) avaialble. So I ended up re-reading chapter 9 of the the book “REST in practice“. By the way, very good book, I like it. Some great links while looking around:
- The introduction on OAuth
- Good OAuth introduction by Yahoo
- Google Oauth Playground, so see OAuth live in action

While looking into OAuth, I started making the comparison with WS-Security and SAML in particular. With OAuth, no XML signing nor XML canonicalization, the option to use HMAC instead of keypairs and certificates. So simpler, but not simple!

Note: one of my I8C colleagues (Kim) just finished a project on DataPower appliance to implement OAuth support

The new Google SPDY protocol is another attempt to make the web more efficient and reliable. The SPDY protocol introduces an extra layer between HTTP and TCP/IP (actually SSL/TLS) that primarily allows for multiplexing and parallelizing multiple HTTP requests over a single SSL connection.

The SPDY protocol is not some lab exercise but used in production! The Google Chrome browser uses the SPDY protocol (or should we say extension?) to communicate with most Google’s applications. SPDY remains mostly a Google thing, with no adoption by other big companies (except for Amazon EC2 it seems).

With SPDY, the Chromium browser needs to establish fewer SSL connections. But more importantly, the Chrome browser can launch many HTTP requests in parallel, no longer restricted by a maximum number of TCP/IP connections.

But this made me think: could this have a positive impact on how service consumers are implemented? Similarly to a browser parallizing the retrieval of web content, (web) service consumers should also try to parallize as much as possible.

The HTTP request/response model that underlies web services should not lock us into a synchronous RPC paradigm wherey a requestor blocks waiting for a response. To fully leverage this potential of parallellism, we must move to non-blocking, AJAX like model programming model.

While reading about SPDY, I encountered 2 links worth looking into:
- Recent blog entry by F5 that is a critical review of the SPDY protocol.
- Article that starts with SPDY but goes much further into wild (?) and interesting ideas to re-engineer the workings of the Internet in a more dramatic.