This attempts to extract/summarize the requirements for the stream API defined by the various use cases. I yanked all paragraphs that described the usage of remote sockets/streams from the various use cases and consolidated them in this document. I then summarize the requirements. Most of the requirements focus on simplifying the authentication/authorization for IP socket connections. The security models that must be supported include GSI, Unicore, SSL, and WSRF. The languages that must be supported are Fortran, C, C++, and native java (some indicated JNI was sufficient, but others seem to require native java). -------------------------------- Relevant use cases UC-2 : DiVA UC-3 : DRMAA UC-4 : GridLab UC-5 : KoDaVis UC-7 : RealityGrid UC-9 : Visit UC-10 : VizService -------------------------------- Summary of Requirements Extracted from these use cases UC-2 : DiVA Usage: For adjusting parameters on remotely launched components Functional Requirements: Simplify Authentication and encryption of streams. Sec Model: SSL and/or GSI Stream Types: IP sockets Languages: C/C++ bindings (wrapped to provide TCL and Python bindings) UC-3 : DRMAA Usage: Not certain (seems to have remote vis requirement) Functional Requirements: ? Security Model: ? Stream Types: IP sockets (probably) Languages:Java/C/C++/Fortran UC-4 : GridLab Usage: Remote connect and steering of applications Functional Requirements: Authentication, tunnel through firewalls (not in use case though) substrate for higher level steering interface abstraction. Security Model: GSI ? Stream Type: IP sockets Languages: Java/C/C++/Fortran UC-5 : KoDaVis Usage: Remote connect for visualization of large data. Collaborative/multiuser/syncrhonized vis Functional Requirements: Authentication and simpler socket/stream abstraction Support for multiuser/collaborative interfaces - login mechanism for connecting to data- and interaction-server - data exchange (send, receive) for the scientific data - data exchange to synchronize the collaborative, distributed session - naming mechanism to identify objects which are shared between several visualization systems Security Model: unkown Stream Type: probably IP sockets Languages: Java/C++/C UC-7 : RealityGrid Usage: Remote steering/visualization of running simulations Functional Requirements: Authentication (potentially encryption) substrate for higher-level parameter/steering interface. Security Model: GSI (embedded in tools layer) Stream Type: IP sockets Languages: JNI-Java C++. Instrumenting C/C++/Fortran codes UC-9 : Visit Usage: Remote monitoring and visualization of running simulations using AVS/Express (ParView) Functional Requirements: Authentication multiple connect/disconnect of clients Security Model: Unicore Stream Type: IP sockets Languages: F90/C/C++ . Interfaces to AVS/Express UC-10 : VizService Usage: Remote connect and visualization for large scale simulations Functional Requirements: Authentication/authorization multiple connect/disconnect of multiple clients targeting a higher-level steering interface abstractions Security Model: Now Unicore and/or Globus as middleware. Later, any OGSA or WSRF implementation will do. Stream Type: IP sockets Lanaguages: Fortran/C/Java ===================================================== Raw Text: Extracted all paragraphs relating to stream requirements for the different use cases. ===================================================== ===================================================== UC-2 : DiVA ===================================================== Vis application developers are spending 80% of their time on wrangling transport, job launch, and security issues. This is particularly difficult because most the issues involved in transport, job-launching, and security are outside of the visualization application developer's core expertise, so these tasks take a long time and the developers do a poor job of it. f) The components will need to establish secure socket links where they are not located in the same memory space. In some contexts, this may only be authenticated socket connections, but other contexts require the sockets be encrypted as well. f) Connecting the Components Together: Once the components are "launched," the components that reside on different machines need to be able to communicate with one another via network sockets. This leads to both security and performance considerations (discussed below). Secure Sockets Abstraction: The state-of-the-art use of sockets for remote visualization depends on security practices that are largely debunked as "unsafe" by our security professionals. Most distributed visualization application developers presume that if components were launched securely, the sockets that connect these components together are also secure (who could guess the port number and startup time... its security through obscurity). This is clearly not safe, but the level of effort necessary to move to simple authenticated sockets is considerable (it is not practical to expect vis people to do this). At minimum, a new TCP socket must exchange an "shared secret" in order to make sure the connection is "authentic". If there was a single call to "OpenAuthenticatedSocket (host,port)", then that would be very useful. Likewise, an "OpenEncryptedSocket ()" would be useful in other circumstances. For instance, SGI's VizServer does not encrypt the socket used to convey your login & passwd to connect to the server (its as bad as telnet). File directory listings probably should be encrypted. This should just be targeted at a single TCP socket. We can use GridFTP for performance, but we really need to get the control sockets protected. Visualization application developers typically use C/C++ to implement applications. However, Python, TCL, and Java are increasingly popular for assembling applications that use components that are written in native C or C++ (for instance VTK supports wrapping in any of those bindings). The services should be accessible using C and C++ bindings as a baseline. Those bindings can typically be wrapped so they are accessible in any of the above scripting languages. If we can, at minimum, simplify the API calls required to establish an authenticated socket and even make it simple to establish an encrypted socket (even for low-bandwidth), that would fullfill that requirement. Distributed visualization applications need to meet the bare minimum security standards (something that most currently do *not* do). In most of the scenarios we have constructed, the security needs primarily involve supporting proper authentication in order to connect components together. Authorization is primarily required if a component is actually a persistent service that is not running as the same UID as the user who constructed the workflow. We try to set up the bulk of DiVA valid use cases so that the components are running as the user's UID in order to sidestep such cases as much as possible. The socket traffic for GUI events and component execution does not typically need to be encrypted, except in rare cases such as passing privileged information (encryption keys or passwords). It is important that the security API interact nicely with SSH. When GSI/PKI certs are not available, ssh works quite well. While the single-sign-on abilities of GSI are extremely important, many have found that ssh combined with ssh-auth can do a reasonably good job of emulating the same ability if used as a last resort. This should *not* be ignored (this consideration should be taken into account when designing these APIs). // support for simple authenticated TCP sockets SAGA_OpenAuthenticatedTCPServer (securityhandle, portnumber); SAGA_OpenAuthenticatedTCPSocket (securityhandle, host, port, passwdcallback); // where passwdcallback gets a passwd // if needed in order to support // SSL/TLS security models. // support for simple encrypted TCP sockets SAGA_OpenEncryptedTCPServer (securityhandle, portnumber); SAGA_OpenEncryptedTCPClient (securityhandle, portnumber, passwdcallback); ===================================================== UC-3 : DRMAA ===================================================== There were 120 remote computational nodes and few client nodes with good graphics support. The application was done in Fortran and C. Part of the distributed solution was implemented in Java. 8.3 What are your security needs: authentication, authorisation, message protection, data protection, anonymisation, audit trail, or others? Authentication mostly. ===================================================== UC-4 : GridLab ===================================================== - remote steering or monitoring systems 8.3 What are your security needs: authentication, authorisation, message protection, data protection, anonymisation, audit trail, or others? authentication, authorisation, basic data protection ===================================================== UC-5 : KoDaVis ===================================================== Because the resulting dataset is very big, (about 1GB) it cannot be stored locally but only at one or more central servers.There is a demand to visualize this data to analyse it. To do this, the visualization systems must be coupled to the data servers by a fast network to get online access to the data. All changes in the scene are synchronized online by the interaction server which guarantees a consistent visualization to allow a well coordinated collaborative work session. It also could happen that an additional scientist will enter a running session. In this case the actual scene has to be distributed to this new client. The visualization systems will load an initial scene, connect to the data- servers and request a portion of the data, e.g. a time interval of interest or data for a selection of chemical tracers. The data which is send over the network is sensitive. There should be access restrictions and authentication. 8.3 What are your security needs: authentication, authorisation, message protection, data protection, anonymisation, audit trail, or others? Authentication. 8.4 What are the most important issues which would simplify your security solution? Simple API, simple deployment, integration with commodity technologies. An api which provides a reliable certification mechanism to authenticate a user who connects to the system. What are the things which are important to scalability and to what scale - compute resources, data, networks ? Network is very important to scale up the number of possible participants of a collaborative visualization session. No details can be given now because the project is in an early stage of development. The API should have the following functionality: - login mechanism for connecting to data- and interaction-server - data exchange (send, receive) for the scientific data - data exchange to synchronize the collaborative, distributed session - naming mechanism to identify objects which are shared between several visualization systems ===================================================== UC-7 : RealityGrid ===================================================== The use case common to all applications is the "computational steering" of the code. However "computational steering" is a broad term and incorporates many ideas. At the simplest level, computational steering involves the ability to monitor the evolution of the system under study, and to manipulate parameters that affect the system's behaviour. f. Visualize one or more aspects (e.g. physical fields) of the running simulation - on-line visualization m. Realtime analysis of live streams of data emitted from a simulation (this is a generalization of the concurrent visualization requirement in (f)). Steering clients exist in several flavours: * The Qt/C++ GUI for workstations uses the client-side functions of the RealityGrid Steering Library. * A .NET client suitable for PDAs is tooled against the WSDL description of the RealityGrid Steering Grid Service and Service Registry. * A Java client packaged as a GridSphere Portlet is tooled against WSDL. * A Java client in the ICENI framework has been built against the Steering Library using JNI. GSI (but this is not built into the application, but into the tools layer). Security of the middle-tier services used for computational steering is currently lacking, due largely to the absence of a standardised security model that supports delegation in a Web service world. Message and data protection matter, but are not urgent (however some industrial collaborators take a different view). ===================================================== UC-9 : Visit ===================================================== The progress of the running simulation can be monitored by ParView, an AVS/Express based application that allows an online-visualization of the coupled simulation. Among the steering capabilities of ParView are the ability to insert solutants into running simulations and the ability to select 3D-points in the simulated area for which more detailed data analysis and recording is required (so called break-through curves - BTC). visualization can be dynamic, attachment to a simulation from different systems with different capabilities (performance, network bandwidth) The simulation establishes a network connection to an external application (the visualization/steering application) and is controlled by it. Therefore the steerer needs to authenticate properly. Besides that, there are no special security considerations. 8.3 What are your security needs: authentication, authorisation, message protection, data protection, anonymisation, audit trail, or others? authentication and authorisation of the steerer. Here an example of the simulation (client) API of VISIT: /* attach to a visualization, using a service-name and a password */ vcd = visit_connect_seap(servicename, password, timeout); /* send some data */ visit_send(vcd, tag, timestanp, data, datatype, dimensions); /* receive some data */ visit_recv(vcd, tag, ×tamp, data, &datatype, &dimensions); /* detach from visualization */ visit_disconnect(vcd); *********server API /* init connection for application 'trace' */ lvisit_trace_init(); while (SimTime) { /* test connection, open a new one if necessary */ lvisit_trace_check_connection(); /* receive parameters from visualization in application structure 'parm' */ lvisit_trace_parm_recv(&parm) /* send 3d vector data 'velo' (which is distributed) to visualization */ lvisit_trace_velo_send(&velo,nx,ny,nz,3); } /* close the connection */ lvisit_trace_close() ===================================================== UC-10 : VizService ===================================================== This API serves to connect two remote systems client and server by the grid medium and offers the client a set of tools to perform visualization of large-scale simulations. The visualization is based on images transferred from the server to the client and visualization controls sent by the client to the server. - Send visualization control commands and receive a sequence of images back (streaming capability). [common] - Steer the simulation/application (pause, stop, resume, etc). [concurent] - Plug-in or Plug-out from a running simulation without affecting it. [concurent] - Real-time tracking of simulation parameters. [concurent] // Generate an instance of Concurrent service. VisualizationService cvs = VisualizationServiceFactory.newInstance (CONCURRENT_SERVICE, ...); // Get the visulization streeming. Images or image sections are // streamed on an input stream. InputStream vizInput = cvs.getInputStream ();