1. 1 SensorWebs and Security Experiences Dan Mandl Presented at WGISS Meeting in Toulouse, France May 11, 2009

2. 2 Definition Web Service – from Wikipedia W3C compliant software system designed to support interoperable machin-to- machine interaction over a network It communicates over the HTTP protocol used on the Web and falls generally into two categories Simple Object Access Protocol (SOAP)/Web Service Design Language (WSDL) Representational State Transfer (REST)-ful Both need to be supported, but our preference up to this point is RESTful Web Services to reduce implementation and operations costs

3. Key Implementation Challenges Web Processing Service (WPS) Web Coverage Service (WCS) Sensor Planning Service (SPS) Organization Orchestrating Workflow 1 1 2 2 3 3 Secure transactions Delegation Single sign on

4. 4 Scope Web Services need to be accessible from an Open Network but are not necessarily on the NASA network They are used to access data and/or assets in a bi-directional manner They may need to communicate with many communities on a permanent or temporary basis (e.g. disaster management) Some data to exchanged may Be mostly public Be restricted for dissemination for a specified time period (e.g no distribution rights for 60 days) Have license agreements Web security protocol needs to be easy to implement since many user will have low IT capability Target Web 2.0 mass market Implementable in less than a half a day Leverage existing Web 2.0 standards to lower cost and more easily gain acceptance

5. SensorWeb High Level Architecture L1G SOS WFS SPS SAS SOS WFS SPS SAS Sensor Planning Service (SPS) Sensor Alert Service (SAS) Sensor Observation Service (SOS) Web Feature Service (WFS) SensorML Capabilities Documents Satellite Data Node EO-1 Satellite In-situ Sensor Data Node UAV Sensor Data Node SensorML Satellite sensor data product Web Processing Service (WPS) Web Coverage Service (WCS) Web Coordinate Transformation Service (WCTS) SensorML Capabilities Documents Data Processing Node Internet Sensor Data Products OpenID 2.0 RSS Feeds floods, fires, volcanoes etc Campaign Manager Workflow s

6. 6 Goal is to visualize available satellite data and possible future satellite data in an area of interest and a desired time span on Google Earth. Satellite imagery available on Myanmar flooding as a result of Nargis cyclone May 2008. Overview Builds on Stefan Falkes and Don Sullivans enhanced WCS in which subset of data returned based on user specified AOI and time – ESTO funded

7. 7 Federated Approach Build electronic trust relationships between closed communities over the open Internet Permanent Temporary Permission policies may need to be exchanged across domains Trust relationships must be discoverable within their community trust service providers (layered) E.g. Application registered with community Openid provider and thus could check validity to see if request comes from a trusted domain as a preliminary check)

8. 8 Federated Approach Management Each community needs to manage its users and services in a satisfactory manner but not necessarily identically Provide a recognizable handle for a user or service Provide an accessible profile for user/service attributes Permission policies may need to be exchanged across domains Local trust relationships must be discoverable by local service providers Some attributes may be read-write Privacy issues (user consent to release info)

9. 9 User & Service Profile Standard organization profile Example: http://www.axschema.org/types/ (OpenID possible attributes)http://www.axschema.org/types/ One or more notification methods for delegation of authority or other notifications (SMS, instant messages) Roles/permission granted by organization (e.g. Red Cross representative can task EO-1) Some user profile attributes may be writable by outside services E.g. Digital Rights management/ License agreements Service profile (e.g client application registered so that we know it is valid) Name, description Main URL web page end point RSA public key

10. 10 Secure Transactions Data providers need to make sure that: Message transaction has not been tampered with Message has not been played back in tampering scheme Message is not encrypted Message comes in from valid service consumer Message comes from valid user User has proper permission to access the specified security realm User has delegated authority to consumer (confirmation may be necessary) User has agreed to access/license agreement

11. GSFC USGS Level 0 Processing at GSFC First operational experiment Experimental OpenID Provider (OP) Server Campaign Manager GSFC OpenID Provider (OP) Server Other Federated OpenID Provider (OP) Servers Server User from GSFC Non-GSFC User GSFC Domain Non-GSFC Workflows GSFC Workflows GSFC User

12. 12 NASA Considerations Standard trust service providers that register communities for a fee Incommon.org Levels to authentication certification Level 1 – claimed assurance Level 2 – Identity check, user id and password Level 3 – Increased level of identity check such as checking hard token and 2 factor personal ID Level 4 – Fed PIC smartcard Method of authentication and IT security evolving We are working with GSFC and NASA IT security team to input requirements and for possible collaborative security prototypes