Trans-enterprise Service Grid (TSG) Active Interoperability Across Independent Partners

1. Trans-enterprise Service Grid (TSG)Active Interoperability AcrossIndependent Partners David E. Ellis Information Management Architect (505) 844-6697, dellis@sandia.gov

2. Interoperability Challenge • There are situations requiring cross enterprise messaging • Many current architectures discuss message exchanges in terms of a single enterprise • SOA benefits from its ability to cross ownership boundaries • Federal • Regional • State • Local • Tribal • Crossing ownership boundaries must accommodate both • Technical aspects: syntax, semantics • Policy aspects: access control, security, … to be interoperable • Interoperability among diverse participants requires a prearranged groundwork for communications and understanding supporting: • Different policy and security contexts • Incremental addition of services and participants • Resource multiplier when adding another stakeholder

3. IPAWS Example • IPAWS as example of cross enterprise challenge • Integrated Public Alert and Warning System • Coordination between independent entities • “Component” systems separately owned and governed • Each component provides messaging capabilities but each originally exists with different purposes and goals • Each entity must fulfill its coordinated role in context of its “usual” purpose • Not possible to centrally coordinate all details of operations • Accommodate current system status, including degraded operations • Requires Geo-Targeting of message delivery • Requires non-repudiation of message content

4. IPAWS Connecting Communities Federal Agencies Satellite and IP Network SPOR SPOR SPOR SPOR Local EOC IPAWS Alert Aggregation Radio SPOR SPOR SPOR State EOC Television Mobile IPAWS Coordination Center Commercial Mobile Services

5. IPAWS Connecting Communities How do we connect such an independent, distributed set of resources? Federal Agencies Satellite and IP Network SPOR SPOR SPOR SPOR Local EOC IPAWS Alert Aggregation Radio SPOR SPOR SPOR State EOC Television Mobile IPAWS Coordination Center Commercial Mobile Services

6. Coordinating SOA Services: Choreography vs. Orchestration • Difference between active, central control and adaptive coordination • Orchestra versus Ballet • In orchestration, there’s someone — the conductor — who tells everybody in the orchestra what to do and makes sure they all play in synchronization • Conductor is an active leader • Corrects for anomalies in real-time • Can introduce new information only he has • In choreography, every dancer follows a pre-defined plan — everyone independently of the others • Choreographer coordinates plan but not part of execution • Each participant responsible for adaptive behavior for anomaly response • Message exchange must contain all state information needed to evaluate next action

7. IPAWS Trans-enterprise Services Grid (TSG) • Specific SOA implementation to enable multi-jurisdictional government interoperability • Built on existing and evolving standards • Uses OASIS Emergency Data Exchange Language – Distribution Element (EDXL-DE) for distribution metadata which: • Carries arbitrary Document-Oriented Message content payload • Encapsulates Policy and other context for distribution Choreography • Uses OASIS Common Alerting Protocol (CAP) as alert content standard • Leverages current work on OASIS Service Oriented Architecture - Reference Architecture (SOA-RA)

8. IPAWS Node Terminology - Diverse Scope • IPAWS node • a node that produces, processes, and/or consumes IPAWS content • May reside inside or outside of grid (TSG) trust boundary • Secure Policy-oriented Object Routers (SPORs) • a special IPAWS node that process/forwards EDXL-DE content not explicitly addressed to itself • Edge SPOR is a special node which has bridges between TSG and external interfaces • Core SPOR is a general purpose router with internal TSG capabilities • High Assurance SPOR (HA-SPOR) – a SPOR which uses cryptographic protection to eliminate host Operating System and application exploitation processes • IPAWS host • any node that is not a SPOR but connects to the TSG via a SPOR • Stakeholder nodes which produce or consume IPAWS content • IPAWS communications terminology • IPAWS link – a communication facility or medium which delivers IPAWS content either within the TSG or across the TSG trust boundary • IPAWS neighbors – nodes attached to the same link • IPAWS interface – a node’s attachment to a link

9. Mapping Service Reverse 911 Service DHS/WARN Service SPOR SPOR SPOR IPAWS Workstation IPAWS Workstation SPOR SPOR Broker Tone Alert Tone Alert Internet IPAWS National TSG Protected External Service State EOC Commercial Service Providers Federal EOC TSG = Trans-enterprise Service Grid

10. IPAWS and Choreography • IPAWS requires adaptive coordination of independent entities within bounds of agreed upon actions and objectives • Identity to ensure non-repudiation follows guidance by Trust Council for Communities Of Interest (COIs) • Roles defined by Trust Council must be associated with participants • Messages must be self-contained, including associated role identity • MOU and SLA State attributes are also included as needed by COIs to allow message exchange with other COIs by TSG policy enforcement points

11. IPAWS (TSG) – Client Trust model Proposed SPOR Communications Diagram Needs to generate an Alert Message HTTPS IdentityAgent 4. EDXL-DE + Creds 6. TrustAgent EDXL-DE + SessionID HTTPS FORM HTTPS POST 8. 3. 5. 9. EOC Web Browser LocalIdentity Store 7. HTTPS + Cookie 1. HTTPS EDXL-DE + HTTP Req + Role(s) HTTPSProxyAgent EDXL-DE + HTTP Req 12. HTTPS Redirect 13. 2. 11. 10. GatewayAgent TSG HTTPS + Cookie EDXL-DE + HTTP Resp HTTPS Response 15. 14. EDXL-DE + HTTP Resp + Role(s) 16.

12. Mapping Service HTTPS HTTPS HTTPS Reverse 911 Service DHS/WARN Service SPOR SPOR SPOR IPAWS Workstation IPAWS Workstation SPOR SPOR Broker Tone Alert Tone Alert CAP Message Internet Alert IPAWS National TSG Alert Protected External Service State EOC Alert Commercial Service Providers Unprotected Msg Protected (EDXL) Federal EOC

13. Status of TSG and future work • OASIS standards are being improved to enable cross enterprise messaging • OASIS SOA Reference Architecture is addressing governance and policy management. • OASIS Emergency Management Technical Committee is developing a next version of EDXL-DE to deliver state information into metadata for policy assertions like security • W3C working on Addressing, Policy, Choreography specs • IPAWS Pilot is underway to address issues like • Jurisdictional constraints for emergency messaging • Usability of OASIS and other international Standards • Scalability of TSG Grid concept • Performance limitation of HA-SPOR • Pilot feedback will be shared with appropriate agency and standards organizations to improve cross enterprise messaging

14. Summary - Conclusions • Cross enterprise messaging is a concern for eGov initiatives • Standards organizations are developing standards to address this concern • Service Oriented Architecture • Data Exchange Language using XML • IPAWS will help frame the solution space • Other eGov initiatives could use TSG capability