2011 NASA Open Source Summit - Forge.mil

Forge.mil – DoD Collaborative Software Development Guy Martin, Forge.mil Community Manager [email_address] Richard Bullington-McGuire, Director, Technology [email_address] IT Innovators Award

Forge.mil Vision
TODAY
Siloed development environments
Expensive and time consuming start-up
Limited exposure, sharing, or re-use
Duplication of effort
Developer Tester User Certifier Shared Test & Development Tools/Services/Environments Shared Asset Libraries & Repositories Developer
FORGE.mil
OSS best practices applied to internal projects
Cross-program sharing: software and services
Early and continuous collaboration
Integrated approach to development life cycle
Extensible platform to support delivery of partner capabilities

Forge.mil Services Free, collaborative development environment for internal open-source and DoD community source software On-demand, fee-for-service development environment for individual internal programs and projects
Multi-Tenant Environment
Isolated project spaces for each customer
Shared infrastructure
Private Environment
Full environment dedicated to your program

Forge.mil Community Approach DOD Acquisition Community DOD Test and Evaluation Community DOD IA Community DOD NETOPS Community DOD Development Community Government, Industry & Academia Collaborative Development & Test Note: Forge.mil != DoD & External OSS Community

Forge.mil Key Features
Application lifecycle management (ALM) services
for the DoD Enterprise
Requirements management Source code management Discussion forums Project wiki Document management Project management for distributed development teams Tasking & alerts Release management Real-time reporting Software development services Bug, Issue Tracking Share software, best practices, information

Community Challenges
Hierarchical, process & command driven culture
Extreme risk aversion (with good reason!)
Heavy reliance on documents, in-person meetings, email
Skepticism of new processes/tools
Certification/accreditation of client-side tools (SVN, etc.)

Community Lessons Learned
Government community building is a 'contact sport’
Both ‘carrot’ (grassroots) & ‘stick’ (top-down) needed
Categorization (project, artifact, etc.) VERY important
Documentation/process socialization critical to acceptance
Platform/tool MUST tie into email (notifications)
“ You can’t forklift a revolution…”

Community Lessons Learned
Don’t assume inquisitiveness
FAQ lists are important (even if not read the first time)
Seek out, support, & encourage community leaders
Grow community efforts first around existing tools/tech
Don’t be afraid to use chain of command to jumpstart things
Have realistic expectations

Community Victories
Sampling of Hosted Projects
Army
Apps 4 Army: Innovation contest to develop new ‘mashup’s of Army data
SOSCOE: System of Systems Common Operating Environment - tactical middleware
Navy
Gargoyle: a network activity monitoring and analysis system
NEP-O: Naval Enterprise Portal Oceanography – Agile process used heavily
Vulnerator: Aggregation of security readiness findings for systems
Air Force
AF EIM: code supporting Air Force’s Enterprise Information Management
UAS TSPI Server: a common network interface to multiple UAS ground-stations for sensors requiring real-time telemetry source
Marine Corps
DCGS-MC: Distributed Common Ground/Surface System – Marine Corps
MAGTF C2: Marine Air Ground Task Force Command and Control
Joint Chiefs & DISA
NSLDSS: National Senior Leadership Decision Support Service
DIB: Distributed Common Ground/Surface System (DCGS) Integration Backbone
CommunityCAC: CAC Utilities/Firefox plugin
DODBastille: RHEL STIG lockdown utilities
Initial Forge.mil capability (April 2009) supporting collaborative software development & reuse
Today (March 2011)
Over 2700 software releases available
~47,000 software releases downloaded
Over 36,000 bugs/requirements tracked
Over 39,000 code checkins
Over 3500 discussion posts
~ $160M in software asset reuse ROI
Mar 26

Forge.mil Implementation: Open Source Enabled Agility How we achieved our mission by both producing and consuming Open Source Software (while moving at a very rapid pace) Disclaimer: These implementation notes reflect the experiences and opinions of the author, Richard Bullington-McGuire, the architect for the initial implementation phase of Forge.mil, and do not represent DISA’s official positions Slides following marked with a “*” are contributed by Richard Bullington-McGuire

First Challenge: Secure it Fast *
Implementation effort began on Nov. 10, 2008
First fielded in production (LOA) on Jan 23, 2009 (< 90 days)
Biggest Roadblock: Security
Application Security and Development STIG Requires:
PKI User Authentication
Support both soft cert and CAC hardware token
Clients: Web browser, Subversion, and SOAP API
Encrypt system passwords at rest (including database user names and passwords)
Solution: Extend open source elements of software stack

Forge.Mil Internal Architecture * Key Concepts and Architecture
CollabNet TeamForge 5.x on Red Hat Enterprise Linux 5.x
Open Source foundations: Apache HTTP Server, mod_ssl, mod_python, JBoss, Tomcat, Subversion, Lucene, Apache James, PostgreSQL
Key insight: extend security features by building on the open source components below CTF using Python and Java modules
Key insight: enable CAC token authentication in Subversion clients by extending and distributing new client binaries
Deployment Architecture software.forge.mil Application Server svn.forge.mil Integration Server Single Sign On (SSO) Database Application Database Forge.mil User With x509 Client Certificate (CAC/ECA)

