A Web Server for Basic Grid Services D. Calvet DAPNIA/SEI, CEA Saclay Gif-sur-Yvette Cedex

Lyon 21 November 2001 GRID and WWW Functionality of a typical Web server useful for GRID: –Anonymous access, or server authentication, or mutual client and server authentication (e.g. X.509 certificates) –Plain-text or secure transfers (encryption), HTTPS over SSL –File read/write access by clients –Execute access on a server is not well defined -> the basis of the GRID can be seen as providing the « Execute » capability to the existing WWW Some basic GRID Services: servers and users authentication users authorization secure data transfers remote process creation

Lyon 21 November 2001 Providing Basic Services for Grid Dedicated packages, specific protocols –E.g. Globus and gatekeeper protocol -> viable option, main (only?) stream of work in DataGRID « Standard » Web tools –Re-use as much as one can from WWW technology –Use Web browsers as clients; HTTP(S) protocol as is –Make extensions to one of today’s web server to provide the missing parts -> this option is investigated in the present work: feasibility, proof of principle, how much effort is needed … but all code is for demonstration only (i.e. incomplete, quickly done – ~6 person month - and most likely unsafe)

Lyon 21 November 2001 Technical Choices An open-source JAVA based Web server –portability, ease of customization,… Choice: JETTY ( Hook to host computer via CGI interface –PERL scripts for interaction with host computer –C programs to wrap critical parts, system commands… -> Code runs on any UNIX-like machines Use of standard X.509 certificates for authentication –JAVA like trusted certificate management (keystore file) –or Globus/OpenSSL like certificate storage (directory of files) Off-the-shelf web browsers for clients -> Zero installation or specific program on the client side

Lyon 21 November 2001 Software Architecture CGI GUI, Server authentication Web server HTML form Perl script Execvp Upload User B adduser SUID root X.509 Certs and CRLs Client browser X.509 Certs (and CRLs) Environment variables DN allowed DN denied DN to login HTTPS User A Dynamic account setup User authorization Execvp Upload Client authentication Secure channel Process creation HTML (stdout) (stdout)

Lyon 21 November 2001 Implementation Server and Client authentication (JAVA) –Supported by Jetty without any modification -> but no check of CRLs in today’s SUN JDK classes –SUN’s X509TrustManager replaced by our own version -> support trusted Certs and CRL’s a la Globus/OpenSSL Client authorization: (PERL CGI script) –Client rights: transposed combination of UNIX flags « rwx » document read on server (all authenticated users) file upload to server (authorized users) execute command or program on server (authorized users) -> more refinements can be imagined Secure data transfer –HTTPS support in Jetty and Web browsers without any change

Lyon 21 November 2001 Implementation (con’t) Users and accounts –1 account per user: correspondence between the user’s DN and his local account provided by a mapfile –Dynamic account creation on the server if a user’s DN is not in the mapfile, is in a file users.allow and not in a file users.deny file users.allow: list of users’ DN permitted to have an account (e.g. project wide list distributed to all sites) file users.deny: list of users’ DN not permitted on this site/server (local policy enforcement) Remote process creation (PERL script and C wrapper) –return output in HTML to the client

Lyon 21 November 2001 Demonstration Top window: server; bottom window: client

Lyon 21 November 2001 Demonstration

Lyon 21 November 2001 Demonstration

Lyon 21 November 2001 Demonstration

Lyon 21 November 2001 Tentative comparison with Globus FunctionGlobus 1.1.3Proposed scheme Client software/interfaceSpecific / command lineInternet Explorer, Netscape / Graphical Single sign-onYes (grid-proxy)No Server protocolProprietary (gatekeeper)Web standards: SSL, HTML, CGI… Data transfersAuthenticated; plain-text onlyAnonymous and in plain-text (HTTP) or authenticated and encrypted (HTTPS) Information serviceGIS, GIIS, LDAP browserNot studied – adapt web search tools? Other servicesMPI support, GSI ftp, HBMDynamic login setup Platforms/OS supportlimitedClients: almost any; servers: UNIX-like Critical part for securityDaemon running as rootHooks to some SUID commands Development effort10’s of person-year0.5 person-year Deployment effortAdministrator and user trainingWeb server administration

Lyon 21 November 2001 Potential of proposed approach Pros –Minimum effort by extensive re-use of web stuff –Reduced dedicated package to develop, install and maintain –Web servers and browsers are ubiquitous and come by default with any modern OS –Software companies could extend the scope of their web products in the direction of the GRID (if there is a market…) Cons –Proof of principle is easy, but obstacles may be found later –Introduces security weaknesses in web servers –Relies a lot on software industry (will they do what we need?) –Clients tight to a Web browser (no access via console, batch) –The GRID is much more than the basic services mentioned –For DataGRID, orthogonal to the approach based on Globus

Lyon 21 November 2001 Summary Today’s Web stuff could be the basis of the GRID –Anonymous or authenticated accesses –Clear or encrypted data transfers –File read/write access by clients on a server Adaptations around a JAVA-based Web server showed –Server and client authentication with X.509 certificates/CRLs –Dynamic computer account creation on server for authorized remote users (or use of an existing account) –File upload, program execute for authorized remote users –Data stream encryption between client and server –Client software: off-the-shelf web browsers Paper submitted to CCGrid2002 as a personal contribution