Tuesday, September 21, 2010

Wave in a Box (WIAB) and FedWave

This is a cross-post from my blog on the Military Social Networking system milBook

On 2 September 2010, Google announced the way ahead for the open source version of Google Wave, now called Wave in a Box (WIAB).

Here is a quick summary of features for WIAB from that announcement:
  • An application bundle including a server and web client supporting real-time collaboration using the same structured conversations as the Google Wave system
  • A fast and fully-featured wave panel in the web client with complete support for threaded conversations
  • A persistent wave store and search implementation for the server (building on contributed patches to implement a MongoDB store)
  • Refinements to the client-server protocols
  • Gadget, robot and data API support
  • Support for importing wave data from wave.google.com
  • The ability to federate across other Wave in a Box instances, with some additional configuration
The implications of this for the fledgling Federal Wave (FedWave) project are still being examined, but this could be a significant shortening of the way for this project.

I have been in contact with the Google team working WIAB, and below is a list of non-functional requirements provided to them that relate to the FedWave project. The requirements and the following response from Joseph Gentle (Google) were posted to the forum (list) on the Google Group for the Wave Protocol here:

1. CAC enabled (Government Smart Card w/ Certificates):
2. Army Knowledge Online (AKO) and Active Directory authentication:

These should be quite easy to implement.

The planned authentication system has 2 parts: An authenticator, which provides the client with a signed token, and a verifier, which verifies the validity of the token. I'm looking at using an RSA key pair to generate & sign the tokens. The verifier will be bolted deeply in fedone. For this, what we need is multiple authenticator implementations. Each implementation needs a copy of the signing key,
and a way to talk to the client (to authenticate it, and if its authenticated give it a token).

The first implementation of that will be a simple password check. I don't know anything about LDAP or smart cards. But it will be quite easy for someone who does know that stuff to hook it up.

3. Usable with mobile clients (iPad, iPhone, Android)

There are projects to make native clients for ipad, iphone and android. Others on this list will know more.

4. Automated installation/ Operation on Windows and Linux Servers:

The plan is for a totally hands-free installation that does everything except for federation. Federation will require a TLS certificate signed by a trusted party and an XMPP server (which could be bundled). We haven't looked in depth at making an installer. I imagine its not too difficult. Maybe someone on this list can help us out here?

5. Security/ Standards:
a. Encryption: Client-Server (SSL) and Server-Server (PKI): The ability to protect data in transit is important.

Tick. The client-server protocol will use SSL with a signed certificate. The server-server communication is authenticated as well, though I don't know the details there.

b. Authorization: once authenticated, users should only be able to access authorized waves/wavelets/blips. This would probably be done using the authentication system in some manner.

Yes. Not done yet, but it will.

c. No use of Google Web Tools (GWT)or other unapproved code: Don't take this the wrong way, but many of the Government security types are totally set against anything that uses GWT. They contend it obfuscates the underlying code and could be an attack vector into the system.

This is a hard one. At the moment the entire web client is written using GWT. We plan to make splash (a lightweight non-gwt client) work with fedone, though live typing doesn't work in splash. (There will be a lot of work to make this happen).

If this is super important to you guys, it might be worth making a native wave client, or waiting until native wave clients are made by 3rd parties.

d. Servers with full STIG (Security Technical Implementation Guides): STIGs are just settings on the server that lock down specific ports, protocols, and portions of the system in question for maximum security. They can cause things to not work, but have to be followed as much as possible or exceptions must be sought.

I don't know what that is, but making a document detailing which ports need to be open and whatnot should be easy to write.

e. Use approved Federal Government XMPP

There's no presence / XMPP-based chat support in WIAB. This is surprisingly difficult to implement.

6. Full code review/ test throughout development: This is more of a going-forward concept, but it is important from a security standpoint to make sure no "sleeper" code gets onto Government networks.

Pre-commit code reviews are standard google practice. We are doing code review for all new code added to fedone.

Fedone (and hence wave-in-a-box) code reviews take place here:

7. Full Presence/ Awareness (XMPP):
8. Email integration (in and out):
9. Embed waves in portal pages:

None of these things are planned for v1.0 of wave-in-a-box. I think they're all important, but not critical to having a working product.

10. Robust Search: The ability to search through waves and across federated servers for keywords and tags is important.

Search will work, but there's no current plan to make full-text search work across federated servers. (You will be able to search any wave that you have been added to explicitly, but public waves hosted on other servers won't appear in your search results).

11. Archive/ persistence of waves:

This will be done. Further, all operations are signed in the database(so archives will be tamper proof).

Thanks to Joseph for responding to my post. He has been very helpful. If there are other non-functional requirements I missed, please post a comment and I will add them to the list.

There was an office hours session with the Google WIAB team on 15 September 2010 and there was a lot of good information shared. They are making steady progress on the code, but there are still a lot of things the team has left to accomplish, including authentication, among others.

Informational Links:
The Google Group for the Wave Protocol is here.
The 20 Sep 2010 WIAB Status Report is here.
The WIAB task list is here.
The list of starter projects is here.

All the documentation has been consolidated on the Google Wave Federation Protocol site.

Note: many of the URLs in this post require a Google login and group membership to access.

The next step for FedWave is to install a working model of the FedOne server, so that WIAB updates can be deployed as development goes forward. I will be blogging that on milBook as I do the installation.

Thanks for your patience as I have assembled this post. I look forward to your comments and questions.

No comments:

Post a Comment