2011 NASA Open Source Summit - Forge.mil


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

2011 NASA Open Source Summit - Forge.mil

  1. 1. Forge.mil – DoD Collaborative Software Development Guy Martin, Forge.mil Community Manager [email_address] Richard Bullington-McGuire, Director, Technology [email_address] IT Innovators Award
  2. 2. Forge.mil Vision <ul><li>TODAY </li></ul><ul><li>Siloed development environments </li></ul><ul><li>Expensive and time consuming start-up </li></ul><ul><li>Limited exposure, sharing, or re-use </li></ul><ul><li>Duplication of effort </li></ul>Developer Tester User Certifier Shared Test & Development Tools/Services/Environments Shared Asset Libraries & Repositories Developer <ul><li>FORGE.mil </li></ul><ul><li>OSS best practices applied to internal projects </li></ul><ul><li>Cross-program sharing: software and services </li></ul><ul><li>Early and continuous collaboration </li></ul><ul><li>Integrated approach to development life cycle </li></ul><ul><li>Extensible platform to support delivery of partner capabilities </li></ul>
  3. 3. 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 <ul><li>Multi-Tenant Environment </li></ul><ul><li>Isolated project spaces for each customer </li></ul><ul><li>Shared infrastructure </li></ul><ul><li>Private Environment </li></ul><ul><li>Full environment dedicated to your program </li></ul>
  4. 4. 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
  5. 5. Forge.mil Key Features <ul><li>Application lifecycle management (ALM) services </li></ul><ul><li>for the DoD Enterprise </li></ul>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
  6. 6. Community Challenges <ul><ul><li>Hierarchical, process & command driven culture </li></ul></ul><ul><ul><li>Extreme risk aversion (with good reason!) </li></ul></ul><ul><ul><li>Heavy reliance on documents, in-person meetings, email </li></ul></ul><ul><ul><li>Skepticism of new processes/tools </li></ul></ul><ul><ul><li>Certification/accreditation of client-side tools (SVN, etc.) </li></ul></ul>
  7. 7. Community Lessons Learned <ul><ul><li>Government community building is a 'contact sport’ </li></ul></ul><ul><ul><li>Both ‘carrot’ (grassroots) & ‘stick’ (top-down) needed </li></ul></ul><ul><ul><li>Categorization (project, artifact, etc.) VERY important </li></ul></ul><ul><ul><li>Documentation/process socialization critical to acceptance </li></ul></ul><ul><ul><li>Platform/tool MUST tie into email (notifications) </li></ul></ul><ul><ul><li>“ You can’t forklift a revolution…” </li></ul></ul>
  8. 8. Community Lessons Learned <ul><ul><li>Don’t assume inquisitiveness </li></ul></ul><ul><ul><li>FAQ lists are important (even if not read the first time) </li></ul></ul><ul><ul><li>Seek out, support, & encourage community leaders </li></ul></ul><ul><ul><li>Grow community efforts first around existing tools/tech </li></ul></ul><ul><ul><li>Don’t be afraid to use chain of command to jumpstart things </li></ul></ul><ul><ul><li>Have realistic expectations </li></ul></ul>
  9. 9. Community Victories <ul><li>Sampling of Hosted Projects </li></ul><ul><li>Army </li></ul><ul><li>Apps 4 Army: Innovation contest to develop new ‘mashup’s of Army data </li></ul><ul><li>SOSCOE: System of Systems Common Operating Environment - tactical middleware </li></ul><ul><li>Navy </li></ul><ul><li>Gargoyle: a network activity monitoring and analysis system </li></ul><ul><li>NEP-O: Naval Enterprise Portal Oceanography – Agile process used heavily </li></ul><ul><li>Vulnerator: Aggregation of security readiness findings for systems </li></ul><ul><li>Air Force </li></ul><ul><li>AF EIM: code supporting Air Force’s Enterprise Information Management </li></ul><ul><li>UAS TSPI Server: a common network interface to multiple UAS ground-stations for sensors requiring real-time telemetry source </li></ul><ul><li>Marine Corps </li></ul><ul><li>DCGS-MC: Distributed Common Ground/Surface System – Marine Corps </li></ul><ul><li>MAGTF C2: Marine Air Ground Task Force Command and Control </li></ul><ul><li>Joint Chiefs & DISA </li></ul><ul><li>NSLDSS: National Senior Leadership Decision Support Service </li></ul><ul><li>DIB: Distributed Common Ground/Surface System (DCGS) Integration Backbone </li></ul><ul><li>CommunityCAC: CAC Utilities/Firefox plugin </li></ul><ul><li>DODBastille: RHEL STIG lockdown utilities </li></ul><ul><li>Initial Forge.mil capability (April 2009) supporting collaborative software development & reuse </li></ul><ul><li>Today (March 2011) </li></ul><ul><li>Over 2700 software releases available </li></ul><ul><li>~47,000 software releases downloaded </li></ul><ul><li>Over 36,000 bugs/requirements tracked </li></ul><ul><li>Over 39,000 code checkins </li></ul><ul><li>Over 3500 discussion posts </li></ul><ul><li>~ $160M in software asset reuse ROI </li></ul>Mar 26
  10. 10. 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
  11. 11. First Challenge: Secure it Fast * <ul><ul><li>Implementation effort began on Nov. 10, 2008 </li></ul></ul><ul><ul><li>First fielded in production (LOA) on Jan 23, 2009 (< 90 days) </li></ul></ul><ul><ul><li>Biggest Roadblock: Security </li></ul></ul><ul><ul><ul><li>Application Security and Development STIG Requires: </li></ul></ul></ul><ul><ul><ul><ul><li>PKI User Authentication </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Support both soft cert and CAC hardware token </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Clients: Web browser, Subversion, and SOAP API </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Encrypt system passwords at rest (including database user names and passwords) </li></ul></ul></ul></ul><ul><ul><li>Solution: Extend open source elements of software stack </li></ul></ul>
  12. 12. Forge.Mil Internal Architecture * Key Concepts and Architecture <ul><ul><li>CollabNet TeamForge 5.x on Red Hat Enterprise Linux 5.x </li></ul></ul><ul><ul><li>Open Source foundations: Apache HTTP Server, mod_ssl, mod_python, JBoss, Tomcat, Subversion, Lucene, Apache James, PostgreSQL </li></ul></ul><ul><ul><li>Key insight: extend security features by building on the open source components below CTF using Python and Java modules </li></ul></ul><ul><ul><li>Key insight: enable CAC token authentication in Subversion clients by extending and distributing new client binaries </li></ul></ul>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)
  13. 13. Consuming Open Source * <ul><ul><li>Server-side: </li></ul></ul><ul><ul><ul><li>All custom extensions and amendments built on software shipped with RHEL 5. Goal: keep system as vanilla as possible. Use RPM for packaging extensions. </li></ul></ul></ul><ul><ul><ul><li>PKI enablement required updating stock mod_python with newer version, and writing user mapping logic tied to SSL </li></ul></ul></ul><ul><ul><ul><li>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 </li></ul></ul></ul><ul><ul><li>Client-side: </li></ul></ul><ul><ul><ul><li>CAC-enabled Subversion with TortoiseSVN 1.5.5 </li></ul></ul></ul>
  14. 14. Producing Open Source * <ul><ul><li>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) </li></ul></ul><ul><ul><ul><li>We developed and distributed: </li></ul></ul></ul><ul><ul><ul><ul><li>A working Windows CLI svn client with CAC support </li></ul></ul></ul></ul><ul><ul><ul><ul><li>A modified Subclipse client with CAC support </li></ul></ul></ul></ul><ul><ul><ul><ul><li>A cross-platform Java SVN client with CAC support </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Updated versions of TortoiseSVN with CAC support </li></ul></ul></ul></ul><ul><ul><li>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) </li></ul></ul>
  15. 15. Achieving Mission Success Fast * <ul><ul><li>We would not have been able to field this service so quickly without both producing and consuming open source software </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>We focused on using OSS to solve real security issues, and worked within the DoD certification & accreditation process </li></ul></ul><ul><ul><li>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) </li></ul></ul>
  17. 17. 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
  18. 18. Policy and Guidance <ul><li>HR 2647, National Defense Authorization Act for Fiscal Year 2010, Sec. 804. </li></ul><ul><li>“ 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 — </li></ul><ul><li>. . . 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 </li></ul><ul><li>. . . be designed to include — </li></ul><ul><ul><li>early and continual involvement of the user; </li></ul></ul><ul><ul><li>multiple, rapidly executed increments or releases of capability; </li></ul></ul><ul><ul><li>early, successive prototyping to support an evolutionary approach; and </li></ul></ul><ul><ul><li>a modular, open-systems approach.” </li></ul></ul>
  19. 19. Benefits of Using Forge.mil Forge.mil reduces administrative costs, increases productivity, and improves visibility. Key benefits include: FOR DEVELOPERS FOR MANAGERS FOR EXECUTIVES <ul><li>Access a full featured development platform over the web or directly from your IDE </li></ul><ul><li>Have fewer meetings and less administration when collaboration is part of everyday development </li></ul><ul><li>Link to continuous integration servers and provision build and test servers in the cloud whenever you need them </li></ul><ul><li>Speed new project startup </li></ul><ul><li>Secure access to project assets </li></ul><ul><li>Enhance team productivity and collaboration </li></ul><ul><li>Improve visibility into project status </li></ul><ul><li>Reduce management and administrative overhead </li></ul><ul><li>Access critical team assets via the web or your Microsoft Windows desktop </li></ul><ul><li>Consolidate and centralize to reduce administration, licensing, and infrastructure costs </li></ul><ul><li>Establish governance and regulatory compliance </li></ul><ul><li>Improve predictability of the development organization </li></ul><ul><li>Integrate easily into existing systems to extend return on investments </li></ul>
  20. 20. 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 <ul><li>mod_python </li></ul><ul><li>sfauth (svn auth) </li></ul><ul><li>sf_sso </li></ul><ul><li>looks up cert->user mappings in SSO db </li></ul><ul><li>sf_pki </li></ul><ul><li>calls TeamForge login() method via SOAP using master password, redirects user through alternate login path accepting username + session ID </li></ul><ul><li>JBoss </li></ul><ul><li>On App server only </li></ul><ul><li>Web Rendering </li></ul><ul><li>SOAP Server </li></ul><ul><li>JAAS module: masterpassword.jar </li></ul><ul><li>Tomcat </li></ul><ul><li>James Mail </li></ul><ul><li>Lucene Indexes </li></ul><ul><li>SCM viewer (on integration server) </li></ul>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 <ul><li>Client Software </li></ul><ul><li>Web browsers (IE, Firefox) </li></ul><ul><li>Subversion clients (DAV over https) </li></ul><ul><li>Custom SOAP clients </li></ul><ul><li>All must use client cert auth. </li></ul>http proxy + SOAP Server -> Database PostgreSQL / TCP 5432 JBOSS -> Tomcat Java RMI PKE changes to baseline are listed in italics
  21. 21. Ongoing Challenges & Opportunities * <ul><ul><li>Is Forge.mil the One True Path for DoD software development? </li></ul></ul><ul><ul><ul><li>Walled garden protected by CAC & ECA certificates is a disincentive to public participation. However, public participation is not the primary function of Forge.mil. </li></ul></ul></ul><ul><ul><ul><li>Forge.mil is trying to solve the internal collaboration problems within the DoD using OSS methodologies. </li></ul></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul><ul><ul><li>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. </li></ul></ul>