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:
http://codereview.waveprotocol.org/

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.

Forge.mil: The Government Version of SourceForge

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

The US Federal Government has created a family of services to support technology development in the Department of Defense (DoD) called forge.mil. According to the site, forge.mil is a collaborative environment to accelerate the development and deployment of dependable software and services within DoD.

Much of this post will be based on an overview presentation available on the site titled "Forge 101: An Introduction to Forge.mil".

The Forge.mil Vision is to enable the rapid development, test, certification, deployment and acceptance of new products and services on the Global Information Grid (GIG) by providing policies, processes, tools and a federated development and test infrastructure. Forge.mil is intended to provide a collaborative environment for developers, testers, Warfighters and other stakeholders for the rapid development, testing, certification and deployment of software.

Top level support for this idea is starting to take shape. In the National Defense Authorization Act for FY2010, Congress has called for the DoD to ‘develop and implement a new acquisition process for information technology systems’ – one designed and based on early and continual user involvement, rapidly executed incremental capability, early prototyping and open systems. The Forge.mil environment is perfectly suited to meet these goals.

To build a toolset, Forge.mil initially focused on the development community.  Software developers were the ones least likely to be involved in the ongoing program management and software acquisition process. The capability that exists in Forge.mil today is centered on software development, software version control, code management, and release management. The core product Forge.mil is built on is CollabNet TeamForge.

There are two types of tools in Forge.mil today:

1. Development Tools (Source Code Management, Trackers for Requirements, Bugs or Issues, Change Requests, File Release Management, Task Management and Real-time Reporting
2. Communication Tools (Project wiki pages, Discussion Forums and Document Management)

One of the greatest features this set of tools provides is the ability to relate software builds with the requirements met or bugs fixed in each of these builds.  The ability to associate artifacts within the same tool set allows users to associate:

•  A Document with a task (create training manual by a certain date)
•  A Tracker with a discussion post (a user requirement that needs clarification)
•  A File commit with a bug tracker or requirement tracker (commit new code that fixes a bug or fulfills a requirement)

Artifacts – documents, requirements and bug trackers, software builds and releases – are visible and accessible to the test community, the IA community and other program and project stakeholders.  This visibility and availability of program information is key to successfully working with distributed teams.

Forge.mil is available to U.S. military, DoD government civilians and DoD contractors for Government authorized use. Access to Forge.mil requires a valid DoD Common Access Card (CAC) or a PKI certificate issued by a DoD approved External Certificate Authority (ECA) with a DoD government sponsor.

The first offering launched in April 2009 was SoftwareForge.  The goal for SoftwareForge was to model the best of the open source communities in terms of doing collaborative development and bring that into the DoD by offering the same set of capabilities and enable the same set of approaches that have been driving successful open source projects. SoftwareForge enables the collaborative development and distribution of open source software and DoD community source software.

After SoftwareForge rolled out, there were project teams stating they had a need for the same toolset for projects and teams that were unable to operate in the open.  They wanted the same tools in a private project space.  ProjectForge provides the same application life cycle management tools to DoD projects and programs as SoftwareForge, but for projects that are not doing DoD community source development and/or need to restrict access to specific project members.

The following criteria are used by the community/project review committee when determining whether a project is appropriate for the SoftwareForge site: Project has an Open Source or DoD Community Source license Project is not a ‘fork’ OR a 'mirror' of an existing external Open Source project If a fork is required (e.g. - security reasons), will be evaluated case by case Project must accept ‘DoD internal public/open’ view permission Project must be willing to consider contributions (code, docs, patches, etc.) from participants outside of their team Project should not be a duplicate of an existing project on the site The goal of the project adjudication process is not to deny or make it difficult for new projects to be created. Ideally, if the new project criteria are adhered to, project approval can be done in less than 48 hours (depending on the number of requests in the new project queue). This process is designed to ensure the usefulness of SoftwareForge for both developers and consumers of software.

The plan currently is to use this for the FedWave development effort, if other conditions are met (Sponsorship, approval, etc.).

I believe this is an exciting advance in Government software development and should be very beneficial. As always, the opinions expressed here are strictly my own, and I welcome your comments.