Consuming Open Source *
Server-side:
All custom extensions and amendments built on software shipped with RHEL 5. Goal: keep system as vanilla as possible. Use RPM for packaging extensions.
PKI enablement required updating stock mod_python with newer version, and writing user mapping logic tied to SSL
Secure password storage required the m2crypto library for the mod_python extension layers, and extending JBoss with a module for reading the encrypted passwords using a key stored on a RAM disk. Password encryption functions : m2secret
Client-side:
CAC-enabled Subversion with TortoiseSVN 1.5.5

Producing Open Source *
Main Roadblock: lack of hardware token support in SVN clients. Only TortoiseSVN 1.5.5 had support for hardware token authentication with the CAC (we redistributed it)
We developed and distributed:
A working Windows CLI svn client with CAC support
A modified Subclipse client with CAC support
A cross-platform Java SVN client with CAC support
Updated versions of TortoiseSVN with CAC support
These efforts helped inspire broader support for hardware token-driven SVN clients (see the latest releases of: CollabNet Desktop for Eclipse and Visual Studio, which support hardware tokens)

Achieving Mission Success Fast *
We would not have been able to field this service so quickly without both producing and consuming open source software
Leveraging Open Source let our small team make architecture-level tweaks to vendor-supplied software stacks that would have taken the vendors much longer to make
We focused on using OSS to solve real security issues, and worked within the DoD certification & accreditation process
Licensing: we produced & consumed the software under the original terms of the various licenses (no new licenses introduced, no artificial hurdles in the reasonable distribution of software we modified under existing licenses)

BACKUP SLIDES

Upcoming Capabilities: Full Application Life-cycle Support Development Zone Validation/ Pre-Production Zone Dashboard, Reporting & Monitoring Build Libraries & Code Repositories Production Zone Agile Software Development Unit, Integration & Regression Testing Static Code Analysis System Testing IA Certification IT & Data Standards Today Release & Operations Management Q2 11 Q4 10 Q4 11 Q4 12 Cloud Hosting Environment

Policy and Guidance
HR 2647, National Defense Authorization Act for Fiscal Year 2010, Sec. 804.
“ The Secretary of Defense shall develop and implement a new acquisition process for information technology systems. The acquisition process developed and implemented pursuant to this subsection shall, to the extent determined appropriate by the Secretary —
. . . be based on the recommendations in chapter 6 of the March 2009 report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology; and
. . . be designed to include —
early and continual involvement of the user;
multiple, rapidly executed increments or releases of capability;
early, successive prototyping to support an evolutionary approach; and
a modular, open-systems approach.”

Benefits of Using Forge.mil Forge.mil reduces administrative costs, increases productivity, and improves visibility. Key benefits include: FOR DEVELOPERS FOR MANAGERS FOR EXECUTIVES
Access a full featured development platform over the web or directly from your IDE
Have fewer meetings and less administration when collaboration is part of everyday development
Link to continuous integration servers and provision build and test servers in the cloud whenever you need them
Speed new project startup
Secure access to project assets
Enhance team productivity and collaboration
Improve visibility into project status
Reduce management and administrative overhead
Access critical team assets via the web or your Microsoft Windows desktop
Consolidate and centralize to reduce administration, licensing, and infrastructure costs
Establish governance and regulatory compliance
Improve predictability of the development organization
Integrate easily into existing systems to extend return on investments

Forge.mil PKE changes: HTTPD modules * Application Database Single Sign On (SSO) Database software.forge.mil / svn.forge.mil Application Server or Integration Server Red Hat Enterprise Linux 5 Vmware ESXi
mod_python
sfauth (svn auth)
sf_sso
looks up cert->user mappings in SSO db
sf_pki
calls TeamForge login() method via SOAP using master password, redirects user through alternate login path accepting username + session ID
JBoss
On App server only
Web Rendering
SOAP Server
JAAS module: masterpassword.jar
Tomcat
James Mail
Lucene Indexes
SCM viewer (on integration server)
PostgreSQL 8.2 Databases On Separate RHEL 5 VMs Apache HTTPD Forge.mil User Service w/ x509 Server Cert, Reused as Client Cert Client -> Server https / TCP 443
Client Software
Web browsers (IE, Firefox)
Subversion clients (DAV over https)
Custom SOAP clients
All must use client cert auth.
http proxy + SOAP Server -> Database PostgreSQL / TCP 5432 JBOSS -> Tomcat Java RMI PKE changes to baseline are listed in italics

Ongoing Challenges & Opportunities *
Is Forge.mil the One True Path for DoD software development?
Walled garden protected by CAC & ECA certificates is a disincentive to public participation. However, public participation is not the primary function of Forge.mil.
Forge.mil is trying to solve the internal collaboration problems within the DoD using OSS methodologies.
Not every project (Open Source or otherwise) will be a good fit for Forge.mil, but many projects will be a fit that would not be a good fit for a more public repository.
Having this service available has helped shape the ongoing community discussion about what normative behavior should be regarding producing and consuming Open Source in the context of DoD projects.

2011 NASA Open Source Summit - Forge.mil

by NASA Open Government Initiative on Mar 29, 2011

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 74

Statistics

2011 NASA Open Source Summit - Forge.mil Presentation Transcript

http://gov20.govfresh.com	67
http://lanyrd.com	7