SensorWebs and Security Experiences

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

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 2 Secure transactions Organization Orchestrating Workflow Web Coverage Service (WCS) Sensor Planning Service (SPS) Web Processing Service (WPS) 3 Delegation 1 Single sign on

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

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. • Builds on Stefan Falke’s and Don Sullivan’s enhanced WCS in which subset of data returned based on user specified AOI and time – ESTO funded Satellite imagery available on Myanmar flooding as a result of Nargis cyclone May 2008. Overview

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. 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. User & Service Profile • Standard organization profile • Example: http://www.axschema.org/types/ (OpenID possible attributes) • 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. 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. First operational experiment USGS User from GSFC GSFC Workflows Non-GSFC User Level 0 Processing at GSFC GSFC Experimental OpenID Provider (OP) Server Campaign Manager GSFC Domain Other Federated OpenID Provider (OP) Servers Server GSFC User GSFC OpenID Provider (OP) Server Non-GSFC Workflows

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